NATIONAL BUREAU OF STANDARDS RE

10 431

A SEARCH AND RESCUE SIMULATION MODEL FOR THE UNITED STATES COAST GUARD

VOLUME II

ANALYST LEVEL DOCUMENTATION

Technical Report to United States Coast Guard

Plans Staff, Office of Operations

U.S. DEPARTMENT OF COMMERCE

NATIONAL BUREAU OF STANDARDS
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards1 was established by an act of Congress March 3, 1901. The Bureau’s overall goal is to strengthen and advance the Nation’s science and

technology and facilitate their effective application for public benefit. To this end, the Bureau conducts research and provides: (1) a basis for the Nation's physical measure- ment system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety.

The Bureau consists of the Institute for Basic Standards, the Institute for Materials Research, the Institute for Applied Technology, the Center for Computer Sciences and

Technology, and the Office for Information Programs.

THE INSTITUTE FOR BASIC STANDARDS provides the central basis within the United States of a complete and consistent system of physical measurement; coordinates

that system with measurement systems of other nations; and furnishes essential services leading to accurate and uniform physical measurements throughout the Nation’s scientific community, industry, and commerce. The Institute consists of a Center for Radiation Research, an Office of Measurement Services and the following divisions: Applied Mathematics—Electricity—Heat—Mechanics—Optical Physics—Linac

Radiation2—Nuclear Radiation2—Applied Radiation 2—Quantum Electronics 1 —

Electromagnetics2 —Time and Frequency2 —Laboratory Astrophysics3—Cryogenics3

. THE INSTITUTE FOR MATERIALS RESEARCH conducts materials research lead- ing to improved methods of measurement, standards, and data on the properties of

well-characterized materials needed by industry, commerce, educational institutions, and

Government; provides advisory and research services to other Government agencies;

and develops, produces, and distributes standard reference materials. Tie Institute consists of the Office of Standard Reference Materials and the following divisions: Analytical Chemistry—Polymers—Metallurgy—Inorganic Materials—Reactor

Radiation—Physical Chemistry.

THE INSTITUTE FOR APPLIED TECHNOLOGY provides technical services to pro- mote the use of available technology and to facilitate technological innovation in industry and Government; cooperates with public and private organizations leading to the development of technological standards (including mandatory safety standards), codes

and methods of test; and provides technical advice and services to Government agencies

upon request. The Institute also monitors NBS engineering standards activities and

provides liaison between NBS and national and international engineering standards

bodies. The Institute consists of the following technical divisions and offices: Engineering Standards Services—Weights and Measures—Flammable Fabrics

Invention and Innovation—Vehicle Systems Research-—Product Evaluation

Technology—Building Research—Electronic Technology—Technical Analysis

Measurement Engineering.

THE CENTER FOR COMPUTER SCIENCES AND TECHNOLOGY conducts re search and provides technical services designed to aid Government agencies in improving cost effectiveness in the conduct of their programs through the selection, acquisition,

and effective utilization of automatic data processing equipment; and serves as the principal focus within the executive branch for the development of Federal standards for automatic data processing equipment, techniques, and computer languages. The Center

consists of the following offices and divisions: Information Processing Standards—Computer Information—Computer Services —Systems Development—Information Processing Technology.

THE OFFICE FOR INFORMATION PROGRAMS promotes optimum dissemination

and accessibility of scientific information generated within NBS and other agencies of

the Federal Government; promotes the develop ment of the National Standard Reference

Data System and a system of information analysis centers dealing with the broader

aspects of the National Measurement System; provides appropriate services to ensure

that the NBS staff has optimum accessibility to the scientific information of the world,

and directs the public information activities of the Bureau. The Office consists of the following organizational units: Office of Standard Reference Data—Office of Technical Information and

Publications—Library—Office of Public Information—Office of International

Relations.

1 Headquarters and Laboratories at Gaithersburg, Maryland, unless otherwise noted; mailing address Washington, D.C. 20234.

2 Part of the Center for Radiation Research.

3 Located at Boulder, Colorado 80302.
NATIONAL BUREAU OF STANDARDS REPORT

NBS PROJECT

4314561 June 1971

NBS REPORT

10 431

A SEARCH AND RESCUE SIMULATION MODEL FOR THE UNITED STATES COAST GUARD

VOLUME II

ANALYST LEVEL DOCUMENTATION

By

S. S. Karp, M. D. Maltese

T echnical Report to United States Coast Guard

Plans Staff, Office of Operations

IMPORTANT NOTICE NATIONAL BUREAU OF STAN

for use within the Government. Be and review. For this reason, the p whole or in part, is not authorize Bureau of Standards, Washington,

the Report has been specifically pr

Approved for public release by the

Director of the National Institute of

Standards and Technology (NIST)

on October 9, 201 5.

accounting documents intended

ibjected to additional evaluation

sting of this Report, either in

Office of the Director, National

the Government agency for which

ies for its own use.

U.S. DEPARTMENT OF COMMERCE

NATIONAL BUREAU OF STANDARDS

PREFACE

This volume is one of a series which documents a Search and

Rescue Simulation Model for the United States Coast Guard. The

material reported in this documentation was developed by an interdisciplinary team at the National Bureau of Standards with representation from the U.S. Coast Guard under MIPR Z-70099-0-01935.

The complete documentation is comprised of the following:

Volume I Executive Level Documentation

Volume II Analyst Level Documentation

Volume III Programmer Level Documentation for ’’PREPROCESSOR"

Volume TV Programmer Level Documentation for "OPSIM"

Volume V Programmer Level Documentation for "POSTPROCESSOR"

Appendix A Flow Charts for Programmer Level Documentation

Appendix B Program Listings for Programmer Level Documentation

The study was initially conducted under the supervision of Martin

J. Aronoff; subsequently efforts were supervised by Richard T. Penn, Jr.

Technical Project Leadership was supplied throughout the project by

Stephen S. Karp. Other participants from the National Bureau of Standards

Technical Analysis Division included the following:

Susan S. Chamberlin Elizabeth E. Leyendecker

'Linda K. Cummings Marcia D. Maltese

Mary Jane Duberg Patsy L.B. Saunders*

William Elliott, III Wayne A. Steele

Walter G. Leight Michael R. Vogt

Joel Levy Arnold L. Weber

1
Valuable advice was received from Alan J. Goldman* and Prof. Gustave J. Rath

of Northwestern University.

U.S. Coast Guard participants included:

Paul D’Zmura Gerald L. Underwood

Thomas T. Matteson Robert R. Wells

Support services were furnished by the following members of the

NBS Technical Analysis Divison:

Mary M. Abbott Frances E. Jones

Theresa I. Conrad Lucinda I. Farrell

* Staff members of the NBS Applied Mathematics Divison

11
TABLE OF CONTENTS

page

Part I - Introduction and Background. 1

1. Problem Definition 1

2. Alternative Methodologies 8

3. Design of the Simulation 14

Part II - Details of the Simulation 33

1. Introduction to Part II . . 33

2. PREPRO - The Preprocessor for SARSIM 34

A. Cleaning Routines ........... 36

B. User Control in PREPRO. 38

C. Program for Calculating Case Parameters (PCP) 38

D. The DEMGEN Program 60

3. OPSIM - The Operational Simulator of SARSIM 67

A. The Single Resource Assignment Subroutine (SRAS) 68

B. The Multi -Resource Assignment Subroutine (MRAS) 89

C. Interrupting the Service of a Multi -Resource Case 101

D. The Service Subroutine (SS) for SRAS and MRAS of OPSIM. . . 123

4. POSTPRO - The Postprocessor of SARSIM 142

APPENDIX A - Inter -District Assignment and Service Subroutine

(IDASS) of OPSIM A-l

APPENDIX B - Glossary of Terms B-l

APPENDIX C - Glossary of Flowchart Symbols C-l
LIST OF FIGURES AND TABLES

page

FIGURE 1 - Sample Assistance Report 14a

FIGURE 2 - SARSIM Structure 35

FIGURE 3 - Major Steps in PREPRO 37

FIGURE 4 - PGP Flow Chart 45

FIGURE 5 - PCP Flow Chart (continued) 46

FIGURE 6 - PCP Flow Chart (continued) 47

TABLE 1 - Assistance Rendered; Translation to Need 54

FIGURE 7 - Needs Flowchart 57

FIGURE 8 - DEMGEN Flowchart 66

FIGURE 9 - Major Steps In the Single Resource Assignment

Subroutine 69

FIGURE 10 - Resource Capability Matrix 73

FIGURE 11 - Select an Ordered Set of Capable Resources 79

FIGURE 12 - Modeling the Assignment of a Resource to Service Case . 80

FIGURE 13 - Resource Idle and Operational; Crew Availability

(RIOCA) 88

FIGURE 14 - Multi -Resource Assignment Subroutine 94

FIGURE 15 - NOTIF 95

FIGURE 16 - Line Illustration of the Service of a Multi -Resource

Case 97

FIGURE 17 - Illustration of A (i) 99

TABLE 2 - Fuel Endurance and Refuel Time (Hrs.) 104

FIGURE 18 - SASS Flowchart; RISE, 108

TABLE 3 - Fractions of PRTSM(i) for varying levels of S^ 109

IV
page

FIGURE 19 - SASS1 Flowchart 110

FIGURE 20 - Calculation of PR(k) 112

FIGURE 21 - SASS and SASS1 Continued 115

FIGURE 22 - TEST and ARSCH 116

FIGURE 23 - NSET; XRISE; XSET; COMPL 117

FIGURE 24 - TEST; ARSCH; FUEL; HOMEF; and SNBK 121

FIGURE 25 - SS and ARVSH 126

FIGURE 26 - ARVSN (continued) 127

FIGURE 27 - ONSCN and RETN 128

FIGURE 28 - SRCHF; EXQ; TERM and HOME 130

FIGURE A1 - Special Pre-processing for IDASS A9

FIGURE A2 - IDASS; ASINI; IS A- 10

FIGURE A3 - ASIN 2;ASIN 3; A-ll

v
FOREWORD

The United States Coast Guard has recently been responding to

more than 40,000 distress incidents per year in the coastal and inland

waters of the continental United States which are under their jurisdiction. They have aided recreational boaters, commercial fishermen,

and other individuals in maritime distress, preventing or limiting

loss of life and destruction of property.

Projections of future recreational boating shows an average

increase of 4.4% per year*. This increase alone might soon impose

severe demands on Coast Guard services to be rendered to the general

public. For this and similar reasons, the Coast Guard must make strategic

plans for the Search and Rescue (SAR) missions, with regard to procurement,

allocation, and organization of resources within budgetary constraints for

any selected time frame.

The tools of management science, systems analysis and operations

research readily lend themselves to the type of problem represented here.

Accordingly, the National Bureau of Standards, in a joint effort

with the Coast Guard**, has developed a Search and Rescue Simulation

Model (SARSIM) to assist Coast Guard management in its approach to

planning for future SAR activities.

*"Long Range Forecase of Activities in the Marine Environment with

Implications for Planning Coast Guard Search and Rescue Operations",

National Planning Association, Washington, D.C., Feb. 22, 1971,

Executive Summary p. 10

**Karp, S.S. and T.T. Matteson, "The Integrated Team Concept, of

Simulation Model Development", Proceedings of the 1971 Summer

Computer Simulation Conference .

vi
SARSIM is a highly flexible, user-oriented model. It simulates

Coast Guard response to an input caseload scenario, i.e., people and/or

property in distress. The automatic summary output from the model

(e.g., response times, resource utilization statistics, etc.) gives the

user considerable insight for judging the effectiveness of the SAR

system with regard to each input scenario.

The user is offered a variety of modes in which to operate the

model. For example, he can prepare, automatically, a multitude of

client demand scenarios. He can perturb the SAR resource inventory,

i.e., vary the number and classes of resources, their physical capabilities,

their deployment (location), and manning levels. He may also choose to

exercise the model with different server disciplines (resource assignment

schemata). In addition, the user can supply criteria to be applied to the

simulated case history output for additional optional analysis.

In simmary, SARSIM offers flexible, built-in capabilities to

aid Coast Guard decision makers in developing long range strategic plans

to carry out the SAR mission.

Vll

Part I - Introduction and Background

1. Problem Definition

Need

Because of the rapid and continuing growth of marine activity,

especially in recreational boating, combined with the constraints

imposed by national budget allocations, the Coast Guard has found it

necessary to examine its current readiness postures and operating

policies and to project future Search and Rescue (SAR) Force Level

Requirements on an integrated resource basis. That is, the Coast

Guard's aircraft, cutters and shore stations with their associated

boats must be considered simultaneously as a system in order to

plan properly for the entire SAR mission.

In order to provide insight to evaluate the system comprehensively

on a unified basis, a methodology had to be developed and associated

criteria, or measures of effectiveness had to be created to help

analyze the various SAR mission alternatives.

Typically, management is concerned with determining the best

mix of resources to accomplish the SAR mission, simultaneously answering

such queries as:

How many resources of each type should be procured (or

phased- out)?

© Where should the resources be deployed to achieve maximum

effectiveness?

What are the most cost-effective crew manning readiness levels

for each Coast Guard station, for various times of year, week,

day?

- 1

-
» What are the differences among various operating tactics?

• What are the effects on the system of the introduction of

new resource types, having increased capabilities?

9 What are the effects of introducing different organizational

structures, such as grouping the facilities of store stations?

Objective

The initial objective of this study was to assess the feasibility

of various methodologies to assist Coast Guard management in answering

the questions posed above; and given its feasibility, to propose the

design for the most promising methodology. Underlying this goal was

the study team's desire to provide management with a highly realistic,

flexible tool to examine the SAR system under a wide range of conditions.

Since direct experimentation with the system is probably infeasible because of its potential danger to human life, it quickly became apparent

that a model of the SAR system would most likely be necessary.

Description of the SAR Process

The Coast Guard’s search and rescue activities constitute a fairly

complex process, characterized by heterogeneous classes of clients in

distress. Furthermore, depending on the type of distress and the urgency

with which assistance is required, there may be available a wide variety

of types of SAR resources to serve the clientele. Resources differ in

capability, related to their physical attributes and the environmental

conditions at the time of an incident.

SAR incidents may involve peril to people or the threat of damage

to or loss or property. Occurrences of distress incidents tend to

- 2

-
cluster at "preferred" locations or peak time periods, but are generally

widely enough distributed around the average times and places that they

seem to occur, to all intents and purposes, at random. The needs for

assistance also vary widely, and include rescue of personnel in the

water, search for lost vessels, extinguishing of fires, dewatering of

flooded vessels, help with repairs or replacement of damaged material,

or towing to safety.

The Coast Guard resources dedicated to SAR are, for the most part,

located at shore stations along coasts where distress incidents are most

often experienced. These stations are grouped into about a dozen

major districts* and several minor districts (which are either geographically small or which serve relatively few cases) . The major districts

