Consider the following scenario: A search has been in progress for several days, and you must decide how to allocate resources for yet another operational period. Here is the information you have on hand:

There are 3 search segments within the search area, not including the ROW. These segments are labelled 1, 2, and 3.

Now consider a completely different scenario. Two identical searches are run simultaneously, each with the same resources available to them, but the management teams decide to use the resources differently. After 5 days, the first search has a ROW POA of .65 (65%), and the second has a ROW POA of 41%. The second team takes 10 days to reach a ROW POA of 65%.

Question: Which management team used their resources more efficiently? Think about this question and try to answer it in your own mind before you read on.

It is our contention that the first management team did a much better job than the second. In fact, when David Lovelock first described this scenario to Mike Ebersole, Ebersole made the comment that the second team "wasted its resources." If you agree, then what this suggests is ...

Using ROW as a measure of the efficiency of the allocation of resources is now a third alternative. Thus, we are proposing that the ROW POA can have a potentially critical role in the planning stages of a search, as a measure of search effectiveness. We can use ROW POA to plan ahead, at the beginning of an operational period, in addition to using it at the end of a period. Instead of just indicating whether a search should be suspended or expanded, ROW POA can tell us how we should deploy X number of resources in Y number of search segments in the most efficient manner possible!

With these thoughts in mind, let's return to the first search scenario (that is, 3 segments with resources A and B). Following the maxims stated above, we should compute the ROW POA for every possible scenario, ranging from putting both resources into the same segment to putting the resources into different segments. After that, we need to select the scenario that has the largest ROW POA, right?

Table 3 shows the results of the calculations. For information, the current or beginning ROW POA is .15 (15%).

Scan down the percentages in Table 3 and select the top or highest three. If our maxim (that the ROW POA is a measure of how efficiently resources are allocated) is correct, then the scenarios making the best use of search resources are Case 4 (ROW POA 21.28%), followed by Case 6 (20.98%), and Case 2 (20.62%). The three worst plans would be Cases 1, 5 and 9, where both resources are put into the same segment. How does this agree with your hunches or experience?

Let's return briefly to Table 3. You might be tempted to say that there is not much difference between the ROW POA for Case 4 (21.28%, the best case), and Case 9 (18.14%, the worst case). Based on this, and other factors, you might therefore decide to follow Case 9. That would be a mistake. In order to convince yourself that there is indeed a significant difference between Cases 4 and 9, you should compute the percent relative increase in the ROW POA for each case, which is given by the following formula:

Relative Increase = [100(ROW POA(updated) - ROW POA(current)]/ROW POA(current)

Using this formula, the relative increases for the above scenario are:

Mathematically, we note here that the idea of maximizing the updated ROW POA is directly proportional to maximizing what we could refer to as the overall probability of success. In fact (by Bayes' Theorem), it can be shown that the ROW POA is given by the formula:

Note that figures used in these formulae must be numbers (decimal equivalents) between 0 and 1 - they are not percentages.

From these formulae, it can be seen that if we allocate resources in such a way that the ROW POA (updated) is as large as possible, we have also maximized the overall probability of success, given the current search area segmentation. The concept of maximizing the overall probability of success may seem more natural to some than maximizing the ROW POA (updated). In any event, the same optimum resource allocation is found using either ROW POA (updated) or OPOS - it makes no difference. The CASIE search software utilizes the maximization of ROW POA (updated).

Now, in order to make practical use of this approach to optimizing our resources, we must face the potentially burdensome computational effort involved. For a touch of reality (unfortunately), we will show what this optimization entails. Notice in our scenario that with 3 segments and 2 resources, there are 9 (3²) possible combinations. In general,

Some of these scenarios (e.g., 10 segments and 11 resources) would require some REAL pre-planning, to say nothing of extended computer warranties, a reliable power supply, and having to pass the search on to later generations! And remember that this all started simply because you were trying to decide today where to assign the resources for tomorrow's operational period!

The CASIE search software will give advice on resource allocation for up to 10 segments and 6 resources. More than this seemed impractical from a "time necessary to compute" standpoint. The authors realize searches quite often have more than 10 segments and 6 resources. We hope that, for whatever reasons, some segments and resources can be sorted out manually, until only an optimal number (10 or less segments and 6 or less resources) remain. These are what can be plugged into CASIE's "Resource Allocation Advice" feature, located under the "Planning" main menu selection.

Since running the "Resource Allocation Advice" module can be rather time intensive under some scenarios (see Table 4), we recommend that the CASIE software be installed on another, non-critical computer. The "Resource Allocation Advice" program can be initiated on this second machine, leaving the first computer free to run other CASIE features.

CASIE's "Resource Allocation Advice" will generate the top three scenarios having the highest ROW POAs, and will indicate which resources should be assigned to which search segments. If the search managers have different assignments in mind, they are encouraged to use CASIE's "Hypothetical Search" feature. In this section of the software, managers can fill in predicted or tentative resource PODs, and obtain the predicted shifted POAs, cumulative PODs, and (most importantly, in this case) a POA for the ROW. If the ROW POA under their scenario is close to CASIE's recommendations, the search managers will know their plan for deploying resources is valid and can be implemented.

So, what do you do when the number of search segments exceeds 10 or the number of resources is greater than 6? If you have access to a very fast computer, and know the "C" programming language, then you might look at the source code of the program BIGPLAN.C, which is on the CASIE distribution disk. It contains instructions on how to change the code to fit your scenario. If you ever use BIGPLAN.C, we would be very interested in getting all the details, in particular: the number of segments in your search area, the number of resources available, the type of computer you used, and how long it took to do your calculations. However, if you don't have access to a fast computer, then we're sorry to say that search and rescue is still an art, not a science.

Section I Section III Section IV