Introduction
Last time we outlined the analysis of cable installation operations for a hypothetical operation at WaveHub. We looked at the map and the shelter characteristics of the vessels we intend to use and outlined the main objective of the analysis, which is:
“When should we take the trenching vessel on hire, relative to the installation vessel?”
In addition we sketched out our operations, at quite a high level, ahead of putting them in to Mermaid, this sketch is shown below:
In this post we are going to look at how we can model these operations in Mermaid and consider, in a little more detail, how we vary the length of the lay and trench operations.
Modelling in Mermaid
The challenge
Our mobilisation, trials and demobilisation tasks occur once during the whole operation. The lay and trench operations, and associated reload and crew change operations need to occur across the array, which is comprised of 35 cables. A simple model would outline the associated operations and repeat the containing group a sufficient number of times, however this approach makes a few assumptions:
- That each cable lay operation takes the same amount of time (i.e. the distance we lay over is always the same);
- That each trench operation takes the same amount of time (i.e. the distance we lay over and the geology of the seabed is always the same);
- That we restock our vessels on every loop, or (if we nest repeating groups in other repeating groups) at a constant frequency;
- Similarly, that our crew changes take place on every loop or at a constant frequency.
These assumptions are unacceptable for this work, the operations vary in length due to the changes in distance and geology and our restocks and crew changes are similarly affected. Therefore we need to consider a different way to model these activities.
Option 1: Model every task
We could build a flow diagram where every single task to be performed is specified individually. By doing this we do not take advantage of Mermaid’s ability to repeat tasks and groups. Since there are 665 separate items in the operation plan (when we loop across the array) it quickly becomes apparent that this is a very inefficient way of modelling this operation. In fact, not only is it inefficient it is also dangerous and difficult to maintain as the size of the diagram grows and our ability to control our operation decreases. We really shouldn’t take this approach to modelling this operation.
Conclusion: Bad, don’t do this.
Option 2: Use occasional tasks
Mermaid has the option to include occasional tasks and groups in an analysis, these are operations which are only performed on some repeats of a parent group. More information regarding occasional tasks can be found in the posts here, here and here.
This analysis can make use of this type of task. Firstly we can set the reload operations to only occur on some of our 35 repeats. Secondly we can specify each lay operation and each trench individually and set the occurrence to once on the relevant repeat (shown below), this allows different length tasks to be specified.
By doing this we generate the diagram below. Here we have significantly less than 665 task cards to represent the 665 task and we have improved the simplicity and manageability of the diagram, however, we really should be able to produce something even simpler than this.
Conclusion: Improvement; more manageable, but could do better.
Option 3: Variable duration
A recent addition to Mermaid is the introduction of tasks which change length with each repeat. This is different to the learning rate feature as the durations may change as specified by the user, rather than decreasing linearly or exponentially. We can make use of this feature in our analysis here. More information on variable duration tasks can be found here.
The duration of each task can be specified for each repeat, as shown below:
Below we can see how this simplifies the trenching group (we also apply this method to the cable lay and the restock operations):
We still need some occasional tasks and groups, to ensure our resupply and crew changes occur at the correct time, and we still need some repeat dependency connections to ensure correct scheduling (we won’t go into that here), but this is a much simpler diagram (below) to manage and shows the operation is a much clearer manner than the alternatives (including the 665 row Gantt chart).
Conclusion: Good, clear, simple diagram which is easy to understand and maintain. We should use this approach.
Running the simulation
We’re now ready to run the simulation. Remember, we’re looking to determine the optimum offset between the cable lay vessel going on hire and the trenching vessel going on hire. To start with we’ll take the trencher 32 days after the installer. We’ll designate this out base case and then run simulations at different offsets, these being:
Next time
In the next post in this series we’ll take a look at the results of this simulation and consider what steps we need to take next.