contain from 30 to 50 stations, called Operating Facilities (or OPFAC's),

at which are stationed about 80 - 150 rescue -capable units (resources)

categorizable into some 15 - 20 resource types. Short stations with

small boats handle the bulk of the SAR incidents encountered. They are

supported by fixed-wing aircraft and helicopters at nearby Coast Guard

air stations, as well as long-range aircraft which might be stationed

at considerable remove outside the district. Covering Coast Guard

cutters are also available to assist, either from shore stations or while

operating independently on SAR patrol at sea.

The SAR process may be viewed as a spatially distributed queueing

system in view of the areal extent of SAR cases and the decentralized

*Coast Guard districts generally consist of several contiguous states

and are numbered like U. S. Naval districts.

- 3

-
deployment of Coast Guard resources. Coast Guard receipt of notification of a distress situation corresponds to the random arrival of

a client ("customer" in the text book sense) . The resources at the

station receiving the notification may or may not be capable of responding to the call for assistance, depending on the combination

of pertinent factors. These include the location of the incident

relative to the station, the characteristics of the unit in distress,

the nature and seriousness of the distress , the environmental conditions, and the physical and operational characteristics of the local

resources. Thus, for example, a small boat might not be capable of

operating effectively in high seas , or might not be able to tow a larger

boat.

Capable resources assigned to a station might not permit response

to a call for assistance if, for example, they were all busy on other

cases, or "down" for maintenance, or not fully manned. Consequently,

availability at the time of call must be considered along with capability.

Dependent on established policies, resources from nearby shore stations (or covering air stations and cutters) may be called upon to

render the necessary SAR services. Whatever policy has been set, a

capable resource is assigned if such is available. If assignment cannot

be made, the client will perforce wait (in a queue, as it were) until

the earliest feasible assignment. However, if the seriousness of the

situation warrants, ongoing service to an earlier arrival might well be

interrupted to attend to a higher priority case. At each station

several queues may exist simultaneously, each containing cases of the

- 4

-
same priority in the order of their arrival into the system. The highest

priority queue will be served as capable resources become available, and

in the order in which cases arrived. Only after that queue has been

emptied will lower priority cases be handled. (Provisions may also

be made to review the priority of waiting cases and raise it, if

necessary or desired.)

It is clear from the foregoing abbreviated discussion that there

are compound interactions among the clients (i.e., the cases of distress)

who enter the system, the inventory of local resources at the notified

station and their status, neighboring and covering stations and the

status of their resources, priority interrupt and resource assignment

policies, the ambient conditions at sea, and other applicable factors.

These interrelationships contribute to the difficulty in selecting an

approach for modeling of the SAR process , and hence had to be examined

in considerable detail to assure a reasonably accurate analytical

facsimile.

Scope

The study leading to the simulation model reported herein was

limited in scope to include only the SAR mission of the Coast Guard. Its

other missions such as law enforcement, aids to navigation, merchant

marine safety, etc., are preemptible by a SAR incident and can be

reasonably excluded.

- 5

-
Only surface vessels and air resources have been considered in

the study. More specifically, cases which cannot be aided by the

above categorized resources, (such as "overdues" located through

communications checks, cases requiring medical advice, or cases aided

by a station's motor vehicle) are not considered.

The study was to be open ended relative to time frame. That is,

the end product methodology had to be futuristic in concept such that,

for example, the projected demand over a ten year period could be

applied and the force requirement determined; or new equipment and

operating techniques could be considered without redesigning the methodology.

However, in the interest of providing meaningful data to the Coast

Guard management, some macro-level of organization is preserved. By

using the Coast Guard district as the system boundary in examining the

problem, pertinent variables could be considered in more detail than,

for example, if the entire East Coast operation were modeled as a whole.

The selection of the district level of organization as a boundary is

further justified by the relative independence of operations from

district to district. To be realistic, however, particular interdistrict

activities are also considered simultaneously when examining the system

on an intradistrict basis. This approach was an obvious requirement

since certain long-ranged aircraft resources are made available to handle

cases along a single coast. In bounding the problem in such a fashion,

no loss of important interaction among the districts is encountered.

- 6

-
Of course, a subset of the model should be exercisable so that if

the user chose to apply the methodology to an organizational level of

lesser magnitude than the district (e.g. , a single station), he might do

so, provided that he recognizes that the results are localized to that

level. In short , simulation at any organizational level is permitted, but the

limitations imposed by the required level of detail for meaningfully

modeling the search and rescue system, the level of station interaction

and queueing, and the available computer storage, all contribute to

the definition of these bounds. Further, these last two constraints

also place an upper bound on the number of cases that can be examined

simultaneously, thus bounding somewhat the time frame, (e.g., a month,

a peak period) of a single model exercise.

The study approach does not encompass the causative factors involved

in SAR cases. Boating safety education, although important to the entire

SAR problem, is not considered in the study, as the incidences are

taken as given. The objective here, then, is to examine alternative

ways of serving a given forecast caseload so that the Coast Guard can

compare the performance and cost of each alternative as part of its

long range planning and evaluation effort.

- 7-
2 . Alternative Methodologies

The recommendation to examine the feasibility of developing a

model of the SAR system, with emphasis on measuring resource utilization

on an integrated basis , was made to Coast Guard management (as reported

in the Second Interim Report on a Multi-year Special Analytical Issue

Study, June 1969) by the Plans Staff, in the Office of Operations,

USCG. This group had already developed a simple queueing model for a

single Coast Guard shore (small boat) station, applying the Poisson

arrival s/Exponential service time queueing formulations to determine

the number of servers (boats, crews) required to provide a given level

of service for that station's caseload. These shore stations have a

relatively homogeneous set of servers (small boats) and a high incidence

of arrival of the typical case, making the closed form model a reasonable

predictive tool for resource analysis for a single shore unit.

The Technical Analysis Division at the National Bureau of Standards

was called upon to examine the entire integrated SAR problem, offer

its recommendations as to the proper methodology, and subsequently to

complete the study as a joint endeavor with the Coast Guard. Three

basic methodologies became apparent to the study team. The first

approach is to perform certain well planned experiments directly with

the SAR system, collect empirical data, and measure the effects of

the experiment. Second, the analytical model approach may be applicable,

if the client/server relationships can be extended to represent the

integrated SAR system in closed form. A third approach, the development

- 8

-
of a large scale simulation model, could be undertaken so that indirect

experiments might be undertaken with a realistic model of the SAR

system.

To apply the direct experimentation approach in the real world

is extremely risky for the Coast Guard from two viewpoints. First,

the chances of getting useful results are not very promising because

of the difficulties of conducting closely controlled experiments on

the operational system. Coast Guard experience indicates that field

personnel do not always comply with the experimental rules. For

example, when a case is to be queued, often an additional resource

would be dispatched to service it ’’illegally" to avoid any possible

risk. More importantly, however, the risk associated with the possible

loss of life or destruction of properties, when the system is undergoing

experimentation, is one that could carry serious moral, legal and

political implications, each of which is desirable to avoid.

A review of the literature* has indicated that the state of the

art in the development of analytical models of sophisticated, highly

complex queueing systems has not advanced sufficiently to be applied to

the SAR system, without the drawback of making over-simplifying

assumptions. For example, the heterogeneity of the physical capabilities

of the several different resource types make the analytical modeling

approach essentially untractable for investigating the trade-offs of

various resource type mixes for servicing a given caseload. Some

additional complications are: Calls for service are distributed over time and geography according to distributions that

* See references 1 through 11

- 9

-
are known only empirically; the service process is of priority interrupt

type, and a client's priority may change as a result of either undergoing

service or of being interrupted, or both; the needs of the client may

vary widely in both type and amount -- for example, a case may be a simple

single resource tow lasting a half hour or a complex search case involving

several aircraft, cutters and boats for a week or more. Although queueing

systems with some of the above characteristics have been examined in the

literature, the combination of all of these complexities, and many more,

does not appear to solvable analytically. And if a sufficiently

complex analytical model could be developed, it would undoubtedly consume a

considerable amount of time and money, to the point that its solution would

probably not be timely.

Simulation, the third approach, although also costly in both design

time and money, has the potential of yielding the most flexible methodology,

and could perhaps provide the best payoff to Coast Guard management.

Simulation modeling is preferred over controlled real-world SAR

experimentation since it avoids the risks of direct experimentation with

the general public. Furthermore, simulation offers considerably more

flexibility than the limited experiments which might be undertaken

directly. Simulation modeling is also preferred to analytic modeling

where the problem characteristics prohibit timely solution with current

state of the art. The SAR response devolves on a fairly complex set

of decisions within a hierarchy of a formal organization. These decisions

encompass the differing physical capabilities of the inventory of SAR

- 10 -
resources, the environmental conditions at the time of the incident,

the service requirements of each client, the server disciplines, etc.

Often such complex problems can be formulated analytically, but cannot

be solved analytically in a timely fashion for immediate use. Although

the analytic approach could work if the complexities of the SAR system

could be sufficiently simplified, such an approach would almost certainly

fall short of adequately answering Coast Guard management's questions.

Frequently, simulation is considered only as a "last resort" after

other problem approaches are considered lacking and not applicable.

Certain unique properties of the simulation approach, however, do make

it attractive to the analyst in preference to other techniques.

To illustrate, it may desirable to observe the dynamic behavior

of a process, especially a man- system- environment problem: such as SAR,

and collect a variety of simulated data. Since the ratio of simulated

time while observing this behavior to the actual time can be very small,

a large assortment of experiments can be performed. Often simple

performance criteria for evaluating a system just do not exist; or the

observers of the system may evaluate its performance quite differently.

These last two points make simulation more attractive as the approach

to solving the SAR problem, as a single static point solution leaves

Coast Guard management without a spectrum of resultant observations both,

aggregate and detailed, for making the best decision for SAR planning.

A secondary value of simulating a system is its use in developing

and testing tactical operating policies and procedures. Often, portions

- 11 -
of the simulation model, close replicas of the real system, can be used

as training devices (similar to operational games) , allowing the user

to change input conditions, make decisions during the game and observe

the system response. Not only can this become an effective training

device, but it also can provide insight when the user is interested in

certain dynamic interactions, rather than the overall behavior of the

system.

There are drawbacks to simulation in that the development and exercise

of such a complex model could prove to be very expensive. However,

when it is realized that a savings of only 1 % of the $150 million annual

budget for SAR could easily repay the investment several times over,

the expense of simulation does not seem so critical.

The question always arises as to the validity of a simulation

model (or any model or empirical examination of a problem) . Model

validation is indeed a topic in itself, and is treated in a separate

report, but some thoughts are noted briefly in this section.

Validation, too, can be expensive, and even unproductive, but there

are reasons to believe, before building the simulation, that a successful

validation for the SAR model is possible. First, there exists a relatively

good and complete data base of SAR incidents. Second, the SAR model can

be constructed so that it is essentially deterministic in nature (as

opposed to probabilistic). Thus, the confidence that it is a good

replica of the SAR system can be gained from a few simulation exercises

and a comparison of the simulation results with some carefully prepared

- 12 -
statistics generated from historical data. In contrast, if the

simulation were highly probabilistic, many exercises would be necessary

to gain assurance that the model is an adequate replica of the

system.

In summary, the simulation approach has been selected as the

methodology for studying the SAR problem because of its several advantages

,

few disadvantages and high probability of success.

- 13 -
3. Design of the Simulation

The purpose of this section is to review the major design considerations which were analyzed during the design phase of the Search And

Rescue Simulation (SARSIM) model. It is felt that this section will be

helpful towards obtaining a fuller understanding of the descriptions of

the algorithms of SARSIM presented in Part II of this volume.

Inputs and Outputs

A simple yet effective way of viewing the overall SARSIM model

is via its inputs and outputs. The inputs to the model are in part

dictated and constrained by the available SAR data base. The core

of the data base is the set of SAR Assistance Reports which are filled

out for each distress case the Coast Guard answers. Figure 1 shows a

sample report and indicates the kind of information that is available.

In retrospect, almost every item on this form is used in SARSIM either

directly, via parameters calculated from these items; for post-processing

analysis (e.g. "Value of Property Involved"); or for validation comparisons. Further, much of this data was used during the design process

to verify many of the model's assumptions.

Three years of this data (approximately 40,000 cases per year)

were cleaned, organized, sorted, and merged at the National Bureau

of Standards just prior to and during the early stages of the simulation

development. Although many automatic checks were made during the

cleaning of this data, some key punch errors and inconsistencies may

still exist, not to mention the possibility that the information may

- 14 -
SAMPLE ASSISTANCE REPORT

TREASURY; DEPARTMENT

u- s. COAST guard ASSISTANCE REPORT

CG-327 2 (Rev. 9-65) NSS q p. flRST LCSICfU- FJltD

I REPORT CONTROL SYwnoi. OS&-2DOC [ ALL TIMES LOCAL

REPORTING UNIT (Include location or permanent station) Cr / o gc€s£Z-O C5tlsHc>>'

Cr /o u c tss £<e r , M9s3

lF Col. — W ^ — ^ \ ~ J . A. IDENTIFYING DATA: | INSTRUCTIONS i

1

0 i 2 LOSICftL FILU>5 PER- C.tiS£ Reference: Latest revision of COMDTINST 3123.9

L Prepare original only. Use of pen or pencil is permitted.

2. Shaded areas require use of code list at all times.

3. ALL SPACES MUST BE FILLED. See reference for codes when an item is unknown or not applicable.

* Y - yes, N - no, U - Unknown or not applicable; DIR - Defi- j ciency Improvement Report

** To the nearest tenth of an hour.

l 2 o, / 3,0 / .3 ,<Z Unit Accounting Code

4 2 9 o 2,2, V Unit Cafee Number

V) 3 13 u 0 2, 2

Multi-Unit Case Controller Code

and Case Number ' n 4 18 o. 3 <S Month and Year Unit Notified (Item Cl) :

21

B. DISTRESSED UNIT DATA: CARD NO. 1

. 21 o t n S.^,3,2. IS Distressed Craft Number Ij2 52 o,y / Type of Distress

2 79 _L5

Date/Time Distress Incident Occurred ,13 55 2 il Distressed Unit Description

y> 3 35 Total Number of Persons in Distress ' or on Distressed Craft 14 67 & Source of Information

4 39 or r ,

Total Number of Lives Lost Among

Persons in Distress lot 15 68

1 Means of Notifying Coast Guard

41 5 43 o t o ,o , / ,S.o t o

Value of Property Involved 70 16 70 Oi°^

i Type of Distress Area { 51 6 51 S', O Air Temperature (°F) Record the severest weather encountered in the distressed unit’s area, (Required in all cases

unless omission is specif- ically covered in the

reference.) NA - not applicable

7*> 17' 73 o Nature and Severity

LlT J V

7 S3 4\o Sea Temperature (°F) 7fc> 18 76 1 Cause of Incident

8 55 2,0 Wind Force (Kpots) 77 19 77 3 Final Status of Property 1

51

fcl

9 57 O Ao Height of Sea (Feet) 71 20 78 v

Was Distressed Unit’s Emergency Equipment

Satisfactory? (No - COMMENT REQUIRED)

:n 50 o 3

Visibility (Nearest Mile) UK - unknown

77 21 79 A/* Were Non-Coast Guard Units in a Position and Capable of Performing Rescue-*

li 61 y

Was Distressed Unit Being Set Onto a Dangerous Beach or Shoal Within 5 Miles? SO 22 30 Vessels 65 Fe^t and Under. Had Vessel been Boarded within Past Year0

i

C. REPORTING COMMAND DATA: Card No. 2 (Cover ONLY Reporting Command Performance except Items C6 and C7.)

i 21 / & 1.0, / ,s Date/Time Notified Ufc 9 56 <3,0,

Miles Distressed Unit lowed, escorted 3 or Transported

m 2 27 3 Day of Week When Notified 10 60 O,.— Number of Bodies Recovered n 3 28 O

Number of Assistance Cases in Progress at Time . Notified •U 5 11 63 0 , 0 , 3: Number of Persons Saved n 1 4 29 / / ,0/ ,s

Date/Time First Assisting j Resource Underway 12 66 Number of Persons Otherwise Assisted

4S

102

. 5 35 / Number of Assisting Craft or Groups Assigned to Case 127 13 69 Number of Persons Indirectly Assisted

1~

6 36 / / , 0,2 5" Date/Time First Assistance

at Distress Position 152. 14 72 / ,4T / , / 3 ,'S^ Date/Time Case Terminated

7 41 TITUDE . 3 . V -V Position at which Distressed m 15 78 o Report Review Requirements

101 16 79 Thit Horn for HQ USE ONLY 47 LONG 0,7 .O

TUDE V ,o wJ

Located by another Unit.) ;

115 > 8 51 0,0,0 Distressed Unit’s Distance (miles) from Reported Position 140 ; 17 80

j D. ASSISTING RESOURCE DATA: Cord No. 3 (One cord for each resource.)

14 i 21 / ?> Tvnp of Resource Reoorted in this Section ISO

1 10 60 o\t Method of Locating Distressed Unit

14 5

14 <1

Lb 5

Ibl

2 2? O V V ,3 . / ,7

Assisting Boat, Vessel or

Aircraft Number 142 11 62 AJ— Assistance Rendered to Personnel

3 29 /,4T / o /

5" Date/Time (3) Underway,

(4) On Scene, Started Searching

or Rendezvoused.

174 12 64 (o Primary Assistance Rendered Relating to Property 1

l<ilo 13 66 Secondary Assistance Rendered Relatingto Property / s / n s s'

5 4

0 o

i 2

Distanc s to Scene, Search Area or

i/ous Point 1M 14 68 0,7. On Scene Frequency

(5 /\ 5

J 1 i M o ——

Hours Spent Searching or Conducting

17 0 15 70 / O Ship/Shore or Air/ Surface Control Circuit

ltd 7 49

i i ! O O 0,0 Total Miles Traveled on Case 172- 16 72 Was Equipment ana/orrcrbuuuu * ......

Y Satisfactory? (No - DIR REQUIRED)

1'I4 g 54 On / . *'2Total Time Underway on Case 17 73

I'll _9 58 0, / Number

18

4

FIGURE 1 -14a-
SAMPLE .ASSISTANCE REPORT (continued)

NBC FOfcKM F0 R SUCCXSSXVE LOGICAL FVLLDS

1 1 1 0 1 N'JM&ee. or 3-tftRi>5 per case

3 1 21 - 1 Type of Resource Reported in this Section 42 io 50 1

' Method of Locating Distressed Unit

5 2 23 1 1 . | 1

' Assisting Boat, Vessel or

Aircraft Number 44 n 62 1 Assistance Rendered to Personnel

11 3 29 1 1 1 1 Date/Time (3) Underway,

(4) On Scene, Started Searching

or Rendezvoused

12 64 '.-1 Primary Assistance Rendered Relating to Property

17 4 35 1 1 4% 13 66 1 Secondary Assistance Rendered Relating

to Property

5 41 I I 1 Distance to Scene, Search Ares or Rendezvous Point 60 14 68 1 On Scene Frequency

-1 6 45

** Hours Spent Searching or Conducting Communications Check 52. 15 70 Ship/Shore or Air/Surface Control Circuit

51 7 49 Total Miles Traveled on Case 54 16 72

* Was Equipment and/or Personnel Performance

Satisfactory? (No « DIR REQUIRED)

3fa 8 54

'

Total Time Underway on Case 55 17 73

40 9 53 Number of Sorties 5fc> 18

D. ASSISTING RESOURCE DATA*. Cord No. 3 (On® cord for each resource.) j D. ASSISTING RESOURCE DATAs Cord No. 3 (One cord for eoch resource.)

57 i 21 ai Type Of Resource Reported In this Section ! 4 to 10 60 Method of Locating Distressed Unit 54 2 23

l 1 — l 1

Assisting Boat, Vessel or

Aircraft Number 1 4 % 11 62 Assistance Rendered to Personnel

3 29

.... *- a - a - Date/Time (3) Underway,

(4) On Scene, Started Searching

or Rendezvoused

100 12 64 Primary Assistance Rendered Relating to Property j 11 4 35

t a 1 102 13 66 Secondary Assistance Rendered Relating

to Property

i'i 5 41 ii I ’ Distance to Scene, Search Area or Rendezvous Point 10^ 14 68 On Scene Frequency ii 6 45

**

1 1 _ * Hours Spent Searching or Conducting Communications Check Ida 15 70 Ship/ Shore or Air/ Surface Control Circuit VC 7 49 Total Miles Traveled on Case 10% 16 72

* Was Equipment and/or Personnel Performance

Satisfactory? (No - DIR REQUIRED)

10 V 54

** Total Time Underway on Case 104 17 73

" 1 I;

14 58 a Number of Sorties no 18

D. ASSISTING RESOURCE DATA: Cord No. 3 (One cord for each resource.) U i i 21 1 Type of Resource Reported In this Section 150 10 60 1 Method of Locating Distressed Unit

1 1

5

2 23

i - i- a »

Assisting Boat, Vessel or

Aircraft Number IS2 11 62 Assistance Rendered to Personnel

11 \ 3 29

n .. Date/Time (3) Underway,

(4) On Scene, Started Searching

or Rendezvoused

15 4 12 64 Primary Assistance Rendered Relating to Property 125 4 35

_a i 1 5fc 13 66 Secondary Assistance Rendered Relating

to Property

1 51 5

£J41 At 1- * Distance to Scene, Search Area or Rendezvous Point 15? 14 68 On Scene Frequency

13.5 6 45 1 « • Hours Spent Searching or Conducting Communications Check lfco 15 70 Ship/Shore or Air/ Surface Control Circuit

i -Vi 7 49

1 1 1

| Total Miles Traveled on Case 1L2 16 72

* Was Equipment and/or Personnel Performance

Satisfactory? (No » DIR REQUIRED)

.144 V 54

** Total Time Underway on Case 5

(T* o« 17 73 •

j 4 % 58 1 Number of Sorties K4 18 HAVE YOU PREPARED ONE SECTION D FOR EACH CRAFT OR GROUP INDICATED IN ITEM C5?

. .. NAME OF DISTRESSED CRAFT Msry Ks>y

NAME AND ADDRESS OF OPERATOR A. 6. 5ee

/OSLO Pls>n 3 tr&e C

G/o zr&r , Wavs.

NAME AND ADDRESS Of OWNEiOf DIFFERENT

COMMENTS (List nsmaa md addresoau cl parson® reported in CIO &nd Cll) A'ndr-giJ ^ W C ” S"s m && 3 1*0

» 0 St*

}

C? Zeiss'S.

JossLfh c. See —

S* SeB/

J'r. — Lee vT iJe> €’ — r.L. JT /£>ZLZL‘

^

3f/7

DATE SUBMITTED ^ICNATURI j DATE INITIAL*

i AS if l. S<T4fi74M REVIEWED AND FORWARDED /at i -14b-
have been erroneously recorded at the origin Despite these facts,

this data base represents a valuable resource for the design, operation

and validation of the model.

The exogenous inputs, then, for SARSIM are the historical cases

and their attributes, for example: date and time of notification,

location, environmental conditions, assistance rendered (need), case

severity, search requirements, etc.

The endogenous inputs are used to describe the SAR system to be

simulated. These user inputs include: district identification;

station data (including, for each station: location, number and types

of resources , covering aircraft stations and cutters , crew manning

levels for each shift, etc.); resource type data (including for each

resource type: operating costs, endurance, speeds capabilities

reliability, etc.); shift data; tolerance times as a function of

severity levels and case type; standby data; and many more descriptors

of the system to be simulated.

The outputs for a given run, or exercise, of the model can be

categorized into two basic types. First are case outputs , which include

such summary statistics on the cases serviced during the simulation

exercise as: average waiting time; average service time; number of

incidents of interrupts and queueing; etc. The second type

are the system outputs , which measure such things as the utilization of

resources (overall, by station, by resource type, by time period etc.);

number of system failures; number of standby call-ups, etc.

- 15 -
The outputs described above are all automatically printed after

every run of the model. Additional information can also be obtained

concerning case outputs via a postprocessor program. If the user chooses

to have this additional output, he can specify that an output case

tape be created; then the postprocessor can use this tape to retrieve,

analyze and print out the additional statistics desired by the user.

Boundaries

The choice of the district as the basic boundary of the model

has already been discussed. (See, in Section 1, the discussion under

"Scope.")

Methodology for Treating Time Advance

An investigation of the SAR data base revealed that, even during the

peak boating season, on the average only about 3 to 51 of the SAR resources

are busy at any particular time. In other words, there is very little

"interesting" (i.e., SAR) activity during most of the time. On the other

hand, when cases do come up, the amount of activity is very high and the

average time between significant events becomes small. For these reasons

it was decided that the time advance mechanism in the model should be

discrete, rather than continuous, and event oriented rather than time

interval oriented. This approach is highly efficient for SARSIM, since the

computer need do no work during the long periods of inactivity; yet during

periods of high activity, the computer will be able to simulate all of the

interesting events regardless of how fast they occur. SARSIM then has

been modeled as a discrete event digital simulation.

- 16 -
Level of Detail

Any simulation is limited in the number of events it can handle

efficiently. The district caseload (approximately 7000 per year)

is sufficiently small that multiple events for each case can be

considered. Therefore, for each case, in addition to origination

and termination, it will be possible to simulate other events such

as notification, response /launch, on scene, interrupt (s) , priority

change(s), and searching, etc. in order to make the model more realistic

These added events will, for example, allow a resource enroute to a

case to be diverted to another case of higher priority (i.e., interrupt)

It will also allow a case in progress to have its priority change (in

either direction) to reflect changing conditions and assistance

already received.

Since the Coast Guard desired to investigate alternative

resource mixes, it was not sufficient that the simulation merely

assign the same resource type to a given case as was assigned

historically. Therefore, a highly sophisticated set of resource assignment algorithms had to be designed such that the preferred resource

(or resources, for a multi-resource case) is selected from all the

existing resources being simulated for assignment to each case. The

provision for priority interrupt, of course, further complicates these

algorithms.

The resource assignment algorithm for long* search cases is

*Cases involving searches of less than one-half hour duration are handled separately.

- 17 -
somewhat more complex than for non-search cases because of the widely

differing capabilities for search among the various resource types.

However, the servicing of a search case in the model is less detailed

than the servicing of a non- search case. This is due to the limited

data available in the data base on how the search was carried out (e.g.,

search pattern, track width, etc. are not given) and also due to the

relatively minor incidence of long search cases in the overall SAR

system. Only a small fraction of the total SAR caseload involves

a long search requirement. However, when such a case does come up, it

consumes a considerable amount of (usually expensive) resource time.

Therefore, the objective of servicing long search cases in the simulation

was mainly to account for this resource utilization when the relatively

unlikely event of a long search comes up -- because the resources

occupied on a search case will not be available (unless interrupted)

for the more common non-search cases. Hence the level of detail need

not be as fine for these long search cases.

Selection of Programming Language

As a result of a comprehensive analysis of the available programming

languages and associated computer systems, the SIMSCRIPT 1.5 language

was chosen for basic operational module of SARSIM. A report entitled:

"Selection of Programming Language," Feb. 20, 1970, was delivered to

the Coast Guard which presented this analysis and recommended this

language.

FORTRAN V is used for the preprocessing programs because of its

- 18 -
universality and suitability to these kinds of calculations.

QUICK QUERY is used for postprocessing because it is compatible with

the SIMSCRIPT language.

Methodology for Case Generation

The generation of the demand tape containing the exogenous

case inputs is based on the SAR data base and, in particular, each

generated case is obtained from the description of an actual case which

has occurred historically. A discussion report of the advantages and

drawbacks of this data base approach, as compared to a highly

conditional Monte Carlo approach where each attribute of each case

is obtained from conditional distributions, has been submitted* to

the Coast Guard. These advantages are summarized here:

a. Using actual historical cases and their attributes

precludes the possible generation of cases whose

attributes are not entirely consistent within the case.

b. The conceptualization and development of a highly conditional

Monte Carlo preprocessor that is both consistent and accurate

would be highly time consuming. Much data analysis would be

required to determine a feasible trade-off among the accuracy

in generating cases, a manageable program, and the computer

storage limitations.

c. Using historical cases and their attributes contributes

to the task of validation. It is much more meaningful to

*Karp, S.S.

,

"Alternatives for Geographically Locating SAR Cases,"

5/11/70

- 19 -
i i • 'N - ay

aup ftjp

:.) yr‘

’

: isoD -

' ;
Structure of SARSIM

For any programming system of the size and complexity of SARSIM,

there exists a strong motivation to construct it in a highly modular

fashion. The reasons for this are due to: (1) the economics of

operating the model modularly; (2) the greater efficiency and simplicity

of programming small, discrete modules; and (3) the advantage that the

different functional parts can be written in different languages, each

appropriate for its module.

A very natural organization for SARSIM was to divide the overall

model into three major functional blocks: the Preprocessor (PREPRO)

,

the Operational Simulator (OPSIM) , and the Postprocessor (POSTPRO)

The Preprocessor is a set of FORTRAN programs which prepares the

exogenous demand tape from the historical SAR data files. This demand

tape contains a chronological ordering of cases with their respective

attributes. The user can vary the caseload either overall or by

selected criteria, such as specific case parameters, to produce any

desired forecast demand scenario. The Operational Simulator is the

basic module of SARSIM. It is a discrete event digital simulation

written in SIMSCRIPT which models the assignment of the preferred

resource (s) and simulates the service of each case. It calculates

certain summary statistics for standard output and can produce an output

case tape for further detailed analysis by the Postprocessor. The

QUICK QUERY* information retrieval system is used to provide this analysis.

*Developed for the Economic Development Administration by Consolidated

Analysis Centers Incorporated, Santa Monica, California, U.S.A.

- 21 -
The economics of this approach are readily apparent. The

costly and time-consuming task of preparing an exogenous demand

tape can be done off-line in the Preprocessor. Once a satisfactory

tape has been generated, it can be used numerous times by the

Operational Simulator to compare the performance of alternative

system configurations (e.g.

t different resource levels, mixes,

locations, etc.) when using the same caseload scenario. The

most promising of these runs can then be investigated in more

detail via runs of the Postprocessor. This approach then can

eliminate much unnecessary repetitive processing.

A further advantage in the case of SARSIM is that nearly

all of the stochastic elements of the simulation can be resident

in PREPRO, leaving OPSIM relatively deterministic. In this way,

several runs of PREPRO can be made creating several different scenario

tapes, because each is started using a different random number

seed. (The program currently allows for ten different scenarios

to be generated during a single execution of PREPRO.) Summary

statistics are also output on each scenario allowing the user to

select an appropriate demand tape from those created. The selected

tape can then be input to OPSIM, which services these cases nearly

deterministically. (The only randomness in OPSIM is in the probability

of an on-line failure of the selected resource, and the probabilistic

reevaluation of the case's severity during its service.) This not

only makes OPSIM very efficient in its processing of the caseload, but

- 22 -
also fewer repetitions of OPSIM runs are now required because of

the small variance in OPSIM outputs due to these minor stochastic

effects. Similarly, as mentioned previously, a relatively deterministic OPSIM is far easier to validate than a stochastic representation.

Each of the three functional blocks of SARSIM is further

functionally modularized. The PREPRO organization is very straightforward; its five basic parts are: (1) a set of "cleaning routines"

to edit and correct errors in the data base; (2) a set of data

processing programs to sort and organize the data base such that it

is compatible with the requirements of OPSIM; (3) a program for

calculating additional case parameters required by the OPSIM

program; (4) a program for randomly generating caseloads; and (5)

a program for generating caseloads in their historic, chronological

order (for validation purposes)

The organization of OPSIM is based primarily on a partitioning of

the types of SAR cases encountered in actual practice. Although this

partitioning can be done in several ways, a very natural and manageable

categorization became apparent in terms of the multiplicity of resources

responding to a case. An examination of the SAR data base revealed

that about 85% of all cases are serviced by a single Coast Guard

resource, while the remainder required two or more resources. Further,

the simulation of the selection process for assigning the preferred

resource (s) to a case is conceptually very different from the simulation

of the servicing of a case. For these reasons, it was advantageous to

- 23 -
construct the Single Resource Assignment Subroutine (SRAS) as

the basic module of OPSIM.

Cases requiring a multiplicity of resources are handled by

the Multi Resource Assignment Subroutine (MRAS) . MRAS relies

heavily on part of SRAS in assigning the individual participants

to a multi-resource case. In addition, MRAS performs the scheduling

of the several resources on a given case, provides for continuous

coverage of the distress client, and simulates the coordination

necessary for such events as multiple (hand- off) tows and interrupt

of a resource involved in a multi-resource case.

Simulation of the service of both single and multi -resource

cases is performed by the Service Subroutine (SS) . In addition

to scheduling all the service functions that must be performed,

SS also calculates the statistics that are output at the conclusion

of the OPSIM run.

Because both the assignment rules and the servicing of long

search cases are very different than for non- search cases (as

was discussed previously) , a separate module for simulating long

search cases was constructed. The Search Assignment and Service

Subroutine (SASS) , as the name implies, simulates both the

assignment of resources to search cases as well as the service

of this portion of a case. If at the conclusion of a search the

client requires additional service, either SRAS or MRAS, as

appropriate, is called by the OPSIM Executive Routine (OPSIM EXEC)

- 24 -
to complete the case.

OPSIM EXEC performs similar control functions on other types

of cases as well as managing such interface functions as maintaining

queue discipline and interrupt control. It also handles such

"bookkeeping" functions as terminating the simulation of cases at the

appropriate time and calling the statistics and output programs within

OPSIM.

The Postprocessor is composed of two functional parts. The

File Definition and Maintenance (FDM) software is used to actively

create (define) the file of output cases from OPSIM, or to modify

an existing file, so that it is compatible with the requirements

of the QUICK QUERY language. The Quick Query Program (QOP) is used

used to passively access this file for data retrieval, manipulation

and display. Generally FDM is run only once for a given output

from OPSIM, while QQP may be run several times to obtain different

analyses and statistical printouts. This is another, although minor,

example of how the economies of operating the model modularly are

achieved via the SARSIM structure.

Model Assumptions

As a result of much analysis of the SAR data base, and discussions

with many Coast Guard officers having operational SAR experience,

together with the necessity of making simplifications because of

constraints on computer storage, execution time, etc., several

simplifying assumptions were made. The most major of these were

- 25 -
presented earlier under the Section "Scope." The more important

of the remainder are given below.

1. Primary Station Assignment

In the actual SAR system the assignment of a case to a shore

station is generally made on the basis of the stations’ geographical

"area of responsibilities." Because of the difficulty of treating this

in the model (due to complex, sometimes concave areas) , and because

these areas would have to be redefined everytime a station was added,

deleted, or its location changed, a simpler approach was taken. This

approach is that the station closes to the location of the case, from

among the station which handled the case historically and its adjacent

stations, is assigned as the primary station. Note that the historical

primary station does not necessarily serve the case in the model; this

is described more fully in Part II, Section 3A (SRAS).

2. Sequence of Events

The macroscopic sequence of events in SARSIM has been fixed in

order to prevent unnecessary complications. Thus, if any long search

requirement exists, it must be performed first. If the client is found

and requires further on-scene assistance, this is done next. Finally,

if a tow or escort is needed, this will be simulated to conclude the

case. It has been determined that very few exceptions to this sequencing

have occurred in actual practice.

3. A Priori Search Requirement

Consistent with the objectives of the search routine, discussed

- 26 -
earlier under "Level of Detail," the search requirement, in terms of

total search miles, is known for a case before the search begins. The

number of search miles to be searched in SARSIM is set equal to the

amount searched for this case historically. Again, search is a background activity simulated to account for expended resource time.

No attempt is made to optimize search procedures

4. On-Scene Needs

The type of service a case requires has been defined in SARSIM

as the need(s) of the case. Examples of on-scene needs (i.e., other

than search or tow) are firefighting, dewatering, provide equipment,

refloating, evacuate personnel, etc. The needs of a historical case

are determined indirectly from its SAR Assistance Report from the

three "Assistance Rendered" items (Figure 1). Since one need per

resource is required by the model (See ' 'Multi-Resource Cases"

assumption, below) a dominance pattern had to be created so that the

most important need per resource would be used. A description of

how this is done is given in Part II, Section 2 (PREPRO)

5. Equi- Capability

Given the need of a case, its location and the environmental

conditions, a subset of the district’s resources are checked in the model

to determine whether each is capable of serving the case. In so doing,

the assumption of equi -capability is made with respect to the resource

selection process. For example, if two different resources are both

capable of serving the need of the case, under the given environmental

- 27 -
conditions, regardless of the fact that the performance by one may

be superior to the other, each is considered as fully capable, for

purposes of resource selection. (Other factors, such as time of

response, cost, busy- idle status, home station, etc. are also

considered in the selection process for the set of capable resources.)

In other words, capability in SARSIM is a binary decision.

6. Tolerance Concept

Basic to the resource selection algorithm is the concept that a

distress client should be served within a given tolerance time which

varies with (five levels of) his distress severity. All resources

which are capable of serving the need of the client, under the existing

environmental conditions, witin the tolerance time are considered

equally satisfactory from a performance point of view. That is, a

resource which could arrive earlier than the tolerance time is not given

preference over one which would arrive later, but still within tolerance.

(A ranking based on cost is made to select the preferred resource

among those which can meet tolerance.) Only in the situation that no

resources can meet the tolerance time, will preference be given to the

faster resource.

7. Weather Conditions

Since actual historical cases are used in the generation of cases

(see ' Methodology for Generating Cases") , all weather descriptors for

a given case are consistent. This avoids, for example, the possibility

of having a case with 50 knot winds and calm sea state. However, using

- 28 -
the option of random generation of cases, it is possible to have

several simultaneous cases in the simulation system, but with different

weather conditions. This was considered acceptable by the Coast Guard

because it was felt that it was preferable to have internal consistency

within a case, rather than consistency across cases. To provide both

appeared to be a major effort, but one which would not produce

significantly better results.

8. Multi- Resource Cases

Since SARSIM is basically a model which accounts for the utilization

of resources, it is important that the simulation be able to replicate

this utilization fairly closely. In the case of multi -resource

responses to cases, it is difficult to determine from the cases’

Assistance Reports why the given number of resources were used on

a given case. That is, there exist many cases in the data base which

appear to be very similar, yet a different number of resources were

used on each case.

The basic assumption used for these multi- resource cases is that the

simulation will respond to the same number of needs that were responded to

historically. Although this approach has the disadvantage of limiting

the investigation of alternative numbers of resources in serving these

cases, it has the advantages of both simplicity of modeling as well as

accuracy in replicating history. It should also be noted that only

about 15% of all non- search SAR cases are multi -resource, therefore

the effect of this assumption is not dominant.

- 29 -
9. Output Measures

Although most of the outputs are derived straightforwardly, some

have inherent assumptions which need explanation for proper interpretation.

a. Exceptional Cases

These are cases which possess such unusual combinations of

attributes that they cannot be served within OPSIM.

This condition is usually due to an erroneous data item in

the Assistance Report; it may also be due a resource which

exceeded its rated capability historically to serve a case

in distress. Also, certain air escort cases can become

"exceptional cases" if unusual combinations of queueing

and interrupt occur. This was accepted to avoid modeling a

very complex situation which occurs for less than one

percent of the caseload.

b. Utilization Statistics

Utilization indices (in %) are calculated on the basis of

the total number of resources of a given category, rather

than on the number of "ready" resources. For example, a station

having five boats of different types and two crews (i.e., two

ready boats) which expended 72 hours of resource time on SAR cases

during a month, will have a utilization of 2.0% (based on the

five boats) rather than a utilization of 5.0% (based on the two

crews). This method was used because it would not be possible

^However, a read-out is provided automatically to describe any such

exceptional cases

- 30 -
to obtain utilizations of resource types if crew utilization

were used, since crews may serve on several different resource

types. It is also important to note that this index is not

used here as a measure of system performance, but rather as

a check on the model's validity. Therefore, as long as the

comparative historical utilizations are calculated in the

same way, there should be no misunderstanding,

c. Waiting Time

The assumption inherent in the calculation of waiting time of

a case is that is based on the first arrival of a resource to the

scene of the incident. It is therefore this arrival time minus the

case's notification time. Subsequent waiting, either due to delays of

other resources (for a multi -resource case) or due to interrupt of the

first resource after it has arrived on scene, is not included in the

calculations. This is based on the notion that a client's anxiety will

have been satisfied once the first resource arrives to assist him; also,

the first resource is likely to overcome quickly the critical part of the

incident in its first few minutes on scene. The remainder of the case

is usually of a more routine nature. The output measures "C Failures"

(cases waiting longer than their tolerance times) and "Demerit" (a

measure of excess waiting time) are also based on this same concept

of waiting.

- 31 -
REFERENCES

1. Benes, V. E. [1963] - General Stochastic Processes in the

Theory of Queues (Addison- Wesley, Reading)

2. Cobham, A. - "Priority Assignment in Waiting Line Problems"

Operations Research Vol. 2 (1956) pp. 70-76

3. Fortet, R. - "Definition Generate des Processus de Service et

Elements pour leur Theorie" Revue Roumaine de Mathematiques

Pure et Appliquees Vol. XII No. 9 (1967) pp 1235-1241

4. Jaiswal, N. K. - Priority Queues (Academic Press, 1968)

5. Karlin, S. and Me Gregor, J. - "Many Server Queueing Processes

with Poisson Input and Exponential Service Times"

Pacific J. Math 8_ (1959) pp 87-118

6. Kiefer, J and Wolfowitz, J

- "On the Theory of Queues with Many

Servers" Trans. Amer. Math. Soc . Vol. 78 (1955) pp 1-18

7. Keilson, J. and Kooharian, A. - "On Time Dependent Queueing

Processes" Am. Math. Stat. 31 (1960) pp 104-112

8. Kesten, H. and Rurmenberg, J. Th. - "Priority in Waiting Line

Problems" Proc. Akad. Walt. Amst A. Vol. 60 (1957)

pp 312-336

9. Schechter, M. - "On the Use of Computer Simulation for Research"

Simulation and Games Vol. II No. 1 (1971) pp 73-88

10. Skinner, C. E. - "A Priority Queueing system with Server-Walker Time"

Operations Research 15 (1967) pp 278-285

11. Takacs, Lajos ~ Introduction to the Theory of Queues

(Oxford University Press, 1962)

- 32 -
Part II. Details of the Simulation

1. Introduction to Part II

The Search and Rescue Simulation Model (SARSIM) is an event -oriented

computer program based on Coast Guard search and rescue activities,

as discussed in Part I of this volume. It is comprised of three

major program packages which may be employed flexibly to explore

particular sets of input conditions. The remainder of this volume is

devoted to comprehensive presentations for these major functional

blocks of SARSIM: the PREPROCESSOR (PREPRO) , the OPERATIONAL SIMULATOR

(OPSIM) , and the POSTPROCESSOR (POSTPRO) . Particular emphasis will be

placed on modeling the complex SAR system in OPSIM.

The simulation is designed to be exercised for a district, as

defined by the Coast Guard. Selection of the district level was

prompted by constraints imposed by limitations of computer storage,

plus the fact that there is generally negligible interaction between

districts except for the employment of long-range resources , such as

the C-130. The limited number of these special resources, which are

made available to any district on a given coast, are easily included

in the resource profile and are exercised in the simulation for those

cases requiring them.

The discussion of PREPRO explains the procedures and programs

entailed in generating an exogenous Demand Tape; the programs are

currently designed for use with the pre-Fiscal Year 1970 data format

- 33 -
of the SAR Assistance Reports prepared by the Coast Guard for each case

encountered.* The Demand Tape is then processed through OPSIM, where

service for the case is simulated and summary statistics are collected

and printed as standard output.

Finally, a prepackaged information retrieval system can be used in

POSTPRO. A great deal of pertinent information is offered as standard

output in the summary statistics provided by OPSIM, including utilization

statistics for each type of resource and each stations, some "failure” data,

and an exceptional case file (that is , cases which cannot be served) . These

data are highly aggregated, however, and may tend to mask out significant

items of interest. The prepackaged concept for POSTPRO is an exceptionally

attractive approach in that it provides a mechanism for filtering out special

summary information on selected types of cases of particular interest to the

user.

An overview of the structure of SARSIM is shown in the three related

sections of Figure 2. Individual cases, with their description attributes,

are prepared and ordered in PREPRO. Resources are assigned to provide

services for these cases in OPSIM, which also generates output data with

regard to cases and resources. More detailed analysis of the processed

cases can be conducted in POSTPRO to satisfy requests for special

information.

2. PREPRO - The Preprocessor for SARSIM

The fundamental purpose of PREPRO, the Preprocessor, is to prepare

*Treasury Department, U. S. Coast Guard, CG-3272 (revised 9-65)

Assistance Report.

- 34 -
PREPROCESSOR

Single

Resource

Assignment

Subroutine

SRAS MRAS

Multi

Resource

Assignment

Subroutine

Search

SASS

Assignment $

Service Sub.

POST PROCESSOR

Post Specialized

Process Outputs

Figure 2 SARSIM Structure

- 35 -
an exogenous DEMAND TAPE, which is used to drive OPSIM. This DEMAND

TAPE contains sufficient information about historically -derived case

parameters to pass control to appropriate subroutines within OPSIM.

Conceptually, PREPRO may be separated into three major components:

a report-editing routine, one for calculating case parameters for use

in a scenario, and a third for generating an ordered caseload. (A

fourth routine, the Case Assembly Processor, is also required to

sort and collect similar cases requiring the services of two or

more resources.)

Figure (3) shows the major subroutines and ordering of steps

within PREPRO. These are described in detail in the following sections

A. Cleaning Routines

A tape is prepared from historical SAR Assistance Reports,

organized by the Operating Facilities (OPFAC’s) within a given district

This tape is edited so that obvious errors are removed and there is

internal consistency of the data. The Cleaning Routine results in

an OPFAC FILE*. Those cases which required the services of two or

more units are sorted and collected on their multi -unit case number

to produce the CASE FILE, which then becomes the input to the Program

for Calculating case Parameters (PCP) of PREPRO.

In addition to those cases occurring within the district and

*The term "FILE" is used in the sense of an unordered collection

of case records. "TAPE” indicates a chronological ordering of case records.

- 36 -
Note: TAPE implies chronological order; FILE does not.

Figure 3

Major Steps in PREPRO

- 37 -
filed on the CASH FILE, special attention is given to those cases

served by the long-range C-130 aircraft, both within and outside

the district being exercised. These cases, filed on the C-130

TAPE, are input to the PCP for a detemination of their case

ULfll fjk - parameters. The C-130 TAPE is prepared from the caseload at the

air station from which the C-130's are deployed. For example,

the cases at Elizabeth City, N.C. which were historically served

by a C-130 are culled and written on the C-130 TAPE for the east

coast of the Continental United States.

B. User Controls in PREPRO

The 3AR Assistance Reports, as edited within the cleaning

routine, are the basic input to PREPRO, but subject to controls supplied

at the user's option. These options include specification of growth

rates in demand for services at particular stations or for specified

classes of clients, as well as the scenario description in terms of

maximum number of cases to be generated or calendar data limits. For

example, separate DEMAND TAPES can be generated for such scenario

descriptors as peak season and non-peak season.

C. Program for Calculating Case Parameters (PCP)

Using information from the CASE FILE, the PCP calculates parameters

required in OPSIM for each case, whether or not directly available

in the historical case records. The data base may be for a single

district for a single fiscal year or for three years, but all data

must be consistent in format. (A developed program permits

- 38 -
conversion of data from the Ji oldH

(pr©»-1970 format to the one currently

in use, but not conversely.)

Some of the data for the simulation can be taken directly from

the Assistance Report, while other data bad to be devised using

straightforward algorithms. Below is a list of case attributes

developed in PGP which are the input to DEMGEN. Some of these

parameters correspond directly to the pre-FY'197Q SAR data format as

described in USCG CQdDT INST 3123. 9A dated 31 March 1966. (Note

that this Preprocessor is designed fgsr the pre-FY70 data format

and that modifications must be made for any other format.)

- 39 -
Case Attributes Developed in PCP

1 . AIA: District in which the case occurred

2. STAND: Station number

3. A3: Case number

4. A4: Month and year the station was notified*

5. MINCI

:

Date and time the station was notified*

6. B3: Number of people on board

7. B5: Value of the vessel

8. B6: Air temperature

9. B8: Wind force

10. B9

:

Sea height

11. BIO: Visibility

12. B12A: Type of distressed vessel

13. L: Length of Vessel

14. S: Severity i.e., relative seriousness/urgency

15. n: Number of needs other than search or tow

16. m: Number of resources that towed or escorted

17. NN: Total number of explicit needs:

If n = 0 and m > 0, then NN = 1

If n > 0 and m > 0, then NN = n + 1

If n = 0 and m = 0 , then NN = 0

*These values are combined into OCCUR, the date and time of

notification.

- 40 -
18. 2T:

19.

20. S,

21. SV

The degree of non-parallel service on a multi -re source case. The range is 0 - 1,

where if - 1 is the series service of the case. See Section 3B (MRAS) for further

explanation.

Length of time spent on scene serving a multi

resource case. If t =0, then the case is one of the following: (a) search; (b) tow; (c) escort;

(d) search and tow; or (e) search and escort.

Equivalent number of resources operating in parallel

on a long duration search case. If S^ = 0, then

the case does not involve a long search prior to

serving any other needs.

Indicates if a short search is required before

serving the first need.

r 0, if there is no short search

1, if the resource serving the first need

also searches for the client

2, if an additional resource is called to

search for the client

22. TSM: The Total number of Search Miles on a case. If TSM

= 0, then both S^ = 0 and o. 23. MILES: The distance off shore

24. X Case location in nautical miles relative to a user input district origin. If the location

j

: unknown, it is assigned a location. This is

25. explained further in the text.

26. NEED(i) : Explicit assistance requirement of the case.

27. tos(i): Amount of time spent on scene for serving need(i)

tos (i) = 0 for search only and tow only cases.

28. A(i): Proportion of time into the multi -resource case completion that the subsequent resource commences

service. (0 - A (i) - 1)

- 41 -
The inputs requred to operate PCP are the following:

1. CASE FILE: The SAR Assistance Reports have been processed

through the Cleaning Routines and the inconsistences

removed (with Coast Guard assistence) . The Case Assembly

Processor assembles multi -unit cases and prepares the

CASE FILE. The CASE FILE thus contains all cases for a

given district single unit and multi -unit, sorted on date

and time of notification (earliest for multi-unit cases).

Area cases which required resources from the district being

exercised are also included and, in general, can be treated

as multi -unit cases.

2. C-130 TAPE: The C-130 TAPE contains all cases that were

served historically by a C-130 aircraft, from a single

air station, sorted by date and time of notification.

3. District Location Data:

(a) District Origin: All case locations are referenced

to an inputted district origin; (Origin Latitude and

Origin Longitude.)

(b) BETA: Coefficient for calculating distances. (See

next section)

.

(c) Unknown Case Location Data:

- 42 -
conversion of data from the ’’old" (pre-1970 format to the one currently

in use, but not conversely.)

Some of the data for the simulation can be taken directly from

the Assistance Report, while other data had to be devised using

straightforward algorithms. Below is a list of case attributes

developed in PCP which are the input to DEMGEN. Some of these

parameters correspond directly to the pre-FYl970 SAR data format as

described in USCG CCMDT INST 3123. 9A dated 31 March 1966. (Note

that this Preprocessor is designed fgtr the pre-FY70 data format

and that modifications must be made for any other format.)

- 39 -
The inputs requred to operate PCP are the following:

1. CASE FILE: The SAR Assistance Reports have been processed

through the Cleaning Routines and the inconsistences

removed (with Coast Guard assistence) . The Case Assembly

^Processor assembles multi-unit cases .and prepares the

1 h

CASE FILE. The CASE FILE thus contains all cases for a

given district, single unit and multi -unit, sorted on date

and time of notification (earliest for multi -unit cases)

.

Area cases which required resources from the district being

exercised are also included and, in general, can be treated

as multpL-unit cases. FiS (T

dCg&t

^

<^/3d

2. C-130 'TAPE: The C-130 TAPE contains all cases that were

3.

served historically by a C-130 aircraft, from a single

air station, sorted by date and time of notification. (U£*l£^> Pcf

^

<2A SC r <L<~ District Location Data : y

(a) District Origin: All case locations are referenced

to an inputted district origin; (Origin Latitude and

Origin Longitude.)

(b) BETA: Coefficient for calculating distances. (See

next section)

.

(c) Unknown Case Location Data:

- 42 -
i. For cases occurring in the district with no

location given, a location is assigned the Cartesian

coordinates (x^ + Ax, y^ + Ay) from the historic

primary station, i. Both Ax and Ay are user inputs

and apply for the entire district. The coordinates

(Xf, y.) are also input for: each station, i.

ii. For cases served historically by a C-130 aircraft

but with no location given, a location is assigned

corresponding to the district selected via Monte

Carlo techniques. A distribution of C-130

cases across the districts is input along with a

C-130 case centroid location for each district.

(This centroid represents that location where most

C-130 cases occurred in that district.)

(d) Search Speeds: For each resource type, L, the search

speed, SOA^(L) is required to calculate TSM.

(e) Information for translating the assistance rendered

historically, to property and personnel, into the needs

of the case used within the simulation.

(Note that the special cull conditions for removing certain

cases, (such as communications checks,) from the SARSIM Case File

and the decision point for distinguishing between a long search and

a short search are internal to the program, and not user input.)

- 43 -
The PCP processes a case at a time, generating the proper

parameters relative to whether the case is single resource, multi

resourced, or a search case. Figures (4) through (6) illustrate

the algorithms which make up.* the PCP.

Each case in the CASE FILE has case identifying data, distressed

unit data and reporting command data and resource data.

If the case is historically a multi-unit case, with multiple

command reporting data, then the date and the time the case arrived

to the system becomes the earliest time a Coast Guard station was

notified of the case. This is the minimum value of the set of Cl's,

the date and time the reporting command was first notified, called

MINC1. This Coast Guard station or the earliest reporting command

becomes, for the time being, the primary station. (The primary is later

recalculated in OPSIM EXEC as the closest of the set {P+A} , where P is

the primary and A are its adjacents.)

If the case is a single -unit case then the reporting command

becomes the primary again until modified by the OPSIM EXEC.

Those cases appearing on the C-130 TAPE must have their district

identified prior to assigning a primary station. For each of these

cases, the distance from the case location to the District Centroid

of each district is calculated and that district corresponding to the

minimum of these distances is assigned.

If no location is given for the cases appearing on the C-130

TAPE, then the district is assigned via the Monte Carlo of the

- 44 -
Figure 4

PCP Flow Chart

- 45 -
Figure 5

PCP Flow Chart (continuation)

-46-
te: Elapsed

spent on scene serving needs other

than search or tow

A(i): Proportion of

time into Case

completion resource

i arrived on scene.

X: Degree of

non-parallel

service of a multi -resourced

case

tes: Elapsed time

spent searching

(Long duration

search)

S* Average number

or resources searching during daylight

hours

Figure 6

PCP Flowchart (Concluded)

- 47 -
district in accordance with an inputted frequency distribution of

the 0130 cases across the districts of interest.

Once all the 0130 cases have been assigned a district, the

primary station can then be detemnined. If the case has been assigned

to a district other than the one being exercised, then the primary

becomes the station at which the 0130 ! s are based. (For example, on

the East Coast, Elizabeth City would be assigned as the primary.)

If the 0130 case occurs in the district being exercised, then no

primary is assigned. Instead, if there is no primary, then OP SIM

EXEC calculates the closest Coast Guard station in the district and

assigns it as the primary.

For each case, its location (latitude, longitude) is converted

to Cartesian coordinates, (x,y) relative to the district origin.

(Origin Latitude and Origin Longitude.) Latitude and longitude

are given in minutes. BETA is the length in nautical miles of a

3 degree of longitude at the district origin.

If the case has no given location, then a location is assigned

some inputted distance from the primary. (This scheme is not used

^

for those cases from the C-130 TAPE). Given that the primary, i, is

located at Cartesian coordinates (x^, y^) from the district origin,

then the case is assigned the location (x^ + Ax, y^ + Ay) . Both

3Bowditch, Nathaniel U. S. Government Printing Office, 1966 corrected print.

- 48 -
Ax and Ay are user input, and hold for the entire district.

If the case is from the 0130 TAPE, and has no location, then

the 0130 Case District Centroid is assigned, corresponding to

the district either calculated or assigned as described above.

Next, the OPFAC identification numbers are replaced by a

sequential station number, STANO, used in the simulation.

From the resource data records of a case, the total search time

of the case, D6T0T, and the total search miles, TSM, are calculated

by examining the hours spent searching and the resource type, L,

that searched historically. That is,

D6T0T = J D6(i), where, D6 (i) is the hours spent

i

searching by resource i; and,

TSM = 2 D6(i) * SOA^CL), where SOA^CL) is the search speed

th i

of the L

l type resource.

The variable MILES, the distance the distress is located off shore,

is determined in the following fashion:

1. If the code for B16, the Type of Distress Area, indicates the

case occurred less than a 1/2 mile off shore, then

MILES = 0.3 miles.

2. If the code indicates the case occurred less than 5 miles

off shore, but greater than 1/2 mile, then MILES = 3.0 miles.

- 49 -
3. If the code indicates the case occurred less than 10

miles off shore, but greater than 5 miles, then the

distance is taken as 8.0 miles.

4. For values of B16 exceeding 10 miles, the distance is the

value of B16. However, if B16 is unknown, then MILES = 10.0)

The severity, S, of the case is mapped in the following way in

an attempt to model properly the higher urgency of responding to cases

involving high danger to personnel. Thus, increasing values of

severity will indicate increasing seriousness:

1. If the code indicates the value (1), i.e.,no immediate

danger to personnel or property, it maps to a severity level

for simulation purposes as a (1)

.

2. If the code indicates a (2), i.e. , moderate degree of

danger to property, then it is mapped as a (2)

.

3. If the code indicates a (3), i .e . , moderate degree of

danger to personnel and property, then it is mapped as a (4).

4. If the code indicates a (4), i .e . , serious , involving

property only , then it is mapped as a (3)

.

5. Finally, if the code indicates a (5), i .e . , serious

,

involving personnel or personnel and property, then it

is mapped as a (5)

.

- 50 -
Each case input to OPSIM requires indicators to determine if

the client's location is unknown and a search must be conducted prior

to serving any of his needs. A short search is characterized by

a total search time, D6TOT, of one-half hour or less. If the

situation calls for a short search, it is performed either

by the first resource on scene or by a single additional resource,

called to scene by the resource first to arrive scene. From

the resource data, the earliest resource arriving to the scene

is examined to see if it historically performed the search. If so,

then the total search task is assigned to that resource and if not,

then an additional resource must have been called in, and the code

for short search, S2, is set to a 2.

If D6T0T exceeds a half-hour, then is coded as zero, and S^,

the average number of resources that searched for an extended

period is determined next. (See Figure 5.) is defined as the ratio

of the total resource time spent searching, D6T0T, to the daylight

hours of search. This implies that the developed value represents

the equivalent resources searching in parallel. To calculate S^,

the elapsed time spent searching on the case, tes, must be found.

For each responding resource, i, D4FRST(i), the clock time resource i

completed searching, is calculated as the sum of D4(i), the time

resource i arrived on scene, and D6(i), the elapsed time resource i

spent searching. The elapsed time, tes, becomes:

tes = MAX {D4FRST (i) } - Min (D4(i)}

i i

4Although not parameterized, this value may be changed by a simple

program modification.

- 51 -
Note tes includes the nighthours within the elapsed search time

of the case; thus the nighthours, NH, must be calculated and subtracted from tes.

The hours of daylight are taken as 14 hours. If tes does not

exceed 14 hours, then NH is set to zero. If tes is between 14 and

24 hours, NH becomes tes minus 14 hours. If, however, tes exceeds

24 hours, NH becomes tes/2.4 or the proportion of tes attributable

to night time. A constant is added to the ratio to facilitate rounding

up to the next whole resource. The brackets [ ] indicate truncation

to the largest integer. Thus, S

: is given by.

s

1

where,

D6T0T

tes-NH

+ .99

J

NH - 0, if tes - 14; or NH = tes -14, if 14 < tes £ 24; or NH = tes/2.4, if tes > 24

Once all the search parameters are calculated for the case, the

parameters relative to the serving of the remaining needs, including

tow or escort (i.e. non-search), are determined next.

The time each resource spends on scene, tos (i) , serving a need other than search, tow or escort is derived from the resource

From the data base, the following information is used: D8 Ci))

the total elapsed time spent searching; D3(i), the time the resource

was underway; D4(i), the time the resource arrived on scene; and D9(i)

- 52 -
the number of sorties. From the above, the expression for time on

scene as becomes:

tos(i) = D8(i) - D6(i) - 2 * D9 (i) * (D4(i) - D3(i)}

Corresponding to the time on scene is a specific need, NEED(i),

for each resource participating on the case. Again, each NEED(i) is

a service requirement other than search, tow or escort. Subroutine NEEDS is called to convert the historical assistance rendered

to personnel (Dll) and property, both primary (D12) and secondary

(D13) , to a single coded value required for each "need" (and for

each resource) in OPSIM. These translations, the basis of NEEDS, are

listed in Table 1. Note that some of the coded needs in OPSIM encompass

a number of different types of assistance rendered. The reader is

referred to Section III, of SRAS, and, in particular, the Resource

Capability Matrix, for a description of those resources capable of

performing these needs. Figure 7, Subroutine NEEDS, illustrates

the decision process necessary to translate the assistance rendered

(reported on each resource card) to a single need. D^ , the assisting

resource type, is queried initially. Personnel aided by an aircraft

preempt aid to property. If the assisting resource is an aircraft

and Dll is positive, then the need becomes the translated Dll.

If Dll is zero, and D12 is positive, then D12 need is recorded. If

both Dll and D12 are zero, then the need becomes 18, General Assistance

Rendered.

- 53 -
Table 1

Assistance Rendered; Translation to Need

If Dll is: Then the Need Becomes

Personnel in Position of Peril,

Rescued or Assisted by:

10: Attempted Rescued-Failed 16: Evacuate People

11: Boat or Vessel Pickup

12: Amphibian Water Landing

13: Helicopter Water Landing

14: Helicopter Hoist

15: Dropping/Providing Equip

.

L: Provide Equipment

16: Aircraft Landing on Land 18: General Assistance Rendered

17: Vectoring Other Unit to Assist Vector Other Unit

18: Personnel Assistance 16: Evacuate People

Medical Evacuation of Personnel by:

30: Boat or Vessel Pickup

31: Amphibian Water Landing

32: Helicopter Water Landing

33: Helicopter Hoist f

34: Diversion of Other Unit 5: Vector Other Unit

35: Vehicle or Personnel 18: General Assistance Rendered

36: Aircraft Landing on Land

Medical Aid Rendered to Personnel by:

40: Delivery of Doctor

-54-j
Table I (continued)

41: Delivery of Medical Supplies 1: Provide Equipment

42: Diversion of Other Unit to Scene 5: Vector Other Unit

43: Passing Medical Advice 18:

] General Assistance Rendered

44: Rendering First Aid 18: General Assistance Rendered

97: Recovered Bodies j 16: Evacuate People

99: Unclassified 18: General Assistance Rendered

If D12 or D13 is: Then the Need Becomes:

60:

r Attempted Salvage -Failed

. .

14: General Assistance RenderedSurface

61: Fought Fire 4: Fought Fire

62: Dewatered

1 6: Dewatered

63: Dewatered and Towed 15: Tow; Dewatered and Towed:

Refloated and Towed

64: Refloated 7: Refloated

65: Refloated and Towed 1 st Tow; Dewatered and Towed

,

66

67

68

69

Towed

Refueled or Resupplied

Escorted

Tugbird Tow

70: Delivered Pump by Vessel

Refloated and Towed

9: Refueled and Supplied

*

15: Tow; Dewatered and Towed;

Refloated and Towed

2: Delivered Pump § Equipment

*Need is 10: Surface Escort, if B13 indicates distressed unit is

not an aircraft.

Need is 17: Air escort, if B13 indicates distressed unit is an aircraft.

+or Need is 19: Rescue and Tow is Dll > 0 and D1 not an aircraft.

- 55 -
Table I (continued}

71: Delivered Pump by Air i

72: Freed Vessel from Ice 8: Icebreaking

73: Freed Distressed Unit 13:

1 Freed From Position of Peril

74: Made repairs 3: Made Repairs

75: Located Property and Advised

Owner

| 12: Located Property

76: Recovered Property ist Tow; Dewatered and Towed;

Refloated and Towed

77: Navigational Assist 18: General Assistance Rendered

78: Destroyed Menace to Navigation 14: General Assistance RenderedSurface

79: Stood by 11: Stood by

99: Unclassified 18: General Assistance Rendered

- 56 -
-Uo.

0 -Mn V D11>0?

jYes

NEED = 19

IRETlj

yS'Yes / \

D12 = T0W*s NEED = 18

' 1

. No Trancl a -ho -^nD13 = iuw*/

Dll to — t l , MEED

D12> 0? > No

V

1 Yes

Jfes / r

r Ndi3 = toi^ [ NEED = 15 yN° NEED = 14

.

H

*T0W; Dewater § Towed; Refloated and Towed

Figure 7

NEEDS Flow Chart

- 57 -
If the assisting resource is not aircraft and Dll is greater

than zero and D12 or D13 is tow, dewater and tow, or refloat and tow,

then the need is coded as a 19, rescue and tow. If D12 or D13 is not

a tow, dewater and tow nor refloat and tow, then assistance to personnel

predominates, and the need becomes the translated Dll assistance

rendered.

If the assisting resource is not an aircraft and both Dll and

D12 ate zero, then the need is coded as a 14, General Assistance

Rendered. If Dll is zero but D12 is not, then D13 is queried.

If D13 is a tow, dewater and tow, or refloat and tow, then the need

becomes 15, tow, dewater and tow, or refloat and tow. If D13 is not

a tow, dewater and tow, nor refloat and tow, then the need becomes

the translated D12.

The total number of needs, n, is determined by accumulating the

total number of resources other than those which searched, towed

or escorted. The value m is the number of resources that performed

a tow or escort. NN is determined according to those conditions

presented previously in Section 2C on page [13].

In order to simulate the degree of parallelism in the service of

a case, additional case parameters had to be extrapolated from the

data base. First, the elapsed time spent rendering aid (other

than search, tow, and escort) t tQi is found. For each resource i on

the case, D4FRST(i) is calculated, as described previously. (Recall,

D4FRST(i) is the time that resource i complete searching (if D6(i)

- 58 -
were greater than zero) assuming search commenced immediately upon

arrival on scene of resource i.) In addition, the time resource i

completes searching for the client, (if any search was involved,)

and servicing him, designated LVTM(i) , is calculated as the sum of

D4FRST(i) and tos (i) . t can then be calculated thus:

t = Max' (LVTM(i) } - Min {D4FRST(i)>.

i i

Next, in order to schedule subsequent arrivals of resources to

the scene of the SAR incident, A(i), the proportion of time into

case completion resource i arrived on scene to serve need i, is

found:

D4FRST(i) - Min {D4FRST (i)

}

A(i) = — 1

t - tos (i)

For the first resource on the case, A(i) is set to zero.

Finally, a, the degree of non-parallel service on a multi

resource case serving needs other than search, tow or escort, is

calculated as:

t - Max {tos (i) }

i

l tos(i) - Max (tos(i)}

i i

The reader is referred to the material on MRAS for a comprehensive

discussion of A(i) and a.

Once, the case is completely processed, it is output on the

SARSIM CASE FILE, the input to DEMGEN. When the end of file (EOF)

is reached, that is all the cases on the CASE FILE and the C-130

TAPE have been processed, PCP halts.

- 59 -
It is stressed that the case attributes have been developed

from the data base, i.e. the CASE FILE and the 0130 TAPE,

Essentially the case is reconstructed on a time line, and partitioned

Into the general order of search, if required; service of needs,

other than search, tow or escort; and, finally, tow or escort, if

required. In re-constructing the case from the data, inconsistencies

in the recording of the data have been overcome, so that the case

is simulated as closely as possible to the historical past.

D. The DEMGEN Program

The main objective of DEMGEN Is to prepare a chronological

CASE TAPE* from the SARSIM CASE FILE, which was an output from the

PCP. The user may choose whether the ordering should confom to

past history, or whether randomness Is to govern.

The first option, described in Volume III of this series as

a separate program called HIST, recapitulates historical precedent.

The user specifies inclusive dates of interest and DEMGEN creates

a CASE TAPE listing the cases of a given district in the historical

order of their occurrence during the period of interest, along with

the appropriate case parameters. This provides a mechanism for

simulating history, thereby enabling a comparison with simulation

results for OPSIM with the corresponding historical outcomes. Valuable

insights may thus be afforded into the simulation and validation processes.

*See footnote on page 36.

- 60 -
The user's second option is to have times of occurrence determined

by random processes. This option may be applied separately to the

cases occurring within the district and also to those historically

served by 0130 aircraft.

This second option preserves the correlation between an individual

case’s attributes and its relative time of occurrence, i.e.,the

concept here supports the fact that certain kinds of cases occur

at certain times of the year and are peculiar to the time of week

and time of day. Specifically, the output from PCP retains the

historical time of occurrence, and DEMGEN sorts these cases from the

SARSIM CASE FILE by predesignated time periods . These time periods

are:

1. Weekday Day cases in Peak season

2. Weekday Night cases in Peak season

3. Weekend Day cases in Peak season

4. Weekend Night cases in Peak season

5. Weekday Day cases in Non-Peak season

6. Weekday Night cases In Non-Peak Reason

7. Weekend Day cases in Non-Peak season

8. Weekend Night cases in Non-Peak season

Cases with all their attributes are stored in the computer

according to these categories or "boxes". That is, there exists a

file of cases for each of the above-listed time periods.

- 61 -
The arrival time of a case is generated by the Monte Carlo

technique from a set of interarrival time distributions calculated

from the historical times of occurrence. Inter-arrival times of

the district have been assumed to be exponentially distributed. The

concept of a set of these distributions attempts to model the changing

arrival patterns over the day. More specifically, for each of the

designated time periods, a distribution is developed for each hour

in the time period. The parameter A^. represents the average arrival

rate for the ith hour of the jth time period. This parameter is

estimated by examining the number of arrivals in a given hour over

the time period of interest for a given district.

For the random generation of case arrivals , a start time is given

to initiate the generation of a CASE TAPE. Given the hour and date

of the start time, a case is selected randomly from the proper file

corresponding to the time period. (Since sampling with replacement

is applied,the case is not removed from the file.) A random

sample is then drawn from the proper interarrival time distribution,

using that corresponding to the i^1 hour in the time period.

The reciprocal of this sample, At, represents the time from the start

time to the next case arrival. Thus, the time the next case occurs

is the start time plus At; this time, designated OCCUR, is the time

the case arrives to the system or requests assistance. OCCUR is

included as a case attribute and is output onto the CASE TAPE.

- 62 -
A new sajriple is dram from the distribution corresponding to

the time period of the latest OCCUR. The next time of occurrence of

a succeeding case becomes the sum of OCCUR and the new At. From

the proper time period file corresponding to this newly updated

OCCUR, a case is then randomly drawn. The procedure is continued

until the scenario limits have been reached, i.e., either the stop

time of the simulation or a user input upper limit on the number of

cases is reached.

It is desirable to prevent the generation of large interarrival

times. This situation can occur quite frequently when the arrival

rates (A^) are small. Without any limitation, a small A^ could

result in several time periods being bypassed, in which the A^'s

are greater than that A^. used to generate the long interarrival time.

Two schemes are offered to the user to help prevent this from happening.

The first scheme limits the generation of interarrival times to

3/A^ hours, truncating the asymptotic tail end of the exponential

distribution. (The cut-off, 3/A^. was chosen since this value

represents approximately 951 of the area under the exponential

distribution curve.) Thus, if the next interarrival time exceeds

3/A.

hours, OCCUR is updated to OCCUR + 3/A.

hours and the process

i] ij

continues with the new A. . corresponding to the new time period. Also,

ij

if any A. . is zero, then no arrival occurs and OCCUR is updated one

ij

hour and the new A. . is used to determine the time of the next arrival.

13

- 63 -
The second scheme checks for an arrival in every (i, j)

interval, but does not guarantee an arrival in that interval. If

the sampled interarrival time, At, exceeds 60 minutes, then a new

sample is drawn. The process is continued until the sample drawn. At

is no more than 60 minutes . Then the time of occurrence of this

new case becomes:

OCCUR (New Case) = OCCUR (Old Case) +

(n-X) *60 minutes + A^,

where n is the number of samples, and At is less than 60 minutes.

Each time a sample is required, it is sampled from a distribution

with the A^ corresponding to the interval currently being investigated.

A number of user options are offered to develop the desired

CASE TAPE. For example, mechanisms are incorporated to accommodate

the growth of cases via preselected logic switches if it is desired

to increase the case population across all the cases by XI. Similarly,

any set of A^’s may increased by XI, or any specific A^

can be increased by a given percentage.

For more specialized growth patterns involving particular OPFAC's

and selected case parameters, e.g. , clientele type, the user can

input his desired "IF" statements into the GROW routine. This software

"grows" the cases randomly at the proper rate and inserts them in

the proper files. This option allows the most flexibility (other

than by hand selection) in providing the user a mechanism for creating

a desired demand.

- 64 -
Figure 8 summarizes the DEMGEN operations. A random number

seed, RNSEED, may be input by the user, if desired.

Once all the cases have been generated in accordance with the

desired scenario, those C-130 cases in concert v/ith this scenario

are inserted chronologically with the cases already generated to

produce the CASE TAPE, if the historical date option for C-130

cases is taken. Should it be desirable to merge a Scenario Tape

with the CASE TAPE to produce the final DEMAND TAPE, this can be done

by writing a simple merge routine. If no SCENARIO TAPE exists, the

CASE TAPE obviously becomes the input to OPSIM.

- 65 -
DEMGEN Flow Chart - Figure 8

- 66 -
3. OPSIM The Ooerational Simulator of SARSIM ..I,.. . -p. «... „ ii

-V fc—, >-- . .. m ^• -,11 ^ .. 1 4J 1 c - - u Individual cases are processed through OPSIM using the data on

the exogenous DEMAND TAPE supplied by PREPRO. If required, a long-search

is simulated, followed by assignment of one or more resources to satisfy

needs for sendees other than search. (It should be recalled that location,

needs and other case parameters of simulated cases are based on historical

occurrences.) The overall structure of OPSIM is' included in Figure (2) on

page 35.

The OPSIM EXEC first examines the parameters of the presented case

before passing control to the appropriate subroutine. In addition, the

OPSIM EXEC calculates the distance of the case from the historicallydesignated primary station and also from adjacent stations, choosing the

closest of these as the primary station for the simulation: this is considered to be the station initially notified of the case and which has

primary responsibility for responding. For those cases which historically

had no primary station or a non-primary station, the OPSIM calculates

the nearest possible primary station in the district.

If there is a single client need (other than search) , control is

passed to the Single Resource Assignment Subroutine (SRAS) ; the Multi

Resource Assignment Subroutine (MRAS) is called if there are two or more

needs to be satisfied. For each of these assignments, the service is

simulated in the Service Subroutine (SS) . After each case has had its

needs satisfied, the Service Subroutine calculates summary statistics for

the Standard Output. Long search, however, has specialized calculations,

handled within the Search Assignment and Service Subroutine (SASS)

.

- 67 -
For the assignment of resources in SRAS or MRAS, OPSIM considers

both:

(a) Case attributes, such as needs to be met, case severity,

environmental factors, physical characteristics of the vessel

in distress and its location; and

(b) Resource attributes, such as status, location, ability to

satisfy the client's needs, ability to operate in the given

environment, and cost factors.

Resource selection in SRAS and MRAS is based on considerations of

cost to vector a capable resource to the scene of the incident, time to

transit to the scene, and case severity. In contrast, resource selection

in SASS also entails consideration of the cost for a capable resource to

cover the search area, the time required to cover, and severity conditions.

For both search and the satisfaction of other needs, the set of resources

eligible for consideration consists of those at the primary station and

its adjacent stations, as well as the air stations and cutters covering the

primary station.

The four major subroutines, SRAS, MRAS, SASS and SS, are described,

in that order, in the sections which follow.

A. The Single Resource Assignment Subroutine (SRAS)

(1) General Description

A large fraction of SAR incidents are served by a single resource.

For SARSIM, the Single Resource Assignment Subroutine (SRAS) forms an

ordered set of capable resources which could satisfy a single-need case,

The major steps are outlined in Figure (9) . The ordering depends on the

- 68 -
c

Single Resource

Assignment Subroutine

Select an Ordered Set

of Resources

See Figure 11

See Figure 12

c

Exit to Service

Subroutine SS

Major Steps in the Single Resource Assignment Subroutine

Figure 9

- 69 -
time and cost of transiting to the scene for each considered resource,

as well as policies for assignments prescribed by the user. In particular,

"queue discipline" and "server discipline" must be specified to determine

when service should be interrupted for cases of higher priority and the

extent to which nearby stations interact with one another. Further details of assignments and service will be presented in a later section.

(2) Required Inputs

Some of the inputs required in the exercise of SRAS are supplied from

PREPRO; others must be furnished by the user. The case attributes, from

PREPRO, may be grouped as follows to show where, within the total simulation, they come into play:

(a) Operational Capability Factors, which determine whether a

resource type is capable of servicing a particular need, depending on the values of the following attributes:

(i) Location of the case

a. Case coordinates

b. Distance off shore

(ii) Need(s) of the case (e.g., tow, dewater and tow,

refloat and tow, evacuate personnel on board, provide

equipment, deliver pump, make repairs, fight fire, etc.)

(iii) Type of distressed unit

(iv) Length of distressed unit

(v) Number of personnel on board distressed unit

(vi) Sea swell

(vii) Wind

- 70 -
(viii) Visibility

(ix) Air Temperature

(b) Supplementary Factors - Case attributes (i) and (ii) below

affect the Operational Simulator; (iii) and (iv) provide additional

information for the Postprocessor.

(i) Time of occurrence, OCCUR

(ii) Severity of the case, S.

(iii) Nature of distress (case type)

(iv) Value of the vessel

The user must specify the following inputs to OPSIM for each

simulation run:

(c) Station Inputs - For each station in the district:

(i) Location of the station

(ii) A list of the station’s "feasible” adjacent stations,

that is, those stations adjacent to the primary station

(including surface patrol areas) with resources that

might be sent to serve a case In the operating area

of the primary station.

(iii) A list of the aircraft stations and responsible cutters.

(iv)

(Responsible cutters are handled exactly like stations

in that a cutter is a station in itself which can serve

cases in the primary station’s area.)

Station’s Resource Matrix, including the number of each

resource type attached to the station; initialization

status data >i»e., busy or idle; and location.

- 71 -
(v) Crew Manning Level as it varies over the day and day

of week and the crew level at which a standby is

called.

(d) Resource Type Inputs

For each resource type, the following inputs are required from the

user:

(i) Resource Capability Matrix - This matrix, prepared by

the user in binary code, indicates the capability of each

resource type to respond to a case for each operational

capability factor and environmental factor permitted.

Figure 10 illustrates the form of this matrix. Capability

is assessed as being full 1, or absent, 0, relative to

each case attribute. Figure 10 is presented for illustrative

purposes only; these assessments can be varied by the

user.

(ii) Resource Reliability - For each resource type, a coefficient

defines the probability of '’failure" immediately prior

to assignment. Failure may result from unexpected malfunction, inoperability due to planned maintenance,

or both.

(iii) Resource Speeds of Advance - For each type of surface

resource, the speed can be modified as a function of sea

swell . For air resources , modification for wind was considered unnecessary. The resource speed of advance is used

to calculate the time for a resource to vector to the scene.

- 72 -
FIGURE 10

RESOURCE CAPABILITY MATRIX

W

Y

M T

R M

U U U B / H H TTT M M/WWWWW CUHH

CASE ATTRIBUTES B B B L L M P P Y M H 1 1 5 H

(L) CM) Cu) B B S B B T E E 3 6 2 3

