Damage Stability Evaluation with the Probabilistic Methodology

Several variations of the probabilistic approach to stability-while-damaged have been developed over the years, but newer regulations are focusing on the method adopted in 2005 by the International Convention for the Safety of Life at Sea (SOLAS), known as Resolution MSC.194(80). Two versions of this method are prescribed: one for passenger ships and one for cargo vessels. The passenger-ship version escalates the complexity of the required calculations to a new level since it adds a requirement to evaluate stability with heeling moments due to wind, passenger crowding, and lifeboat deployment and in addition, requires checking intermediate flooding to determine whether lesser stability might be encountered as flooding progresses.

All probabilistic methodologies are based on a thorough analysis of the vessel's response to damage or flooding where single and multiple compartments are assumed to be flooded one at a time and in combination. A range of damage extents is considered, where higher probability of damage is generally assigned to lesser extents of damage. For each damage scenario, the probability of survival is calculated using certain formulas which are ultimately based on statistics from experience with ships at sea. The product of the probability of damage times the probability of survival is a partial probability which contributes to an overall measure of stability when added together with all the other partial probabilities from all of the extents of possible damage along the length of the vessel. This grand summation is called a subdivision index. Actually it is only a partial subdivision index, because under other loading conditions or drafts the calculations will produce different results. Therefore, partial indices from multiple drafts are combined to arrive at the attained subdivision index which is then compared to a required index. The required index is set in consideration of the type of ship, its length and, at least for passenger ships, the numbers of people on board.

The probabilistic approach to stability has much to recommend it. It takes into account the fact that there is no such thing as enough stability to meet the most severe damage or the most severe weather. As a practical matter, ship design must aim for an acceptable probability of survival. Since all of the design features affecting stability are rolled into one probability, the designer is free to make tradeoffs without being hurt by unnatural features of rigid stability criteria or tempted to exploit loopholes in the rule to increase loading limits at the expense of real safety. With the probabilistic approach, design tradeoffs, insofar as they affect stability, are realistically represented in the attained subdivision index.

From the standpoint of the computational procedures, the great advantage of the probabilistic method is that it embraces the problem of damage extents as well as the problem of survivability after damage, combining the two in one elegant measure. This formalizes and standardizes the generation of damage scenarios and makes it possible to present the results in a compact format. Since the probabilistic methodologies directly address specific features of ship subdivision, there are (at least theoretically) fewer decisions left to the person running the calculations. It offers the potential of a high degree of automation and time-saving for the designer.

The methods of determining damage and survival probabilities must address the many possible intricacies of ship subdivision is a general manner. The approach that has been taken by the formulators of these methods is to envision an idealized set of features which is assumed to represent all of the important features of any real ship, and then design rules that address the idealization. However, it is not always possible to address real subdivisions, using such rules, without ambiguity. Therefore, when actual computational procedures are laid down in computer code, the verbal rules have to be augmented in order to make the software work. In other words, methods must be programmed that take the features of the real ship and fit them into the idealizations upon which the rules are built. In most cases this transformation is straightforward; but in some cases a choice has to be made between alternatives, which seem to satisfy the wording of the rules. In such cases, the software might well have a means of user input so that decisions about how to treat these features can be made intelligently and deliberately by the naval architect.

For example, wing tanks or compartments are effective in limiting the flooding due to horizontal penetration through the side shell of the vessel. The extent of such penetration is linked to its probability: a greater extent of penetration requires more energy and is therefore less likely. In concept, a given wing-tank design will limit flooding to the wing tank when the penetration is less than a certain value. In order to get the highest probability out of this damage case (that is, to contribute most to the attained index) the designer will want the penetration value used in the calculations to be as large as possible. But what is this penetration value which just misses rupturing the wing bulkhead? Is it simply the distance from the side shell to the wing bulkhead? What if the side shell is not a nice flat wall? What if the bulkhead is sloping in various directions, has knuckles or is stepped? What is a fair penetration value to use in those cases?

What should, in theory, be a highly automated task can become demanding, not only for the software designer but for the software user. Designing software that both automates the task and avoids hiding decisions which the user should be overseeing is a challenge.

An example of how this challenge can be met is the new damage-stability wizard which runs in GHS. It can automate almost all aspects of the task, so that setting up a run for calculating the subdivision index on a passenger ship using the MSC.194(80) method can be done is just a few minutes. Yet it provides the naval architect with means of refining the procedure to take advantage of special features of the ship design. In keeping with this philosophy, it automatically produces a compact report presenting all of the essential information on which the computations are based; yet it provides options for getting detailed notes that describe every step of the process.

GHS alone, without the wizard, provides procedures which implement several versions of the probabilistic damage method, including MSC.194(80). Traditionally, the user would prepare a run file laying out the commands for defining subdivisions, setting up load conditions, and executing the appropriate probabilistic calculations. For passenger ships under MSC.194(80) the user would also have to write a macro to perform the survival probability calculation, including heeling moments and intermediate flooding. The Damage Stability wizard takes over all of these tasks, yet it provides for additional control by means of optional inputs.

Known simply as DAMSTAB2, this damage stability wizard is more like an application program than a wizard, as the term is commonly used. Though written entirely in GHS command language, DAMSTAB2 operates like an independent program. Its job is to automatically prepare the input files for performing damage stability calculations and then to run the calculations. It accomplishes this by launching a separate session of GHS which runs off the inputs it has prepared. It can launch and keep track of more than one session at a time -- one performing the calculations for starboard-side damage and the other for port-side damage, for example. For preliminary design calculations it is a great timesaver. But it also provides the means of optimizing the calculations to take advantage of special design features while providing detailed reports to answer any questions about the manner in which the calculations were done.