Boat Optimal Availability Time Simulation
Executive Summary / TL;DR
For logistical simplicity, the Coast Guard leverages a shared small boat across multiple different asset types. To streamline planned maintenance on these shared small boat assets, the Coast Guard developed a centralized pool to send the assets to where highly specialized mechanics can perform the maintenance. And Coast Guard units can receive fully operational small boat assets from the pool, alleviating unit technicians from performing specialized depot-level maintenance and increasing the unit’s operational availability. The Boat Optimal Availability Time Simulation (BOATS) will provide recommendations for the rotatable boat pool with regards to pool size and sustainability of Coast Guard missions and operations. Utilizing simulation best practices, the BOATS model determined a minimum boat pool size of 90.
Dave Kent, Joe Kidwell, Sara Peeleman, Landon Pogue
1.0 Motivation and Problem Description
The United States Coast Guard (USCG) commonly utilizes a single small boat asset in association with mission support across multiple classes of cutters. The small boat used most frequently is the Over-The-Horizon (OTH) cutter boat. The OTH is favored throughout the USCG for its capability and in promotion of consistency. Synchronized with the ideas of consistency of capability and qualified operators is the idea of consistency in asset depot-level maintenance. To standardize planned OTH depot-level maintenance, the USCG developed the Cutter Boat Pooling Program (commonly referred to as “Boat Pool”).
The Boat Pool program consists of a rotatable pool of OTH cutter boats and their associated trailers. The purpose of the program is, “To increase operational readiness and eliminate the impact of depot-level maintenance on operational availability” (Melvin, 2017). Generally, upon return to homeport, Cutter crew members are responsible for returning the OTH assigned to the cutter to a central pool of OTHs to ensure completion of depot-level maintenance in accordance with appropriate periodicities. Then, prior to the cutter’s scheduled departure for patrol, a fully mission capable OTH with 100% maintenance completion will be provided from the boat pool for operation. The intent of the boat pool program is to repeatedly supply fully mission capable OTHs while minimizing the amount of time a specific OTH spends within a non-mission capable status for depot-level maintenance (Melvin, 2017).
The primary motivation for the Boat Optimal Availability Time Simulation (BOATS) is to provide recommendations for the rotatable boat pool with regards to pool size and sustainability of USCG missions and operations. This problem is ideal for simulation due to the length of time associated with identifying lost operational days for the Coast Guard. One year of time accounts for only two to three cutter patrols or just one OTH depot-level maintenance availability. Similarly, the data generated from just one year of operations and depot-level maintenance is minimal, resulting in a wide range of variance in an area where variation tolerance is very low. Through simulation, we can gather results and can simulate many years in the process. This enables a high level of confidence in results and does not impractically extend USCG resources. While controlled experiments on the actual boat pool would extend actual USCG resources.
1.1 Simulations Measurements
The key model parameter to be investigated through simulation is the loss of operational days due to a lack of availability of fully mission capable OTHs. Other model parameters will include the average number of non-mission capable OTHs in the depot-level maintenance boat pool and the average length of time (in days) that an OTH spends within the depot-level maintenance boat pool. Similarly, the average number of OTHs set as fully mission capable within the centralized boat pool and the length of time an OTH spends in the boat pool designated fully mission capable will be additional model parameters.
Following collection and analysis of output data from the simulation, recommendations for the minimum boat pool size needed to maintain a fully staffed OTH fleet among all cutters, and the optimal boat pool size based on different operational demands (OPTEMPO) will be provided. A sensitivity analysis will be conducted to determine how increasing or decreasing the OPTEMPO affects the required boat pool size.
The assumptions utilized in the model provide a schema for simulation initialization, allow for a concise statement of business rules, and identify system characteristics.
2.1 List of Assumptions
The simulation utilized the following list of assumptions:
- The age of simulated OTH craft are initialized based off one OTH delivery weekly during the initial acquisition period of he simulation.
- Initially, OTH craft are no more than 90 days late to start depot-level maintenance.
- Travel time to the maintenance pool is independent of the host cutter’s geographic location (homeport).
- OTH craft are not sent to or requested from the pool by a deployed cutter.
- Depot-level maintenance resources are sufficient to prevent additional maintenance delays.
- When a cutter’s deployment is delayed, the deployment is shifted to the right rather than being cut short.
- The USCG does not change its OPTEMPO or patrol lengths during the ten-year simulation period.
- Fast Response Cutters (FRCs) are not required to send their OTHs to the maintenance pool unless their OTH requires maintenance.
2.2 Explanation of Assumptions
Assumption 1 assigns a realistic spread in ages to OTHs at the beginning of the simulation rather than having all OTHs initialized with the same age. For this simulation, age is defined as the time since the last maintenance was completed and serves as the trigger for requiring maintenance. Assigning a spread of OTH ages prevented the simulation from requiring a long warm up period in order to realistically distribute OTH maintenance demands.
Assumption 2 caps the initial age of OTHs 455 days. This cap prevented a long list of OTHs from requiring maintenance at the onset of the simulation.
Assumption 3 prevents over-complication of the model. Additionally, the required lead time for an OTH prior to a cutter patrol would make the travel time differences insignificant.
Assumption 4 prevents the use of the OTH maintenance pool as a source of a replacement OTH for cutters that experience an OTH casualty an impossibility. This assumption prevents complication to the model with little value add (based on the infrequent occurrence of OTH casualties).
Assumption 5 codifies changes in resource availability were not considered in BOATS. This assumption is well supported by the fact that resource allocation for OTH maintenance is contractually controlled.
Assumption 6 prevents unrealistically short cycling a cutter and OTH.
Assumption 7 prevents complication of the model. In general, during a ten-year period it is expected the USCG would surge its OPTEMPO to account for national security concerns. The severity of this assumption was limited in the study by varying OPTEMPO and patrol lengths as part of the experimental design. Thus, an OTH strategy accommodating the continual strain of USCG assets for a ten-year period was selected and the Boat Pool should be capable of responding to a temporary strain and increased stress levels.
Assumption 8 prevents unnecessary OTH transactions on the model. It is imprudent to require FRCs to send their OTHs to the pool upon arrival to homeport because doing so provides no added benefit. There is no added benefit because FRCs would immediately generate a demand for an OTH. A demand that could be met by the OTH they just shipped.
3.0 Input Data Analysis
Small Boat Product Line within Surface Forces Logistics Center documents depot-level maintenance availability times. Data from 2008 through 2018 was available for analysis to generate depot-level maintenance times for each OTH upon their entry into the depot-level maintenance pool. Figure 1 shows a histogram of the depot-level maintenance time data.
Upon visual inspection, the maintenance times may be approximately modeled by either an exponential, gamma, or lognormal distribution. Using maximum likelihood estimation (MLE), the maintenance times best fit:
- An exponential distribution rate 0.0128435.
- A gamma distribution with shape 2.5276123 and rate 0.0324585
- A lognormal distribution with mean 4.1442946 and standard deviation 0.7078441
The goodness-of-fit statistics for the maximum likelihood estimation exponential, gamma, and lognormal distributions are given in the table below:
The gamma distribution has the best Kolmogorov-Smirnov statistic, AIC, and BIC. A gamma distribution with shape 2.5276123 and rate 0.0324585 is used to model the OTH depot-level maintenance times for simulation.
4.0 Simulation Description
BOATS is written entirely in Visual Basic Application (VBA). Many decision-makers prefer to see results in Excel and VBA makes it simple to output simulation results to a spreadsheet. People without a technical background are usually familiar with Microsoft Excel, which makes it easy to convey results. This is especially true for military decision-makers. There were drawbacks like computation time and random number generation control, but the benefits of VBA made it the right choice for BOATS.
4.1 Computation Time
BOATS does suffer from computation speed limitations. At around 2-2.5 seconds per replication it takes about 40 minutes to run 1000 replications. The experimental design calls for over 300 scenarios requiring 1000 replications each to reach the desired accuracy. This comes to nearly 70 hours of computing time and over 3 million years of simulated time.
4.2 Random Number Generation
VBA lacks a way to control the pseudo random number generation seed. This presents the potential to impact results if a model run were to run through all the numbers in the pseudo random algorithm. For this to occur, it would require a set of 1,000 replications to use more than 231 random numbers.
One BOATS replication requires the following numbers to be generated:
- Each Cutter needs a random number to determine its scheduled length of time in-port or deployed. A cutter needs ten years of schedule time (3,652 days). Classes of cutters have different schedule parameters. Average patrol length/in-port periodicity for large class cutters are approximately every 90 days. 3,652 days (ten years) divided by 90 days results in 41 random numbers generated per large cutter schedule. There are 45 large class cutters. So, 41 multiplied by 45 results in 1,845 random numbers. Average patrol length/in-port periodicity for patrol boat class cutters are approximately every 21 days. 3,652 days (ten years) divided by 21 days results in 174 random numbers generated per patrol boat class cutter. There are 18 patrol boat class cutters. So, 174 multiplied by 18 results in 3,130 random numbers. In total, 1,845 random numbers plus 3,130 random numbers results in a requirement for 4,975 random numbers to generate cutter schedules.
- Maintenance periods for OTHs also require random numbers. An OTH will go to the depot-level maintenance boat pool once per year. So, ten random numbers per 100 OTHs totals 1,000 random numbers. Therefore, the total number of random numbers is about 6,000 random numbers. For 1,000 replications, this would require approximately 6,000,000 random numbers
These results are well below the threshold of 231 random numbers, eliminating the concern of a lack of a random number generator seed control impacting the results.
4.3 Model Flow Diagram
The steps in the BOATS model corresponding with Figure 2 are as follows:
4.3.1 Initialize Simulation
The initialization process creates all cutters based on user defined parameters. Each cutter has a 0.5 probability to initialize as deployed, or in-port. If a cutter begins deployed, then it writes a random number to be the day it returns. Since it is not determined in initialization how long the cutter started the deployment, this first schedule item is distributed uniformly with Uniform(0, upper bound schedule parameter). The same process is used for cutters initialized in-port.
The initialization process creates all OTHs. The total number, or pool size, is user defined. OTHs are initialized with a hull number, and age. The hull number is a unique identifier for each OTH. The age is determined by: (index)7 mod 455. This models one OTH delivery each week and no OTH is more than 90 days out of its maintenance periodicity, which is an appropriate mix of OTHs in the pool that require maintenance, and those that do not require maintenance.
All OTHs are then assigned. Each cutter deployed receives the appropriate number of OTHs. OTHs that require maintenance are assigned to the non-mission capable (depot-level maintenance) pool. Fully mission capable OTHs are assigned to the fully mission capable pool.
4.3.2 Determine Cutters Arriving and Departing Based on Randomly Generated Schedules
If a cutter is arriving or departing on day i, it enters the following logic.
4.3.3 Arriving Cutters Send OTHs to Boat Pool
Arriving cutters send their OTHs to the Boat Pool: a) OTHs that do not require maintenance go to the fully mission capable pool, b) OTHs that require maintenance go to the non-mission capable pool.
The above does not apply for FRC class cutters. These are Patrol Boat class cutters and are deployed much more frequently than larger cutters. When a FRC arrives it only sends its OTH to the pool if it requires maintenance, and immediately requests a new fully mission capable OTH. This models the real-world requirement for the FRCs to keep a fully mission capable OTH on hand. FRCs are often requested to respond to local search and rescue cases and opt to use their small boat rather than deploy the cutter itself.
When an OTH’s maintenance is complete, it is immediately shifted to the fully mission capable pool and is available for deployment.
4.3.4 Departing Cutters Request OTHs from the Fully Mission Capable Pool
Departing cutters request the appropriate number of OTHs from the fully mission capable pool. These requests are made 45 days in advance of the actual scheduled departure date. This models transit time from the pool to the cutter’s homeport, and about two weeks of time for the cutter to accept the transfer, complete any required trainings and other pre-deployment activities.
If there are not enough fully mission capable OTHs in the pool to support the request, then the cutter’s deployment is delayed. The cutter will shift its deployment date to the next day an OTH is available and log the delay for statistics gathering.
4.3.5 Statistics Gathered/Recorded/Updated
Statistics are gathered. Statistics are logged and gathered in many parts of the flow, but it is shown this way for diagram simplicity.
4.3.6 Time Advance
Advance the clock one day. Return to step 1 until runtime is reached.
Advance the clock one day. Return to step 1 until runtime is reached.
4.4 Time Step vs Event Step
The BOATS model is written as a time step simulation with a time unit equal to one day. Rewriting the simulation to event step would improve computation time. Nevertheless, the time step simulation is manageable.
4.5 Description of Classes and Selected Properties and Methods
The BOATS model contained five class modules: OTH, cutter, cutterCollection, OTHCollection, and a queue class.
Through interviewing the Coast Guard’s Small Boat Product Line Manager, it was discovered the non-mission capable pool behavior was not appropriately modeled with a first come, first serve (FCFS) queue. Projects are addressed dynamically in actual shipyard operations. For example, the manager knows there is going to be a request for an OTH in the next 30 days. The manager would not prioritize a ninety-day OTH project because it arrived before a fifteen-day project. They would complete the fifteen-day project so they could meet the request. The data collected reflects this process. So, when an OTH is assigned to the non-mission capable pool it generates a maintenance time independent of the OTHs ahead of it as it would in a classic FCFS queue. This obviated the use of the queue class. The non-mission capable and fully mission capable pools are implemented as OTHCollections instead of queue classes. For this reason, the queue class is not discussed, however it operated as a simple queue class to.
The OTH class module gives the OTH properties such as age, which is the number of days since its last completed maintenance, maintenance status, and attachment to a cutter. The cutter class module defines cutter properties such as the class of cutter (NSC, HEC, MEC270, MEC210, or FRC), the number of OTHs required, and upper and lower bounds on deployment length. The OTHCollection and cutterCollection class modules are identical except for a few unique needed methods. Further information on the OTH and cutter class modules as well as the OTHCollection and cutterCollection class modules can be found in Appendix A.
4.6 Description of User Defined Parameters
4.6.1 Patrol Schedule Bound
The lower and upper bounds define the end points for random schedule generation. The default values are defined in the code and can be changed by the user for each class of cutter. Cutters generate an in-port or deployment period by generating a uniformly distributed discrete random number with ~Uniform(lower bound, upper bound).
4.6.2 OTHs Required
OTHs required is the number of OTHs required for a cutter to be considered ready to deploy. If this number of OTHs are not available from the pool, then the cutter is delayed. This can be adjusted for each class of cutter.
OPTEMPO is an abbreviation used by the Coast Guard for Operational Tempo. As applied to cutter schedules, it represents the proportion of time that a cutter spends deployed to its total time. So, with an OPTEMPO of 0.5, a cutter’s expected time in-port equals expected time deployed and an OPTEMPO of 0.7 means that total deployed time divided by total time is approximately 0.7.
To make this OPTEMPO affect the proportion of deployed time we created a function that modifies the upper bound of each patrol schedule:
- Let a be the modifier we need.
- Let b be the desired OPTEMPO (0 < b < 1).
- Let u be the upper bound of a cutter schedule.
- Let l be the lower bound.
An unmodified proportion is an OPTEMPO of 0.5:
The numerator represents the expected deployed time, and the denominator represents the expected deployed time and expected in-port time. 1/2 is factored out on the left-hand side.
Introduce a as a scalar of u (only for the deployment lengths) to have the desired effect on the right-hand side.
Now solve for a as a function of b resulting in:
a will now be the desired scalar to shift the upper bound parameter to achieve the specified OPTEMPO. When the next arrival dates are calculated (deployment length) the upper bound is multiplied by a, which sufficiently changes the expected deployment lengths.
4.6.4 Boat Pool Size
The size of the boat pool establishes the total number of OTHs in the system. Preliminary runs revealed a boat pool below 75 OTHs was completely untenable for a system of 54 cutters. Also, it is not possible to run the simulation with fewer OTHs than there are cutters in the system because how they are initialized would cause a runtime error. We did not consider pool sizes larger than 125 which is the current order the USCG has for OTHs.
The default runtime for the simulation covers a ten-year period (3,652 days). It is based on the procurement cycle for boats of this type. Platforms like the OTH, experience an expected hull life of fifteen years. Procurement for a project of this size usually begins five years ahead of the asset being delivered. Additionally, we did not want to extend the scope of the project to include assets breaking down irreparably by making the runtime longer than the expected hull life of the OTHs. If the user desires, runtime can be adjusted to any positive value.
The number of replications does not impact pool performance. It is only a tool to batch replications with the same set of parameters.
4.7 User Interaction
The BOATS model features a fairly simple user interface where OPTEMPO, Pool Size, Runtime, and Replications can be manually entered by the user. The input values are used once the user presses the RUN button. When left blank, the default simulation run values for the fields are: OPTEMPO = 0.5; Pool Size = 100; Runtime = 3,652; Replications = 10.
The right-hand of the parameter input window (shown in Figure 3) displays the default cutter configurations for each class of cutter. To update a cutter’s parameters, the user must select its specific tab and enter the new lower bound, upper bound and OTHs required. The user input form checks for appropriate data type entries in these fields to avoid runtime errors. The user must then press the Update Configuration button for the change to be reflected.
Table 2 below displays the default values in the simulation.
|Cutter Class||Patrol Lower Bound||Patrol Upper Bound||OTHs Required|
The data generated by each simulation will be output to a new Excel worksheet. Parameters are recorded and printed on the left for each run, and the notable summary statistic Excel formulas are written onto the worksheet.
5.0 Output Analysis
Several pilot runs were performed to determine the number of replications required to support the desired accuracy. Following the determination of replications, several data runs were performed in accordance with a parameter variation strategy. Based on the results of these data runs, an appropriate number of OTHs were selected to support Coast Guard tasking with no expected lost operational days.
5.1 Pilot Run Analysis
Pilot runs consisted of forty replications performed at 50%, 60%, and 70% OPTEMPO with 50, 60, 70, 80, 90, 100, and 125 OTHs in the pool using an average patrol length of 90 days for NSCs, 90 days for HECs, 90 days for MEC270s, 70 days for MEC210s, and 21 days for FRCs.
Our accepted error for Lost Operational Days was one percent with an acceptable absolute error of one day for the fully mission capable queue time, non-mission capable queue time, and average operational delay event time. Using these standards, the required number of replications for each data run is calculated. The maximum number of replications for each number of OTHs was then selected as the number of replications that would be performed for any further data runs using that pool size. The number of calculated replications is given in the table below.
|Number of OTHs||Replications|
Additionally, the mean number of lost operational days for each number of OTH for each OPTEMPO as analyzed to determine a lower OTH bound for the experimental procedure. Table 4 shows the data obtained.
Preliminary Data: Average Lost Operational Days
|OPTEMPO||50 Boat Pool||60 Boat Pool||70 Boat Pool||80 Boat Pool||90 Boat Pool||100 Boat Pool||125 Boat Pool|
Due to a USCG requirement to be able meet all planned patrol tasking, no further data runs using less than 80 OTHs would be required. Thus, the experiment utilized 1,000 replications regardless of pool size.
5.2 Parameter Variation Strategy
Runs of the BOATS model using 80, 90, 100, and 125 OTHs over 50%, 60%, and 70% OPTEMPO over several proposed patrol length schedules were completed. The table shows what average patrol lengths were considered for all OPTEMPOs and OTH boat pool sizes.
Average Deployment Length
6.0 Conclusions and Recommendations
6.1 Recommendations to the United States Coast Guard
The USCG could downsize the OTH boat pool to 90 OTH assets. Pool sizes of 125 and 100 can support any schedule/OPTEMPO variation. This was an expected result based on pilot run results.
6.2 Recommendations for Further Study
Study of the USCG boat pool operations can be expanded. Particularly in the area of cost-benefit analysis for modifications to pool operations.
For instance, can boat pool performance be improved or OTH pool size be reduced by introducing regional maintenance centers as opposed to a single nationwide center? This would require a more detailed understanding of the operating costs and dynamics of shipyard operations, costs of establishing a new maintenance center, and shipment time and costs. The BOATS model can be built upon to include costs and variable shipment times to answer questions like these.
Simplified assumptions were implemented within BOATS. Additional information could eliminate many assumptions:
- OTH ages could be initialized with actual data.
- Travel time could be made variable from each homeport to the maintenance center.
- The occurrence of OTH breakdowns, requiring a new request be made from the fully mission capable pool could be modeled.
- Schedule parameters could be dynamically adjusted to better approximate real-world cutter schedules.
- The occurrence of irreparable breakdowns could be modeled, removing an OTH from the pool entirely.
The BOATS model set out to answer a relatively basic question: how many OTHs are required in the boat pool to meet all USCG system requirements? This is appropriately answered by the BOATS model determining a minimum boat pool size of 90.
With this in mind, the BOATS analysis provides a lower bound for OTH pool operations. If the budget for the OTH acquisitions could only support buying a total of 75 OTHs, BOATS could be used as justification to show a need to buy at least fifteen more OTHs for a minimum of 90 in order to meet Coast Guard operational requirements.
A.1 OTH Class Module
- Age: the number of days since it completed its last maintenance.
- MaintenanceStatus: Boolean, true is fully mission capable, false is non-mission capable.
- Attached as Cutter: the cutter the OTH is stationed with, null if in a pool.
- MaintLength: holds the day on which the OTH’s maintenance will be completed.
- TimeInFMCPool: used for gathering fully mission capable time statistics.
- Returns a Boolean for whether the OTH needs to go to the non-mission capable pool or not.
- makeMaintenanceLength(i as Integer) as Integer
- Returns a random number based on a fitted distribution of the data. ~Gamma(RND(), 2.528, 30.769) + day i)
- This is the day in the simulation on which this OTH’s maintenance will be completed.
A.2 Cutter Class Module
- intType: contains an integer from 0 to 4 that describes the class of the cutter.
- NSC = 0; HEC = 1; MEC270 = 2; MEC210 = 3; FRC = 4.
- OTHreq: the number of OTHs a cutter requires to be deployable. This parameter is user defined.
- lb and ub: the lower and upper bounds on deployment schedule parameters which are user defined.
- OTHattached: the number of OTHs assigned to the cutter.
- OTHCollection: holds the cutter’s OTHs.
- arr and dep: arr holds the date of next arrival if deployed, and dep holds the date of the next departure if in-port.
- delayEvent: records the length of a delay event.
- Writes the next arrival based on the current day, lower and upper schedule bounds, and OPTEMPO parameter.
- Adds ten days to account for travel time of the OTH to the pool.
- Writes the next departure based on the current day, and lower and upper schedule bounds.
- This modifies the upper bound of the schedule parameter to create the proper proportion to meet the OPTEMPO parameter.
A.3 OTHCollection and CutterCollection
- These classes are written over the VBA object collection and is the only property of these classes.
- Looks through all cutters in the collection and returns the lowest departure/arrival as appropriate.
- Looks through the OTH’s in the collection and returns the lowest date that the maintenance will be completed.
- returns the index position in the collection of the OTH that has the lowest maintenance completion time so the correct OTH is removed.
These views are mine and should not be construed as the views of the U.S. Coast Guard.