40 ! 30’ 17' 44/52 36 B 95 82 L C C 0 E A F

Swell

0-5' 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

5-10* 1 0 0 1 1 0 1 1 0 1 1 1 1 1 1

10-20' 0 0 0 1 1 0 1 1 0 1 1 1 1 1 1

20' 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1

Wind

< 60 Kts

.

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

> 60 Kts. 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1

Visibility

< 1/4 Mile 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

1/4 - 1/2 Mile 1 0 0 1 0 0 1 1 1 1 1 1 1 1 1

> 1/2 Mile 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

- 73 -
FIGURE 10 (continued) (2)

Air Temperature

< 20 ° 0 0 0 1 0 0 1 1 1 1 1 1 1 1 1

> 20 ° 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Visibility

Offshore

0 - 1/2 Mile 1 1 1 1 1 1 0 0 0 0 0 1 1 1 1

1/2 - 5 Miles 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

5-10 Miles 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1

10 - 20 Miles 1 0 0 1 1 0 1 1 1 1 1 1 1 1 1

20 - 50 Miles 0 0 0 1 1 0 1 1 1 1 1 1 1 1 1

> 50 Miles 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1

NEED AND

RELEVANT FACTORS

Provide

Equipment 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Delivered pump/

Equipment 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Made Repairs 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0

Fought Fire 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0

Vectored

Other Unit 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Dewater 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0

- 74 -
FIGURE 10 Continued) (3)

Refloated 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0

Icebreaking 0 0 0 1 0 0 1 1 1 1 1 0 0 0 0

Refueled §

Resupplied 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0

Escorted 1 1 1 1 1

*1± 1 1 1 1 1 1 1 1 1

Stood by 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Located Property

§ Owner Advised 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Freed from

Position of Peril 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0

General Assistance

Rendered (Surface) 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0

Tow, Dewater § Towed7

Refloated 5 Towed

O' -301 1 1 1 1 1 1 1 1 1 1 0 0 0 0

30' -65' 1 1 0 1 1 1 1 1 1 1 1 0 0 0 0

65 -100' 1 0 0 1 0 0 1 1 1 1 1 0 0 0 0

100-200’ 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0

> 200' 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0

Evacuate (Rescue

(POB)

0 -5 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

- 75 -
FIGURE 10 (continued) (4)

5 -10 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1

10-18 1 1 0 1 1 1 1 1 1 1 1 1 1 0 0

18-25 0 0 0 1 1 0 1 1 1 1 1 1 0 0 0

> 25 0 0 0 0 0 0 1 1 1 1 1 1 0 0 0

Air Escort 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

General Assistance

Rendered 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Rescue § Tow 1 1 1 1 1 1 1 1 1 1 1 0 0 0
(A search speed is also included for each resource type,

to be used in the search routine, SASS)

.

(iv) Resource Operating Cost - This is the dollar cost per

hour for operating each resource type and is used to

calculate the cost for each resource to vector to the

scene for subsequent ordering of resources.

(v) Resource Type Ranking - This is a relative (ordinal)

ranking among the resource types by some user-determined

cost. It can be used in lieu of operating cost in the

final ordering of resource types prior to assignment.

(vi) Resource Underway Time - This is the time for a particular

resource type to get underway from its homeport. (Note:

resources on patrol should have no underway time, or startup time. Small boats and aircraft may have a short time

to get underway, but larger surface resources may require

several hours.) DLAY(L) for the L^1 resource type is input.

(e) Tolerance Time - This reflects the maximum acceptable waiting

time for a client, measured from first notification of the

incident. For each severity level, S, a time, TOL(S) , is input.

(If possible, assignments will be made for resources which can

arrive on scene within the limits set by TOL(S).)

(f) Resource Assignment Policy - The user chooses from a set of resource assignment policies, each of which describes a preferential ordering of the desirability of calling an adjacent

station and the desirability of interrupting another case.

These policies define the server discipline in the simulation.

- 77 -
(3) SRAS Logic

When a single-need case is processed in 0PS1M, control passes to

SRAS and, subsequently, to the preselected resource assignment policy

(RAP) . The Service Subroutine (SS) is executed to simulate client

service time and resource service time. (SS is discussed in a later section.)

Figure 11 shows the flow of operations of the first major step in

SRAS, selecting an ordered set of capable resources. Figure 12 illustrates

one of the resource assignment policies. It may be helpful to refer to

these flow charts during the ensuing discussion.

(a) Selecting an Ordered Set of Capable Resources to Service a Case.

Briefly, the problem of selecting an ordered set of capable resources

is accomplished by considering the case’s attributes, the resource's

capability to satisfy the case's requirements, the relative distances

between candidate resources and the case, the cost involved in

vectoring each resource and the time for the resource to get underway.'

Figure 11 indicates the flow of operations.

Step 1 : The first step is to determine those resource types

which are capable of serving the case. The Resource Capability

Matrix (Figure 10)is accessed for the appropriate rows corresponding to applicable value for each of the case's attributes. These

rows are then "ANDed" by the Boolean operation, and the result,

a binary list, indicates capable resources. A zero indicates

that the resource is incapable of serving this case; a one indicates capable resources. A zero indicates that the resource is

incapable of serving this case; a one indicates capability.

- 78 -
Step 6

Figure 11

Select An Ordered Set of Capable Resources

- 79 -
Figure 12

Modeling the Assignment of a Resource to Service Case

- 80 -
To illustrate, consider the following case: A 42’ boat with 3

people on board requires a tow from 15 miles offshore. The environmental conditions include air temperature of 68°, visibility beyond

a 1/2 mile, wind at 20 knots, and swell of 6'.

From the Resource Capability Matrix, the appropriate rows are

selected (rows 2, 5, 9, 11, 15, 33, 37). Now, "ANDing" these rows,

the result is:

100110110110000

Interpreting this result, we find that the resource types which can

serve the case include:

UTB (L)

MLB (44 $ 52)

MLB (36)

WPB 95

WPB 82

WMEC

WHEC

Step 2: The second step is to retrieve from the Station Resource

Matrix for the station, its adjacents, its covering aircraft

and patrol boats, those resources corresponding to the capable

resource type list. It should be noted that the station referred

to above is also a case attribute, and is, therefore, known at

the time the case enters SRAS. This station does not necessarily

answer the case. It is used as a mechanism for identifying a

- 81 -
subset of resources within the entire district, which could

answer the case. The result is a list of capable resources

which are within "answering" range.

Step 5 : Using the location of the case and the locations of

the capable resources found in step 2, the time it takes each

resource in the list to vector to the expected location of the

case, t er

,(K), is computed.

Step 4 : Since the case enters the system with a given severity,

S, the tolerance, TOL(S), can be compared to t (K) + DLAY(L),

where t

vec 00 is calculated in step 3 and DLAY(L) is retrieved for

each resource (if at homeport) . If there are no t

C

(K) +

DLAY(L) which are less than or equal to TOL(S), then step 5

is executed. Note: DLAY(L) is used only if the resource

is to be vectored from its homeport to the expected case

location

.

Step 5 : The capable resources for which t (K) + DLAY(L) does

not exceed TOL(S) are ordered by increasing cost. The resources

which cannot meet the TOL(S) criteria are ordered on increasing

t (K) + DLAY(L). These two lists are then merged, first

V CL

by cost and then by time. As part of the design, the user is

offered two methodologies for ordering capable resources. It

may be recalled that the user may opt for calculating the cost

for each capable resource to get underway and vector to the

expected location of the case, with the result used in the ordering process; alternatively, he may choose the resource type ranking to order the capable resources. The selection of the

- 82 -
methodology is under use control. Once the ordering has

been completed, the preselected resource assignment policy

is then executed with this final ordered capable resource

list.

Step 6 : This step is entered if no resources satisfy

tyec (K) < TOL(S). The capable resource list from step 3 is

ordered on increasing t

C

(K) + DLAY(L). Cost is not a

factor in this situation.

(b) Resource Assignment Policies

These policies offer the user the opportunity to select a set of

rules which govern the operational procedure, at the primary station, in

calling for assistance from its adjacents, covering aircraft and cutters.

(Covering aircraft and cutters can be included for every station, primary or adjacent.) These plans offer a wide diversity of operations,

from pure station autonomy to an interactive station grouping policy.

In addition, these policies offer the user the opportunity to test

various interrupt rules in the resource selection process.

Each policy contains a decision block which ascertains the

status of a capable resource, busy or idle; this also considers crew

availability. If a crew is not available, the resource cannot be

assigned. More precisely, this decision block could be entitled "Is

there an idle resource and an available crew?" This block will be discussed further in a later section.

Basically, each policy assigns an idle capable resource with an

available crew to the incoming case. Some policies allow the

- 83 -
interrupt of a busy resource if the incoming case's priority is

higher than those cases already being served.

A policy is preselected through the user inputs, and is called

via a logic switch. Using the logic switch scheme, additional plans

can be designed, added, and offered to the user. Policy 1 is detailed

here in the text as an example . The additional plans offered

are outlined in. the text below.

(i) Resource Assignment Policy 1 (RAP 1)

Policy 1 considers the idle resources at the primary and

adjacent stations sequentially, then considers interrupting

busy resources at the primary and adjacents sequentially

if the new case has a higher priority than those cases

already undergoing service by these stations. Figure 12

shows the logic of this policy.

Step 1 : Examine the idle resources, R's,at the primary

station, P. (Primary includes covering aircraft and cutters.)

Select the first idle resource from the Ordered Capable

Resource List. Proceed to Step 6 for service of the case.

Step 2 : If there are no idle resources at P, examine the

idle resources at all of P's adjacent stations. Select the

first idle resource at the adjacent stations, A, from the

Ordered Capable Resource List. Proceed to Step 6 if one

is found.

Step 3 : If there are no idle resources at either P or A, and if

the case has a higher priority than those cases being served

- 84 -
at P or A, then interrupt a busy resource at P, serve the

case in step 6, and queue the interrupted case. (The wait

time in the system of the interrupted case and his interrupt

count are updated for output purposes.) The interrupted case

is treated as a new arrival to the system by subroutine QUEUE,

which queues the interrupted case, (if possible another capable resource is located to serve the interrupted case.) QUEUE updates

and records the following information for output purposes:

a. NOINT: The number of times interrupted.

NQUE: The number of times case enters a queue.

REA: The (first) reason for being placed in the queue.

PRI, the priority of the case is increased by IDELTA (user

input) to give some preference to interrupted cases.

Step 4 : Step 4, at A, is analogous to step 3 at P; it is

executed if either an idle resource cannot be found at P or

A, or a busy resource cannot be interrupted at P. If a resource cannot be interrupted at A, proceed to step 5.

Step 5 : Queueing the case delays the start of the service

of a new case or prolongs an interrupted case. A case is served

when a capable resource becomes idle via EXQ subroutine. If

the arriving case is of lower or equal priority than others

undergoing service, it must wait for a capable resource to become

idle. A non- interrupted queued cane retains its original

arrival time to the system. The interrupted queued case takes

the time of interrupt as its arrival to the system. (This ,

- 85 -
in effect, causes the simulation to find an idle capable

resource for the interrupted case.)

Step 6 : Control is passed to the Service Subroutine (SS)

once the resource has been assigned. The ©lapsed times for

the resource to get underway, vector to the case, serve the

case and return are simulated in this routine.

(ii) Additional Resource Assignment Policies

Most of these policies model a number of "server disciplines,"

such as a queue discipline other than priority interrupt.

These policies range from complete station autonomy to

station grouping,

a. RAP 2: This policy, considered to be similar to the current

operational procedure, examines the idle resources at

P; considers interrupt at P; examines idle resources at

A; considers interrupt at A; queues the case or the

interrupted case; exits to SS. Briefly, the steps are:

P; P Interrupt ;A; A Interrupt; Queue.

b. RAP 3: This policy groups the primary station P, and the

adjacent stations A. The steps are: (P + A) ; (P + A)

Interrupt; Q.

c. RAP 4: This policy models station autonomy in that the

primary P is considered alone. The steps are: P; P Interrupt;

Q.

d. RAP 5: This policy considers no interrupt and station

autonomy. Priority ordering is allowed in the queue. The

steps are: P; Q.

- 86 -
e. RAP 6: This policy is only applicable for multiresource and search cases. The steps are: P; A; Q.

This is further described in the MRAS documentation.

Note, a simple first-in first-out (FIFO) queue discipline can

be modeled within each policy by letting the priority of all cases take

on the same value. This could be done with a minor modification to

PCP in PREPRO.

(c) Resource Idle and Operational and Crew Availability (RIOCA)

Within each resource assignment policy, the question of idle

resource occurs at the primary station in resource assignment policies

1,2, 3, 4, 5 and at the adjacent stations in policies 1, 2, 3 and 6.

This takes into account the operational status of the resource and the

availability of the crew. That is to say, when the ordered capable

resource list is queried, in the preselected resource assignment policy,

the question of on-line failure of the resource type and crew availability

at the station to which the resource is attached, is also asked. (See

Figure 13 for the flow of operations.) If the resource is idle, control

passes to the assessment of operability of the resource, step 1. This is

accomplished via Monte Carlo and comparison of the sample with the resource’s

reliability coefficient. Reliability is a function of resource type.) If

the resource is operational, control passes to step 2, which queries the

crew status at the station to which the resource is attached. If a

crew is immediately available, the crew is assigned to the resource and

the resource is assigned to the case. A call to subroutine SS is then

made. If the crew is not immediately available, a standby crew is called

- 87 -
- 88 -
up with a given delay time (if provided for by the user) . If the

resource is not idle or if the crew is not available, control is passed

back to the preselected resource assignment policy, RAP, where an

attempt is made to find a capable resource at the primary (or adjacent)

station (depending on the RAP) . Again, an available crew is also

sought in RIOCA along with a determination of the resource's status

and operability.

The user of the simulation is offered the option of including

the policy of calling up a crew which Is on standby by means of a set of

codes for the variable CL. If CL is set to -1, the user excludes

the policy of call up. If the user selects 0 or 1 for the value of CL,

then a standby crew is called when the number of crews available (and

not busy) reach the preselected level, 0 or 1. Checks are included

in the program so that only a single standby is called per case.

B. The Multi -Resource Assignment Subroutine (MRAS) of OPSIM

(1) General Description

This section describes the assignment and scheduling of resources

to aid those SAR cases with two or more needs, exclusive of the requirement for search. (Assignment of resources for the search need is

simulated in SASS, described in Section 3C, beginning on page 101.)

The Multi -Resource Assignment Subroutine (MRAS) may simulate the assignment of two or more resources from a single responding station, as well

as resources assigned from two or more responding stations.

Resource assignment in MRAS is based on such case attributes as

client's needs, case severity, environmental factors, physical characteristics

- 89 -
of the unit in distress , and case location. In addition, resources are

examined on the basis of their capability to serve the case needs,

ability to operate under the environmental conditions, and the status,

location and cost of each resource.

Paralleling the dynamics of search and rescue, clients are served

in the simulation in the following general order of need: if required,

the client is located through search; any needs beyond search are

served on scene, if possible; finally, if required, the client is towed

or escorted. Multiple services other than hand-off tows and escort may

be performed simultaneously, in sequence, or some intermediate combination

of series and parallel operations.

To minimize scheduling problems for several resources to serve

multiple needs other than search or tow, the simulation treats each

need of a multi -resource case as a new arrival into the system. This

is equivalent to converting a multi -resource case into a set of single

resource cases, each one with an associated arrival time and service

need. Details of scheduling are provided in section (3) of MRAS, below.

Two difficult problems arose in MRAS with regard to distinguishing

between single and multiple needs. On the one hand, there are operational

situations where resource selection is based on the capabilities of a

single resource to service several needs. Conversely, a single need

may be partitioned so that several resources must be assigned to service

it. This latter problem is posed, for example, when several resources

are sent to fight a major (but single) fire.

To facilitate the handling of the first type of problem, multiple

needs served by a single resource were treated as a single need in the

- 90 -
simulation. The partitioning of a need to justify assigning several

resources was not modeled; rather, a one-to-one correspondence exists

between the number of resources historically assigned to the case and

the number of needs simulated in OPSIM.

Since the multi -resource case is basically a set of single resource

cases with associated needs, MRAS utilizes the fundamental logic of

the Single Resource Assignment Subroutine (SRAS) . An ordered set of

capable resource types for each need of the case is found, as in SRAS;

a resource is assigned from this set according to a strategy selected by

the user, or in the case of station autonomy by setting a user switch.

Each strategy defines the ’’queue discipline” (e.g., priority interrupt)

and ’’server discipline” (e.g., level of station interaction).

Each multi-need case is first partitioned into a set of single

resource cases. A subroutine then creates the associated arrival times

for each member of this set according to the time required on scene to

serve the need, and the degree of parallel service of the needs of the

case. The initial arrival of the case to the system is preserved for

the first need.

Each case has an ordered set of needs, created in PREPRO. Conditionality of needs is preserved partially by the macroscopic ordering approach

to handling the case's search requirement, its needs beyond search, and,

finally, the tow or escort need, if necessary. However, the needs other

than search, tow and escort are considered independent, and no hierarchical

order is preserved except that they may be ordered in time, according to

the case history. To explain, those needs other than search and tow

- 91 -
(or escort) , which are treated independently, can be queued in the

simulation and served out of historical order.

During the service of a multi -resource case an attempt is made

to provide continuous coverage of the client. This is simulated in the

Service Subroutine, SS, but cannot be guaranteed should a case with

higher priority arrive to the system and preempt a multi -resource case

being covered.

(2) Required Inputs to Operate MRAS

MRAS inputs are essentially the same as those for SRAS. A few

additional case attributes are generated in PREPRO especially for

multi -resource cases. These include:

(a) The 'degree of non-parallelism in servicing the particular

multi -resource case, (y) .

(b) The proportion of time into case completion the subsequent

resources commence service, (A(i)).

(c) The on scene time for each need except search, tow or escort

(tos(i)) .

(d) The primary station - the Coast Guard station receiving the

distress call (as determined in PREPRO)

.

The user inputs remain the same as in SRAS, but also include a switch

(INTRAP) to override the preselected resource assignment polic;y. In addition,

the hand-off distance for tow (or escort) cases (HO) must be input.

HO is the minimum hand-off distance from shore for the tow (or escort)

situation. The assumption is made that hand-offs occur at a distance

HO or greater from the tow (or escort destination) , thus preventing the larger

resource from towing (or escorting) into waters not safe for its navigation.

- 92 -
(3) MRAS Logic

When a case requires the service of two or more needs, the

OPSIM EXEC passes control to MRAS if the case has no long search

requirement. Control is also passed to MRAS from SASS if, at the

conclusion of the search, additional service of more than one need

is required. Additional notifications of this case are created and

an ordered set of capable resources are found at each notification

time. Once this set of capable resources has been determined, control

is passed to the preselected resource assignment policy (or the

redefined policy, based on the user's input relative to the resource

selection in SRAS and the desired level of station interaction.) When

a resource has been assigned from the set, (SS) is executed to simulate

the service of the client’s need. Pertinent statistics relative to the

client and the resource are also calculated in SS.

Figure 14 shows the flow of operations for the first steps of MRAS,

i .e. , scheduling the set of subsequent notification times for the needs

of a multi -resource case, excluding search, tow or escort. These notification times are the stimuli to the system for assignment of resources

to serve this case's needs. Figure 15 illustrates how a set of capable

resources is determined and how the user-controlled switch selects the

proper resource assignment policy should certain station autonomy policies

be indicated by the user. These steps are elaborated in the ensuing

discussion.

(a) Scheduling a Set of Notifications for a Multi -Resource Case

To simulate the dispatch of subsequent resources to service the

needs of a case, certain case attributes had to be calculated in

- 93 -
Figure 14

Multi -Resource Assignment Subroutine

- 94 -
NOTIF

Figure 15

NOTIF
PREPRO relative to the elapsed time of the case and the delay between

the arrivals of subsequent resources to the scene of the incident.

These attributes include the degree of non-parallel service of the

case, and the delay of the commencement of service on scene of the

"i" subsequent needs, A(i).

The service of a typical multi -resource case is shown in Figure 16.

In this situation, three needs require servicing, but none are search,

tow or escort. The first resource is dispatched at t^ and takes t

vec

(l)

amount of time to traverse to the scene; client is located immediately,

and service commences at t

2

« The two additional resources arrive on

scene at times t^, and t^. The resources spend tos(l), tos(2) and tos(3) on

scene, respectively. The elapsed time, t

0

, that this case is serviced on

scene is defined as the time elapsed between t

2 and t^. When simulating

such a case, it is possible that the service of the (three) needs be

either in series or in parallel or somewhere between these two extremes.

Referring to figure 17, the range of t is given by: n Max (tos(i)} < t < £ tos(i),

where the lower bound is strict parallel service and the upper bound is

strict series service. The maximum number of needs other than search,

tow or escort, is "n”. The calculation of t is made from the following

equation:

n

t = Max (tos(i)} + y[E tos(i) - Max (tos(i)}]

e

i

where , 0 < y <, i

Note that when y

=

0, the case is served in parallel; conversely, when

Y

= 1, the case is served in series. Figure 17 only suggests a

- 96 -
*

*2

I* tos(l)

I

t

5

4

4

: i *i

tos (2)

iH- .tos (3)

Legend

V

t

3

:

t

4

:

t

5

:

t

6

: V

System is notified case has occurred. Equivalent to OCCUR.

First resource arrives on scene.

Second resource arrives on scene.

Third resource arrives on scene.

First resource leaves scene after expending tos (1) amount

of time on scene.

Second resource leaves scene after expending tos (2) amount

of time on scene.

Third resource leaves scene after expending tos (3) amount

of time on scene.

t

veC

(l) : Amount of time the first resource spends traversing to the

t : e

scene

The elapsed time the client is provided Coast Guard

assistance, on scene, but not including search or tow.

Figure 16 . Line Illustration of the Service of a Multi -Resource Case

- 97 -
distribution on y,of the type which might in the future be used to generate

f by Monte Carlo methods . (This might be appropriate if all other case

attributes were obtained via Monte Carlo.) In the current configuration,

fis determined from the case record in PREPRO. (See the PREPRO

discussion.)

The parameter A(i) insures that the notification time to the system

for need "i" occurs such that the resource could expend its tos(i)

within t . This A(i) can be viewed as the degree of parallelism among

the resources serving a multi -resource case. Its range is given by:

0 < A(i) <1. Conceivably, the elapsed time could later be lengthened

should any of the selected resources not be able to arrive on scene within

the required tolerance. (See Figure 17 for an illustration of A(i), for

the general case.) Subroutine SNEED (see figure 14) , using tos (i) , y

and A(i), calculates t^, and the set of notification times (NOTIF(i)}

for this case. Each MOTIF (i) is given by:

NOTIF(i) = OCCUR + A(i) [t - tos(i)] -TOL(S)

where OCCUR is the notification time of the case . OCCUR will be updated

to the time at which the client is found, should MRAS be entered

from SASS. (The reader is referred to the discussion in PREPRO on page 59

for the derivation of A(i) from the case record.)

At the notification times, i.e., each member of the set (NOTIF(i) }

,

control is passed to NOTIF. N0T1F finds a capable resource and selects

the proper RAP.

- 98 -
A

f

r=o

parallel

T

y=l

(series)

Illustration of a Suggested Distribution on y

A Ci) [t. -tos(i)]

- t <4-T0L(S)—

/b i NOTlF(i)

i

Legend

! i Illustration of AQ.) General Case; Figure 17

t^: Notification of the case arrival to the system, OCCUR.

Latest possible arrival on scene of first resource within

tolerance, TOL(S).

t,: The system is notified of the requirement of service of the

ith need.

t,: Latest desirable time a resource can arrive on scene to

commence service of the ith need, within tolerance TOL(S)

t^: Latest time a resource can arrive on scene to commence service,

t^; Service ceases

Figure 17: Illustrations of - Destribution and A(i)

- 99 -
If the case is a multi -resource tow or escort (a hand-off tow

or escort) with no previous needs (other than long duration search) , then

subroutine NOTIF is called at OCCUR, i.e., when the case arrives to the

system or when the client has been found. For the first resource assigned

to serve the tow need this procedure is followed. However, the subsequent

requests for resources to tow (or escort) are handled in SS, the Service

Subroutine. A comprehensive discussion is offered on this subject in the

section describing SS* Also, should the case require the service of a

single tow or escort after other heeds have been served, this, too, is

handled in subroutine SS.

The process for selecting a set of capable resources is the same

as in SRAS, (See section 3A(3) of SRAS on page 78 .) That is steps 1, 2,

3 and 4 of SRAS are executed for each need triggered by each NOTIF(i).

Once an ordered set of capable resources has been found, the proper

resource assignment policy, RAP, is applied to this set.

(b) Selecting the Correct RAP

The user selected resource assignment policy is input relative to

the single resource assignment scheme. For simulation of multi -resource

cases, however, an internal switch may be set to allow adjacent stations to

participate on multi -resource cases, whereas station autonomy applies

to single unit cases.

Referring to Figure 15, with RAP 4 (P, PI, Q) and INTRAP = 1, the

computer redefines the RAP for multi-resource cases to be RAP 2 (P, PI, A,

AI , Q) . Similarly, should the user select RAP 5 (P, Q) , then the RAP is

redefined as RAP 6 (P, A, Q). If RAP is 1, 2, 3 or 6, then the selected

RAP is executed

.

*See page 123 - 100 -
(c) Interrupting the Service of a Multi -Resource Case

Should a resource serving a need of a multi -resource case, (other

than search, tow or escort,) be interrupted, that need of the case is

queued. This does not necessarily affect remaining needs. However,

the client can neither be towed nor escorted until all the other needs

have been serviced. In other words, the macroscopic order of service

of the case is preserved; that is, searching for the client must be

completed before any need is serviced; and all the needs must be

serviced before the client can be towed or escorted.

C. The Search, Assignment and Service Subroutine (SASS) of OPSIM

(1) General Description

The approach to modeling long search cases is quite different from

the approach for serving other needs, for which no consideration is given

to time spent on scene. (Usually, time on scene varies little from one

resource to another when servicing non-search needs.) For search, however, the time required to search a given ’’area" varies greatly with

resource. (Note: search "area” will be carefully defined below.) The

primary objective when searching is to select a resource which can

cover the greatest fraction of a specified search ’’area” within a time

tolerance or before sunset and, if possible, at least cost.

The duration of a search may be classified as "long" or "short",

and is determined in PREPRO. Short searches* are simulated through SRAS

or MRAS, and are generally exemplified by resource arrival to service

a need other than search, but inability to locate the client immediately.

This often derives from erroneous position report or drifting from the

*One half-hour or less.

- 101 -
reported position. In contrast, long searches, such as overdues, may

last as long as a week or more and may consume considerable resource

time. Furthermore, there may be additional needs when the client is

located

.

It is important to note that the basic use of SARSIM is for planning

involving resource allocation and utilization. Consequently, SASS location

processes are limited, for the objective is not related to search

techniques and tactics , Although future models might perhaps investigate

search tactics, more detailed descriptions of cases would be required.

The present data base in inadequate to allow estimates of detection

probability. For example, neither search width, nor track spacing, nor

search pattern, nor search area dimensions are given on the assistance report. Nonetheless, it is possible to extrapolate the number of linear

search miles for each participating resource from the hours spent searching.

Therefore, the term search "area" is defined in terms of these linear

search miles. Given this limited amount of data, the approach of covering

an acceptable portion of the required linear search miles in a given

tolerance time (or prior to sunset), for a minimum cost is reasonable.

(2) Summary Description of SASS

The typical operational response to a need for search is the

assignment of at least one resource, regardless of time of occurrence,

if at all possible. This philosophy was incorporated in the modeling effort.

Should the case occur after sunset, one resource is sent to the scene,

if available. The case is then scheduled for further service, if necessary,

- 102 -
and resources are scheduled to arrive on scene at sunrise of the

following morning. This procedure is followed in order to provide a

timely response , Keeping in mind that nighttime searches are generally

relatively ineffective, the bulk of the search effort is scheduled for

daylight hours. Should the case occur between sunrise and sunset of a

given day, resources are sent to search in order to cover as much of the

search ’'area” as possible before securing for the night at sunset. The

search for a client would then continue the following day during the

hours between sunrise and sunset until the total number of search miles of

the case are exhausted (and the client found, or the search called off).

Endurance limitations, either because of refueling or crew change

requirements, of each resource type in the inventory are taken into

account in the assignment of the resources to the case, and in scheduling

subsequent sorties. This is a user input expressed in hours for each

resource type. (See Table ). Refueling is also scheduled when

necessary and requires subsequent sorties. The time it takes to refuel

is also listed in Table 2

The PREPRO examines the history of each case in the data base, including hours spent searching, elapsed time of the case, and the search

speed of the resource that responded to the case, to develop the equivalent number of resources (operating in parallel )that participated in the

search (S-^) , and the total linear miles covered in the search (TSM)

Since it is operationally desirable to assign an aircraft/surface

resource mix to a search case, the total linear miles are allocated to

the resources assigned to the case. This allocation or fractional split

- 103 -
FUEL TIME

ENDURANCE REFUEL

RESOURCE TYPE (HRS.) (HRS.)

UTB(L) 14 0.5

UTB(M) 14 0.5

UTB(U) 5 0.3

MLB(44-52) 14 0.5

MLB 36 14 0.5

MRB/MSB 14 0.5

WPB 95 120 1 WPB 82 1 WYTM/WYTL 120 1 WMEC UNL+

8

WHEC UNL+

8

C-130

12*

* 0.5

HU16E 12* 0.5

HH52A 4.5 0.3

HH3F 6.0 0.3

+ 999 Hours

*Assumes Double Crew

TABLE

Fuel Endurance and Refuel Time (Hrs.)

- 104 -
is a user input, the only requirement being that the fractions must

add to unity. To demonstrate this concept, consider a case requiring

two search resources . Hie user input for the split between two search

resources could be, for example, 0.70 and 0.30. Using the assignment

criteria, most likely an aircraft would be assigned to cover 0.70 of

the total miles while a surface resource has a good probability of being

assigned the remainder, 0.30. Recall that the assignment criterion

is based on the least expensive resource that will cover an acceptable

fraction of the desired amount of search "area” within tolerance or

before sunset.

One additional user input helps to control the intensity and duration

of the search by allowing the user to place emphasis on any desired day

of the search. (For example , the user may choose to emphasize the first

day.) This input variable is PDC(DAY) . It may be desirable to attempt

to cover, for example, at least 501 of the search miles on the first

day and at least 20% of the remaining search miles on subsequent days.

This example models an initial concerted search effort followed by a

decreased emphasis on subsequent days.

(3) Inputs to Operate SASS

(a) The additional case attributes, other than those discussed in

SRAS but required by SASS, include the following: (These attributes are

developed in PREPRO)

(i) TSM: Total (linear) search miles on the case.

(ii) srTotal number of search resources required on the case

(iii) n: The number of needs except search, tow or escort.

- 105 -
(iv) m: The number of sequential tows or escorts required

(v) P: Primary station of the case.

(vi)S: Severity level of the case.

(vii) XC,

YC Case location.

(b) The additional user inputs include:

(i)

(ii)

SUNSET and SUNRISE times (Seasonal variations

can be introduced by exercising either a peak

or non-peak scenario.)

(TOLS(S): Tolerance times for searching as a function

of severity level, S, of the case.

(iii) SOA^(L): Search speed of the Lth type resource.

(iv) END(L): Endurance (hours) of Lth type resource.

Time it takes the Lth resource to refuel.

Operating cost/hour for the Lth type resource.

(vii) PDC (DAY) : Desired percentage of the search miles to be

covered by each search resource as a function

of the DAY of the search.

(viii) PRTSM(i) : Fractional split of TSM among the S

£

, search

resources assigned to the case, (i=l, 2, ...,

(v) t

£

(L)

(vi) OC(L)

(ix) x: The number of hours before SUNRISE when an

attempt is made to assign resources to search

cases secured the night before.

(x) INTRAP: INTemal (adjacent inclusive) Resource

Assignment Policy switch.

- 106 -
(4) SASS Logic

SASS is called by the OPSIM EXEC if S^, the number of resources

on a long search case, is at least one. Any other subsequent need

requirements are later served through SRAS and MRAS , depending on the

values of n and m.

The first step in SASS is to allocate to each resource that

portion of the total search miles, TSM, indicated by the values of

PRISM (i) . (See Figure 18.) The result is a set(SM(i)} of search miles

allotted to each resource. Table 3 below illustrates how the user may

define the fractional split of these miles as a function of the value of

S^, the number of search resources. The set {SM(i)> is given by:

SM(i) = TSM * PRTSM(i) , where i = 1(1) Sr

OCCUR, the time the case enters the system, is examined next.

Should the case take place during the hours between SUNRISE minus

x hours and SUNSET of a given day, SASS1 is called after notifications

have been created for each SM(i) . Creating additional notifications

to the system treats the case as a set of single resource cases, each

having a requirement for covering SM(i) search miles. Should the case

enter the system sometime after SUNSET, but prior to SUNRISE minus

x hours, then a single resource, if available, is vectored to the

scene immediately. The remaining S^-l required SM(i) *s are placed

in a SUNRISE LIST, via RISE, to be served at SUNRISE minus x hours.

In order to model the concerted effort approach to cases occurring at

night, the values PRTSM(i) should be input in descending order

of magnitude.

- 107 -
Figure 18

SASS Flowchart; RISE

- 108 -
PRTSM(i)

S

l

v\

1 2 3 4 5

1 1.00 - - - -

2 .70 .30 - - -

3 .50 .30 .20 - -

4 .30 .30

| .20 .20

5 I .30 .25

1 .20 .15 .10

Table 3

Fractions of PRTSM(i) for varying levels of S-^

SASS1 finds an ordered set of capable resources at the primary

and adjacent stations and uses setps 1 and 2 of SRAS. (See Figure 19.)

An attempt is made to complete the search miles, SM(i),within search tolerance time, TOLS(S), or before SUNSET for long search cases. Comparing the

current simulation clock time, TIME, plus TOLS(S) to SUNSET defines the amount

of time available to search before securing for the night at SUNSET. This

applies to aircraft only, as surface resources are permitted to search at

night to their endurance limits. Each resource type has some capability to

search; whether they are all capable to serve this particular case depends

on the environmental conditions . The appropriateness of selecting a

resource is also a function of each one's ability to cover an "area"

satisfactorily. For each of the K capable resources, PR(k) is calculated

to represent the percentage of the "area" which that resource can cover within

TOLS(S), or before sunset. This is a function of the position of each

resource relative to the case, the vector and search speeds of each resource

- 109 -
Figure 19

SASS1 Flowchart

- 110 -
and the endurance and refuel times of each capable resource. The calculation of PR 00 is best illustrated by referring to Figure 20.

Consider two capable resources, the kth and (k+1) , which can start

for the search area at some simulation clock time, TIME. The kth resource

which has a shorter endurance than the (k+l)st, arrives at the search area at

time U after expending t (k) to arrive on scene.* It must depart the area

1 r vec

at tg to return home and spend t^(L) amount of time refueling, then takes

t (k) amount of time to return to the search area, arriving at t. to con- vec v ^ tinue searching. The slope of the straight lines between and t^, and

between and t

5

, S0A

3

(L)/SM(i) , is the normalized rate of coverage for

this resource, where SOA^CL) is the search speed. PR(k) is the product

of this rate and the accumulated time spent searching. The (k+l)st

resource arrives on scene at and searches until t

5

, covering PR(k+l)

.

Both resources stop searching at TIME + TOLS(S).

Once the set of PR(k) 's is calculated, the desired coverage level,

is retrieved. For those short search cases which require an additional

resource to search(i.e., S

2 = 2) ,SASS1 is called with PDC(DAY) = 100%, and

DAY equal one (since it is desirable to cover the entire search area

that first day before serving any additional need on these short

search cases). Also, the severity of the case may be increased

(as specified by the user) in this case to the

*It is assumed here that in the typical operational situation the

searching resource is dispatched from its home station, rather than from

whatever location happens to obtain at that moment. Little accuracy

is lost in the calculation of PR(k) as a result of this assumption.

-Ill-
For any capable resource R, the percentage area covered, PR(R)

,

is given by the following equation:

PR(R) - )(END(L) - 2tvecW }

1 ^]%^

+ TOLSCS) - {ENB(L) + t

f

(L)

j

•t (k)

vec

J

(Note: Figure 20 is continued on the following page)

- 112 -
I TOLS (J END (L) +1 where, I TOLS(S) represents the largest number possible integral of

sorties (during TOLS(S) the resource expends a maximum amount of time,

subject to its endurance limitations); and, the following

conditions hold:

A. (END(L) - 2 t (k)} > 0

vec

B. TOLS (S) - (END(L) + tf

(L)

}

C. (END(L) - 2t (k)

}

vec v J

TOLS(S)

END(L)+t~(L) ‘vec® i 0

> TOLS (S) - { END (L) +t£ (L) }

' t

vec

(k)

TOLS (S)

END(L)+t

f

(L)

D. PR (k) > 0

In addition, certain situations can occur, and PR(k) takes on other

forms. These are:

A. If (END(L) - 2 t

yec

(k)} < 0, then PR(k) = 0

n Tf micro - +* n.yy

[ 1TOLS(S) 1 r

* [END(L) + t (LJJ

[END (L) - 2t K

CRD

)

vec

C. If, TOLS(S) - (END(L) + t r (L) }|T0LS(S)

1

END CL) +t

f

(L)

{END(L) - 2 t

vec

(k)}

t (k) < 0, vec ^ J

- t

then TOLS(S) - (END(L) + t f(L)} TOLS(S)

END(L)+t

f

(L)

vec

t (k) = vec

v J

(END(L) - 2t

v0c

(k)}

and PRQc)

- ^30! (END(L) - 2t

vec

(k)

j g^tf(L) * 1

Figure 20 (continued)

- 113 -
value SVAR to ensure quick response and non-interruptibility of this

additional resource. The cost, C(W, &r each capable resource is

calculated using the following equation.

C(X) = OCCL)*(tvec

(l0 + SM(i)/SOA

3

(L))

Cost as calculated here includes the total tine spent searching and

the cost to vector to the scene.

Those resources whose PR(k) meet the desired PDC(DAY) are ranked

on increasing cost. Those resources whose PR (10 is less than the

desired are ran

'Kec^ on decreasing PR 00 . Finally,

those resources which cannot cover any area before TOLS(S), but

can at least vector to the search area and return within endurance,

are ranked in increasing t

yec

(k). The cost for any additional sorties

required because of limited endurance is not directly calculated

here, because these resources are already penalized in the PR(k) calculations

.

A final merged list is created listing ranked capable resources

first by increasing cost, next by decreasing PR(k),and last by increasing

t (10 (See Figure 21.) Control is passed to RAP to find a re- vec

v

source at the primary (and adjacent) stations (s) to service the case

from this list. (The internal switch INTRAP is activated as in MRAS

should the selected resource assignment policy be RAP 4 or RAP 5 .)

SSS, the Search Service Subroutine is called once the capable

resource is found in RAP. Within SSS, if this is the first resour

assigned to the case,(i.e. ,SFLAG is unity) , control is passed to TEST.

The objective is to vector the first resource immediately to the scene

- 114 -
©

Calculate C(k) = OC(L)* Ct

vec Ck) *

(PR(k) )=0) A (END(L) -2t

vec (k>0) /PRCk^PI (PR(k)>0)A(PR(k)<PDC(DAY)

CPR(k) >0) A (PR(k) >PDC(DAY)

)

1 f -—, * —

Rank resources on

increasing t (k)

1 Rank resources on

increasing cost

1 Rank on decreasing PR(k)

|

^RGE/

LISTS

Set

RAP = 2

<

Resource Assignment

Policy _J

t,_(k): ^SWSET-TJME-^4-- ^ARSffl

vec

t (k)

vec v '

Is resource

selected °©>- — % aircraft?

@ TIME+t (k) ^ vec

CRSG

v_/

Yes

TIME + t (k): SUNRISE ^MSCH

sYec ^(aTTME +

Figure 21

SASS and SASS1 Cont'd

- 115 -
TEST J

@TIME + t

vec

rv'i + SM(i) w S0A

3

(L) {J/T\ COMPL J XU

Aircraft

C )

Figure 22

TEST and ARSCH

- 116 -
SM(i) = SM(i)

t

s (i)*SOA

3

(L)

CSDI

?

Examines the SUNRISE

j LIST and vectors re- sources to arrive at

SUNRISE when possible

| or thereafter

i

Places queued

search cases in

SUNRISE LIST

.jzzs-zz z zzz ... _ XRISE is called at TIME = SUNRISE

XSET is called at TIME = SUNSET

i

i

i

i

i

I

i

I

>

i

i

i

i

-x

DESTROY

CASE

Release the resource;

Search completed

Release the

resource; destroy

SM(i)

Figure 23

NSET; XRISE ; XSET; and COMPL

*See SS routine

w
to commence searching for the client, (See Figures 21 and 22.) TEST

compares the endurance, END(L) , against the total time required on the

case,(i.e,, to vector to and from the scene, 2 t c

(k); plus the

source is sent to the scene and control is passed to event routine COMPL

at the end of service of the case. It is assumed that the longer endurance resources will remain on scene searching during the night. COMPL

(see Figure 23)passes control to TERM and subsequently to EXQ. TERM

terminates the search need of the case just served, while EXQ examines

the queue for a case or a need of a case that can be serviced by the

resource which just became idle (i. e., completed serving the search need) _

(See the following section on SS for discussions of TERM and EXQ.) COMPL

also examines the case to determine if any subsequent needs beyond search

require service. Control is passed to SRAS or MRAS dependent on the values

of n and m.

If, on the other hand, the first selected resource's endurance is

less than the total expected time required to spend searching, then

control is passed to ARSCH, at the time the resource arrives on scene

to commence search. (See Figure 22.)

The subroutine ARSGT schedules the completion of the search need or

additional sorties (if refueling is required to complete the service

of the case) ; updates the SM(i) to be covered; and secures the case for

the night, if necessary. To model the search capability of certain

resources more realistically, aircraft are prevented from continuing

. If END(L) compares favorably, then the re-

- 118 -
their searching after sunset, whereas surface resources are permitted

to continue to search beyond sunset, but within their endurance constraints.

If the selected resource is an aircraft and the required search

time, t2 Ci) ? can be expended within endurance and vector time limitations

and prior to SUNSET, then COMPL is called at the end of the search time.

If instead, SUNSET occurs before the aircraft can fulfill its t

s (i), the

search is secured for the night, and the t (i) is updated to the amount

of time remaining until SUNSET. Since this search need has not been fulfilled, control is passed to NSET at SUNSET. NSET updates the remaining

search miles SM(i) , places the need in the SUNRISE LIST via subroutine

RISE, and calls EXQ. The SUNRISE LIST is examined at SUNRISE-X hours.

Surface resources remain on scene covering their assigned SM(i) if the

endurance limitations have not been exceeded. Upon completion of t (i)

COMPL is called.

In the instance where the selected resource cannot cover its assigned

SM(i) within endurance, sorties are scheduled to complete the search need.

The resource can only search that amount of time representing the

difference between the endurance and the time to vector to and from the

scene. This time becomes t (i) in this instance. Surface resources remain

on scene (beyond SUNSET if necessary) expending their assigned t

s (i),

returning home to refuel . Aircraft will remain on scene and search until

SUNSET or until they have spent their t

s (i), whichever occurs first.

In the latter case, if SUNSET occurs first, then NSET is called. If refueling is required to continue service of this case, prior to SUNSET,

then control is passed to FUEL.

- 119 -
The number of search miles SM(i) are updated in RJEL and control

is passed to HOMEF, where the resource is refueled. The resource becomes available to be vectored back to the search "area" after expending

t^(L) time refueling. HOMEF passes control to SNDBK. Subroutine SNDBK

first attempts to find a "better" idle capable resource to fulfill the

remaining search requirement. This is done with a call to SASS1. If

no resource can be found , then the original resource is assigned to

continue searching.

In Subroutine SNDBK,a resource will be vectored back to the search

area if he can arrive prior to SUNSET of that day, or if his vector

time is so large that the resource will arrive on scene after SUNRISE

minus X hours of the next day. Should the resource not be able to arrive

before SUNSET, but can arrive at SUNRISE minus X hours or after, then the

search need is placed in the SUNRISE LIST via RISE. (See Figure 24

illustrations of FUEL, HOMEF, and SNDBK.)

The discussion relative to SSS thus far has covered the first

resource assigned to a case, and the scheduling of subsequent sorties

for any resource selected to serve a search need of the case. Referring

back to Figure 21, if this resource is not the first one on the case

but is a surface resource, then control is passed to ARSCH when the

resource arrives at the search area. If ^however, the resource is an aircraft,

then it is vectored to the case if it can arrive on scene prior to

SUNSET or if the vector time, t (k) is so long that the resource will

not arrive until after SUNRISE of the next day. Should the aircraft

not be able to arrive before SUNSET, but can arrive prior to SUNRISE of the

next day, the case is placed in the SUNRISE LIST via RISE, and EXQ is called.

- 120 -
Figure 24

TEST; ARSCH; FUEL; HQMEF; and SNDBK

- 121 -
SUNSET-

@TIME + t

yec

(k)

SUNRISE -x

@ TIWE + t

vec

(k)

ARSCH

Figure 24 [continued)

- 122 -
The event XSET is called automatically at SUNSET. It has been

created to specially handle queued search cases. XSET extracts search

cases from the queue and places them in the SUNRISE LIST.

XRISE examines the SUNRISE LIST at SUNRISE minus X hours and

vectors resources at appropriate times to arrive on scene at SUNRISE.

These routines are illustrated in Figure 23.

D. The Service Subroutine (SS) for SRAS and MRAS of OPSIM

(1) General Description

Once a resource has been selected to service a need in either SRAS

or MRAS, control is passed to the Service Subroutine, SS. This routine '

simulates the required service activities; the continuous coverage of the

client, should it be required in a multi -resource case; the re-evaluation

of the severity level of the case during the elapsed service time, etc.

Upon completion of the service of a need of a case, the resource

assumes an idle (alpha) status. The case statistics relative to servicing

this need and the statistics regarding the utilization of the resource

are recorded. The queue is examined for waiting cases at the resource’s

primary and adjacent stations, depending on the selected resource

assignment policy, to determine if the released resource is capable of

serving a waiting case before returning to home port.

(2) Inputs

The operation of SS is dependent on the case attributes and the

user inputs. Certain simulation-developed case attributes are, of

course, carried for statistical analysis purposes.

- 123 -
(a) Case Attributes

The Case attributes used in SS include:

(i) tos(i)

The time on scene for the l need.

(ii) n: The number of needs other than search or tow.

(iii) m: The number of tow or escort resources.

(iv) S

2

: The indicator for a short search requirement.

(v) TSM: The miles to be covered searching for the client

(also required for a short search)

.

(vi) S: Severity level of the case.

(vii) NEED: Explicit need of a case undergoing service.

These attributes were discussed in the section on PREPRO.

(b) User Inputs

The user inputs are a combination of operational experience and

extrapolation of historical data:

(i) DRS(j): Probability distribution for re-evaluation of

the case severity level, i.e., the severity level

becomes S + IPC, where DRS(l): % Increase by a

unit, IPC = 01; and DRS(3): % No change, IPC = 0.

(ii) KS: The number of examinations, on scene, of the

case severity.

(iii) HU: Distribution for hook-up time tor tow cases

(or delay for surface escort cases)

.

(The time required to obtain the information required in the SAR

assistance form is not specifically included in the service time,

nor is there an allowance for any delay for "unhook" time. In

- 124 -
most instances these activities require a relatively minor fraction

fraction of the total service time of the case.)

(iv) HO: Hand-off point, (miles from shore) for multi

resource tows , or escorts

(3) SS Logic

Control is passed to SS after the assignment of a resource (to

serve the i tn need of a case) is made in RAP. ARVSN is called at the

time the assigned resource arrives on scene or at the expected location

of the client.

ARVSN performs a number of functions which include: passing control

to SRCHF, a subroutine which simulates the activities for locating the

client under short search conditions; calling ONSCN, a subroutine which

simulates the re-evaluation of the cases severity level as time passes

during the servicing of a need; and releasing a resource which serviced

a previous need and had covered the client until another resource could

arrive on scene. RETN is called when coverage is no longer required.

(See Figures 25-27.)

If the case is a multi -resource case, coverage is provided for the

client unless the covering resource is interrupted to serve a higher

priority case. Therefore, upon arrival on scene, should a resource be on

scene and waiting, after having served a need of this case, the waiting

resource is released. This is done in RETN. (See Figure 27.) TERM and

EXQ, called by RETN, record statistics on the case and resource, and

examine the queue to serve waiting cases, respectively. These routines

are explained later in the discussion.

- 125 -
List of "Waif

Flags for (i - 1ft at resource on\ a case

J/, N°

. Determine Des- tination to which

client is towed

or escorted

ONSCN is called

KS-1 times during

service of this

need

\ Case\ Calculate DD

^ Distance to

j Location

j

Destination

SR: Single Resource

MR: Multi -Resource

FIGURE 25 SS and ARVSN

- 126 -
Yes

*S0A1(L) or

S0A2 QL] depending

on weather condition

,i 1 nr 2

^RETNj

- 127 -
SR: Single Resource

MR: Multi -Resource

Figure 27 ONSCN and RETN

- 128 -
SRCHF is called if a short search is required only on the service

of the first need. An attempt is made here to simulate the typical

situation where a resource has been vectored to the expected location,

but cannot find the client. The position may have been erroneously

reported, or the client may have drifted from his last reported position.

The resource must search for the client or call up an additional resource to perfonn the search. (See Figure 28.)

Before a client can be towed (or escorted) , his destination must be

established. Ordinarily the client’s destination is the primary station

(i.e., the case's primary station). However, in the situation where

the client is being towed (or escorted) by a resource on patrol , then

the client is towed to a predesignated station for that patrol resource % (Each patrol resource's predesignated station is treated

as an adjacent to the patrol station, where the patrol station

is considered a primary. Each patrol station will have on adjacent.)

Once the destination is known, the distance to that point, DD, is

calculated.

Analysis of the historical data indicated that very few tow or

escort cases required more than a single hand-off, implying that, in

most cases, not more than two resources towed, or escorted, in series.

The decision was therefore made to limit the maximum number of hand-offs

to one, or the case will have a maximum of two tow needs (or two

escort needs) . (Cases involving more than one resource to tow or

escort will automatically be reduced to two resources.) The request

for tow or escort is made at the arrival of the case to the system, or

- 129 -
PDC (DAY) = 1001

S = SVAR

(

exq ^

Examine queue

for highest

priority case

awaiting service

Available re- sources can serve need of

awaiting case § can vector I

Calculate

to return

to homeport

t (i) ret Resource not

capable or crew

not available

j @ Time + t (i) i ret

(wHCME I

C

TM

3.

Record Statistics on ith

need

/ OUTPUT \

l CASE 1 \ TAPE J

(rE^

Figure 28: SRCHF, EXQ; TERM and HOME

- 130 -
at the completion of those needs other than tow or escort. The request

for hand-off is made after the first tow or escort is satisfied. These

requests are not scheduled in advance as in the situation of servicing

the other needs.

If the case is a single resource air escort (i.e. , the escorting

resource is an aircraft), the time spent escorting, TOWTIME (i), becomes

the ratio of DH, the distance between the client and his destination,

th

to the speed of advance of the l type resource assigned to this need

of the case; either S0A1(L) or S0A2(L), depending on weather conditions

1 or 2.

If, instead, the case indicates a single resource tow (or surface

escort), (i.e., the escorting or towing resource is a surface unit)

then the time expended in rendering service includes the hook-up time,

t^, and the tow or escort time, TOWTEME(i) taken as the ratio of the

distance DD to the towing speed, TSP. The towing speed is dependent on

the client length. The hook-up time, t^, is drawn randomly from

the distribution HU, a user input. Surface escorts have been approximated

by treating them as tow cases. Historically, their number is not

excessive and thus the approximation is acceptable.

If the case requires a hand-off tow or escort, then the distance to

the destination is divided evenly between the two needs. The hand-off

point is a point halfway between the client and his destination.

However , should half of the distance between the client and his destination, D2(CASE), be less than HO miles, where TO is a user input

representing the minimum hand-off distance from the client’s destination,

- 131 -
then the hand-off point becomes HO miles from the client’s destination.

The distance off-shore is also updated relative to this hand-off point

for the second tow or escort need. HO is currently considered as a

quarter mile off-shore.

The time spent towing the client to the hand-off point is calculated

similarly as in the single resource case. Once the hand-off point has

been reached, or the single -resource tow has been completed, control is

passed to RETN.

Should a tow or surface escort be interrupted by a higher priority

case, the client's position is updated to where he is dropped off, and

the need queued. The hand-off point is "preserved" in the case of an

interrupt of a multi-resource tow. No provision is made for picking

up air escort cases if the escorting resource is interrupted to serve

a higher priority case. A means of re-evaluating the severity level of the case has been

provided to the user in the subroutine ONSCN . From the cumulative distribution of DRS, the direction of change in severity is determined by

the Monte Carlo of the amount of unit change, IPC. In specifying the

parameter KS,th.e user indicates that the severity is to be re-evaluated

KS-1 times during the service of this need. RETN is called at the end of

service of the need of the case. Since the case's severity level is

expected to remain fairly constant during the service of the tow or

escort need, no re-evaluation is provided when these needs are being

serviced.

- 132 -
RETN insures continuous coverage of the case should the service

of the case not be completed and the subsequently scheduled resources

have not arrived on scene. (See Figure 27.) The resource already on

scene will provide coverage for the client, but cannot insure coverage

should a higher priority case arrive to the system and require the

services of the covering resource. If a resource has arrived to serve

another need of the case, and thus covers the case, or if the case is single

resourced, then TERM is called, followed by EXQ and the covering resource

is released. Before a resource covers a client, it examines the queue

to see if it can serve a need of this case that has been previously

queued. In addition, a covering resource examines the queue for a queued

need of any case, every QT hours, where QT is variable.

Figure 27 illustrates RETN where coverage is provided dependent on the

relationships of the arrive -on -scene time ROS(i + 1) of the (i + l)s at

resource to the leave-scene time, RLS(i), of the i^h resource.

Besides providing coverage to the client during the service of his

needs, the resource serving the last need will serve the tow or escort

needs if capable. If not, that resource will cover until resource

capable of towing can arrive to scene.

As mentioned previously, short searches are handled in SRCHF if

the search is done by either the first resource on scene or by an

additional resource called to scene. (See Figure 28.)

SRCHF examines the S^ code of the case and either lengthens the

resource service time of the first resource on scene, so that a search

can be accomplished; or passes control to SASS1, a part of the Search,

Assignment and Service Subroutine, SASS. Resource selection is made

- 133 -
in SASS1 to cover the total search miles, TSM, the first day. The

severity level of the case is increased in order to model the urgency

of the request for service made by the first resource on scene, and also

to lower the probability that this additional resource can be interrupted.

If the search is done by the resource serving the first need, its

on scene time, tos(i), is lengthened by the amount t^. This can occur

either directly through examination of the value of or by default,

should there be no additional capable resource available when requested

by the first resource on scene. In this case, the resource serving the

first need will also perform the search.

The philosophy behind SRCHF is that the resource assigned to the

first need was selected with regard to this need ,not for searching. Only

after arrival on scene to find the client missing did the "need" for

search become apparent. Thus, as is often the case, another, more

suitable resource may be required to find the client.

Upon completion of service of all needs, TERM records certain of

the case's statistics, removes the case from the system and files it

off-line into the Output Tape*for special postprocessor analysis . (See

Figure 28.) It also records the station and resource utilization

statistics. Below is a list of these statistics and their definitions:

(a) Case Statistics

(i) COSTC: Total cost for service of the case, including

the cost of a long search and the cost to

vector to the expected location. In the case

of a single resource or multi -resource case *If opted by user.

- 134 -
requiring no search, the cost of servicing

the case on scene for a particular need is

not included. Cost is calculated in this fashion

because the on-scene portion of a case (or need)

other than search is relatively resource independent. The philosophy is somewhat different

in selecting a resource for a long search. For

these cases , the cost of covering a desired

amount of search miles varies widely for

different resource types. Therefore, this

cost includes the cost of performing the

search as well as the cost of vectoring to

the scene.

The cost of the case is accumulated over all interrupts. Note

also tha£, regardless of the cost option, COSTO (i.e., the

operating cost per hour or cost ranking) selected, COSTC is

calculated as above.

(ii) TSVCThe total time the case spends in the system from

its arrival to its completion.

(iii) TQUE: The total time the case spends in the queue accumulated each time the case is placed in the queue.

(iv) NQUE: The total number of times a case is queued.

(v) TQUE1: The elapsed time spent in a queue prior to the

first arrival of a resource to the scene.

- 135 -
(vi) TWAIT

:

(vii) CNRES

:

(viii) NOINT:

(ix) TINT:

(x) PRI

:

(xi) REA:

(xii) RESA(i)

:

The elapsed time prior to first arrival of a

resource on scene. This is usually equal to

the time it takes the resource to vector to the

scene T

vec

(k) plus the time the client spent in

queue, TQUE1, except if the case was interrupted.

The total number of resources serving the case,

including the resources assigned after the

case has been interrupted.

Number of times the case is interrupted.

Total time the case is in the interrupted state,

waiting in the queue.

Final priority of the case; priority is a

function of severity level, which is re-evaluated

during the service of the case and is updated

if the case is placed in queue, or in ONSCN.

The reason the case was first placed in a queue.

The case can be queued for either of two reasons:

a. If there are no capable resources available

at the primary and adjacent (dependent

on the resource assignment policy) available at the time the case enters the system; or

b. If service is interrupted due to a case of

higher priority.

For each i^ need of the case, the first resource

serving that need is recorded.

- 136 -
(b) Station and Resource Statistics

Statistics are collected in OPSIM relative to stations and their

resources . District level aggregates and averages are also derived

and offered as the Standard Output, and are printed by the Report

Generator

For each resource, 1, in the inventory, the average utilization

index UTIL(l), is calculated as the ratio of the total number of hours

throughout the simulation the resource was busy to the total time

simulated.

For each station in the district the average utilization index

is calculated for each shift. (The simulation allows for a maximum

of eight shifts relative to a week within a given peak or non-peak

season. These shifts correspond to the manning levels of the district.

If, for example, the manning levels change at given times of the day,thes

times dictate the shifts.) The average utilization index per station i,a

per shift R,USHF (i,R), is calculated as the ratio of the total number

of resource hours used to the total potential number of resource

hours available during that shift, across the resources attached

to station, i.

Certain aggregate statistics are found for each station i in the

district. These include:

(i) The number of cases served by station i: NCAS(i).

(ii) The number of needs served by station i: NEEDS (i)

(iii) The number of interrupts at station i: NINTR(i)

(iv) The number of times a standby crew is called at station i:

NSTBY(i) .

- 137 -
(v) The number of times a standby crew was called, but

not used at station i: UNPRO(i). A time delay exists

between call-up and the time at which the standby arrived

at the station. Therefore, a waiting case could be served

by a manned resource which became available during this

delay time.

Three levels of failures are defined and are recorded for each

station. These include:

(i) The number of cases which came into station i where there

was no capable resource in the district to serve, or

failure type A FAILl(i).

(ii) The number of cases where was no capable resource at the

primary (and adjacent), or failure type B, FAIL2(i).

(iii) The number of cases where the case was not served within

tolerance FAIL3(i).

Average wait time at a station is also calculated along with

average utilization index. Average wait time is the arithmetic average

of the values of TWA1T for those cases arriving at that station.

Average utilization index at a station i, USE(i), is calculated

as the ratio of the resource hours used to the potential resource

hours at station i.

Any exceptional cases are included as automatic output, and

their parameters are also output. These include any cases for which

no resource can satisfy a need of the case.

- 138 -
A district summary is provided as part of the Standard

Output and includes

(i) The total time simulated.

(ii) The total number of cases that occurred during the

the total simulated time.

(iii) The total number of cases that were completed.

(iv) The total number of cases where failure type A occurred:

2 FAX LI (i)

1

(v) The total number of cases where failure type B occurred:

2 FAXL2 (i)

i

(vi) The total number of cases where failure type C occurred:

? FAILS (i)

i

(vii) The average utilization index across the district is calculated as the ratio of the total resource hours used to

the total potential number of resource hours in the district, throughout the duration of the simulation.

(viii) For each shift, the average utilization index across the

district is calculated as the ratio of the total resource

hours used to the total potential resource hours in a

given shift.

(ix) The total number of needs served and the total number

of interrupted needs are aggregated for the district.

(x) The average time any case waits, taken as the arithmetic

average of the TWAIT values across all the cases , is

also calculated.

- 139 -
(xi) Finally, aggregates of the total number of standbys,

Z NSTBY(i) and total number of unproductive standbys

X

Z UNPRO(i) are calculated for the district,

i

The reader is referred to the program listings* Report Generator

Section, for a layout of these statistics.

After the collection of statistics is completed on each case,

and each case’s contribution to the station and resource statistics

recorded, the resource is made available to those cases awaiting

sendee in the queue. EXQ examines the queue for a waiting case at

the primary station (and adjacents depending on the resource assignment policy). (See Figure 28.)

If the resource is capable and operational and a crew is available,

the resource is assigned to the highest priority waiting case. If

there are no waiting cases that this resource can serve, the resource

is vectored home. Crew availability is assessed in exactly the same

fashion as if the resource were at its home station, that is, the

changes in crew manning levels over the day are taken into account.

HOME is called at the time the resource has arrived at its home

station. Here the status of the resource and crew is updated to

idle

.

If the need of the waiting case to be serviced is a search need,

the remaining endurance of the resource is examined. The time to

vector to scene is compared against SUNSET of that day or SUNRISE of

the next day. That is, if the resource can arrive before SUNSET it

*Contained in Appendix B of this series, NBS Report # 10436.

- 140 -
is vectored. If the resource can arrive after SUNRISE of the next

day, then he is vectored. Vectoring takes place only if the

resource is capable, has sufficient endurance, and an available

crew. Otherwise, the case remains in the queue. Recall that

queued search cases are examined at SUNRISE - X hours.

A special subroutineCSTNBY) examines waiting cases at the time

a standby crew arrives to the station. The same logic of EXQ relative

to the resources is included, but a crew is already available -- only

the resources capability, endurance, etc. , need be assessed.

- 141 -
4. POSTPRO - The Postprocessor of SARSIM

The Service Subroutine of OPSIM automatically produces the

OPSIM STANDARD OUTPUT* and may also be instructed to generate an

OUTPUT CASE TAPE for specialized data analyses in the Postprocessor

(POSTPRO) . Prepackaged data retrieval programs such as Quick

Query —^ are currently used to provide these specialized outputs. The

Quick Query program was developed by C.A.C.I. and is compatible with the

SIMSCRIPT language in which OPSIM is programmed.

A typical request might consist of the aggregation of all weekend

cases which waited more than some specified number of hours and whose

severity level was initially at some given level.

The OPSIM STANDARD OUTPUT provides statistics with reference

to resource types* stations* and the district as a whole. In addition,

data are printed out on any exceptional cases , that is 9 cases which

cannot be served due to lack of a capable resource in inventory at

the primary or adjacent stations (failure types A and B) * or an

interrupted air escort case.

Any changes to the input conditions are also listed. These changes

are relative to a given base run and include the following:

(1) Any changes to the station to include additions or deletions

of stations to the district; and/or changes in the station

I/ ' 'Quick Query User’s Manual for Economic Development Administration",

Working Paper, by Consolidated Analysis Centers, Inc., C.A.C.I.,

January 1970.

- 142 -
attributes, such as the type and number of resources; or

the shift levels.

(2) Any changes in the resource types in the district inventory

such as additions or deletions of types; attribute changes

of each type, for example, the capability of a given type.

(3) Any changes in the resource deployment at any station,

existing or new.

(4) Any changes to the crew manning levels, new or existing.

In addition to changes, the user input options relative to

the PREPRO, OPSIM and POSTPRO are delineated, so that the simulation

exercise can be uniquely identified.

Completed cases are filed on the Output Case Tape. The POSTPRO

operates on this tape, as an option to the user, and generates

additional statistics of interest to the user. This option provides

flexibility of output reporting at the management and analyst levels.

Having a file of completed cases, with both the input information and

the status at completion, allows for a wide variety of queries to be

processed.

For each case, the following inf ormation is hept

(1) OPFAC: The historical primary station of the case.

Note, this primary is assigned in PREPRO, and updated in OPSIM. The

updated value is P, the primary station.

(2) NOCAS: Number of case.

- 143 -
(3) IDLOC: District in which the case took place.

(4) OCCUR: Date and time of case arrival to the system

(5) BOX: An indicator showing whether the case occurred during

the weekday or on a weekend and either during the

day or night.

(6) FPRI: The priority of the case as it enters the system.

(7) MMM: The number of tow or escort needs

(8) NNN: The total number of needs except long search and

tow or escort.

(9) GAMMA: Degree of non parallel service.

(10) AIR: Air temperature at time of the case.

(11) OFSHR: Distance off-shore.

(12) VIS: Visibility

(13) WIND: Wind Force

(14) SWELL: Sea height

(15) L: Length of distressed vessel

(16) POB: Number of people on board distressed vessel.

(17) SIS: Number of resources in long search

(18) S2S: Sho^t search code

(19) TSM: Total search miles on case

(20) UTYPE: Type of distressed unit

(21) VALUE: Value of distressed unit

(22) XCX: Original Case location

- 144 -
(23) YCY: Original Case location

(24) XC: Case location (Updated)

(25) YC: Case location (Updated)

(26) STAIN: Reassigned primary station

(27) CNRES: Number of resources involved in a case

(23) PRI: Final case priority

(29) REA: First reason case was queued.

(30) COSTC: Total cost to serve the case

(31) ITOL: Indicator relative to case being served within tolerance

(32) NOINT: Case interrupt count

(33) NQUE: Number of times case was queued

(34) TINT: Total time in interrupt status in the queue.

(35) TQUE: Total time case spends in queue.

(36) TQUE1: Time case spends in queue prior to first resource

arriving to scene.

(37) TSVC: Total time case spends in system

(38) TWAXT: Time between case occurrence and arrival of

first resource

(39) NEED(i): Need of a case

(40) OST(i): Time on scene of Need (i)

(41) DELTA (i ) : Delay of next resourse arrival, multi-need case.

(42) RESA(i): Resource assigned to serve Need (i)

- 145 -
When the case includes search and or tow or escort,

RESA(i) is expanded to include the resources assigned to serve these

needs as well.

Using the Case Tape, with the above attributes, the user can

make specialized requests. For example, an aggregation, or printout

of all weekend cases which waited more than a given amount of time

and had a given input severity (or priority) can provide the user with

some insight as to whether his resources are strategically placed,

or perhaps his manning levels need alteration. The added information

of wait time broken out by severity level enhances the Standard Output

relative to average station TWVIT and stand by call-ups.

- 146 -
APPENDIX A: Inter-District Assignment and Service

Subroutine (IDASS) of OPSIM

I . Introduction

As originally conceptualized, a special submodel was developed

to model the availability of the C-130 aircraft to service cases within

its long-ranged capability. Simulation of cases which occurred historically external to the district were to be simulated in IDASS and

served only by a C-130. Those that occurred inside the district could

be served by any capable resource, perhaps a C-130, the selection being

dependent on the cost option, tje statis pf tje respirces. the environmental conditions , and the case parameters

An improved approach to handling the simulation of those cases

served by the C-130 has since replaced IDASS. This discussion is

in the main body, including the special preparation required to

develop the case parameters for C-130 cases. The air station at

which the C-130’s are based is included in the list of primary stations.

To prevent any other resource type from responding to the out of the

district C-130 cases, this air station has no adjacent stations.

The effort required for designing IDASS and developing the computer

program was well spent in that it proved to be the pilot effort in

the application of the selected computer language, SIMSCRIPT to SARSIM.

Since IDASS is a functioning model, but not included in the current conceptualization of SARSIM, a discussion is presented in this appendix.

SARSIM is basically designed to be exercised on the district

level. Those resources assigned to each district are normally called

A-l
upon to serve those cases that occur in the district. Special attention

is given, however, to the C-130 since some of its characteristics, such

as its long range potential and faster response, have resulted in its

frequent use on an inter-district basis. Such employment of resources is

an exception to the district boundary assumption. It is important,

therefore, to model the availability of this resource to serve cases in

the district being exercised simultaneously with all other districts

using these C-130's. The major objective of SARSIM, as it is presently

envisioned, is to measure the sensitivity of SAR effectiveness within

each district by varying such factors as resource allowance, deployment,

and case load. IDASS provides a means of including C-130’ s as an

integral part of any CONUS coastal Coast Guard district by modeling

the availability of a C-130 to service cases on an inter-district

basis , concurrently with the normal work load of the district under

investigation. Therefore, the Coast Guard manager has at his disposal a tool to measure the effects on each district and on each

coast, of varying the number of C-130 ’s, their work load and deployment.

II. Background and Assumptions

The Lockheed C-130 is four engine, fixed wing aircraft which is

capable of proceeding 1200 NM at 290 knots to the site of a SAR incident, remain on scene for 21/2 hours and return to the point of origin

with adequate fuel reserve. On the average, its total airborne time

is approximately 12 hours.
C-130 SAR coverage for CONUS is currently provided by 'two

Coast Guard air stations: San Francisco, California., (12th district)

for the West coast; and Elizabeth City, North Carolina, (5th district)

for the East coast. The East coast, insofar as C-130 availability is

concerned, is comprised of 1st, 3rd, 5th, and 7th Coast Guard Districts.

For the West coast, C-130's are available to the 11th, 12th, and 13th

Coast Guard Districts.

Time of case notification is considered time of assigned resource

departure. No warm-up or communication delays have been considered

in the simulation concept at this point. These time delays can be

incorporated in the model at a later date. Provisions for crew rest

and refueling have been included for those flights exceeding 12 hours,

and for certain interrupt situations. All flights between the 1st

and 7th; or 3rd; or 8th; districts on the East coast assume an enroute

refueling delay of one hour. Likewise, a similar delay appropriate

for the West coast is to be included.

The number of C-130's, i.e., the allowance, available for SAR

missions is adjusted to account for the effects of maintenance, crew

manning levels, and non-SAR functions.

III. Special Preprocessor Required for IDASS

Before the logic of IDASS can be discussed, it is necessary to

discuss the special processing required of the C-130 historical data.

For each coast, a C-130 case file is prepared by examining the historical SAR workload at Elizabeth City (or San Francisco) and retaining those historical C-130 cases. (From this point, only the
East coast will be addressed to facilitate illustration of the

techniques in this special processing.)

The historical C-130 case load is analyzed and the relevant distributions and parameters developed. See Figure A1 for the flow of

these operations. The PGP, program to calculate case parameters, can

be modified to develop these parameters; or, since there are relatively

few of these cases , it may be preferable to prepare these cases

manually. A distribution of time on scene also must be developed for

input to IDASS. The Demand Generator can likewise be modified to

generate the C-130 case load. All C-130 cases carry an extra attribute,

the district where the case occurred. An additional processing step

is therefore required to determine the district within which the

case occurred.

The output of this special processing is a C-130 case load with

the district identified where each case occurred. This output is then

merged, on date and time of occurrence, with the Demand Tape for the

district to be exercised. The final composite merged tape becomes

the input to the Operational Simulator.

IV. Required Inputs to Operate IDASS

The required inputs for operating IDASS are similar to those

described in the section in SRAS. The user inputs applicable to this

subroutine include the station inputs describing the "equivalent"

number of C-130 's attached to the station for SAR purposes with crew

manning level and maintenance factors inherent in this number. One

more input required for IDASS is a matrix providing the expected vector
time to arrive on scene between each pair of districts and between

Elizabeth City and each district. This matrix, AOST (i, j) describing

the average time of arrival to a case in district i, from district

j, includes the time required to refuel, if required. An illustration

of AOST (i, j) matrix is presented in Table Al. The entries shown in

each AOST (i, j) cell represent the C-130 flight hours to vector to or

from the weighted centroid in each of the four East Coast districts

and Elizabeth City. This weighted centroid is derived from an analysis

of the historical data determining a specific latitude and longitude

within each district as the one most representative of where the

average C-130 case occurred in that particular district.

Case Location versus Time to Vector to Scene

(Hours)

C-130 Location "j"

To District 1 3 5 7 E City

From

District

1 .5 1 2 6* 3

3 1 .5 1 5* 1

5 2 1 .5 3 1 7 6* 5* 3 .5 3

E City 3 1 1 3 0

*Assumes refuel enroute

TABLE Al: AOST (i,j)

V. IDASS Logic

The interface between the Preprocessor and the Operational

Simulator, the OPSIM EXEC, determines which resource assignment
subroutine to enter. As each case arrives to the system, the district

in which it occurred is examined. Control is passed to IDASS for

those cases outside of the district undergoing exercise. Note that

a case which historically was a C-130 case occurring within the district being exercised is served in the normal fashion, as a single

resource or search case. Thus, the case has an opportunity to be

handled by any capable resource including a C-130. Similarly, cases

emanating from the work load not historically associated with C-130’s

are, of course, now eligible for a C-130 assignment via SRAS, MRAS

or SASS.

The flow of operations within IDASS is illustrated in Figures A2

and A3 . Briefly, IDASS simulates the assignment of a C-130 to the

case and the service of that case. A resource is assigned to a

case if the resource is idle at the time of arrival of the case to

the system, or a resource is on a lower priority case and can be

interrupted to handle the new arrival to the system. Otherwise, the

case must wait in a queue for a resource to become idle and available.

Step 1 : Refer to Figure A2. Accessing the status of each

C-130, the first step is to determine if there is an idle resource

at the air station (e.g. , Elizabeth City). If so, control is

passed to ASIN 1 which simulates the service of the case and the

scheduling of crew rest and refueling, if required.

Within. ASIN 1, the total on scene time, TOS, is attained

via Monte Carlo and the vector time, TVEC, is retrieved from the

matrix AOST (i, j); the sum of TOS and (TVEC) is added to OCCUR,
the current simulated clock time, to determine the Expected

Idle Alpha Time (ELAT). If the difference between EIAT and OCCUR

exceeds the maximum 12 hour endurance of the C-130, crew rest

and refueling is simulated; and additional sorties are required to

service this case.

Control is passed to routine IS which calculates the client

service time (CST) , or the elapsed time the client is undergoing

service (including vectoring) by the Coast Guard. In addition,

the resource service time (RST) is also calculated. CST is the

sum of the total on scene time, TOS; the time to vector to the

scene, TVEC; and additional TVEC's to and from the scene for

those cases requiring additional sorties. RST is the sum of CST

and the time required to return to Bravo-Zero status at the home

station (e.g., Elizabeth City). EIAT becomes the sum of the

time of departure of the resource and the client service time,

CST.

If no C-130 ? s are idle at the station, step 2 is executed.

Step 2 : An attempt is made to assign an idle C-130 which is

returning to the air station (e.g., Elizabeth City). If there

are idle-retuming C-130 's control is passed to ASIN 2. See

Figure 25.

Within ASIN 2, the closest ’’idle- returning" C-130 to the

case is selected. The remaining process is similar to ASIN 1.

If there are no idle resources returning to the air station, then

control passes to step 3.
Step 3 ; If the case is of a higher priority than other cases

currently being served in the system, then the lowest priority

case is interrupted and control passes to AS IN 3. The interrupted

case is placed in the appropriate priority queue and awaits additional service on a first-in, first-out basis. Subroutine QUEUE

places the interrupted case in the queue. (See the SRAS description for an explanation of QUEUE.) This new case is treated

similarly as a case in ASIN 2. If, however, the new case is of

a lower priority than those cases already undergoing service, it

is placed in tire appropriate queue to wait for a C-130 to become

available, by calling subroutine QUEUE. When a C-130 becomes

idle, subroutine EXQ (see SS description) examines all queues to

determine which case, if any, should be served by this resource.

VI . Special Output Reporting for IDASS

Since IDASS is a macro -level simulation of the availability of

C-130 to serve inter-district cases, as compared to the simulation

of district cases, only, certain aggregate statistics are kept. These

include: total number of C-130 cases; total client service time;

total resource service time; total number of C-130 flights exceeding

12 hours. For each queued or delayed case, its time spent in the

queue, its reason for delay, and its identification are recorded.

After each district has been exercised under similar conditions,

and the results integrated, the Coast Guard manager will be capable of

evaluating the utilization of C-130' s for the coastal SAR mission.
Special Pre-Processing for IDASS

A

Figure Al:
Figure A2: IDASS; ASIN1; IS
Figure A3: ASIN 2; ASIN 3

A- 11

Appendix B: Glossary of Terms

A: Adjacent Station

AIA: District in which Case occurred. See IDLOC

AIR: Air temperature at time of the Case. See B6.

AOST(i,j): Vector time for IDASS from i to j

A3: Number of Case. See NOCAS.

A4: Month and year station was notified.

B16: Type of distress area

BETA: Length in nautical miles of 1 degree of longitude at district origin

B3: People on board distressed unit

B5: Value of property involved

B6: Air temperature at time of the Case. See AIR.

C (K) : Cost for each capable resource K

CL: Crew Level

Dl: Assisting resource type

D3: Time resource was underway

D4: Time resource arrives on scene

D4FRST: Time resource arrives on scene time and completes search,

D6: Search Lime for a single resource

D6T0T: Total search time for a Case

D8: Total elapsed time underway on Case

D9: Number of sorties for a resource

Dll: Assistance rendered to personnel

D12: Primary assistance rendered to property

B-l
D13: Secondary assistance rendered to property

DD: Distance and destination client is to be towed or escorted

DLAY(L): Time to get underway for resource type L

DRS: Distribution for severity level change

A(i): Proportion of time into case completion resource i arrived on scene

EIAT: Estimated idle alpha time - IDASS

END (L) : Endurance in hours for resource type L

EOF: End of file

FLAG: Indicates if the (i-l)st resource is waiting on the ith resource

FPRI : Priority of the Case as it enters the system. Determined in

PREPRO. See S.

FRST: First resource on scene begin serving a need

y: Degree of non-parallelism of a multi -resource Case

HU: Hookup time distribution

IDELTA: Step increase of the Case priority

XDLOC: District in which Case occurred. See AIA.

INTRAP: Overide RAP switch

IPC: +1 Severity increase

-1 Severity decrease

0 No severity change

k: Index for resources

K: Number of capable resources.

KS: Number of re-evaluations to be made of the case severity, a user input

L: Index for resource types

LAST: Time last resource left scene after searching and serving need

B-2
Aij

Arrival rate, ith hour of jth time period

LVTM: Time at which resource i completes search, if any, and servicing

m: Number of tow or escort resources. See MMM

MILES: Distance off-shore. See OFSHR

MINC1: Minimum time of notification of the Case. See OCCUR and A4

MMM: Number of tow or escort resources. See m

MR: Milti- resource

n: Number of needs except search and tow. See NNN

NN: Total number of needs plus hand-off tows; NN = n+m-1, when m > 0

NN = n , when m = 0

NNN: Number of needs except search and tow. See n

NEED: Specific need of a Case

NEED(i): Need being served by ith resource

NH: Night hours if tes exceeds the number of daylight hours

NOCAS: Number of the Case. See A3

NOINT: Number of interrupts of the Case

NOTIF: Notification time of Case

NQUE: Total number of times a Case is queued

OC(L): Operating cost/hour, for resource type L

OCCUR: Date and time of Case arrival to the system. See A3 and A4

OFSHR: Distance offshore. See MILES

Origin Latitude : )

<> district origin

Origin Longitude

: J

P: Primary station as defined in OPSIM

B-3
PDC(DAY): User input, percentage of SM(i) desirable to achieve,by each

search resource, for the DAYth day into the search

PR(k): Percentage of SM(i) completed before SUNSET or TOLS(S) by each

of the K capable resources

PRI : Priority of the Case

PRTSM (i) : Fractional split of TSM as a function of SI

RLSfk): Resource leave scene = TIME + t (k) + t (i)

REA(CASE) : Reason case was first placed in queue

RNSEED: Random number seed

ROSQc): Time resource arrives on scene = TIME + t c

(k).

RST: Resource Service Time - IDASS

RAP(i): Resource assignment policy

S: Severity of the Case. See FPRI and PRI

SI: Average number of search resources; operating in parallel

S2:

j

0 No short search

"S 1 Short search by assigned resource

I 2 Short search by additional resource

SFLAG: Indicates first resource assigned to the search Case

SM(i): Number of search miles a search resource attempts to complete

S0A1 (L) : Speed of advance for resource type L during weather condition 1

S0A2 (L) : Speed of advance for resource type L during weather condition 2

S0A3(L): SOA when searching, for resource type L

SR: Single resource

STAND: Station number as defined in PREPRO

SUNRISE: User input time

SUNRISE LIST: A list of held-over search cases which are examined at

SUNRISE - x

B-4
SUNSET: User input time

SVAR: Severity increase factor for short search

t : Elapsed time on scene serving needs

tes: Elapsed time spent searching only

t^(L) : Refuel time, for resource type L

t^: Tow hookup time (or escort delay time)

TIME: Current Simulated Clock Time

TOL(S): Tolerance for non- search use at severity level S

t

g

(i): Time spent on scene searching for sortie i

tos(i): On scene time for serving need i

tos: Hookup time plus tow time

TOS: Time on scene for IDASS

TOWTIME (i) : Tow time for the ith towing resource; or escorting resource

TOLS(S): Search tolerance time at severity level S

tret(i) : Time to return to homeport

t : Towspeed

t

st Q0: Time spent searching (total)

> for capable resource k

TVEC: Time to vector to case IDASS

Tvec 00 : Time it takes capable resource k to vector to expected search

area

TSM: Total search miles on a case

x: The hours before SUNRISE when held-over search cases are examined

for resource assignment (user input)

Case Location in statute miles

B-5

Appendix C. Glossary of Flowchart Symbols

Control is passed to a subroutine at the simulation time, STIME

Control is returned to main program at

present time, TINE

f

!

©

R^rj)

IRET

Connector

Return to main program

Return to main program

( )

Control is passed to a subroutine at the present

time, TIME

C-l
Subroutine called at

present time, TIME

Merge information according

to a given order