NATIONAL BUREAU OF STANDARDS REPORT

10 592

A SIMULATION MODEL FOR ESTIMATING AIRPORT TERMINAL

AREA THROUGHPUTS AND DELAYS

T echnical Report

to the

Federal Aviation Administration

Systems Analysis Division

Systems Research and Development Service

Technical Analysis Division and

Applied Mathematics Division

Report No. FAA-RD 71-9

by

U.S. DEPARTMENT OF COMMERCE

NATIONAL BUREAU OF STANDARDS
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards ' was established by an act of Congress March 3, 1901. Today,

in addition to serving as the Nation’s central measurement laboratory, the Bureau is a principal

focal point in the Federal Government for assuring maximum application of the physical and

engineering sciences to the advancement of technology in industry and commerce. To this end

the Bureau conducts research and provides central national services in four broad program

areas. These are: (1) basic measurements and standards, (2) materials measurements and

standards, (3) technological measurements and standards, and (4) transfer of technology.

The Bureau comprises the Institute for Basic Standards, the Institute for Materials Research, the

Institute for Applied Technology, the Center for Radiation Research, 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 an Office of Measurement Services and the following technical

divisions:Applied Mathematics—Electricity—Metrology—Mechanics—Heat—Atomic and Molecular Physics—Radio Physics -—Radio Engineering -—Time and Frequency - —Astrophysics -—Cryogenics.-

THE INSTITUTE FOR MATERIALS RESEARCH conducts materials research leading to im- proved methods of measurement standards, and data on the properties of well-characterized

materials needed by industry, commerce, educational institutions, and Government; develops,

produces, and distributes standard reference materials; relates the physical and chemical properties of materials to their behavior and their interaction with their environments; and provides

advisory and research services to other Government agencies. The Institute consists of an Office of Standard Reference Materials and the following divisions: Analytical Chemistry—Polymers—Metallurgy—Inorganic Materials—Physical Chemistry.

THE INSTITUTE FOR APPLIED TECHNOLOGY provides technical services to promote

the use of available technology and to facilitate technological innovation in industry and Government; cooperates with public and private organizations in the development of technological

standards, and test methodologies; and provides advisory and research services for Federal, state, and local government agencies. The Institute consists of the following technical divisions and

offices: Engineering Standards—Weights and Measures — Invention and Innovation — Vehicle

Systems Research—Product Evaluation —Building Research—Instrument Shops—Measurement Engineering—Electronic Technology—Technical Analysis.

THE CENTER FOR RADIATION RESEARCH engages in research, measurement, and application of radiation to the solution of Bureau mission problems and the problems of other agencies and institutions. The Center consists of the following divisions: Reactor Radiation—Linac Radiation—Nuclear Radiation—Applied Radiation. THE CENTER FOR COMPUTER SCIENCES AND TECHNOLOGY conducts research and

provides technical services designed to aid Government agencies in the selection, acquisition,

and effective use of automatic data processing equipment; and serves as the principal focus

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 — Sys- tems 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 development of the National Standard Reference Data System and a system of information analysis centers dealing with the broader aspects of the National Measure- ment System, and provides appropriate services to ensure that the NBS staff has optimum accessibility to the scientific information of the world. The Office consists of the following

organizational units: Office of Standard Reference Data—Clearinghouse for Federal Scientific and Technical

Information —Office of Technical Information and Publications—Library—Office of Public Information—Office of International Relations.

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

- Located at Uoulder. Colorado 80302.

' Located at 5285 Port Royal Road. Springfield. Virginia 22151.
NATIONAL BUREAU OF STANDARDS REPORT

NBS PROJECT

4314569 May 1971

NBS REPORT

10 592

A SIMULATION MODEL FOR ESTIMATING AIRPORT TERMINAL

AREA THROUGHPUTS AND DELAYS

Judith Gilsinn

with

E. H. Short, W. A. Steele, D. Klavan

Technical Report

to the

Federal Aviation Administration

Systems Analysis Division

Systems Research and Development Service

by

Technical Analysis Division and

Applied Mathematics Division

Report No. FAA-RD 71-9

IMPORTANT NOTICE NATIONAL BUREAU OF STAh

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, 2015.

accounting documents intended

bjected to additional evaluation ting of this Report, either in

Iffice of the Director, National

he Government agency for which

es for its own use.

U.S. DEPARTMENT OF COMMERCE

NATIONAL BUREAU OF STANDARDS
*
TABLE OF CONTENTS

pag£

1. INTRODUCTION 1

2. FUNCTIONAL DESCRIPTION OF THE MODEL 7

2.1 GENERAL DESCRIPTION 7

2.2 SPECIFIC DESCRIPTION OF SIMULATION MODEL 21

2.2.1 FLIGHT GENERATION 22

2.2.2 OPERATION SEQUENCING 28

2.2.3 MAINTAIN SEPARATION 29

2.2.4 LAND OR TAKE OFF 31

2.2.5 OUTPUTS 32

2.3 SPECIFIC DESCRIPTION OF PREPROCESSOR 38

3. DESCRIPTION OF COMPUTER IMPLEMENTATION 49

3.1 GENERAL REMARKS 49

3.2 THE PREPROCESSING PROGRAM 55

3.2.1 DATA GROUP 1 - AIRCRAFT TYPE DESCRIPTION 58

3.2.2 DATA GROUP 2 - MIX OF AIRCRAFT TYPES 60

3.2.3 DATA GROUP 3 - LANDING AND TAKEOFF RATES, BY HOUR OF

DAY 60

3.2.4 DATA GROUP 4 - SEPARATION REQUIREMENTS 61

3.2.5 DATA GROUP 5 - AIRPORT DESCRIPTION 63

3.2.6 DATA GROUP 6 - RUNWAY USE AND DEPARTURE FIX DISTRIBUTION 65

3.2.7 SIMULATION INPUT 66

3.2.8 PREPROCESSOR OUTPUT 67

3.3

THE SIMULATION PROGRAM 69

3.3.1 EVENT EXGEN 72

1
page

3.3.2 EVENT GEN 78

3.3.3 EVENT NXTOP 81

3.3.4 FUNCTION FREER 84

3.3.5 EVENT LAND 87

3.3.6 EVENT TOFF 93

3.3.7 EVENT FTIUP 99

4. OUTPUTS FROM ILLUSTRATIVE RUNS 103

5. RECAPITULATION AND NEXT STEPS 121

5.1 VALIDITY AND MODEL SENSITIVITY 124

5.2 SENSITIVITY ANALYSES 126

5.3 MODEL MODIFICATIONS 128

5.4 AIRPORT DATA FILE 134

5.5 CONVERSION OF THE MODEL TO A TIME-SHARING SYSTEM .... 136

6. BIBLIOGRAPHY

APPENDIX A: INPUT FORMATS § USER INSTRUCTIONS 140

APPENDIX B: MODEL ELEMENTS (ROUTINES, VARIABLES, ETC.) 157

APPENDIX C: LISTING OF THE PREPROCESSOR PROGRAM 162

APPENDIX D: LISTING OF THE SIMULATION PROGRAM 172

APPENDIX E: CONVERSION TO OTHER COMPUIERS i88

APPENDIX F: SEPARATION BETWEEN A LANDING AND A PRECEDING

TAKEOFF 192

APPENDIX G: TIEUP TIME RESULTING FROM INTERSECTING RUNWAYS ... 194

APPENDIX H: (MOCK) INSTRUCTIONS ON HOW TO USE THE NBS AIRPORT

CAPACITY/DELAY SIMULATION MODEL 196

FIGURE 2.1.1: DELCAP CRITICAL EVENTS (RELATIVE TO A SINGLE

AIRCRAFT)

ii
page

FIGURE 2.1.2: ILLUSTRATIVE LIST OF CRITICAL EVENTS FOR TWO

FLIGHTS 14

FIGURE 2.1.3: ACTUAL ORTER OF- OCCURRENCE OF CRITICAL EVENTS FOR

ILLUSTRATIVE LIST 15

FIGURE 2.2.1: SAMPLE MODEL OUTPUT 35

FIGURE 2.3.1: STANDARD CHARACTERISTICS OF AIRCRAFT TYPES .... 42

FIGURE 2.3.2: SAMPLE PREPROCESSOR OUTPUT: AIRCRAFT AND TRAFFIC

DESCRIPTIONS 46

FIGURE 2.3.3: SAMPLE PREPROCESSOR OUTPUT:AIRPORT CONFIGURATION . 47

FIGURE 3.2.1: PREPROCESSOR FLOWCHART 56

FIGURE 3.3.1: FLOWCHART OF THE DELCAP SIMULATION ROUTINES. ... 70

FIGURE 3.3.2: FLOWCHART OF EVENT BEGIN 73

FIGURE 3.3.3: FLOWCHART OF EVENT CHOUR 74

FIGURE 3.3.4: FLOWCHART OF EVENT EXGEN 76

FIGURE 3.3.5: FLOWCHART OF THE EVENT GEN 80

FIGURE 3.3.6: FLOWCHART OF THE EVENT NXTOP 82

FIGURE 3.3.7: FLOWCHART OF THE FUNCTION FREER 85

FIGURE 3.3.8: FLOWCHART OF THE EVENT LAND 88

FIGURE 3.3.9: FLOWCHART OF EVENT TOFF 94

FIGURE 3.3.10: FLOWCHART OF THE EVENT FTIUP. 100

FIGURE 4.1: AIRCRAFT AND TRAFFIC DESCRIPTION FOR RUN SET I . . 105

FIGURE 4.2: THROUGHPUTS, FIRST SET OF RUNS 106

FIGURE 4.3: MEAN DELAYS, FIRST SET OF RUNS 106

FIGURE 4.4: AIRCRAFT DESCRIPTIONS FOR RUN SETS II § III. . . . 109

FIGURE 4.5: TRAFFIC MIX FOR RLN SET II 109

FIGURE 4.6: AIRPORT DESCRIPTION FOR RUN SET II 110

111
page

FIGURE 4.7: OUTPUT FOR RUN SET II Ill

FIGURE 4.8: TRAFFIC MTX FOR RUN SET II 114

FIGURE 4.9: PICTORIAL DESCRIPTION OF JFK 114

FIGURE 4.10: AIRPORT DESCRIPTION FOR RUN SET III 115

FIGURE 4.11: RESULTS OF RUN SET I IT 117

IV
ABSTRACT

This report documents a simulation model (DELCAP) designed

to estimate airport throughputs and aircraft delays, taking into

account their dependence on (1) the traffic level and mix of user

types, (2) the airport configuration, and (3) the separation

rules in force. The model is implemented in two parts: a preprocessor

to facilitate data entry by providing standard data input which a user

may elect instead of providing his own, and an event-oriented simulation

model. The report includes a discussion of the elements in the airport

system which are modeled, a description of the simulation model's logic,

and a set of sample outputs. Listings of the model programs, and a

users' guide to their operation, appear as appendices. The report

concludes with suggestions for next steps in this development effort,

including validity and sensitivity analyses, model modification, and

data collection.

1. INTRODUCTION

DELCAP is a fast -time computer simulation model designed to

provide measures of airport throughput and user delays (under IFR

operations) , for a broad range of scenarios described by

(a) airport configurations and operating modes

(b) mixes of user aircraft types, and

(c) separation criteria.

It is presently conceived as mainly a planning and analysis tool,

for use in answering single queries or a series of "what if?" questions

concerning what effects changes in (a) and/or (b) and/or (c)

would have on delays and throughputs.

The model is written in the "simulation language" SIMSCRIPT 1.5,

and is presently operational on the UNIVAC 1108 computer at the

National Bureau of Standards (NBS) . In addition to the simulation,

there is a FORTRAN preprocessing program which allows the user to

provide model input in an easier and more flexible manner than that

required by the standard SIMSCRIPT input format.

The model has been run for a variety of airport runway

configurations and is believed to be capable of handling all the

configurations schematized in Table 1 of FAA’s AC 150/5060-3A

("Airport Capacity Criteria Used in Long Range Planning"), under

any mode of operation which has been described to us as "reasonable".

(An example of an "unreasonable" mode of operation is an open V

- 1

-
configuration operating away from the point and having landings

on both runways. In this case the landing patterns would cross

in the air.)

The design of a computer simulation model is generally

guided (either explicitly or implicitly) by one of two opposing

philosophies. The first of these, which might be termed the

"include every detail" view, aims at maximum realism; its ideal

is a model which closely and comprehensively mirrors all the workings

of the process being simulated. It is hoped that such a model

will "leave nothing out" and will thus be capable of answering

almost any reasonable question which might be asked about the system

under study. One consequence is that modeling and programming efforts

can proceed without awaiting prior specification in operational

terms of just what questions are to be posed.

On the negative side, however, such models are necessarily

expensive to build, to provide with reliable data at the required

level of detail, and to run. They are usually so large and complicated that only experienced computer personnel can operate them.

Because of these drawbacks, a common result is that they are run

only a few times (if at all) . Moreover their development involves

a special danger: building the "perfect model" tends to become an

end in itself, the designer losing sight of why it was desired in

the first place.

-2 -
The other view, which might be called the "model as little

as you can" philosophy, holds that models should be designed to

answer specific classes of questions, and should include only

those details of the system being modeled which directly affect the

answers to these questions. Such models, therefore, usually

cannot adequately answer questions other than those for which

they were designed. There is also the danger, in designing such

a model, of omitting some relevant detail because its relevance

was not recognized in time. This risk can never be eliminated

absolutely, but it can be reduced to a level acceptable in practice

by careful study of the system before actual design of the simulation

is begun. Indeed, proponents of the "model as little as you can"

view usually spend at least as much time in studying the system

as in the construction of the simulation model itself.

The advantage of this particular approach is that the model

is of manageable size, and therefore easier and less expensive to

operate. It can actually be used by planners, to answer questions

of the type it was designed to answer. Because of this ease

and low cost of operation, many different cases and variations

can be simulated.

There is a drawback to the "model as little as you

can" approach, which may well be the real reason many modelers

subscribe to the "include every detail" philosophy. A model which

is more "abstract", i.e. which is based on deliberate and selective

- 3

-
abstracting from real-world complexity , is also more difficult

to explain. Use of such a model lays the designer open to

accusation of ”why did you omit this or that detail?”, and leaves

him with a genuinely difficult task if the model must be explained

solely in the operationally- oriented terms familiar to the potential

user of the simulation. A proper description should, however,

produce conviction that the model includes all those aspects

of the system essential for answering the questions at which it is

directed.

In this project, we have subscribed to the second, ’’model as little as you can”, point of view. The present document is therefore designed to describe, to the prospective user of the DELCAP

simulation, which elements of the air transportation system have

been modeled and how they are represented. Chapter 2 will provide

a description of the terminal area as seen through the eyes of the

model. Chapter 3 will provide a more computer-oriented view of

the model. The input data which are needed will also be discussed

in this chapter. Model outputs are taken up in Chapter 4, which

includes descriptions of a number of sample ’’runs” of the model.

Chapter 5 summarizes the present form of the DELCAP effort, and lists

some possible directions for future work to make DELCAP an even

useful tool. This chapter also describes how the model might operate

in a computer time -sharing environment as a highly accessible

analysis tool A bibliography is included as Chapter 6.

- 4-
There are eight appendices to this report. The first of these,

.Appendix A, gives input formats and operating instructions for any

user who wishes to run the model. Sample input decks are also portrayed.

This section is intended for readers without extensive computer backgrounds

but those with more computer experience should also find it useful.

It can best be described as a "DELCAP users' manual'’, which includes

information necessary for running the existing code.

The next four appendices are meant for the programming-oriented

reader who might be interested in altering the code or in transferring

it to a different computer. Appendix B gives a list of the model

elements, subroutines, variables and arrays used both in the DELCAP

simulation and its preprocessor. Appendices C and D give listings

of the preprocessor and the simulation, respectively.

The preprocessor is written in FORTRAN and the simulation is

SIMSCRIPT. Both of these languages are available on a wide range

of computers . However, as anyone who has worked on several different

computers is well aware, the implementation of the same language

on different "machines” is apt to be quite different. Appendix E

has been prepared to document those properties of the DELCAP model

and its preprocessor which are known by NBS project staff to be machine

dependent, and hence to require possible alteration when DELCAP is

- 5

-
converted to another computer. Others may come to light during the

conversion process. It was known during the design and development

stages that the model might be converted to other machines, and this

fact was taken into consideration in designing the model; hence the

conversion process should be less difficult than if conversion had been

an afterthought.

The next two appendices contain mathematical derivations of two

\ formulas used in the DELCAP simulation. The final appendix contains

a copy of a Mock Instruction Manual for the DELCAP model as it is

envisioned to operate in its final form.

We conclude this section by listing the project staff involved

in the DELCAP effort:

Operations Research Section (Applied Math Division)

J. Gilsinn (Project Leader)

D. Klavan

Mathematical Modeling Group (Technical Analysis Division)

E. Short

W. Steele

In addition to those listed above, R. Penn of the Technical

Analysis Division and A. J. Goldman of the Applied Mathematics

Division provided valuable criticism and guidance in the course of

the model design and development.

- 6

-
2. FUNCTIONAL DESCRIPTION OF THE MODEL

2.1 General Description

The DELCAP simulation model is designed to provide measures of

throughput and user delays for a variety of teminal-area scenarios

which can be characterized by

(a) airport runway configurations and operation modes

(b) mixes of aircraft types, and

(c) separation rules.

It is intended to handle primarily IFR operations, and so the

rules referred to in section (c) above may be interpreted as IFR

separation rules.

DELCAP is envisioned as a planning and analysis tool for use

in investigating the effects on throughput and delay of changes

in any of (a), (b), and/or (c)It is not designed, for instance,

to provide controller work- load information or to output gate

assignments for various airlines. It is designed to aid in answering

questions such as, ’’Can the present configuration at a given airport

handle an increase of 501 in traffic?”, or "Would delay be decreased

by reserving one runway for large and medium size jets and large

piston aircraft?”. In accordance with the "model as little as you

can” philosophy described in Chapter 1, DELCAP has a limited scope

and limited application. It is designed to be used in planning

for next year or several years hence, rather than planning day-to-day

- 7-
operations. It can be used to examine the effects on the level

of congestion of adding extra runways, or of reducing required IFR

separation. It cannot, however, answer the much more difficult

question of how safe a current or proposed procedure is . It is

envisioned as only one part of the planning process, a tool to be

used by the planner rather than an end in itself.

Because DELCAP has the rather limited aim of providing measures of

delay and throughput, it does not have to simulate in detail the path

flown by each aircraft. All that need be represented in detail

are those aspects of the flight of an aircraft which impede the

free progress of other aircraft. If one aircraft is holding up a

second, which thereby holds up a third, etc., it is necessary only

to simulate the first and to accumulate correctly the total effects

on the others.

Since in DELCAP we are interested only in delay and throughput,

it is not necessary to know exactly where a delayed aircraft actually

is during the delay period. It may be sitting in a line on a taxiway,

or waiting at its gate. It may be flying a full race -track -like holding

pattern, or just a U-shaped curve. Our implicit assumption in the

current version of DELCAP is that aircraft are under control and

can be delivered to the ILS gate for landing or to the end of the

runway for takeoff, as soon as separation rules allow.

[This "perfect control" assumption is necessarily somewhat

optimistic. It can be tempered by adjoining, to the model, appropriate

- 8

-
probability distributions for time increments representing the

deviations from "earliest possible delivery time" which reflect

less -than -perfect control by controllers and/or pilots. Such

"Monte Carlo" elements have been postponed in our initial

development work in favor of concentrating on the basic model logic,]

DELCAP is a terminal-area simulation. Landings enter the model

approximately at handoff to tower approach control ? and leave it as they turn off the runway. Takeoffs enter the model approximately 15

minutes before departure, and leave at handoff to center control.

The present version of DELCAP does not deal with on-the-ground

activities except for the actual landing or takeoff on the runway.

Its "accounting" includes a figure representing the time needed for

a takeoff to depart its gate and taxi to the runway, but variations

in this time due to taxiway and/or ramp congestion are not now

modeled. In short, the priority decisions required by time and

budget limits have led to heavy emphasis on airborne activities

in this generation of DELCAP, with extension to ground activities

seen as a natural "growth step" requiring more care and deliberation

than was available as a "residual" in our present study.

The acronym "DELCAP" stands for DELay CAPacity, the two

items the simulation was designed to measure. Delay is a user

disutility while capacity is in some sense a system utility.

The decision as to the proper balance between these two is a policy

issue, and involves a variety of considerations relating to limitations

- 9

-
on ’’system’' budgets and personnel, value -of-time for operators and

passengers, etc. The DELCAP model’s role in this whole planning

process is to aid by translating FM rules, decisions, and airport

configuration and operation changes into delay and throughput figures.

Since the scope of the model is much less than the full gate-to-gate

span of a flight, the delay estimated in the DELCAP model is only a

portion of the total delay experienced by an air passenger. Specifically,

it is that portion of delay which may be affected by changes in(a) , (b)

or (c) of page 7. Delay is measured as the difference between (i) the

time in an ideal scenario, in which the present landing or takeoff is

the only aircraft using that terminal, and (ii) the time in the real

situation where other planes may simultaneously be seeking to use the

area.

For a landing, the time under the ideal scenario is a sum of:

A minimum flying time from handoff to the outer marker of the desired

landing runway; a time to fly the final approach path; and a runway

occupancy time. The ’’real” scenario as simulated by DELCAP may include

an additional time period (possibly zero) between handoff and the

outer marker to account for other aircraft landing before this one.

This period arises as follows. At handoff the aircraft is filed in a

waiting queue. When the time comes that the aircraft could have

reached the outer marker in the absence of other aircraft, the queue

and the final approach path are examined. If there are other aircraft

before this one in the aueue, it must wait until it is finally at the

- 10 -
head of the line. Then the ’’current obligations” of its final approach

path and runway are examined to determine when this aircraft could first

cross the outer marker and proceed down the final approach path without violating separation rules. The delay to this aircraft is then

the difference between (i) when it could have left the queue were

there no other aircraft interfering with it, and ( ii) the actual time

it was able to leave the queue. A similar process applies to a takeoff.

The ’’capacity” measured by the DELCAP model is actual throughput,

the number of operations (landings plus takeoffs) performed in a given unit of time (e.g., an hour or a day). This kind of ’’capacity”

measure differs from the common definition of capacity. The capacity

of a jug is the amount of liquid the jug can hold. This represents

the absolute limit for the jug, j.ust this much and no more. The

definition of capacity used in the FAA’s Airport Capacity Handbook [4]

refers to the maximum traffic rate which can be handled without average

delay exceeding a prescribed level. Previous work by NBS [6] offered

an alternative to this definition, based on a definition of capacity

as maximum mean throughput rate.

The DELCAP model’s capacity is a throughput measure more akin

to this last than to that contained in the Airport Capacity Handbook .

It differs from the previous NBS work in one significant respect --

it is not a maximum possible throughput rate. Rather it is that

throughput rate achievable from a given distribution of traffic over

the day (or other simulated time period). If traffic is light, throughput

will be small. As traffic increases to a level which saturates the airport,

mean throughput will approach the NBS-defined capacity. In busy periods

- 11 -
the airport throughput will be close to capacity; as peak traffic

levels pass to lower values, throughput will decrease. As traffic

fluctuates, resultant delay will fluctuate, and both will be recorded

by DELCAP. Thus DELCAP records the throughput resulting from a given

temporal traffic distribution.

The DELCAP simulation is a critical -event model. That is, within

the simulation, time is successively advanced from its current value

to that of the "next significant event”, rather than being stepped

along in uniform increments. For periods with a low traffic level,

this type of model saves much computation. Even during periods of

high density traffic, such a simulation does not increase the

number of calculations required. The SIMSCRIPT simulation language

is designed for the critical event type of simulation. The modeler

need only provide suitable descriptions of each type of critical event,

including how these events depend upon one another. The SIMSCRIPT

code then executes the events in chronological order. The critical

events for the DELCAP system are illustrated in Figure 2.1.1. This

figure is in the form of a flowchart because it illustrates the idealized

progression of events. ’’Idealized” is used here to refer to the order

of events as they occur for a single aircraft, without events for other

aircraft interspersed among them. This is not necessarily the order in

which the events occur. As an example, two hypothetical flights and an

illustrative list of the critical events for each are given in Figure 2.1.2.

The order in which the events would actually be performed by the simulation is

given in Figure 2.1.3. Two events happen to occur at 9:17; the order of

these two is inmaterial

- 12 -
Figure 2.1.1: DELCAP Critical Events (Relative to a Single Aircraft)

- 13-
FLT 1 :

( 1 )

( 2 )

(3)

(4)

C5)

Landing on runway 1

9:00 - FLT 1 enters the system.

9:12 - FLT 1 has flown to outer marker; find next operation on

runway 1 (assume next is FLT 1) .

9:13 - FLT 1 has started down flight path;

find next operation on runway 1 (none)

9:16 - FLT 1 has flown down final approach path, FLT 1 lands.

9:17 - FLT 1 leaves the system after occupying the runway.

FLT 2 : Takeoff on runway 2

(1) 9:05 - FLT 2 enters the system.

(2) 9:15 - FLT 2 leaves gate; begins taxiing to runway 2;

find next operation on runway 2

(3) 9:17 - FLT has been given clearance to takeoff;

find next operation on runway 2 (none)

(4) 9:18 - FLT 2 takes off.

(5) 9:23 - FLT 2 is handed off to center control; FLT 2 leaves the

system.

Figure 2.1.2: Illustrative List of Critical Events for Two Flights
9:00 FLT 1

9:05 FLT 2

9:12 FLT 1

9:13 FLT 1

9:15 FLT 2

9:16 FLT 1

9:17 FLT 2

9:17 FLT 1

9:18 FLT 2

9:23 FLT 2

(1)

enters the system

(1) enters the system

(2) find next operation on runway 1

(3) find next operation on runway 1

(2) find next operation on runway 2

(4) land

(3) find next operation on runway 2

(5) leaves the system

(4) takeoff

(5) leaves the system

Figure 2.1.3: Actual Order of Occurrence of Critical Events for

Illustrative List

- 15 -
The basic concept around which the DELCAP simulation model is

built is that of tieup . The presence of one aircraft limits the actions

which another controlled aircraft may take. For example, present FAA

separation rules require any IFR landing aircraft to be separated by

3 miles—' from other landing aircraft and 2 miles from preceding takeoffs

on the same runway; other restrictions apply between takeoffs. Parallel

runways have special rules, depending on how far apart the center lines

for the parallel runways are. These various separation rules are imposed

in the model by declaring certain points traversed by an aircraft to

be off limits ("tying up" those points) to all subsequent aircraft

for a period sufficiently long to insure that the required separation

is maintained. In the present version of DELCAP, tieups can occur

at one of three such points associated with each runway. Two pertain

to landings, namely the outer marker and the runway threshold; the

third, which refers to takeoffs, is the point at the end of the runway

2 / from which a takeoff starts its roll.—

3/ The 3-mile separation—' between successive landings is enforced,

either by tying up the outer marker from the time the first aircraft

crosses it until the second has flown three miles, or by tying up the

runway threshold from the time the first aircraft has landed until the

second has flown 3 miles. (Which of these alternatives applies depends

on the relative landing speeds of the two planes.)

T/ All distances referred to in this report are in nautical miles

Speed will therefore be in knots.

2/ Throughout the remainder of this report, the term "end of runway"

will be used to designate this point. It and the runway threshold

are assumed to represent approximately the same physical point on the

runway.

3/ The 3-mile value and the values for the other separation distances

are adjustable parameters in the simulation model.

- 16 -
The other separation rules are imposed in a similar manner. The

prohibition against more than one aircraft being on the same runway

at the same time is enforced by tying up the runway threshold and the

end of the runway for the entire time a landing or takeoff occupies

the runway. Interference between operations on intersecting runways

can also be represented by the tieup concept: the end and threshold

of a runway are tied up from the time an aircraft on an intersecting

runway starts its roll or touches down until it clears the intersection.

Interference between successive landings on parallel runways 3500

to 5000 feet apart can be portrayed by appropriately tying up the outer

marker or the runway threshold of both runways.

The separation required between a pair of departing aircraft

depends on the particular paths followed by the two aircraft after

departure. If they diverge immediately only a 1 -minute separation

is required, if within five miles then a 2 -minute separation is called

4/ for, etc.— All but one of these separation rules are in terms of time;

the exception, a distance separation (3 mi.), is converted to the weighted

average (over aircraft types) of the time to fly that distance. Each

takeoff is associated with a departure path when it first enters the

model. The simulation assumes that aircraft diverge as soon as their

departure paths diverge. Thus the separation required between two

£/ See Terminal Air Traffic Control (FAA 7110. 8A) for a complete

description of these rules.

- 17 -
takeoffs from the same runway depends solely on the pair of departure

paths involved. An analogous second set of values for separation times

applies to takeoffs on different runways. (This procedure for simulating

separation between succeeding takeoffs is an approximation which may

merit refinement in later work.)

Two final considerations will be emphasized in this overview.

First, in keeping with the design of DELCAP as a planning tool, it

is necessary that the simulation be fast to operate, while representing

enough of the system to provide usable delay and throughput figures.

The current DELCAP has been run to simulate a day's activity (about 1000

operations) at an airport with the runway configuration of New York's

JFK; this took about 12 seconds on the UNIVAC 1108 computer. (The

time-figure includes the time required for reading input data, but not

that for program compilation.) It seems clear that with this speed,

computer-cost and running-time considerations should not deter a

planner from analyzing the full "reasonable" range of cases of

interest to him.

Besides being fast, DELCAP must also be easy to operate if it is

to be useful as a planning and analysis tool. The most time-consuming

and laborious task in running any simulation is preparing the input.

Both the job of collecting the information (if it is not readily available)

and that of formatting it in computer-readable form can be difficult,

indeed forbidding. These problems were recognized in the design of the

DELCAP model. The simulation itself is written in SIMSCRIPT, which

- 18 -
requires a rather awkward and rigidly prescribed input format. To

overcome this, a FORTRAN preprocessing program was written. This

program accepts input in a more easily prepared format and was

specifically designed to make a user's task less laborious. Data

are grouped into six categories. The user m^ specify any or all of these

categories, or may elect not to specify a category, thereby accepting a

standard set of values for that category. At present the configurations

for two airports (ATL and JFK) are available as "standard" sets.

Other airports may be included by assembling the necessary data and adding

them to the input tape.

The six data categories are:

1. parameters describing each type of aircraft, such as landing and

liftoff speeds and runway occupancy times,

2. mix of aircraft types using the terminal area,

3. number of aircraft, desiring landings and takeoffs

respectively, to enter the model for each hour of the day,

4. separation rules,

5. description of the airport configuration and operation, and

6. distribution of runway use by aircraft type, separately for landings

and takeoffs

Standard values for 1 and 4 are independent of the airport, while standard

values for each of the other four categories are provided for each airport

in the airport data list. A user need specify only those data which he

wishes to differ from standard values, plus the airport identifier for the

standard values which depend an airport. This policy, of data input

- 19-
?Tby exception” to a standard data set, facilitates ease of input while still

allowing full flexibility.

This concludes our overview of the DELCAP model and of the design

criteria under which it was built. The next section will describe in

greater detail how DELCAP simulates terminal-area activities. Its

preprocessor will be described in the following section.

- 20 -
2.2 Specific Description of Simulation Model

To explain the operation of the DELCAP model in further detail,

we will in this section "fly” a hypothetical aircraft through the

simulation, describing hew its progress is represented by the various

elements of the model. The next chapter describes in detail the

computer-program implementation of this procedure. Here, our aim is

a functional description of the simulation, rather than a computeroriented view.

Figure 2.2.1 describes the critical events which occur to a single

aircraft

1 . generation of flight,

2. sequencing of operations on a runway,

3. maintain separation, and

4. land or takeoff.

A landing aircraft enters the system at handoff.to tower approach control

and is filed in a landing queue (for its runway) in which it remains until

the minimum time to fly from handoff to the outer marker has elapsed.

The next event which affects this aircraft is the choice, depending on

the operational procedure for its particular runway, of the next

operation ( a takeoff or a landing) which is to occur on this runway.

Once the aircraft has come to the head of the queue and the next operation

is a landing, the model must ensure that the aircraft does not violate

any separation rules pertaining to it. Finally it is removed from

- 21 -
the queue, is scheduled to land, and the relevant points are tied up

to ensure that other aircraft will remain separated from it.

A takeoff enters the system about 15 minutes before departure

as scheduled in a filed flight plan and at this time is filed in a

queue in which it remains until a few minutes before scheduled takeoff.

Mien the flight has reached the head of the queue and the next operation

to be scheduled is a takeoff, the flight is removed from the queue,

and is scheduled to takeoff as soon as possible while maintaining

required separation. Once it has been scheduled relevant points are

tied up to ensure other aircraft are separated from it.

The rest of this section will describe each of these four

critical events in greater detail.

2.2.1 Flight Generation

Aircraft enter the simulation in two ways, one stochastic and the

other deterministic. In any one simulation run, either or both methods

may be used. In the stochastic form, aircraft are generated in a Poisson

manner. (Employment of this particular distribution is somewhat

arbitrary, and it can be replaced by a different one if found more

appropriate.) The use of a Poisson distribution in effect assumes

that the probability of the arrival of an aircraft in the system at

any time is independent of any previous arrivals.

Such randomness may be an appropriate representation for low or

moderate traffic densities. In a highly saturated air traffic system,

- 22 -
however, congestion in terminal areas is felt in other sectors as well.

Since IFR traffic is under control from takeoff to landing, traffic

patterns are in fact not random. Wien a terminal area becomes

saturated, flights destined for this terminal may be held up at

distant points and handed off to the terminal area only as a slot

in a stack becomes available. This extreme case, almost diametrically

opposite to Poisson randomness, represents a nearly uniform distribution

of arrivals into the terminal -area landing pattern.

A similar situation may exist with regard to takeoffs: the

arrival of a takeoff in the "system" is about 15 minutes before

departure as scheduled by filed flight plan, but in actual practice

when the flight plan is filed the pilot can be advised of expected

delay and may revise his flight plan. The simulation deals only with

revised plans, which in heavy traffic would tend to exhibit a less

random behavior.

The particular form of Poisson generation used in DELCAP does

allow representation of the diurnal peaking of traffic density.

The user can specify both the mean number of landing aircraft to be

generated for each hour of the day, and the mean number of takeoffs.

The expected time (as a fraction of an hour) between generation of

successive takeoffs or landings is computed as the reciprocal of

the number of takeoffs or landings entering the system per hour.

If the next scheduled landing or takeoff to be generated enters

- 23 -
the system in the next hour, it is rescheduled according to the

generation rate for the proper hour. This avoids a situation

such as the following:

(a) Hour 1 has 1 landing per hour.

(b) Hour 2 has 12 landings per hour.

fc) Flight 1 is generated (hay) at 1:30; Flight 2 is

then scheduled (say) for 2:30 on the basis of the M l-hour

spacing" rule still in force at 1:30.

If the simulation were really to wait until 2:30 to start generating

flights an average of five minutes apart, then the expected number of

flights for Hour 2 would be only half as large as it should be. The

rescheduling procedure described above can be shown to provide the

correct expected number of landings. For the preceding example,

flight 2 would initially be scheduled for 2:30. At 2:00, however, it

would be rescheduled using the expected time until the next landing

as 5 minutes. Subsequent flights would continue to use this 5-minute

figure until some flight was scheduled for Hour 3. At 3:00, this

flight would be rescheduled, and so on. A second, deterministic method of generating flights is available.

The simulation may be provided (on a magnetic tape or on cards) with

a list of landings and takeoffs in the order of their entries to the

system. This form of traffic generation may be used either instead of

or in conjunction with the Poisson generation described above. For

example, scheduled air carrier flights might be input in a deterministic

- 24 -
fashion while unscheduled flights could be generated by the Poisson

process, fit should be noted that in this case the input values

of the expected numbers of landings and takeoffs for the Poisson

process should reflect unscheduled traffic levels only, not the

combination of both.)

We should emphasize here that in a computer, the stochastic form

is ’’pseudo -random” rather than truly random. If the same starting

number (’’seed) for the computer’s pseudo -random-number generating

routine is used in two runs, exactly the same sequence of ’’random”

numbers will occur. Therefore the stochastic mode of traffic

generation provides a repeatable traffic sample, which may properly

be used in comparing various alternatives. If however the expected

number of landings or takeoffs per hour is changed between two runs,

then different traffic samples will occur.

Each flight which enters the system is (1) designated as either a

landing or a takeoff, (2) associated with a specific runway, (3)

identified as of a particular aircraft type category, and if a departure,

(4) assigned to a particular departure path. In the stochastic

generation process these selections are made through a random process,

while for deterministically generated flights they are read in as part

of the flight description. For the stochastic process, the simulation

must be provided with (1) one distribution of aircraft types for landings

and a second one for takeoffs, f2) the distribution of runway use by

aircraft type for landings and also for takeoffs, and finally

- 25 -
C3) the distribution of departure paths for aircraft using each

runway. As a flight is generated, the appropriate distributions

are sampled to assign to it a type, a runway and (if it is a

takeoff) a departure path.

[It should be clear from the description of this process, that the

runway choice is not influenced by the traffic levels of the various

runways at the time of generation. That is, the runway-use distribution

presently can reflect only general traffic levels for each runway; this

distribution is not altered within the simulation, remaining constant

throughout. Permitting such "adaptive” alterations would require only

a fairly minimal change in the DELCAP model, but the user would then

have to specify those "threshold" traffic levels at which a change in

runway assignment would be encouraged.]

After a flight is generated and has received its proper runway,

type, and departure path assignments, it is placed into a queue of

aircraft waiting to land or takeoff from its assigned runway. There

are two separate queues for each runway, one for takeoffs, and another

for landings. These queues are organized in a first-in first-out

(FIFO) manner. This means that aircraft which are to land on a particular

runway land in the order in which they enter the system, regardless of

speed or category of aircraft. It does not mean, however, that

aircraft landings on different runways (or landings and takeoffs on

the same runway) occur in the order in which they entered the system.

- 26 -
This first-come first-served process models the presently stated

control policy. To model a more sophisticated sequencing policy, the

queues could instead be ordered based on some attribute such as type

classification or flight priority level. (SIMSCRIPT list structure

allows such changes with a minimal amount of recoding.)

Landings remain in the queue for at least the minimum time for

that type of aircraft to fly from handoff to the outer marker of the

proper runway. Takeoffs are generated about 15 minutes before

planned departure and are filed into the queue at this time.

- 27 -
2.2.2 Operation Sequencing

The next section of the simulation which affects our hypothetical

flight is the routine which sequences operations on runways. If for

example our aircraft is to land on "runway R", then it can move up in its

queue only when this routine, applied to runway R, selects the lead

operation of that runway’s landing queue rather than its takeoff queue.

There are four different operational procedures which govern

whether the next aircraft to use the runway in question will be a landing or a takeoff. Runways may be restricted to landings only or

takeoffs only. In either of these two cases the simulation will schedule

the next operation of the permitted type if one is available.

The last two procedures apply to dual-use runways (used for

both landings and takeoffs), and are slightly more complicated. The

first of them seeks to alternate landings and takeoffs during heavy

traffic periods (and to take the first available operation otherwise).

If the last operation was a takeoff, for instance, then the landing queue

is examined. If the first flight in it will be available when the runway

and final approach path are next free, then that landing is designated as

the next operation on this runway. However, if the landing queue is

empty or the first aircraft in it will not be immediately available, the

takeoff queue is examined. If the first flight in the takeoff queue will be

available immediately, it is designated as the next operation. But

if neither landing nor takeoff will be available immediately, the one which

will be available first is chosen. (Of course if there are no aircraft at all

in either queue to use this runway at the time, then no "next operation"

- 28 -
is schedule c

1,)

The fourth procedure attempts to model the "landings take precedence"

rule. This procedure is very similar to the one described above for

alternating operations, except that the landing queue is always examined

first. If the first landing is available immediately then it is assigned

as the next operation. If not, then that operation (landing or takeoff)

which would first be available becomes the next operation. At present

the model provides no method to change the operational procedure for a

runway during the simulation, although it would require only a minimal

change to do so. The user would then be required to specify the conditions

or times for which this should occur.

2.2.3 Maintain Separation

The next block of the model which affects our hypothetical flight

is the section which insures that required separations are maintained.

Relevant when the flight reaches the head of its designated runway’s

landing or takeoff queue, this routine finds the first time the flight

can land (or takeoff) on that runway. For takeoffs the end of the

runway is examined, and the flight is allowed to start its roll as

soon as this point is free (no longer tied up) . For landings both the

outer marker and the runway threshold are examined, since a landing must pass

both of these points: Let t

1

be the time at which the outer marker will be

free (no further tieups for it are currently known) , and t

2

the

corresponding time for the runway threshold. Let T be the time it takes

this flight to fly the final approach path from the outer marker

- 29 -
to the runway threshold. Then the flight may start to fly down the

final approach path at whichever of t^ and t

^ ~T is later.

Several tieups may be in force at any of the three points:

outer marker, runway threshold and the end of the runway. The

model always forces an aircraft to wait until there are no currently

known tieups applicable along its path, even though theoretically there

might be a gap between tieups sufficiently large to allow fitting an

operation between two previously scheduled ones. That this is an

infrequent event in practice depends on the fact that in the model

takeoffs and landings are scheduled approximately the same time

before touchdown and start-of-roll respectively. For any runway

the takeoffs are scheduled in the order in which they are generated,

and similarly for landings. The sequencing routine takes care of

the order of operations on any one runway and takes into account

the times at which those operations can occur. Therefore the only

case in which a flight might be squeezed in between two tieups would

involve inserting that flight before a tieup caused by a flight which

has been previously scheduled on another runway. This circumstance

is unlikely to occur except in the situation of a slow landing which

has just started down the flight path on one runway and a fast takeoff

which could take off on a second runway and remain safely separated

from the landing.

Allowing in the simulation for such "insertions” would require

major complication of the model logic. Granting that the situation

wiH se ld°m occur (indeed we have only seen it once or twice in our

- 30 -
debugging runs) , its overall effect on aggregate measures of capacity

and delay is minimal. On this basis, it was decided that the extra

complication would be unwarranted.

2.2.4 Land or Take Off

Finally, our hypothetical flight is ready to land or take off. In

the simulation this process essentially consists of tying up the appropriate

points to ensure that "following" aircraft maintain required separation

from the given one. "Following" is used here to refer to those flights

whose landing or takeoff is scheduled after the current one. In crder

to maintain the required separation between landings either the outer

marker (if the following landing is slower) or the runway threshold

(if the following landing is faster) is tied up from the time the

current flight passes that point until the second flight has flown

the separation distance. Both the runway threshold and the end of the

runway are tied up for the period the current aircraft occupies the

runway. A landing ties up the end of the runway, and a takeoff the

runway threshold, for a time period sufficient to maintain the separation

between a takeoff and a following landing. (The formula for this

separation, based on the assumptions of constant final approach speed

and constant takeoff acceleration, is derived in Appendix F.) A

takeoff ties up the end of the runway for a separation time required

between takeoffs. Points on other runways with which the present

runway interferes are tied up in a similar manner. For intersecting

runways , the runway threshold and the end of the runway are lied up until

- 31 -
a landing or a takeoff passes the intersection point or turns off

the runway, (The formula for the time until a landing or a

takeoff reaches any point down the runway is derived in Appendix G.)

This concludes the progress of our hypothetical flight, except

for a final routine which records the associated delay. This delay

is recorded at touchdown for a landing, and at the start of roll for

a takeoff. Therefore the delay attributed to any hour only refers to

delay suffered by an aircraft which touched down or started its roll in

that hour. The delay itself may have occurred in the previous hour, or

possibly partially even before that.

To summarize, our hypothetical flight has gone through six steps:

1. generate flight;

2. file flight in the appropriate queue;

3. find the next flight for any runway;

4. find the first time this flight can use its runway and

(for landings) its final approach path, without violating

separation rules;

5. tie up the appropriate points to maintain separation following

this flight; and

6. record flight delay.

2.2.5 Outputs

The final portion of this section will be devoted to describing

the outputs available from the present version of DELCAP. We will

describe later, in Chapter 5, the kinds of output which could be readily

- 32 -
provided with minor changes in the program; it is sufficient to note

here that the current set of outputs is only representative of the

potential outputs available from the present version of DELCAP.

Toward the end of this current work, a proposed set of ’’mock instructions"

describing the DELCAP model was circulated within the FAA. This document was designed to elicit comments on the model’s usefulness and

descriptions of specific problem scenarios in which it could be applied.

It was hoped that answers to the questionnaire accompanying the "mock

instructions” would provide a better description of desired model

output. However this particular goal of the circulation was not

achieved, and so the present model output remains only illustrative

of potential outputs. (The "mock instructions" are repeated as

Appendix H.)

Figure 2.2.1 shows a typical example of model output. Chapter

4 will include a more complete description of model runs; we are

here mainly concerned with the form of the output. The section

which follows this will describe the preprocessor and the output

from it, which provides labeling for a run by describing that run's

input specification. The output in Figure 2.2.1 however, is from

the simulation model portion only.

- 33 -
The airport configuration for this run is that of the Atlanta

airport (ATL) . Delay and throughput figures were accumulated for

24 hours, starting and ending at 8 a.m.-^ The simulation was actually

run for 25 hours, starting at 7 a.m. rather than 8 a.m. to allow

preloading the system so that the delay and throughput calculations

could start off with some traffic already present. The starting

hour of 7 a.m. was chosen because there is very little traffic at this

time and one hour’s preload seems to be sufficient.

5/ The column labeled HOUR refers to the hour of the day, so that

hour 1 is from midnight to 1 a.m. , hour 8 is from 7 to 8 a.m.

and hour 17 is from 4 to 5 p.m. The first hour for which delay

was recorded is therefore actually hour 9.

- 34 -
UPLKAUUNS

0fc.iMt.nA

IcU

OHLKAIIoNb

PERFORMED

TOTAL

DtL AY

(

M

I

NUTES

)

DELAY

PER

A/C

(MINUTES)

LANpiWOb

iMM_Of-rb

IoTml

LANDINGS

TAKEOFFS

TuTmL

LANDINGS

TAKEOFFS

ALL

LANOINGS

TAKEOFFS

ALL

•h «h ® ror>-xh' 0'CMXO'oocoo®x*'f,-*« co ino(yiHoooocH9>NN$«a^o<H«ineli r*- ro r~

O' r^., nNEH^O'O'^O'H^OMThOE X • •••••••••••••••••••*•••• • c\jcccoococcfOcvaas ^^oj«HC\i 0 ^r^^c rr> & <v-*r^ccviflr**^c«^a'cvas H ^ «H ^ ^ (\) H H

3 (\j«c cv ror'-x«-<x~:i-ocM®p''03»*x

ftiCNNoccccwrociOlNiflCiMoireiN ~cM(Mcoxxxr^ 3 CM:j-xx

x

• a

x

O' ro cm 3 X C •H IT rO CV r~ X X o- r- ro C rtMT 3

r- c X) 3 o O 3 fO -H O O' O' rO CM X ro ro *h X (THtOC X m ro .H H ^ CO CM X CM r- r- o r*~ r*- O' CM CM X ®

r- x r~ 3 j- r- CM ro O 3 3 ^ H N OJ H

3- S) X O' O' 3 * o ®

E*

IT CO f- X CM CM X C CM X — X 3 o O' H® (MG rO

CO o O CM o 3 3 cv -« CM —i X f*- X O' «n o r*- ® ® CM ® X ®

CVJ X X XXX X X 3 X 3 HN 3 M dIs- CM O' —M O 3 cf -t X r*> CM CM ”M CM O rO X X X X X X X

cf X ro ro X O' O O CM O CM r*- cm x r- O O' ,4 ,4 O' H

O' 0X^3 3 3 3 3 X CV ~ cm r*- ro —< CV CO 3 r- O' I X cv X

"O -H 3 X CM C X X O' -t 3 3 X M- 3- 3 o

o r- r- 3- x rO 3 O' 3- ® X H

•H CM CM CM rO cl- * X CM

*5

cv — — -Hroxxxf^xxxxr^xxr^xx o

r'd--«d-ir3MXXr>-C!xr»rnxo'o®ii'P^-M®ojX) cm

-h -r-rCM'M'MOCM.M'OCMrOMO-OrO'O O' 3

XC\lXX3XX'XO-«rO ,X)K)XO<OXr^®r-CM3'Xr~ rO

-t CMO-0-0000 0:M-00-OOAI«»» -Hn

oi-orooiM-rT'T'ooij-o'Jj-oc')'-''''' t

"M 3

-h -i 3

cfj--t"OX-r—ion 3> 3- xd-or^-* ,o-«d-xxcM.Hr*'a' —

m -» m \i x 3 rt a t n j -i -i h -i j't

M30'-r3X3'"0-t.,->'0-iTX'OOM3-«0-«D33 O

H OOcfJ-'fOOOCO-t-t -t M -« J)

X

0

T

£X

3

J -rMO:*XO'^C 7' 3 -«MO:i-nO^--0 :J' 3 -«\]OJ- <

- 35

-
This extra hour of simulation also accounts for the fact that one

more takeoff was performed than was generated. Even without delay, the

time between generation and takeoff or landing is 15 - 20 minutes.

Therefore, those aircraft landing or taking off during the first part

of hour 9 (8 am to 9 am) are actually generated during the previous hour,

but are not recorded. Similarly, toward the end of the simulation

aircraft are generated which land or take off only after the simulation

has finished. Therefore, there is no a priori reason for the recorded

number of operations generated to coincide with the number performed.

The distributions of landings and takeoffs were taken from data

pertaining to San Antonio International Airport. However about

60 percent of San Antonio traffic is VFR, whereas in our present

DELCAP model all this traffic is required to obey IFR rules. This

explains the high level of simulated delay, which would certainly

be intolerable at a real airport. This run and the others described

in this report should be interpreted as examples of possible model runs,

rather than runs based on actual data. (Within the time and resource

limits of the current effort, no search for or assimilation of data

sources was possible.) The run does, however, illustrate the capability

of the DELCAP model to portray peaking of landings and takeoffs and the

resultant delays.

It should be remembered when examining these program outputs

that the delay recorded here includes only that encountered in. the teiminal

area of this particular airport, between handoff to tower approach control

- 36 -
and landing , or between desired departure time and handoff to center

control for a takeoff. "Delay" refers only to the extra time above

the minimum required if no other traffic interfered. Airlines expect

delays at certain airports, and adjust their scheduled arrival times

to reflect this. The model does not include the expected time of

arrival for any flight. Rather it computes the minimum time for the

flight to fly from handoff and land, or to taxi to the runway and take

off. Delay is then calculated as the difference between actual time

and the time in this ideal scenario.

This concludes our sketch of model output format. The next section

will describe the preprocessor. EUring the actual running of the model,

the preprocessor precedes the simulation portion of DELCAP. We have

here described the simulation first since its input-data requirements

are what the preprocessor is designed to satisfy.

- 37 -
2.3 Specific Descyiptipn of Preprocessor

Since the DELCAP model was designed primarily for use by planners

and analysts, ease of input was a major consideration in its formulation.

The SUBSCRIPT computer simulation language, chosen because it greatly

facilitates simulation-model programming, unfortunately requires input

in a rigid and awkward format. Therefore a preprocessor program was

written to aid the user in inputting data to the simulation.

It is hoped that DELCAP will ultimately operate in a time -sharing

computer environment in which an analyst would need only to (1) call

up the separation rules, and the configuration and traffic levels, for

the terminal area of interest in the year under investigation, (2) make

any desired alterations to these called-up "standard" data, and (3)

receive his delay and throughput measures, all in a relatively

short time. The user should have to learn only a bare minimum about

working with the computer (perhaps only how to arrange accounting

procedures and associated job numbers and how to call up the DELCAP

program). The DELCAP model would have, on file, airport configurations

and traffic levels (present and projected) for most of the terminals

in the country for the current and desired projection years. The model

would, if the user requested, print out the information contained in

any of its files. The user could modify (temporarily) any or all of

the contents of any file for any particular run. Those items he did

not wish to modify would automatically be retrieved from the proper file

stored in the computer, and used without change in his run. This

- 38 -
philosophy of input by exception to entries in a standard file, we

believe to be an ijnportant feature which would make a model such as DELCAP much easier to use and therefore much more apt to be used.—

The present form of the DELCAP model has not yet achieved this

level of development. The current effort was aimed primarily at formulating

and implementing the simulation model logic. To indicate how the proposed

final form of DELCAP would operate, and also to aid in data input to

the current stage of development, a FORTRAN preprocessing program was

written. The DELCAP modeling system thus presently consists of two

parts, the preprocessor and the simulation model, which are run

in succession. On the UNIVAC 1108 these two programs can be executed

one after another in a single run. For computer systems which do not

allow multiple executes, two runs would be necessary. The preprocessing

program accepts card and/or tape input as desired, and produces both

a printed run description and a tape containing a SUBSCRIPT initialization

deckZ/, which in turn provides input to the simulation model. The

simulation is then run to produce the delay and throughput statistics

for that particular set of inputs.

The present file of airport descriptions contains "data" for only

two airports f JFK and ATL. Even these are only approximate. The runway

configurations were obtained from [20] which does not include the distances

(outer marker to end of runway, and end of runway to intersection)

needed by DELCAP. The operational procedures (landings only", takeoffs

^Tkis was suggested to us by the FAA, and after considering it

carefully, we enthusiastically concur. —-^For a further description of the SIMSCRIPT initialization deck

see SIMSCRIPT, A Simulation Programming Language , by Markowitz,

Hausner and Karr. A sample decx for the DELCAP simulation appears

in Appendix A. 2.

- 39 -
only, dual-use alternate operations or dual-use landings take precedence),

and the distribution of runway use, could only partially be inferred

from this text. No information was given on how landings and takeoffs

were distributed over the hours of the day. Therefore much of the ’’data”

for these two airports have been invented either wholly or in part. The

distribution of landings and takeoffs over the day for both ATL and

JFK was taken from another source [22 ] and applies to a different

airport entirely. The computer runs described later and the existing

data file, therefore, remain only illustrative of model capability.

They do provide, however, a demonstration of how the model would

operate as an aid in planning and analysis

As mentioned earlier in section 2.1, the preprocessor divides

model input into six data groups. The user may specify any or all of

these groups. The particular division employed is somewhat arbitrary

and may be altered if experience running the program suggests a better

arrangement. The. number of data groups could also be changed, but

there is a tradeoff between the flexibility of a larger number of

data groups and the minimum amount a user must specify. The six groups

are:

1. description of aircraft types,

2. mix of aircraft types,

3. landing and takeoff rates by hour of day,

4. separation rules,

5. airport configuration and

6. fraction of each type of aircraft using each runway and departure

path.

- 40 -
Input for data groups 1 and 4 does not depend on the airport, and

so there is only one set of standard values for these groups. The

’’standard” separation rules are taken as:

a. 3 mile interlanding separation,

b. 2 miles separating a landing from a preceding takeoff for

aircraft with Distance Measuring Hquipment,

c. 4 mile departure/arrival fix for aircraft without DME,

d. 1 minute separation between diverging aircraft, 3 minutes

between aircraft using the same departure path.

The standard type classification is that given in the Airport Capacity

Handbook, pages 2.10 through 2.13. Figure 2.3.1 records the standard values

of variables for each aircraft type.

The remaining four data groups depend on the airport involved. The

user may, if he so desires, choose different groups from the file entries

for different airports. (The identifier appearing on the preprocessor

output will be the one associated with airport configuration-.) Care

should be taken when mixing inputs from different airports that they all

have the same number of runways and departure fixes. In describing

the airport configuration the user must include for each runway a name

consisting of a two- character heading (00 is north, 13 is 130° from

north or roughly southwest, etc.), and where desired a one- or twocharacter modifier (e.g., 13L and 13R for parallels, 13FL for a

third parallel to the left of 13L) . These are used only for identifying

runways in the preprocessor output and are not needed by the simulation.

- 41 -
SPEEDS (KNOTS)

TYPE

A

B

C

D

E

LANDING

145

140

130

115

98

LIFTOFF

155

148

140

123

110

RUNWAY OCCUPANCY

(SECONDS)

LANDING i TAKEOFF

50

44

39

33

29

33

30

28

23

21

HAS

DME?

YES

YES

YES

NO

NO

Figure 2.3.1: Standard Characteristics of Aircraft Types

- 42 -
In describing the runway configuration the user must specify two

kinds of data: (1) for each pair of intersecting runways, the distance

from the end of each of the runways to the intersection with the other,

and (2) for each pair of runways, the type of interference between them.

There are two types of interference. In the first type the two run- ways are completely dependent, i.e. landings and takeoffs on one runway

must be separated by the same distances from those on the other as from

those on the same runway. The second type of interference requires

successive landings on each one of the pair of runways to be separated

by the same distance as landings on a single runway, but landings on

one runway do not affect takeoffs on the other, and simultaneous takeoffs

are allowed from the two runways if the takeoffs diverge. If the user

does not specify one of these types of interference, the model assumes

that operations on the two runways do not affect one another.

Figure 2.3.2 and 2.3.3 present sample output from the preprocessor.

They describe the input for the simulation run whose output was given in

Figure 2.2.1. Figure 2.3.2 gives (a) the hours for which the simulation

was run (in this case, the 24 hours from 8 a.m. one day to 8 a.m. the

next), (b) the characteristics of each aircraft type, and (c) the mix

of aircraft types. Figure 2.3.3 gives a verbal description of the airport

(in this case our hypothetical ATL) . The airport description includes

the operational procedure for each runway and the interference patterns

among the runways. Future DELCAP refinement might include graphical

- 43 -
(schematic, map-like) output of the airport runway configuration.

Note, however, that the information now required of the user is not

always sufficient to locate all runways in relation to each other.

If two runways are independent, the only information available is

the heading specification. Since the user is not repaired to specify

the runway endpoint and length, there is no information available

in the current data set indicating that the two parallels 91. and

9R for ATL are offset parallels. Tn order to have graphical output,

then the user would have to enter extra information about the airnort

(e.g. , describing the runway endpoint in some x-y grid) which is not

needed by the simulation program and whose provision would reouire

extra work. This runs counter to the motivation for the preprocessor

namely to allow the user to provide input in an easily prepared form

requiring a minimum of data collection and preparation. It was

therefore decided that the present verbal airport description is adequate

for the current effort and may even be preferable to a pictorial description.

x Iany variations in the preprocessor output are possible. Q ince

the DELCAP model has not yet been applied to a real-world problem,

it is impossible at this stage to anticipate which of the possible

outputs would be most useful and in what form they should appear. The

output of the preprocessor is designed primarily to label a run, describing

those elements which differentiate that run from others. Therefore,

which of the inputs should be printed out, and how best to display them

- 44 -
to make the differences between two runs most obvious, depends on the

particular application. The present form, to be regarded primarily

as an example, has proved useful for the debugging and testing runs

of the current effort.

- 45 -
AIrPOrT

ConF

IoUkA I

ION

fun

atl

AlRPOKT

Id • UJ • X X X X

inm

x

x Z X o o x >• x >- X < x < B B x Z x Z

Id 3 Id 3 d X d X 1 X X

7) X X in z • o • O d o o x UJ H 3 3 O' a d X d z O' z d < CM uJ m id < X X d Id Id < X *- X - I X o T ^ Z x

*—

X 3 o z o s 2 X 3 X 0 d H X X 3 < X * X Z 3 < UJ aJ X — X X X X X < d < Id UJ H d d d 3 3 x *— — X. — X 1 -• J j d d d -* X z tm* < Id • UJ • 2E O 3 3 J) r* J) 3 d X % x r- X CM ir» x

J) J) d d X d in a. 3 J) X X x V0 d d X 3 z z X X 3 X H * < d 3 d 3 3 fO X < Z z J) < < 3 * < X d

II X J 3 n n O' < -4 X >

J\ 1 1 1 d X X X 3 * 3 O' 3 X < —» T Z Z X * 5 « « •* z -1 x x 3 O' O' < < X -4 d B X B d 3 W w o> z O' Z O' 3 X 3 3 d o CM K) X X Z

vO J> i/) < X X >» X X x x X X

Id < < < < 3 < 3 * d

CO B B B B B 3

3E z T z 7 ^ Z S 3 5 3 5 z 5 z 3 Z tr x tr X d XLd X 0)

Figure

2.3.3:

Sample

Preprocessor

Output

Airport

Configuration
I

T

Hr.

aPEtOb

IKislOrS)

Rt)N*AY

OCxUPAnCY

(SECONDS)

LM^ulNb

LlFTuFF

LAN|>IimG

TAKFOFF fO o co *o *h

fO m (\. cv rg

• • • • • C cf CT ro O' S 3 *0 -O Ai

IT

/)

r>

AJ -O -D

-* m t * n

1

Jz

71

Flynir-'

i.

3.2

Sunn'll

o

IY

‘i>»

mcssor

Sitput

Aircraft

and

Traffic
This concludes our functional description of the preprocessor

and simulation. The next chapter will provide a more technically oriented

description, tied more closely to the implementation of the model as a computer program. The reader less concerned with such matters may

wish to skip to Chapter 4, which describes the outputs from illustrative

runs of the model.

- 48 -
3. DESCRIPTION OF COMPUTER IMPLEMENTATION

3.1 General Remarks

The previous chapter described the model from the viewpoint of a

reader familiar with terminal-area operations, but not necessarily with

computer modeling. In this chapter, we present the model from the latter

point of view.

Since the computer simulation model was written in SIMSCRIPT, we

will often find it convenient to describe the model using the terminology

of that language. The reader may thus desire to refer to SIMSCRIPT ,A Simulation Programming Language , by Markowitz, Hausner, and Karr for a more

complete account of these terms. A partial glossary of terms which will

be used frequently follows:

event - The simulation program consists of a series

of subprograms (called event routines)

describing the change in the status of the systent

at each critical event. There are two types of

events: exogenous events , which happen at specific

times input to the simulation, and endogenous events , which occur as a consequence of sane preceding

event in the simulation.

~ System here refers to that which is being modeled, the terminal area.

- 49 -
function - In addition to event subprograms SIMSCRIPT

entities -

attribute

set -

includes "function" routines which are

similar to FORTRAN FUNCTION -programs in that

they calculate a value of a function for

a given set of values of certain parameters.

Entities are the objects which the simulation

models. There are two types: temporary

entities, which during the course of a siitiu-

\ lation come into the system and later leave

(e.g., flights), ahd permanent entities

whose number remains- fixed during any simulation run (e.g., runways and aircraft

tynes)

- Attributes are properties associated with

temporary entities and events. They provide

additional information about the specific

event or entity, such as the type of a given

flight or the identity of the runway upon

which a given landing is to occur.

Sets are lists of particular entities. When

an entity is added to the list it is said

t° be filed in the set. Sets may be ordered

in any of several ways. A FIFO set is ordered

in a first -in- first -out manner (e.g., the landing

- 50 -
and takeoff queues) . The opposite is a LIFO set,

last- in first-out. Finally, sets may be

ranked on some attribute. An example of

of this in the simulation is the set of

tieups associated with any of a runway’s

three interference points. These sets

are ranked on the time at which the tieup

is no longer in force.

schedule - When using the SIMSCRIPT language, the

programmer need only write code for each of

the critical events. Endogenous events

(which occur as the result of other events)

must be scheduled within the caus ing-cvcnt

routine. These scheduled events are then put

in a list of future events; after finishing

each event, the SIMSCRIPT system checks to

find the next event in this list.

create and destroy - When temporary entities enter

the system they are said to be created, and

when they leave they are said to be destroyed.

In the computer, when an entity is created

storage is reserved for it, and when it is

destroyed this storage is returned to the

SIMSCRIPT program and can be reassigned.

- 51 -
The DELCAP model is currently operable under the EXEC II

operating system on the UNIVAC 1108 at the National Bureau of Standards.

The preprocessor is written in FORTRAN V (UNIVAC's augmented FORTRAN IV),

and the simulation in SIMSCRIPT ] .5. A minimum of difficulty is

anticipated in converting the program to other computers, since

care has been taken to design the program to be compatible with other

computer systems. However, to aid in the conversion process we have

included in Appendix E a list of possible areas of computer incompatibility which have arisen in other efforts in which members of this

project staff have participated. SIMSCRIPT 1.5 is available on a wide

range of computers, and most of the compilers were written by a single

company, increasing the likelihood of easy transference.

The present preprocessor consists of about 500 FORTRAN statements,

including comment cards as necessary. A listing of the program appears

in Appendix C. The example preprocessor run described in the previous

chapter took about 3 seconds to execute. This running time will be

increased, however, when the file of standard airport data becomes

large, since much of the execution time would then be spent in searching

for the correct airport information. The preprocessor uses about

6600 words of core storage • The current limits on the number of

runways, aircraft types and departure paths depend more on some of

the formats in the preprocessor than on actual core limits. These

limits are: 9 runways, 10 types, and 5 departure paths. The maximum

total number of interferences allowed is 10. These values are parametrized

in the preprocessor, and may be changed along with necessary formats

if these limits need to be increased. It should be noted here that

- 52 -
the term "runway" refers to a runway operating in a particular direction.

(13 and 31 are two separate runways.) Since the runways are fixed

for a particular run, and runways are not usually operated in both

directions at once, this does not present too great a problem.

However, the:re could be a problem in the future when the tape of

standard airport data is created, since there would then be

several different runway configurations for each airport which must

be distinguished, (e.g., for Washington National, DCA north operations

vs. DCA south operations).

The simulation model consists of about 1300 SIMSCRIPT statements

including comment cards. A listing appears in Appendix D. The

example runs took about 9 to 10 seconds to simulate 25 hours. (The

simulation was run for 1 hour to preload the system and then for

24 hours to accumulate output statistics.) This time is exclusive

of compilation, which takes about 1.5 minutes. Of course, once the

DELCAP model system is in the production phase, compilation would

no longer be necessary.

On the 1108, SIMSCRIPT compilation is a two- stage process. First

the SIMSCRIPT object code is compiled into SLEUTH, the 1108 assembly

language; then the SLEUTH is assembled. Storage has never become a problem with the simulation program. Even with 20 runways, 200 types

of aircraft and 40 departure paths, the data storage requirements are

less than 20,000 words. For an airport with 20 runways there could be

a maximum of about 5,000 additional storage locations used to store

information concerning temporary entities and events. These estimates

- 53-
are all very conservative. (No existing airport has 20 runways,

for instance.) Thus it is not anticipated that computer storage

requirements will limit the applicability of the present version of

the DELCAP model.

The minimum number of data cards required for a run of DELCAP

is three, two for the preprocessor and one for the simulation.

The user must supply at least the first and last hour for the

simulation, and also the preprocessor parameter card indicating which of

the data groups should be standard data and for which airports. The

simulation requires a SIMSCRIPT system specification cardi/which will

be described in greater detail in Section 3 of this chapter.

This concludes our general remarks on the computer implementation

of the DELCAP model. The following two sections will describe the

preprocessor and simulation programs respectively.

'bee pages 101 and 102 of SIMSCRIPT, A Simulation Programming

Language for a further description of this card.

- 54-
3.2 The Preprocessing Program

The preprocessor was designed to aid the user in providing input

to the DELCAP model. It has two major functions. First, it accepts user -

supplied input in a relatively easily -prepared format, and outputs these

data in the more cumbersome foimat required by the simulation. Second,

it provides ’’standard” values for those input items which the user does

not wish to specify . In addition, it checks the input for consistency

and prints warning messages as necessary. Figure 3.2.1 is a flowchart

of the preprocessor program. Although the middle section appears as a

loop, the six data groups differ enough in structure as to require

six separate portions in the program. As is seen from the figure,

the program can be broken into four sections:

1. Read the hours to be simulated and the options card.

2. Compile the data for the six data groups, from usersupplied input or standard files as directed.

3. Write a tape providing simulation input.

4. Print the run identifications.

The program always requires at least two input cards. The first

of these specifies the beginning and ending times for the simulation.

Time is expressed in military time, e.g., 0.00 stands for midnight,

8.30 for 8:30 a.m. and 17.20 for 5:20 p.m. The program will not at

present accept a run of over 24 hours. (Note; a ”24 hour run” is one

which simulates 25 hours but records delay only for the final 24.) A

run from 8.00 to 8.00 is interpreted as a 24 hour run from 8 a.m. one

- 55 -
READ

BEGINNING

AND END

HOURS

READ

OPTIONS

CARD

FOR EACH DATA GROUP

X

)UPJ

^STANDARD

-INPUT ~

NO

YES OUP

1 .or 4

NO

YES

\ READ

/

USER-SUPPLIED

\ INPUT / mM CARDS /

READ

STANDARD

-TAPE'

* f

1 USE

1

i 4

1

STANDARD

INPUT VALUES

,

4- I

\

NO

WRITE /

SUBSCRIPT

/

\ INITIALIZ.

/

\—

/

PRINT

RUN

I DENTI FI CATION

OUTPUT

Figure 3.2.1: Preprocessor Flowchart

- 56 -
day to 8 a.m. the next. Thus the input to the simulation reads from

hour 8 to hour 32 in this case. The simulation is always run for at

least one full hour (and up to two) , to preload the system before beginning

to record delay and throughput. If the simulation is to start on the hour,

it will be started exactly one hour early. If the simulation is to start

at 5:45, it will be run for an initial hour and 45 minutes. The maximum

preload time, then, is one hour and 59 minutes. The simulation always

begins its preloading at the hour, but it will end at whatever minute the

user has specified.

The second data card required by all runs of the preprocessor

specifies which of the six data groups will use standard input. Even

if the user wants to specify values for all six groups, this data card

(in this case, blank) must appear in the deck. ' For data groups 1 and 4

which are not airport -specific, any non-blank character will indicate

standard input. For the remaining data groups, the user who desires to

use standard input must specify the airport in the airport file for

which he wishes to extract the data. Airports are referred to by their

3- character code names (JFK for New York’s John F. Kennedy International

Airport, for instance) . If the particular airport desired is not in the

file, the preprocessor will print a warning message and discontinue

processing. The user may request data for different data groups to be

drawn from different airports. However, he should ensure that the

different airports have compatible sets of data: the numbers of runways

and departure fixes must be the same. Also, if the user provides a

- 57-
non-standard aircraft type description, he should realize that standard

airport data which depend on aircraft type (such as the time to fly

from handoff to the outer marker) have values referring to the standard

5 types of aircraft. The general point to be borne in mind is that the

six data groups are not fully independent, so that care must be taken to

avoid inconsistencies between groups.

The next subsections of this section will describe in greater detail

the data contained in each of the six data groups. The formats for the

input, and sample input decks, are given in Appendix A. The listing of

the preprocessor code appears in Appendix C.

3.2.1 Data Group 1 - Aircraft Type Description

This data group provides the values of variables which characterize

the aircraft types involved in a particular Simulation. The standard

input values were given in the previous chapter (figure 2.3.1). The 5

standard types of aircraft are described in detail in the Airport Capacity

Handbook (pp. 2.10 to 2.13), and depend mainly upon weight and means of

propulsion. These types may be categorized roughly as follows:

(1) type A - large jets

(2) type B - medium jets and large propeller

(3) type C - small jets and medium propeller

(4) type D - light twin engine

(5) type E - single engine

If the user elects to provide his own aircraft type data, he must

stipulate landing and liftoff speeds (in knots) , runway occupancy times

- 58 -
on landing and also on takeoff (in seconds) , and possession or

non-possession of DME for each type of aircraft. The number

of types is flexible, but the current preprocessor program

limit is 10. This limit is parametrized and may easily be increased

with a single program change. Note that data groups 2, 5, and 6 all refer

to information which pertains to aircraft type. The number of types of

aircraft and the basic type information are provided by data group 1,

with which the information contained in the other groups must conform.

This is the responsibility of the user; the present program does not

perform such consistency checks.

The unit of time used in the simulation is the hour. Therefore the

runway occupancy times (given in seconds) are immediately changed

to hours by dividing by 3600.

An additional variable must also be provided by the user electing to

use non-standard aircraft-type input: the speed (in knots) at which a

landing turns off the runway. This is used in the simulation when

calculating the time at which an aircraft reaches an intersection of

runways. From touchdown until turnoff, an aircraft is assumed to be

constantly decelerating from landing speed to turnoff speed. The

calculation of the time to reach any point down the runway , under this

assumption, is given in Appendix G.

- 59 -
3.2.2 Data Group 2 - Mix of Aircraft Types

The second data group which the user may specify, if he so desires,

is the mix of aircraft types. For each type of aircraft, he must give

the fraction of the landings which are of that type and also the fraction

of takeoffs. The fractions for landings must add to one, and similarly for

takeoffs. If one or both does not, an error message will be printed, but

processing will continue . Since the simulation model will need the cumulative distributions, the fractions are immediately converted to those

distrubutions in the preprocessing program. If the user elects to accept

standard data, he must specify the airport whose mix he wishes to use.

The standard mixes all refer to the standard five types.

3.2.3 Data Group 3 - Landing and Takeoff Rates, by Hour of Day

This data group provides the distribution over time of aircraft

entering the system. There are two distributions, one for landings and one

for takeoffs, since the time-of-day patterns may be different for the two.

The user who wishes to provide non-standard data must input the desired number of landings and a number of takeoffs for each simulated hour, up to a

maximum of 24 hours. The preprocessor is presently set up to handle

up to a day’s worth of data. The simulation can be run for more than

24 hours, but the landing and takeoff rates will then repeat in a 24

hour cycle. If the simulation is to be run for less than 24 hours, the

user must remember that the system is preloaded for between one and two

hours before it actually starts recording delay and throughput (recall

section 3.2.1). The user must provide landing and takeoff rates for the

preload time period as well as the period for which delay and throughput

are to be recorded. The simulation needs the average time between

- 60 -
landings or takeoffs rather than the number of them per hour and so

the preprocessor estimates the mean time between landings or takeoffs as

the reciprocal of the number per hour. If there are no landings Cor

no takeoffs) in an hour, the time between landings is set at 9.999 hours,

so there is a finite but very small probability of generating a landing.

The user must specify the airport from which the landing and takeoff rates

are to come. The input data tape will be searched for this infoimation

if this airport is not the same as the one specified for data group 2, or

if data group 2 was user-specified.

3.2.4 Data Group 4 - Separation Requirements

This data group provides numerical values for the separation rules

which are to apply to a simulation run. There are three types of separation

rules: (1) interlanding, (2) landing following takeoff, and (3) intertakeoff. The fourth possibility, a takeoff following a landing, is

governed by the ”no two aircraft on the same runway at the same time"

rule. The takeoff may taxi onto the runway and start its roll as soon

as (but not before) the preceding landing has turned off the runway. The

presently required interlanding separation is 3 miles.,/ In general, all

landings must maintain this separation, unless the two aircraft are to land

on parallel runways separated by at least 5,000 feet.

The rules defining the separation between departing aircraft are

much more complicated, and depend on the paths the departure will take.

These rules for IFR aircraft are given on pages 96 and 97 of Teimnal Air

Traffic Control .

-^lll separation rules are expressed in nautical miles

.

- 61-
The rules are approximated within the simulation by the following

scheme: Each takeoff is assigned a departure path when it is generated.

The simulation uses two arrays which determine the required separation

between aircraft, one for departures on the same runway and one for those

on different runways. These arrays contain for each pair of departure

paths, a time separation between start of roll for aircraft outbound

on those two paths. Our present procedure (just described) is only an

approximation to the rules cited above in that (a) the separation is

not made to depend on aircraft type, and (b) the separation requirement

is not extended into the airspace beyond the airport. [In addition, one

of the present separation rules is in terms of distance rather than time.

The user may approximate this by calculating a weighted (by the mix

of aircraft type) average of the time for an aircraft to fly the required

separation distance (3 miles).]

The standard values for these arrays are: 1 minute for aircraft

flying different paths and 3 minutes for those flying the same path, for

takeoffs from the same runway; and 2 minutes for aircraft taking off from

different runways but then following the same departure path. No

separation rule is imposed on aircraft departing on different runways

for different departure paths. (The representation scheme for aiiport

configurations to be described in section 3.2.5 below will include a

method of indicating to which pairs of runways the inter- takeoff

separation must apply.)

- 62 -
The final type of separation is that required between a takeoff and

a following landing. The separation depends on whether or not the landing possesses EME. If a landing does possess DME then it must remain a required separation distance (presently 2 miles) behind the takeoff. If

the aircraft does not have DME, however, it must not pass a certain

fix (called the departure/ arrival fix) before the takeoff starts its roll.

In our program, the standard value for the departure/arrival fix is 4

miles from the end of the runway.

3.2.5 Data Group 5 - Airport Description

This data group describes the airport’s runway configuration and

operating policies. The user who wishes to use non-standard data must

specify for each runway a two -character heading (00 is north, 13 is

130° from north or roughly southwest, etc.), and a two-character

modification if desired. The latter can be used to designate the

left (L) and right (R) members of a pair of parallel runways. The

four characters (heading and modification) are needed only by the

preprocessor, and are used to label the runways on the preprocessor

output

.

The user must also provide both the distance (in nautical miles)

from the runway threshold to the outer marker and the operation code

for each runway. The code specifies which of four different operating

policies governs the runway: (1) takeoffs only, (2) landings only,

(3) dual use, alternate operations, and (4) dual use, landings take

precedence. The user may pick any one of these policies for any

runway, but he should make sure that the policy agrees with the distribution of runway use in data group 6.

- 63 -
For each aircraft type, the user must provide the minimum time (in

minutes) to fly from handoff to the outer marker. (The preprocessor

immediately converts the time units to hours, the time unit needed

by the simulation.)

In describing the runway configuration, the user must provide

for each pair of intersecting runways the distance (in feet) from

the end of the first runway to the far side of its intersection with

the second, and the distance from the end of the second to the far

side of its intersection with the first. These distances are immediately

changed to their equivalents in nautical miles.

The model does not need to have the actual layout of the airport,

but it does need to know how the runways can interfere with one another.

The user may specify "interference code 1" which means that landings on

the two runways must be separated by the same distance as are landings

on one runway, but that takeoffs are independent of landings and of other

takeoffs. If the user specifies code 2, then landings on the two

runways must be separated by the same distance as landings on one runway,

a landing on one must be separated from a previous departure on either

runway, and takeoffs on the two runways must be separated by the special

separations required of takeoffs on dependent runways. If the user does

not specify a code for any pair of runways, it is assumed that operations

on the one do not affect operations on the other. The preprocessing program

- 64 -
uses this information to create the arrays which are used by the

simulation to tie up appropriate points for the appropriate lengths of time.

3.2.6 Data Group 6 - Runway Use and Departure Fix Distributions

The user who wishes to provide his own input for this data group must

supply, for each type of aircraft, the fraction which uses each runway for

takeoffs and the fraction which uses each runway for landing. He must also

specify for each runway, the fraction of takeoffs using each departure

path. The program checks that the fractions sum to one, and prints an

error message if not. In addition, it checks that a runway which is to

be operated "takeoffs -only" does not have any landings using it, and

that a runway being operated as "landings -only" does not have any takeoffs

using it. Here too inconsistencies lead to the printing of error messages.

Processing continues in spite of error messages.

The preprocessor next computes some other arrays used in the simulation

model. The "latest operation on each runway" is initialized as a landing,

unless the runway handles takeoffs only. The minimum time a takeoff

must remain in its queue is computed as a weighted average (weighted

by aircraft type) of the times to fly from handoff to the outer marker

The minimum time between when a takeoff may be scheduled and when it

actually starts its roll is computed as a weighted average (weighted by

aircraft types) of the time for a landing to fly down the final

approach path from outer marker to runway threshold. These two times

can be interpreted respectively as (a) the minimum time between filing a

- 65 -
flight plan and leaving the gate, and (b) the minimum taxiing time from

the gate to the end of the runway. However, as can be seen from the way

they are computed, their primary purpose in the model is to ensure that

takeoffs are scheduled about the same time ahead of start of roll as

landings are ahead of touchdown. A further discussion of these arrays

is given in the next section.

3.2.7 Simulation Input

The main function of the preprocessor program is to provide an input

deck for the simulation model. Every SIMSCRIPT program requires an

"initialization deck" which gives the number of each of the permanent

entities and initial values for the system variables and arrays for the

current run. The DELCAP model has five permanent entities; two of these

the number of types of operations (2) and the number of hours in a day (24)-

remain constant for all runs , while the other three - the number of runways, the number of types of aircraft, and the number of departure paths -

can vary from run to run. The values of the preprocessor input groups,

whether standard or user-specified, are written out in the format re4 / quired by SIMSCRIPT.— The arrays which store the simulation output delays

and throughputs are initialized at zero. The preprocessor also provides

one "exogenous event" card image on the simulation input tape. This card

schedules the BEGIN event which starts the simulation. If the user is

providing deteministic flight input, then he must also provide this card

image as the first exogenous event.

4/

-See pages 115 to 128 of SIMSCRIPT,A Simulation Programming Language

and Appendix D.

- 66 -
3.2.8 Preprocessor Output

The preprocessor prints out information to label a particular run.

The current print -out is not complete, but has provided adequate

labeling for the debugging runs of the current effort. Future running

of the model in an airport -planning environment should yield a better

idea of which data items would constitute the best labeling.

Sample preprocessor output appears in Figures 2.3.2 and 2.3.3, to

which we now refer again. The first line of output gives the hours

the simulation will be run. (Any error warning messages appear

immediately following this line.) Next, the landing and liftoff speeds

and runway occupancy times are given for each aircraft type. The

mix of aircraft types for landing and for takeoff are listed next.

At the end, the preprocessor prints a verbal description of the airport

configuration, including the appropriate three -character airport

identifier. Each runway is listed by number and by name (e.g., 9L)

,

and the type of operation (takeoffs only, landings only, dual use with

alternating operations, and dual use with landings taking precedence)

is printed. Next, intersections are listed. Finally, interferences

are listed. Two runways with the same heading are identified as ”parallel". Parallels may be independent, semi -dependent (landings on

one interfere with landings but not takeoffs on the other) , or

dependent (landings and takeoffs on one must be separated from landings

and takeoffs on the other) . Only semi -dependent and dependent nonparallel runways are listed.

- 67 -
This concludes our description of the preprocessor program. We

wish to reemphasize that the particular current forms of the input

to this program, and of the printed outputs, were dictated

largely by our needs during program debugging. Because the program

has not yet been used in any real planning situations, some of its

features may prove awkward for users less familiar with the computer.

We have conscientiously tried to foresee such difficulties and to

eliminate them in advance, but as yet the program is still in the prototype

stage. Only its exercise in more of a "production" environment can

be relied on to reveal fully such production -use difficulties as may

remain, and only after these problems are revealed can they be

remedied.

- 68 -
3.3 The Simulation Program

The simulation program is written in the SIMSCRIPT 1.5 pro^

gramming language, which is designed primarily to aid in programming

critical- erent simulations. The user only needs to write code for

each of the types of events, describing how each alters the status

of the system being modeled and how other events depend on this one.

The SIMSCRIPT compiler contains several programs which execute the

user-designed evait routines in chronological order. Storage for

temporary entities, and for events which have been scheduled but

not yet executed, is dynamically allocated by other SIMSCRIPT

routines. The size of arrays and their allocation of storage are

computed at execution time, when sets of initial values are read for

them. The simulation is started off by an exogenous event, in our

simulation the BEGIN event which schedules the routine to generate

the first landing flight and first takeoff flight.

Figure 3.3.1 gives a general ’’flowchart” of the DELCAP simulation model routines. Hie word ’’flowchart” is somewhat of a misnomer

in the context of a SIMSCRIPT model. The diagram indicates which

event routines occur as a result of which other routines , but it

does not give the order in which they are actually executed, since

this is chronological. (Recall the discussion in section 2.1.) The

earlier Figure 2.1.1 gave a flowchart of the DELCAP critical events

for a single aircraft. Figure 3.3.1 describes the computer implementation

- 69 -
y

Figure 3.3.1: Flowchart of the DELCAP Simulation Routines

- 70 -
of this process.

Events GEN and EXGEN create flights , which are the units which

move through the various events in the model. EXGEN is an exogenous

event which occurs at times designated for the arrival into the system

of specific flights. GEN creates flights in a stochastic manner.

Stochastically generated flights are assigned a type, a runway, and

a departure path by the three functions PTYPE, PRWAY, and PDFIX.

Flights are constantly entering the system while other events are

happening. GEN schedules the next occurrence of itself according

to the Poisson process, while the next specific flight (if any are

left) for EXGEN is always available. The event NXTOP finds the next

operation (landing or takeoff) which is to occur on a particular runway. It is scheduled in one of two ways: (1) if the queue is empty

when the current flight is filed in it, or (2) when the current flight

has either begun to fly the final approach path to land or has left

its gate to take off. Condition (1) is detected in GEN or EXGEN,

and condition (2) in LAND or TOFF. NXTOP then schedules the next

LAND or TOFF at the time the runway and/or final -approach path is

free, as determined by the function FREER. Since there is a time gap

between NXTOP and TOFF or LAND during which landings or takeoffs

on other runways may have created new tieups for "this" runway, LAND

and TOFF again determine the first time the runway is free (from

FREER) . Then the flight may land or depart, which in the DELCAP model

implies tieing up the appropriate points for a period of time sufficient

to maintain the required separations. LAND or TOFF then reschedules

NXTOP, and the cycle continues. When a tieup is no longer in force,

the routine FTIEUP destroys it.

- 71-
Four routines do not appear in this list, since they are mainly

for accounting purposes. The BEGIN event (see Figure 3.3.2) starts

the simulation, and schedules the event ENDS which prints the simulation output and stops execution. The routine (HOUR (see Figure

3.3.3) updates the current hour for output of delay and throughput,

and reschedules GEN for the Poisson parameter for the new hour.

The routine PRINT records the delay and throughput information at

touchdown for landings, and at start-of-roll for takeoffs. The

sections which follow describe each of the event routines shown in

Figure 3.3.1.

3.3.1 Event EXGEN. This event creates exogenously -determined

flights provided by the user. This, or the stochastic generation

processes or both, may be used for a particular run. When inputting

the information for the routine EXGEN, the user must supply for each

flight: the hour, minute, and second of entrance into the system,

whether this flight is a takeoff or a landing, the runway, the aircraft type, and (for a takeoff) the departure path, all

in the format described in Appendix A. The SIM3CRIPT programs read

these flights one at a time at the proper simulated time. Therefore,

there is no limit on the total number of flights as long as the

number simultaneously active (including both those generated by

EXGEN and those produced by GEN) is sufficiently small to fit in core.

(For a simulation run with 20 runways, 100 aircraft types, and 10

departure paths, there could be about 6,000 flights active at any given time.

This, which is permitted in the present model, is far beyond the capacity

- 72 -
Figure 3,3.2 Flowchart of Event BEGIN

- 73 -
Figure 3.3.3: Flowchart of Event CHOTJR
of any existing airport to handle.)

Figure 3.3.4 provides a flowchart for the EXGEN event routine. For a

landing, the array TIN stores the time the current flight could (in- the absence

of other traffic) first cross the outer marker after flying from its handoff point. A takeoff’s flight plan becomes active about 13 to 15

minutes before its scheduled departure. In the model this time

period is divided into two segments, so that takeoffs are scheduled

about the same time before start of roll as landings are before

touchdown. The first of these time segments (about 10 minutes),

which may be thought of as representing the time between when the

flight plan becomes active and when the aircraft is cleared to

leave its gate, is added to the current time and stored in TIN.

(The second segment , about 5 minutes, may be thought of as representing a time interval between when the aircraft is ready to leave

its gate and when it could start its roll down the runway; it will

be described in greater detail in the section on the TOFF routine.)

After calculating the appropriate TIN, the EXGEN routine files

the newly generated flight into the appropriate queue. There are

two queues for each runway, one for landing aircraft, the other for

takeoffs. The queues are organized in a first-in-first-out manner.

This means there is no sequencing by aircraft type; when a slew

aircraft precedes a faster one, the latter is not permitted to overtake the former, even if it could reach the outer marker first

without thereby delaying the slower plane.

Each flight must remain in the queue until its TIN. Filing

75-
'
flights into the queue about 10 minutes before they could actually cross

the outer marker or leave a gate provides a means for identifying

the aircraft type of the flight that follows the current flight. This

allows calculation of the proper tieup time to ensure that two aircraft

remain separated by the required distance. This distance depends on the speeds

of both aircraft involved, and so cannot be calculated until the type

of the second plane has been determined.

If the queue was empty before the present flight was added to it,

the NXTOP routine is scheduled to occur at TIN , which is the first

instant when this flight could be removed from its queue. The NXTOP

routine, which schedules the next operation (landing or takeoff) for

a particular runway, thus occurs in one of two circumstances: either

(1) a landing or takeoff has just occurred, or (2) the runway has been

idle but there is now a new flight available for it. Case (1) will be

described later in conjunction with the NXTOP, LAND and TOFF routines.

In case (2), which is detected in the EXGEN routine, the appropriate

queue will have been empty before the flight was filed in it. Therefore the NXTOP routine is scheduled for when the flight is first

available to land or take of. However, an earlier NXTOP may have been

scheduled in LAND or TOFF, since the other queue may not be empty.

In this situation, NXTOP is scheduled, but when it occurs the next operation

will already be defined (NEXT + 0) and the NXTOP routine will be terminated.

This means that NXTOP may be scheduled more often thar necessary. The

- 77 -
programming alternative was the coding of a much more complicated set

of tests to ensure that NXTOP is scheduled only when necessary. This

did not seem warranted, in view of the lack of computer-storage probblems and the logical simplicity of the current test.

3.3.2 Event GEN. This event generates flights in a Poisson

manner. Landings and takeoffs are generated separately, from two

different sets of Poisson parameters. This routine is first scheduled

by the BEGIN routine. BEGIN schedules two GEN’s, one to create a

landing flight and one to create a takeoff. From then on, the GEN

routine schedules the next occurrence of itself. Therefore, within

GEN we wish to sample from the Poisson distribution to reschedule

GEN for the next entry (’’arrival”) of another aircraft into the simulated system.

The procedure used in the computer for sampling from a distribution is based on the fact that the range of any cumulative distribution is uniformly distributed over the interval [0,1]. In the

case here, we have assumed Poisson generation, so the probability

of an arrival in a time period of length dt is ydt (plus comparatively

infinitesimal terms) , where y is the expected number of arrivals per

unit of time. Then the probability q(T) that the next arrival will

occur in at most T units of time is

q(T) = prob (t < T) = 1 - e"^.

Since q is a cumulative distribution, its range is uniformly distributed over the interval [0,1], We therefore employ a standard computer

- 78 -
subroutine to choose a random number R from this uniform distribution,

and then find the T for which q(T) = R, namely

T

= -X In (1-R)

where X = 1/y. The next instance of GEN is scheduled to occur in T

time units. (Note that our time unit for the simulation is the hour,

so X is the reciprocal of the number of arrivals per hour.) Input

to the simulation contains two sets of values for X for each hour

of the day, one for landings and one for takeoffs. As noted

earlier, on the hour, each hour, the next GENs, one for a landing

and one for a takeoff, are rescheduled according to the X for the

appropriate hour.

In the event EXGEN, the type, runway, and departure path are

provided as part of the input. In the stochastic version GEN, however,

these three items are obtained by sampling from the appropriate

distributions. The simulation is provided (by the preprocessor) with

the cumulative distributions of (1) type of aircraft, one for landings

and one for departures, (2) runway use by each type of aircraft for

landings and also for departures, and (3) departure path for each

runway. The three functions PTYPE, PRWAY,and PDFIX perform the

sampling processes.

Figure 3.3.5 provides a flowchart of the GEN routine. After rescheduling the GEN routine for the next landing or next departure

(depending on the current operation), and sampling to obtain a type,

runway, and if necessary a departure path for the current flight.

- 79 -
SCHEDULE NEXT

GEN AT

TIME-X •ln(l-RANDM)

..it CREATE FLT

GET TYPE,

RUNWAY, AND

DEPARTURE PATH

FILE FLT IN

Q

Figure 3.3,5: Flowchart of the Event GEN

- 80 -
the remainder of the routine is the same as for the EXGEN routine.

The appropriate value of TIN is calculated, the flight is filed in

its proper queue, and if the queue was empty before this flight

was filed in it then the NXTOP routine is scheduled at TIN.

3.3.3 Event NXTOP. This routine finds the next operation, landing

or takeoff, which will occur on a runway. Figure 3.3.6 provides

a flow chart for this routine. There are four possible operational

procedures (stored in the variable OPER) available for any runway:

(1) takeoffs only, (2) landings only, (3) dual use, alternating

operations, and (4) dual use, landings take precedence. For OPER = 1

(takeoffs only) or OPER = 2 (landings only) , the sequencing of

operations is trivial; since only one type of operation is allowed on

that runway, NXTOP only needs to examine the appropriate queue. If

it is empty, no landing or takeoff is scheduled and NEXT is set

equal to zero. If the queue is non-empty, the appropriate operation

is scheduled.

If OPER = 3, then NXTOP tries to alternate operations. The

queue for the operation type opposite to the last operation is examined

first. Let t^ be the time the first flight in the queue for this operation could be scheduled. If TIN for this flight is less than tp then

this operation is the one scheduled. However if t-^ equals TIN, the

first flight in the queue for this operation may not be immediately

available. Maybe a flight in the other queue would be available earlier.

Therefore, the other queue is examined in a similar manner. Let t

2

'

be the time the first flight in it could be scheduled. If TIN for

that flight is less than t£, it is immediately available, and this

operation is scheduled. However if the first flight in neither queue

- 81-
Figure 3.3.6: Flowchart of the Event NXTOP
is immediately available, that operation for which the flight is

available first is scheduled. Therefore NXTOP will alternate

operations, except when the first flight in the queue for the alternate operation is not immediately available; in that case the operation

whose first flight is available soonest is scheduled. If no

flights are available, NEXT is set equal to zero and no operation

is scheduled.

For OPER = 4 the NXTOP routine will schedule a landing, if the

first flight in the landing queue is immediately available. If not,

the routine schedules that operation whose next flight is available

first. As can be seen in the flowchart Figure 3.3.6, the logic for

OPER = 4 is the same as for OPER = 3 except that the landing queue is

always examined first.

The NXTOP routine is scheduled in one of two instances: (1) the

LAND or TOFF routine has occurred, or (2) a queue was empty and a new flight has just been filed. In the second instance, NXTOP is

scheduled for the tiipe TIN at which the flight could first be scheduled.

However, since the other queue for the runway need not be empty or a LAND or TOFF routine could just have occurred, another NXTOP may already

be scheduled for this runway. To avoid error because of having several

NXTOPs scheduled at once, an array NEXT with an entry for each runway

has been introduced. Originally it is zeroed. When a next operation for

a runway has been found by NXTOP, NEXT is set equal to 1 (for a takeoff)

or 2 (for a landing) . Then NEXT is zeroed in the LAND or T OFF routine

.

- 83 -
Therefore NEXT is non- zero precisely when a LAND or TOFF is scheduled

but has not yet occurred. NXTOP proceeds to find a next operation for

a runway only if NEXT for that runway is zero. This condition is tested at

the beginning of NXTOP, and if NEXT is non- zero NXTOP is immediately

terminated.

3.3.4 Function FREER. This function finds the earliest time a

particular flight can land or take off without violating the

separation rules. FREER is first called in NXTOP, to find the time

at which the LAND or TOFF routine should be scheduled.

There may be a time gap between the time the NXTOP routine occurs

and the time LAND or TOFF occurs , during which other flights might

add new tieups which require postponement of the operation in question.

Therefore FREER is called again from LAND or TOFF, to determine when

the landing or takeoff may actually occur. Figure 3.3.7 contains a

flowchart of the function FREER. The left-hand side refers to landings,

the upper right-hand side to takeoffs, and the lower right-hand side

to both. T is the maximum of TIN and the current time, used to single

out for examination only those tieups affecting the current flight.

The array TR is created to contain the time (TMAX) each tieup affecting

the flight will no longer be in force, and J is a count of the number

of entries in TR.

For landings, both the set of tieups (OMTI) associated with the

outer marker and the set (THTI) associated with the

runway threshold are examined. The time of tieups in THTI is translated to the outer marker by subtracting off the amount of time it

takes the current flight to fly from the outer marker to the runway

- 84-
Figure 3.3.7: Flowchart of the Function FREER

- 85 -
threshold; this reflects the fact that the runway threshold need only

be free as the current flight gets there, not before. For takeoffs,

only the set of tieups (ERTI) associated with the end of the runway

are examined. The time of these is translated to the gate by subtracting off TDMIN, since takeoffs are scheduled before they leave

their gates to taxi to the runway.

If there are no tieups affecting the current flight (i.e. J = 0),

FREER is set equal to T. If only one tieup affects the current flight

(i.e., J = 1), then TR (1) will contain the time at which that tieup

will no longer impede the start of the landing or takeoff procedure,

and so FREER is set equal to it. If several tieups affect the current

flight, FREER is set equal to the maximum of the TR’s.

It should be clear from the previous description that this routine

does not attempt to fit a flight in between two others, even if the gap

between the two is wide enough. To do so would require a great deal more

coding. The crux of the difficulty is how wide a gap is ”wide enough”.

The tieups occurring as a result of the inserted flight must not affect

any previously scheduled flight. This means that all the tieups which

LAND or TOFF would create must be examined to see if they would interfere

with a landing or takeoff already scheduled or in progress. This is

similar to performing the whole of the LAND or TOFF routine, and involves

the additional burden of identifying the flight which is being interfered

with. (It is no longer just the first in a queue.) Therefore the simpler

procedure, of waiting until the last tieup is no longer in force , was

used in the DELCAP simulation. Future work should investigate the feasibility of elaborating this procedure.

- 86-
One further difficulty can arise when a slow landing follows

(i.e. lands later than) a fast takeoff. NXTOP is called as soon as

the takeoff leaves its gate. The landing therefore is not permitted

to cross the outer marker before then, since FREER is at least T

which in turn is at least the current time of NXTOP. However, if

the landing is slow enough it could in principle be scheduled earlier,

and the takeoff would still be able to precede it while maintaining the

required separation. Therefore, although the sequence of operations

on the runway must be a takeoff followed by a landing, the sequence of

routines should really be LAND followed by TOFF. This difficulty

has not been resolved, but in sample debugging runs it occurred only

about 2 to Vo of the time, and added only about 30 seconds extra delay

at each occurrence. Therefore it does not seem to affect the DELCAP

results by a significant amount.

3.3.5 Event LAND. The primary purpose of both the LAND and TOFF

routines is to tie up the appropriate points in order to ensure that

following flights remain properly separated from the current landing

or takeoff. Figure 3.3.8 is a flowchart of LAND. LAND removes

the first flight from the landing queue for the appropriate runway.

Then it calls FREER to find when the runway and final approach path

are first free so that this flight may cross the outer marker.

The separation rules which apply to a landing, and their implementation, are discussed below:

(1) No two aircraft may occupy the same runway at the same time.

This rule is inplemented by tying up the runway threshold (for landings)

- 87 -
REM3VE FIRST FLT FL FROM Q

T = FREER _

1i

TIE UP ERTI AND THTI FOR ROTlJ

. . > /

TTE UP OMTI OR 1 SEPIMTI TO MAINTAIN ^

'OPER 3>_H§—>-

TIE UP ERTI TO MAINTAIN SEPTL

OR DAFIX

<

KITNW,

•INTERFERES - .WITH OTHERS

YES

FOR EACH INTERFERENCE WITH ANOTHER RUNWAY KK 1

=1

TIE UP OMTI (KK) OR

THTI(KK) TO MAINTAIN SEPLLi

X

^TYPE OF

INTERFERENCE'"''

Bl

TIE UP OMTI (KK) TO MAINTAIN

SEPTL OR DAFIX 3

> •<-

SCHEDULE NXTOP AT T]

=6 q.

TIE UP ERTI (KK) AND

THTKKK1 FOR INTERSECTING RUNWAY

o

Figure 3.3.8: Flowchart of the Event LAND

- 88 -
or the end of the runway (for takeoffs) for the time the current

landing will occupy the runway.

(2) Two landings must be separated by a minimum distance (called

SEPLL, in DELCAP) . We assume a constant nominal final -approach

speed, depending on aircraft type. Therefore, the point at which two

landings are closest while always maintaining the required separation

depends on the relative speeds of the two planes. If the first is

faster, they will be closest when the first crosses the outer marker.

In this case the outer marker is tied up for the time it will take

the second to fly SEPLL. If the second is faster, the two planes

will be closest when the first just touches down. In this case the

runway threshold is tied up from touchdown of the first until that

time plus the time for the second to fly SEPLL.

(3) A landing must be separated from a preceding takeoff. The

separation required depends on whether the landing aircraft has Pi stance

Measuring Equipment (DME) . If not, the landing may not pass a certain

fix (called the departure/ arrival fix) before the takeoff starts.

Therefore, if a landing has passed this fix, no takeoff may occur until

the landing has cleared the runway, and so the end of the runway is

tied up from the time the landing passes the departure/arrival fix

until touchdown. (The end of the runway is already tied up, for the

period the landing will occupy the runway ; by virtue of separation rule

(1) above.) If the landing does possess DME, however, then the two

aircraft (landing and preceding takeoff) need only be separated by

- 89 -
a required distance (called SEPTL in DELCAP) . The standard present

value of the departure/arrival fix is 4 miles from the end of the

runway, and that for for SEPTL is 2 miles. As noted above, the

final -approach speed is treated as constant. Under the assumption of

a single constant acceleration for a takeoff on the ground and in the

vicinity of the airport, the distance the landing must be from the

takeoff when the latter starts its roll is

SEPTL + 0.5 V

2

• ROTT/S,

where V is the speed of the landing, S is the liftoff speed of the

takeoff, and ROTT is the runway occupancy time for the takeoff. (This

formula is derived in Appendix F.) The end of the runway is therefore

tied up from the time the landing passes this point until touchdown

time.

Tying up a point is accomplished in the simulation by creating

a temporary entity called a TIEUP, with attributes TMIN, the time the

tieup goes into force, and 1MAX, the time the tieup is no longer in

force. The TIEUPs are filed in one of the sets OMIT, THTI , or ERTI, which

are scanned in FREER to decide when the runway and final approach path

airspace are free. Once the TIEUP is no longer in force, it is removed

by the FTIUP routine which is scheduled in LAND as the TIEUP is created.

* 90 -
In addition to tying up points on the same runway, points

on interfering runways must be tied up. Two arrays RPT and TPT

control these interferences in the DELCAP simulation. For each runway

and interference, RPT contains the runway being interfered with, and

TPT contains the type of interference. There are six types of

interference

1. Landings on one runway must be separated from landings on the

other runway by SEPLL.

2. Landings on the one runway must be separated from preceding

takeoffs on the other runway in the same manner as that

described in (3) above.

3. Takeoffs on the one runway must be separated from following

landings on the other as described in (3) above.

4. Takeoffs on the one runway must be separated from takeoffs

on the other runway by the same separation as takeoffs on

the same runway.

5. Takeoffs on the two runways are independent if they diverge,

but must be separated if they do not.

6. The two runways intersect.

Types 1, 2, and 6 apply to landings. Tieups for interference

types 1 and 2 are computed in a manner similar to (2) and (3) above.

For intersecting runways, a takeoff or landing on another runway may

not be on the runway between the time the current landing touches down and

the time it passes the intersection or turns off, whichever occurs first.

- 91 -
The time for an aircraft to travel from touchdown to an intersection

a distance D from the end of the runway is

(1/A) (-V + A/2 + 2AD)

where v is the landing speed and A is the acceleration of the landing.

We assume A is constant, so

A = (Vj - v) /ROTL < 0,

where ^

is the turnoff speed of the landing, v is the final approach speed,

and ROTL is the runway occupancy time. This formula is derived in

Appendix G.

The RPT and TPT lists are scanned, and appropriate tieups are

initiated to maintain required separation between the current landing

and operations on other runways. As each tieup is created, it is filed

into the set for the point being tied up. At this same time, an FTIUP

is scheduled to destroy the tieup once it is no longer in force.

Once all the necessary tieups have been created, the LAND routine

sets NEXT = 0 and schedules NXTOP for the time the current landing crosses

the outer marker. Then the delay to this flight is calculated as the

difference between the time it crosses the outer marker, and TIN

(which is the first time it could cross the outer marker were there

no other aircraft present) . The PRINT routine is scheduled at the

touchdown time for this landing. PRINT adds the delay to this flight

to the total delay, and increments the number of landings for the correct

hour. Since all tieups to maintain separation from this landing have been

created and since the delay for this flight has been calculated, the flight

is no longer needed, so it is destroyed. This conpletes our description of the

- 92 -
landing routine. The takeoff routine performs similar tasks related

to takeoffs.

3.3.6 Event TOFF - Figure 3.3.9 is a flowchart of the TOFF

routine. Much of it is similar to the LAND subroutine. The first flight

is removed from the landing queue and FREER is called to ascertain the first

time the flight can taxi to takeoff. Tieups are created to maintain

separation, both on the same runway and on others where there is interference. NXTOP is scheduled for the time specified by FREER, the delay

is calculated, and the flight is destroyed. Thus the overall structure

of TOFF is similar to that of LAND.

Takeoffs, however, are special in one way. They enter the system

about 15 minutes before scheduled takeoff. The TOFF routine occurs

about 4 minutes before takeoff. The reason for this early scheduling

of takeoffs can best be described here, in the context of the TOFF

routine. Takeoffs are scheduled about 4 minutes early so that scheduling

of takeoffs is compatible with scheduling of landings. Landings need to

be scheduled before touchdown, since they must be properly separated

from other operations along the whole of the final approach path. If

takeoffs were scheduled only at start -of-roll , a following landing

could be scheduled no earlier than that start-of-roll. In other

words, the following landing could not cross the outer marker until the

preceding takeoff had started its roll. It would greatly complicate

the model if landings and takeoffs for one runway were scheduled in an

order different from that in which they occur in LAND and TOFF.

- 93 -
REMOVE FIRST FLT FL FROM Q

T = FREER

l

| TIE UP THTI ANt) ERTI FOR ROTT|

v

t ^

I TIE UP ERTI TO MAINTAIN

_ YFS

OPER 3> -- >-

TIE UP THTI TO MAINTAIN SEPTL

OR DAFIX

EACH INTERFERENCE WITH ANOTHER RUNWAY KK

-^1

TYPF r)F

TIE UP THTI TO MAINTAIN

SEPTL OR DAFIX

-= 4 , 5 ^ =6

TIE UP ERTI TO MAINTAIN

SEPTT OR SEP 2

T r t TIE UP ERTI AND THTI . FOR INTERSECTING RUNWAn

SCHEDULE NXTOP AT T|

Figure 3.3.9: Flowchart of Event TOFF

- 94 -
By scheduling takeoffs early, landings and takeoffs can be treated in

the same manner. As noted above, there is still a residual difficulty

when a very slow landing follows a fast takeoff, but for the most part,

scheduling takeoffs early permits proper sequencing and scheduling on

a dual-use runway.

One may still ask, "why generate takeoffs 15 minutes early?”

Phg figure 15 is of course somewhat arbitrary , but it is necessary to

generate takeoffs at least 3 to 5 minutes (depending on the separation

rules) before they are scheduled by TOFF. When calculating the tieup

duration needed to maintain separation from following aircraft, it is

necessary to know the departure path and/or type of the following aircraft.

If the second takeoff will immediately diverge from the path of the first,

for instance, they need only be separated by 1 minute. Otherwise they

need to be separated by a greater time interval. Therefore takeoffs

have to be generated as far ahead (in time) of scheduling in TOFF as

the greatest time separation required between aircraft.

The careful reader may wish to inquire whether this procedure is

indeed not too artificial. We note in response that these time intervals

can be interpreted in terms of real events. The 15 -minute interval

may be thought of as the minimum time ahead of departure at which a flight

plan can be filed. Such a minimum time is in fact required at the more

congested airports, and as more terminals become congested this practice

will become more widespread. Also, with the addition of computer processing

of flight plans, a minimum filing time is quite likely. The 4-minute

- 95 -
time between scheduling and takeoff may be thought of as the time for

the aircraft to leave its gate, taxi to the runway, and complete final

checkout. In the model, queuing for takeoff would then occur before leaving

the gate, although at most terminals gate space is limited and there

are parking ramps for waiting. This is another instance of a situation

in which we are interested in the length of a time interval but not

in where the aircraft is during that interval. We would be interested

in where the aircraft actually is only if this were to affect whether

the aircraft could turn onto the runway when the runway is free. The

DELCAP model does not include, in its present form, any ground operations.

Therefore, the delay figures do not include delays incurred during ground

operations. Future model modifications might address this additional

source of delay.

To return to our discussion of the TOFF routine, we will now

describe the separation rules applying to a takeoff and their implementation.

(1) No two aircraft may simultaneously occupy the same runway.

This rule is implemented in the same manner as it was in LAND. The

runway threshold and the end of the runway are tied up from start of

roll to liftoff.

(2) Separation between departing aircraft depends on the departure

paths being followed by those aircraft. The precise rules governing

separation between takeoffs are contained in Terminal Air Traffic

Control . pp. 96-97. The required separation depends on the distance to

the point of divergence of departure paths. The separation is implemented

in the model through the use of an array SEPTT which depends on the two

- 96 -
departure paths involved. For every pair of departure paths, SEPTT

contains the separation time required between start of roll for two

aircraft bound along those paths. All the separation rules are stated

in terms of time separation, except for one distance separation. In

the present scheme, this rule has to be approximated by a weighted

average of the times for takeoffs of various types to fly the required

separation distance. The standard values for SEPTT from the preprocessor

are: 1 minute for aircraft on different departure paths, and 3 minutes

for those on the same path. This assumes that different departure

paths diverge immediately. The user may, of course, specify his

own SEPTT array depending on the departure routes for the particular

terminal he wishes to study. Separation between departures on different

runways will be discussed below.

(3) A takeoff must be separated from a succeeding landing. The

process here in TOFF is similar to that described in separation (3) of

LAND. If the landing has DME, the runway threshold is tied up from start

of roll until that time plus

(l/S) (SEPTL +0.5 S

2 ROTT/V)

where S is the landing speed, V is the liftoff speed of the takeoff, and

ROTT is the runway occupancy time of the takeoff. If the landing does

not have DME, the runway threshold is tied up from start of roll of the

takeoff until the landing could have flown from the departure /arrival

fix to touchdown.

- 97 -
Each tieup created is filed in the appropriate set ERTI, for

the end of the runway, or THTI for the runway threshold. Along with

each tieup, the routine FTIUP is scheduled for when the tieup is no

longer in force.

TOFF also ties up points on interfering runways in order to

ensure that the required separation from the current takeoff is

maintained. Of the six types of interference listed in the description

of the LAND routine, four pertain to takeoffs:

3. Takeoffs on one runway must be separated from following

landings on the other runway.

4. Takeoffs on one runway must be separated from takeoffs on the

other runway by the same time as takeoffs on the same runway.

5. Takeoffs on the two runways are independent if they diverge,

but must be separated if they do not.

6. The two runways intersect.

Tieups for types 3 and 4 for different runways are computed

in the same manner as separations (3) and (2) above for one runway.

Tieups for type 5 are computed in a manner similar to that of separation

(2) above, except that a second array SEP2 is used instead of SEPTT.

SEP2 contains time separations required between aircraft on different

runways which take the same departure path. Type 6 is handled for

takeoffs in the same manner as for landings. The threshold and end

of the second runway are tied up from the time the takeoff starts its

roll until it has passed the intersection.

- 98 -
The remainder of the takeoff routine is the same as the landing

routine. NXTOP and PRINT are scheduled, delay is calculated, and the

flight is destroyed.

3.3.7 Event FTIIIP - This event destroys a tieup as soon as it is

no longer in force. A flow chart appears as Figure 3.3.10. These

"erasures'* free computer storage for new flights and tieups, and

make searching the sets in FREER easier. Since the sets OMTI, THTI,

and ERTI are ordered by TMAX (the time the tieup is no longer in

force), FTIUP only needs to remove and destroy the first tieup in

the appropriate set

.

This concludes our routine -by -routine description of the

simulation program. We will now describe the input required and

output produced. Any SIMSCRIPT program requires a "system specifications

card" and an initialization deck specifying the number of permanent

entities and the size and initial values of each of the main variable

and arrays. The preprocessor provides the initialization deck. A

user who prefers not to use the preprocessor (and so must prepare

his own initialization deck instead) should refer to S DISCRIPT, A Simulation

Programming Language, pp. 115 to 12 8, for a further description of the

initialization deck and its format. We will describe the system

specification card here, though, since it must be provided by the user:

- 99 -
= 2 =3

REMOVE FIRST

TIEIJP FROM

OMTI

v'

i

j

REMOVE FIRST

TIEUP FROM

THTI

L

->- O <

y

\/

DESTROY

TIEUP

Figure 3.3.10: Flowchart of the Event

si

REMOVE FIRST

TIEUP FROM

ERTI

FTIUP

- 100 -
Columns Contain

1

6

11-12

17-18

23-24

1 (one)

P - if the user desires printing of

the initialization deck. Otherwise,

leave blank.

50

60*) time unit is hours

60j

36 8 (number of tape unit containing

initialization deck)

42 8 (number of tape unit containing exogenous

events) . May be another unit if EXGEN is

used, but first event must be BEGIN.

In addition to the initialization deck, the user may provide

deterministic traffic for input to the EXGEN routine. This input must

be in SIMSCRIPT exogenous -event input format. The first exogenous event

must be BEGIN (event type 1), and the rest may be EXGENs (event type 2),

The format required is given in Appendix A.

Sample simulation output appeared in the earlier Figure 2.2.1.

It includes the number of operations generated, the number performed,

total delay, and average delay per aircraft broken down by hour-of-day

and by operation. Other outputs are in principle readily available, but

since the simulation has never been run in other than a debugging

environment, i.e. to determine which outputs are operationally preferred,

the current set is all that the present coding provides. Queue

statistics, such as average length of queue, could easily be gathered.

- 101 -
Any of the statistics could be gathered by runway or by aircraft type.

The present output should therefore be regarded as illustrative of

model capability, and not as the only ones available.

This concludes our description of the model programs. The next

chapter will describe running the model, and outputs from illustrative

runs

.

- 102 -
4. OUTPUTS FROM ILLUSTRATIVE RUNS

During the course of the current work, the DELCAP model has been

run primarily to test its components. The results of several of these

runs will be presented here. It' should be noted that the scope of the

work to date limited ’’data collection” to use of easily available

published data; we were unable even to get a complete set of data for

any one airport, and the present phase of this model development effort

included neither validity checks nor sensitivity analyses. Therefore,

the reader should view the ’’results” given in this chapter as examples

of model capability, the outputs of model-testing runs, rather than

of ’’application” or ’’production” runs. We will report three sets of computations. The first describes

a parallel runway configuration under three different operational

procedures. The second is the 24-hour run based on Atlanta Airport

(ATL) which was used as an example in Chapters 2 and 3. The third

is a run based on the John F . Kennedy International Airport (JFK)

.

The discussion of each case will be accompanied by a specification

of the associated input parameters

.

The parallel runways for the first set of runs are assumed to

be between 3500 and 5000 feet apart, which under current rules means

that a landing on either runway must be separated from all other

landings . Takeoffs on one runway do not interfere with landings or

takeoffs on the other. Three different operational procedures define

the three cases studied in this set of runs:

- 103-
Runway 1 Runway 2

Case 1: Takeoffs Landings

Case 2: Both Landings

Case 3: Both Both

The traffic mix and types used for all three cases are given in Figure

4.1. The same stream of traffic is generated in the three cases.

In Case 1, all takeoffs were assigned to runway 1 and all landings

to runway 2. In Case 2, 50% of the landings were assigned to

each runway but takeoffs only to runway 1. In Case 3, 50% of the takeoffs

and landings were assigned to each runway. Other than this, the only

difference among the three runs was the operational procedure. In Case 1,

OPER = 1 on runway 1 and OPER = 2 on runway 2. In Case 2, OPER = 3 on

runway 1 and OPER = 2 on runway 2. In Case 3, OPER = 3 on both runways.

(Recall that OPER = 3 means that landings and takeoffs are alternated whenever the appropriate operation can take place immediately; otherwise the

operation which can take place first, does take place first.) The outputs

of the runs refer to a one -hour period during which the expected numbers

of landings and takeoffs are each 30. The simulation was run for one hour

previous to recording output in order to preload the system.

Results for the three runs are tabulated in Figures 4.2 and 4.3.

Since all landings must be separated by the same 3 miles, permitting

landings on both runways could increase throughput only if runway

occupancy time were a more critical factor than a 3 -mile separation

rule. A glance at the data in Figure 4.1 shows that runway occupancy

time for either a landing or a takeoff is less than the time for any

- 104 -
SPEEDS

(KNOTS)

RUNWAY

OCCUPANCY

(SECONDS)

TYPE

DESCRIPTION

MIX %

LANDING

LIFTOFF

LANDING

TAKEOFF

*3- rH

to to to OO

rsi (nj 0

CO

cn

LO

LO

t>-

LOvO

CSJ LOo

VOoLO

LO

LO

LO

to

00

tootoo

to

LO

LOo

0^po

<4Hp0

•I—1

4-> p.

•I—l PU

CO0QU

•H

MH

mh

ajPH1

P>

<4Ha3POP

•H<

vO OLO

TJ P P 0 P

CD T3 i-h P rH

CO 0

CO 0 P-.

CO 4-> P* CO o

4-> 0 O 4-> p 0 *“3 P 0 p*

Ph •d & 0 § 0 rH 3

b0 •H bo rH •H P P frt Td

cd 0 o3 £ 0

hP 2 rJ CO 2 OOJ

4-> bo p

•H *H

hJ 00 o<NI 0

•5bo

tS0

rHbOP

•H

CO 0Pa•H

Ph

PQ u w - 105 -
NUMBER OF OPERATIONS PERFORMED

LANDINGS TAKEOFFS TOTAL

CASE 1 32 28 60

CASE 2 30 11 41

CASE 3 28 27 55

F igure 4.2: Throughputs, First Set of Runs

AVERAGE DELAY PEP AIRCRAFT (MINUTES)

LANDINGS TAKEOFFS ALL

CASE 1 11.25 8.74 10.08

CASE 2 13.19 50.03 23.07

CASE 3 17.09 19.22 18.14

Figure 4.3: Mean Delays. First Set of Runs

- 106 -
landing aircraft to fly 3 miles, so that the separation rule is a more

stringent requirement than the rule prohibiting two aircraft on the same

runway. Hence, no increase in throughput can be gained by allowing

landings on both runways. This is illustrated by the results in

Figure 4.2, where the number of landings actually decreased when they

were allowed on both runways. The decrease stems from the fact that

landings must be separated not only from other landings, but from

takeoffs on the same runway as well. In Case 1 there are no takeoffs

on the same runway as landings, so this rule never comes into play.

In Case 2, half the aircraft land on runway 1 and so interact with the

takeoffs on that runway. In Case 3 all landings interact with takeoffs

and so the landing throughput is cut still further.

In Case 2, the number of takeoffs is drastically reduced. Since

takeoffs can only occur on runway 1, and half the landings also occur

on that runway, it is not surprising to find the number of takeoffs

cut by more than half. When takeoffs are allowed on both runways (Case

3), their number increases to almost its level in Case 1.

Case 1 provides the least delay, as well as the greatest throughput. Since landings must always remain separated by 3 miles from other

landings, landing delay can only increase when landings and takeoffs

are allowed on one runway. Takeoff delay increases dramatically, to

50 minutes per aircraft, in Case 2 (where only one runway handles takeoffs, and landings also use that runway). When both takeoffs and

landings are allowed to use both runways (Case 3) , landing delay

is increased over Case 2 by about 4 minutes per aircraft, while

- 107 -
takeoff delay is reduced about 30 minutes. It is difficult to

determine the exact sizes of these delays from the input since they

depend on the traffic mix, the runway use distribution, and the

distribution of departure paths.

The major conclusion which seems to emerge from this exercise

is that --at least for this particular airport with this particular

traffic level -- under the current separation rules, the best on

the other. Of course no such rule should be inflexibly imposed

on real situations; if the controller is presented with two takeoffs

desiring to leave at the same time, and there is a large enough

gap in the landing stream, he clearly should allow one of the

two takeoffs to use the runway ordinarily reserved for landings.

An additional observation from the preceding analysis is that

the distribution of departure fixes all can have a substantial effect

putting these items, and they must be taken in account when interpreting the results.

The other two output sets described in this chapter have a common aircraft description, given in Figure 4.4. The first of the

two is the Atlanta Airport run which was used as an example earlier.

The traffic mix for this run is given in Figure 4.5, and the airport

description for our hypothetical version of ATL in Figure 4.6.

The results are tabulated in Figure 4.7.

- 108 -
SPEEDS

[KNOTS)

RUNWAY

OCCUPANCY

(SECONDS)

LANDING

LIFTOFF

LANDING

TAKEOFF

-109

Figure

4.5:

Traffic

Mix

for

Run

Set

II
AIRPORT CONFIGURATION FOR ATL AIRPORT

Number of Runways = 3

RUNWAY 1 (9L) - Takeoffs only

RUNWAY 2 (9R) - Landings only

RUNWAY 3 (15) - Dual Use, Alternating Operations

Runways 9L and 15 intersect at a point 2400 feet from the end of

Runway 9L and 1677 feet from the end of Runway 15.

Runways 9R and 15 intersect at a point 5997 feet from the end of

Runway 9R and 6520 feet from the end of Runway 15.

Runways 9L and 9R are semi -dependent parallels - Simultaneous

arrivals are prohibited.

Figure 4.6: Airport Description for Run Set II
Oun

urLKMliuhs

uLi.I-kmilu

oPLKAIioNb

PJHh

uKi-iE.

i

!

1

o|

AL

OtLA

i

(''JnUTLS)

UFlAY

PFR

A/C

(MINUTfS)

LAiiuiHO;>

u

f

, L

Oi-i-j

I

oI

ViL

LAnjUluGb

TmimLOFKs

T

tT

mL

L

AiMU

1

UGS

TAivtOrFb

ALL

LANDINGS

TAKtoFFS

Al.L

ao rof^xf^O'CMXO'co'Oc®vC4r,-«-i lTC\' HCCCCC«O'ftlNJ<Ofl‘^0CiCH\OK)®(\l

ro — — *- 3 x cc a a< 4 x x tv x

eo

ra r- for»r^«Hvoaa'd-0'^^-c-r^ir. r*-cr^ x

• ••••••••••••••••••••••• • AXC.CC XCXC.CrQAO'O' —'«-'CM«-lCM34fs'4C O

4- A( 4 P** 3 CM X P" X «-i O' CM O' ^ *—< «—I ^ ^ (\J

4 A. X a ror^x«-, x--43AXf'-4o-<c

r

ac(\iacccccft,rtcirff«fij(\jcff'ci(\i

— aiajoxxxp'3aj4XX CM

XI

*nv U fO A 4 X 3 X ro CM p- X X 0 p~ ro C •-4 o- o

P~ 3 X 4 3 3 3 0 •H H 4 O' O' o CM X o O •H X X H O X X y* K" X X CM X CM p- Is- 3 r- O' AJ CM X X

p- X 3 4 r- CM O 4 3 3 Is- CM' H

H AJ CM X X O' O' 3 4 JV. 4 X

•H rH r~ X x r~ X AJ Ai X 3 <\J X X 4 c O' •H X CM 3- rO X 3 3 A 3 3 3 A1 CM X X O' X H 3 r*~ X X AJ X X X

A' •H X X X X X X X 3 X 3 H p- 3 AI 4

A. fTS —4 r r z r**. AJ A 1 A! 3 — CM o rT) X T 3 X X 4 X

3“

X O rO X 0'0'OAJ3CMP'-CMXf'“40'440'

T - r. ~ z z z 3 - x cv " > 'O « <\i fl ^ ^ f. if .\ x 4XAIOXCO''-'3 3XP-4-44 O

4lv-r'-4X»HfO3 0'4r'-XX -< hhMM'\1''OJJC!h AJ*0

-t0'-0X40M0CO-<D-tXM4AM4O''~3'J X

a. — --it f xxr^xxxxr^xxr^xx o

+-> 33

5

flj A3£

r*- 4 4 X 3 CM X C Is* 3 X 1^ iO X O' 3 X‘ 4 1^ X CM X A

—i O'4

t-4

a>p

a•H

PU 4AJ04 3 4443-»rOXrOE3rO4r^Xr'-AJ0'XI'~ rO

-i MOO'OOOOO.M'OO'OOAl.-t -tX

M -«AJ4XCX0'XX3-«XAJAJ-»"MAI 3

-( -4 3

JJH'OflHHj'OJ C44!^'-*'O-»4XXM-»r~0' M-»MM4fXn4XJ-»-»H-t O'4

\) 30'-(3X4.'0-»X-0-«4X'OONO-«0-tX33 O

h 0X4440 O 0 C O H -« -t’M HX

-i si 04 X 3 *>» 00'3-4"M04X 0''*'00'3-4\l'04

—I—I— • N AJ AJ AJ AJ

-I <
The ATL airport configuration consists of a pair of offset

parallels 4400 feet apart, plus a crossing runway. However,

about 96% of the traffic uses one or the other of the two parallels.

Since the parallel runways are less than 5,000 feet apart, all

landings must be separated by 3 miles regardless of which runway

they employ. The parallels are operated in the manner of Case 1

of run set I, one for landings and one for takeoffs. The

simulation was started at 7 a.m. and was preloaded an hour before

delay and throughput were recorded. Therefore the first hour for

which delay and throughput are recorded is the one labeled 9 in

the output.

Since aircraft are generated about 15 minutes before landing

or start-of-roll, the first landings and takeoffs recorded in

hour 9 were actually generated during hour 8. Similarly, at the

end of the simulation in hour 8, some takeoffs and landings have

been generated but not yet performed. Although the expected

number of aircraft generated in hour 8 at the beginning of the

simulation is equal to that at the end, the actual numbers in any

particular sample run need not be the same. This explains the

apparent discrepancy of one more takeoff performed than was generated.

Since delay and throughput are recorded at touchdown or startof-roll, the average delay per aircraft for an hour is calculated

as total delay for that hour divided by the number of operations

performed in that hour. For this run, the average delay per aircraft

- 112 -
was much too high to be tolerated at any actual airport. However,

as noted earlier (in Section 2.2.5), the traffic levels employed

are taken from total traffic (VFR and IFR) at San Antonio Airport;

the true traffic levels and peaking characteristics at ATL may be

quite different.

The third set of run outputs to be discussed in this chapter

refer to an approximation of John F. Kennedy International Airport

(JFK). The traffic mix for this run is given in Figure 4.8. The

airport configuration, the most complicated one employed in these

model exercises, is portrayed in Figure 4.9; Figure 4.10 shows

how it appears on the preprocessor output.

Runways 4L and 4R are close parallels (less than 3,500 feet apart),

while runways 31R and 31L are wide parallels (more than 5000 feet apart)

.

Runway 32 (which cannot be located solely from the information given

to the simulation) is shown in proper position in Figure 4.10. This

is a good example of a case in which more information than is needed

by the model would be required to produce pictorial output. The model

only needs the interference patterns . We know runways 32 and 31R interfere

on both landings and takeoffs, but since they do not intersect we do not

not need to know where they are in relation to one another. We also know

- 113 -
Landing Mix

54

Tm. Takeoff Mix

1

2

3

4

5

35

1

6

4

54

35

1

6

4

Figure 4.8: Traffic Mix for Run Set III

4R

Figure 4.9; Pictorial Description of JFK
AIRPORT CONFIGURATION FOR JFK AIRPORT

Number of Runways = 5

RUNWAY 1 (31L)

RUNWAY 2 (31R)

RUNWAY 3 (4L ) RUNWAY 4 (4R ) RUNWAY 5 (32 )

Takeoffs only

Dual Use, Alternating Operations

Dual Use, Landings Take Precedence

Landings only

Dual Use, Alternating Operations

Runways 31L and 4L intersect at a point 2096 feet from the end of

Runway 31L and 3427 feet from the end of Runway 4L.

Runways 31R and 4L intersect at a point 1288 feet from the end of

Runway 31R and 10748 feet from the end of Runway 4L.

Runways 31L and 31R are independent parallels - simultaneous operations are permitted.

Runways 31R and 32 are dependent - No simultaneous operations are

permitted.

Runways 4L and 4R are dependent parallels - No simultaneous

operations are pemitted.

Figure 4.10: Airport Description for Run Set III

- 115 -
runway 4R is parallel to runway 4L, that 4R does not intersect either

31R or 31L, and that 4R and 4L are separated by less than 3500

feet, but do not have to know exactly how far apart 4R and 4L

are or if their endpoints are offset.

Results of run set III are given in Figure 4.11. Again this

is a 24-hour run, from 8 a.m. one day to 8 a.m. the next with the

hour from 7 to 8 the first day run to preload the system. The

same traffic distribution was used in run sets II and III, and

since the random number sequence and starting times were the same,

the exact same traffic sample was obtained. As can be seen from

the output, landing delay for JFK is greatly reduced relative to

ATL. However, takeoff delay is much too great. This is probably

due to the distribution of runway use: 89% of all takeoffs use

runway 31L, while another 9% use 32 and only 1% use 31R. (Again

it should be noted that these are hypothetical data, which for

greater realism should probably be modified to put more takeoffs on

runway 31R.) Also, 85% of all takeoffs are bound on the same departure

path, tending to increase average takeoff- takeoff separation requirements

and hence mean takeoff delays. This latter feature, however, may

reasonably reflect the effects of the restrictions governing use

of the crowded New York area airspace; real New York data would

be needed to verify this.
HOUR

OPERATIONS

GENERATED

OPERATIONS

PERFORMED

TOTAL

DELAY

(MinUTES)

DELAY

PER

A/C

(MJNUTeS)

LANDINGS

TAKEOFfS

TOTAL

LANDINGS

TAKEOFFS

TOTAL

LANDINGS

TAkEOFFS

ALL

LANDINGS

tAkEoFFS

ALL

J - n '© ^ >00'— o—

x

^ino'oomooocnoxin'^pgooin—'O' — oo'rg x

(V| N fO N OO -NOTl/MOTO-NCO OD n n n m n - —

Cg —• ® —* -O O' CD O -• (*1 1/) -•'OQi/1 — O > CO -< T - Cg «*) 0'<0 ® 0' 0 in 000 '0 <'r

) 0' —•CM — T O* T N J) (D - ® rn *o ® « o* ji a n -nji'OanT-MCDjiN -o _ eg eg eg eg ^ _

—• <n t*) nih-i/i^nomcoifl^nQN- in OO — 0000000^4 — — — ^r^T-OOCOOOCDO in — r\4

— m O' N N 1/1 — 'OO'^' — XPgO - l^NQ-NT®Q

— rn n (h o 1/1 in

CO >0 O' CD — O —r>4rv<ON»ni/)N—TO-«T—l/» —

N N l/) « O N --Nna-TCNO^KIMthT- MDN N -O --(MTTTinil-ON

in ^ n in in in>cin^inaaD — O'in -o in o in rn *o e** T - «0 -

co -o co eg if) —

cd

^fMor^ 3-inor^oO'r^>o®inr,^-*inoo 3 — 'O -«so--NNoo-innT-*ino r*- —. Nn®^®inN®inMO‘T —

d — --Nnorinin>oN

O'

:r

rsi ®

-o 'O r* >0 n - >0 t ro^oo-o-n-Nn <0 OO® — 00000'00r^c\400>0 — in Jl N T O N - eg — — r -fl in N •€ - CM a ® eg — — CM ® — — CO — CM

TNn<coNi/iT>c(> o m t - Nn-nN->cch

n n n M n « — — mLnor^r^-o -c e** ® x mmmo ao

ooo'ooo- — o«oo®^)®f^'0®royf^ — m — in m t- eg eg — eg eg — — —. pgpgpgpgegrgrMrgrgegrMPgcM O

t nj t >o o c^> x inoa®OMPiconT o- t m t o - n — rgrnxx jnnTTinN--<-- <1

in

<D

Jha•H

P-H

otOTin-flinN-

0' 0'in®Pi 5-'0 <nx-o®/nr^rvO' x

<M — NTin'OCDO'®®0 - in N M - eg eg O — — o

t t - n in ^oj->OT}-N-n«j-ininN«saeg — cm eg x tininTinM----

rgo^-oinTn-inn-y >c ^ n i\ «— n — «o o o — ronxxxom^ogjcn— — — rg

<*)m

-MnTin<N® 9, o-NnTin-«NC(ho-NflT co

=>7 i * * -

in

-

117

-
This is the last of our illustration model run sets. The

reader will have observed that the set of outputs presented was

rather restricted, including only delay and throughput information,

broken down only by operation and hour of day. Any of these

statistics could also have been recorded by runway or by aircraft

type. If the average number of passengers per aircraft of each

type were provided to the model, average delay per passenger could

be computed, broken down by any of the above categories. A frequency

distribution showing the number of aircraft delayed by up to 5

minutes, by between 5 and 10 minutes, between 10 and 15, etc. can

be computed and output in a graphical foim if desired. (The exact

size of the recording interval for such a distribution would of

course be a user- specified parameter.) In addition to delay and

throughput statistics, queue-length statistics could also be

gathered. The average or the maximum number of aircraft waiting

could be recorded by runway and/or by operation and/or by hour of

day. All of these items are available with some recoding of both

the preprocessor and the simulation. Because the present version

of DELCAP has not as yet been run in a production environment,

the format and content of output most useful in that environment are

not yet known. Designing the "production" output options is one

of the areas which must be included in future work on the DELCAP

model.

- 118 -
Finally, we wish once again to emphasize that the DELCAP

model has so far been run for debugging and logic testing purposes

only, in exercises not including the validation checks or

sensitivity analyses required for genuine applications. That

such further resource -consuming and time-consuming steps could not be

executed during the present phase of the effort was not surprising,

but without them the work which was accomplished is left in a frustratingly tentative and tenuous status. For example, time

did not permit an intensive search for maximally complete and

consistent data to be used in validation runs. Such a search

should be the first task in any future DELCAP efforts; one cannot

confidently interpret or utilize results from an unvalidated model.

Once DELCAP has received this basic checkout, sensitivity analyses

should be performed to investigate the effects on throughput and

delay of such variables as: aircraft mix, operational procedure,

runway-use distribution, diurnal traffic distribution, runway

occupancy times, aircraft speeds, and separation rules. These

analyses will not only provide a valuable insight into the effects

on throughput and delay of variation in the airport parameters,

but will also provide guidelines for the accuracy needed in

collection of data for input to DELCAP.

- 119 -
In a more positive vein, we may note that the DELCAP model

has now produced, with an acceptably small expenditure of computer

time, delay and throughput figures for a complicated runway

configuration with an appropriately high traffic level. The kinds

of input data required by the model have been found in the published

literature, or at least can in principle be secured without a great

data collection effort. The illustrative runs and analyses reported

in this chapter have shown that DELCAP can be a useful tool in gaining

insight into the roles and interactions of separation rules, airport

configurations and operating procedures, and traffic distributions as they affect delay and throughput.

- 120 -
5 . RECAPITULATION AND NEXT STEPS

In this report we have described the present version of the

DELCAP simulation model and its preprocessor, which are currently

operational on the UNTVAC 1108 computer at the National Bureau of

Standards. DELCAP has been tested on several different runway

configurations, and these tests support our expectation and intention

that it be applicable to a wide variety of runway configurations. The

model (preprocessor included) takes only about 12 seconds to simulate

a day’s activity at a major airport.

The DELCAP model is envisioned as a planning and analysis tool.

To that end, we adopted the "model as little as you can" philosophy

of computer simulation, and designed a preprocessor to permit the user

to utilize standard data sets whenever desired and to input other

data in an easily prepared format. The simulation model includes

only those elements of the airport system which affect throughput and

aircraft delays, and is based on the idea of an interference point, one

of those points on the path of a landing or takeoff (in the neighborhood

of an airport or the surface of the runway) where the presence of one

aircraft inpedes the free progress of another aircraft because of required

separation between the two. The simulation contains two interference points

for landings, namely the outer marker and the runway threshold, and one

such point for takeoffs, the end of the runway at which the takeoff starts

its roll. The model deals in detail only with the times at which an
aircraft passes these interference points; flight paths, holding patterns

and takeoff queues are not represented explicitly. Only the interferences

among aircraft, which dictate when a flight may pass the interference

points along its path, are treated in detail in the DELCAP simulation

since these interferences suffice to determine the throughputs and the

delays which are to be measured by the simulation.

Two factors had to be balanced in the design of the preprocessor:

flexibility of input versus ease of input. Since DELCAP is designed

as a tool for aiding analysts in the planning process, it must be

easy and convenient for use by one whose specialty is airports rather

than computers. However, it is expected that planners may wish to

vary almost all inputs to the DELCAP simulation. Therefore, the preprocessor was designed to allow the user to choose those types of

data he wishes to provide himself, while still providing "standard"

sets of data for all input groups so that a complete data set need

not be prepared for each run. The foimats for user-supplied data are

designed to make their preparation as easy as possible, and to allow

easy modification where a desire for such modification can be anticipated.

Input data are divided into six groups and a user may either insert

(all) the data of a group or else utilize the standard data for that

group. For those groups which depend on the airport, a user wishing to

use standard input must specify from which airport’s file these data

are to be drawn. This scheme allows a wide variety of types of

analyses to be made using DELCAP, by providing a convenient means

- 122 -
for varying almost all inputs. However, it limits the data needed for

any one run to those which the user wishes to differ from the standard

data provided. Thus the preprocessor provides both flexibility and ease

of input.

Our documentation has described the current versions of both the

DELCAP simulator and its preprocessor. In the course of these descriptions

we have noted natural areas for future work on the DELCAP modeling

system. We will now list these areas again, to give the reader a better idea both of where we are currently, and of what remains to be

done before the mature DELCAP described in the "Mock Instructions" memo

can be available.

- 123 -
5.1 Validity and Model Sensitivity

The scope of the current work was too limited to allow adequate

validity and model -sensitivity tests. Only basic logic-testing has

been done, to insure that the model does in fact perform as it was

designed to do. Efforts to confirm that this design yields satisfactory

agreement with actual system performance were not included in the

present phase. In order to do this, it is necessary to obtain data

from existing sources (or to collect them specifically for this purpose)

,

and to run the model to compare model outputs with these collected data.

The effort would include preliminary sensitivity analyses to determine

what degree of agreement between model outputs and the observed data

can reasonably be expected. Such sensitivity analyses will also point

out the degree of accuracy needed in collecting model input data in

order to achieve desired accuracy in model output. For instance,

even the small set of testing runs reported in Chapter 4 shows the

need for care in defining the operational procedures, the runway use

distribution, and the distribution of departure paths.

We feel that validity testing is the next logical step in

bringing the DELCAP model into full operational status. Of the

two types of output, throughput figures should be more easily verified

than those for delay, since the number of landings and takeoffs in a

given period of time can be calculated fairly easily. The delay

recorded by DELCAP, however, depends on the description of the

"system" included in the model, and may not be the same as any other

delay measure now tabulated. Therefore, a special data collection effort

- 124 -
might be needed to provide an empirical basis against which to

check DELCAP’s delay figures; this possibility (and potential

alternatives) must be explored systematically.

A model whose performance has not been checked for validity cannot

be properly evaluated adjusted, or elaborated. This is why we recommend

validity-testing of the present version as the next step in the process

of making DELCAP a useful tool for planning. However, we do not wish

to imply that such testing would end at that point. There are several

extensions and revisions to the model which, we suggest in the following

sections, should be undertaken subsequent to the preliminary validity

checks. Further testing against real-world data would be needed to

insure that these procedures, too, have been modeled properly.

Validity checks and any associated data collection efforts may

themselves indicate model changes. The results of such checks are

unlikely to be a clear-cut "yes" or

nno"; more probably, some areas

will prove to be better represented by the model than are others. Such

findings may suggest modifications either in model logic or in the

structure of the data required by DELCAP. In this sense, validity

checking is an on-going process, which is included implicitly in the

other activities suggested in this chapter and which can prove a major stimulus and guide to model improvements .

- 125 -
5.2 Sensitivity Analyses

After preliminary establishment of validity to within appropriate

limits, the model may be exercised in examining the sensitivity of

delay and throughput to variation in the model inputs . We have already

mentioned preliminary model sensitivity work, whose purpose is to

ascertain the ranges over which the model variables produce reasonable

outputs. Such preliminary work would also address the problem of which

variables the model is particularly sensitive to, i.e. which ones produce

the most noticable effects in delay and throughput. This first stage

of sensitivity analysis, conducted in conjunction with validity checks,

would be on the order of "tinkering" with the model, seeing what it

will and will not do, how it acts and reacts under various scenarios.

The scenarios might or might not be real or realistic; rather, the focus

is on the model and how it operates.

With the completion of the first testing cycle, however, the

sensitivity analysis may proceed to a second stage, that of testing

system sensitivity. That is, with the validity of the model’s representation

of the airport system established, the model can be used to test that

system’s reactions to hypothesized patterns of changes in the airport

configuration and operating procedures, traffic mix and levels, and

separation rules . The model can be used for example to evaluate what

traffic levels result in average delay per aircraft of over 20 minutes.

The dependence of throughput on aircraft speed can be studied. The object

of this phase of sensitivity testing is to find how much of a change

- 126 -
in throughput and delay will result from a known percentage change

in some input variable. Responses to changes in combinations of

variables can also be tested. The results of such sensitivity testing

can aid the analyst in understanding the complex interactions in the

airport system, and can help him in designing a minimum series of

runs to investigate those particular changes at particular airports

which he desires to evaluate. The sensitivity runs may eliminate the

need for some runs altogether by duplicating common requests. They

may also provide advance guidance as to which changes are most likely to

achieve the planner’s goals.

- 127 -
5.3 Model Modifications

Once validity of the model has been established, and either concurrently with or subsequent to the sensitivity analyses, certain

model modifications should be undertaken. They fall into six categories

(1) investigating the possibility of modifying the scheduling of

landing and takeoffs (see Section 3.3), (2) revising the output,

(3) including the effect of weather on the system, (4) investigating

the advisability of using probability distributions rather than

single values for some of the variables, (5) the inclusion of VFR

traffic^ (6) allowing some variables to depend on time-of-day, and

(7) adding some ground operations to the model. The seven items appear

roughly in what we feel to be the order of their priorities.

The first modification is designed to overcome the difficulty in

representing a slow landing following a fast departure. In this case

the landing can cross the outer marker before the takeoff leaves its

gate, remain adequately separated from the takeoff, and land after

the takeoff. This creates a problem in the present model because the

landing should be scheduled first, although the takeoff starts its

roll before the landing touches down. That is, the landing and takeoff

should be scheduled in the opposite order to their occurrence.

Another objective here concerns remedying a second difficulty

in the present model's procedure for scheduling landings and takeoffs.

The routine FREER scans the tieups pertaining to a particular flight,

and LAND or TOFF is scheduled when none of the tieups is any longer

- 128 -
in force. However, there may be a gap between the tieups sufficiently

large that the present flight could be scheduled during it without

affecting previously scheduled flights. If so, the present flight

could in reality be scheduled earlier than the present version of the

model permits

.

Modifying the scheduling procedure to change these imperfections

in the present model may turn out to be a difficult task requiring

major modeling changes and additions. For this reason it was decided

that the simpler version of the model was the one to be produced during

the present effort. However, an effort should be made at least to

ascertain the difficulties involved in resolving these two scheduling

problems

.

The second listed area of model modification is the content and

form of the output. As mentioned previously, the model has been run

only to check out its logic. The current output set was designed to

be representative of the types of output readily available from the

model. Once the model’s validity has been established it will be time

to take a further look at what types of output are most desirable. For

a well-based decision on this point, it is necessary to have a better

idea of the types of applications for which the model will be used.

Probably, different sets of output will be most relevant for different

applications . In this case a large variety of output would be made

available, with the user free to specify which sets he desired.

This procedure would require another specification by the user, but

this seems clearly worthwhile if it would procure a set of outputs

- 129 -
much more tailored to his particular preferences and needs.

The last five model modifications involve the addition of features

to the model. The first of these is the representation within the model

logic of the effects of weather on the system. At present the only way

to mirror changes in weather is to vary the parameters describing the

traffic, separation rules or operational procedures. This cannot be

done within a model run, since the associated input parameters are

presently constant throughout each run. Future modification should

include options by which a user could provide weather information,

including a wind profile, and should automate the parameter-variations

resulting from changes in weather conditions. At this point it seems

unlikely that we would want to include automation of weather variations

so major as to force the airport to operate in the opposite direction,

but the feasibility of even this capability should be investigated. Bad

weather also affects the number of missed approaches. In the present versio]

of the model there is no provision for these maneuvers, but the possibility of their inclusion in a future version should be studied.

In the present model version, such parameters as landing speeds

and runway occupancy times are single values, one for each aircraft

type. Yet two "identical” aircraft, loaded the same, need not have

the same exact runway occupancy time or landing speed. These parameters

could be represented by probability distributions, presumably with the

current parameter values as means.

The present model also assumes that a landing aircraft can

- 130 -
be delivered to the outer marker as soon as tieups permit. The degree

to which this ideal can be attained depends on the pilot and controller,

and is therefore subject to human error. Thus there are many areas

in the current model where a single value has been used to represent

items which by their very nature admit a range of possible values.

For this reason, we suggest that those model variables which (like

the ones mentioned above) might best be represented by distributions be

identified, and that an appropriate distribution for each be incorporated.

Some of these distributions may be made responsive to parameters not

now included in the model, such as controllability (human or mechanical)

or weather descriptors. This may allow a fuller range of scenarios to

be tested by the planner, and should provide a better representation of

variations among aircraft.

Yet another model addition would be provision for the inclusion

of VFR traffic. All separation rules in the present model involve IFR

traffic alone. When dealing with the throughput of an airport, however,

it is desirable to include all traffic, VFR as well as IFR. Different

separation rules apply to VFR traffic, and such concepts as the outer

marker for a landing do not carry over from IFR to VFR operations. Ways of

merging the two types of operation within the structure of the DELCAP

model should be investigated, but this enlargement may require a major

effort.

In the present version of the model such variables as user mix,

the runway use distribution, and the operational procedure are constant

- 131 -
for the duration of a run. However, it seems desirable to vary these

in a manner similar to the current variation in traffic levels. The

day might be broken down into several periods, and a different set of

parameters be provided for each period. In this way a runway handling

landings only could be switched to one handling both landings and takeoffs at a time of day when takeoffs predominate. If during certain

periods during the day the traffic mix contains fewer small aircraft

than at other times, this would be reflected in the model. The coding

to accomplish the dependence on time-of-day is relatively minor, so that

the increased flexibility is bought at a low price.

The final feature whose addition to the model is proposed is a representation of some ground operations, mainly those (such as on

taxiways, exit ramps and holding ramps) which affect the aircraft

between its gate and the runway surface. Gate assignment might be

included, if its inclusion can be demonstrated to be worth the amount

of extra input data required. Some ground operations, such as a plane

crossing a runway to get to the terminal, can impede landings and takeoffs.

Others may affect sequencing of operations, such as when a takeoff

holding area becomes filled and there is no other waiting area available.

Still others, such as baggage handling activities, are clearly beyond the

proper scope of a model designed to focus on aircraft delay. Those

aspects of ground operations which affect the delay and throughput

figures calculated by DELCAP should be considered for incorporation in

the model; all others should be excluded.

- 132 -
The seven areas of modification described above are the major

ones suggested for future work on the DELGAP model. Others may suggest

themselves as the work goes on. Several minor modifications have not been

included in the list above. For example, more sophisticated sequencing

techniques, such as ones depending on the number of landings and takeoffs

waiting to use a runway, might be incorporated in the model.

All such additions and modifications should be weighed carefully

before they are undertaken. The decision to go ahead must include a balancing of the additional data requirements, if any, against the

benefits to accrue from the modification. We reiterate that ease of

use is a major goal of the DELCAP model. The more decisions the user

must make, on choosing a standard data set versus providing his own

inputs, the less convenient the model is to him. If the input is

one he would expect to provide (such as some specification of weather

conditions) , indeed one whose absence would arouse suspicion of the

model's outputs, then the extra burden of providing this data is

certainly worth it. If the modification requires a great deal of data,

and promises little change in the output figures, the modification is

much less desirable. All modifications must be studied with this tradeoff

in mind, and only those with a favorable "rate of return" should be

undertaken

.

- 133-
5.4 Airport Data File

In order to achieve the operation of the DELCAP model as described in the DELCAP Mock Instructions , it is necessary to compile a

data file containing preprocessor input data for each airport (or at least

each major airport) in the U.S. The current illustrative "file"

contains infoimation on just two airports, ATL and JFK, much of it

invented either wholly or in part. The process of creating the complete

data file can be divided into two parts, one dealing with the form

of the data (and any necessary reprogramming of the preprocessor)

,

and the second with the actual gathering of the information.

The changes suggested in section 5.3 may necessitate additional

inputs for the DELCAP model. The validity and sensitivity tests may

suggest a reworking of the data group categories and changes in

preprocessor input formats. The format of the data file itself is

likely to be altered to facilitate easier coding. All of these

changes involve some recoding of the preprocessor program.

The second activity involved in creating the airport data file

is the actual collecting and collating of the data, and preparing

them in the form necessary for input to the preprocessor. It is not known

at present exactly which of the various data types are available from

existing sources, or in what form. Therefore preparation of the

file must begin with a comprehensive search of data sources, to ascertain

what data are available where, and to establish if possible the consistency

of data from different sources. This is a laborious and time-consuming

task in itself, but even after data sources are found and checked, there

- 134 -
remains the effort of extracting and coding these data in the form

required by DELCAP. It is unlikely that all the needed data will

already be on record, so that some items will probably have to be

collected in the field. Also, since DELCAP is designed for use in

the planning process, much of the input file will refer to future

years. Therefore it will be necessary to obtain from existing sources

(or to project from current data) future traffic levels, traffic

mixes, and airport configurations for the desired planning years.

Although preparing the airport data file needed by DELCAP

is a major task requiring much effort and time, it should have a payoff

in addition to its use for the model. Such a data file could be

examined to study the properties of airports in the U.S.. Easily

accessible, it will provide people in the FAA with airport information

practically at their finger-tips. There will be one, self-consistent

source of airport data.

- 135 -
5.5 Conversion of the Model to a Time-Sharing System

The final step, in changing the present version of the model

into the version described in the DELCAP Mock Instructions , is that of

converting the programs to a time -sharing system. Such a system

would enable a user to access the program from a terminal in his

own or a nearby office. He would need to know very little about the

operation of a computer, probably only how to activate the terminal

and call up the program. The program would operate in a conversational

mode, asking such questions as "Do you wish to supply airport data?",

and if the answer was "No", "Which airport on file do you wish

standard data to be chosen from?". The user would type in his replies

to each question as it is asked. (The actual foim °f the questions is

of course a matter for study, and must be geared to the backgrounds

of the users.) Once all data were furnished, the model would be

run to supply the delay and throughput figures requested. The user

could then make a few changes in his original data set and run again,

or could start over with an entirely new problem. The program runs

so rapidly that the results would be available while the user remained

at the terminal. Several similar runs could be made in a few minutes

to a couple of hours depending on the amount of data to be typed in.

This kind of procedure allows analysis to be conducted as the model

is run. Questions such as "What if such-and-such a variable is

changed?" can be answered on the spot with very little effort. The

analysis procedure is therefore both quick and convenient.

- 136 -
This concludes our list of future work to be done on DELCAP.

Some of it, such as the validity and sensitivity analyses, is necessary

before the model can usefully be applied. Other parts, such as the model

modifications in Section 5.3, may or may not be desirable depending on

the uses envisaged for the model. Some of those modifications may

of course be more desirable than others, and all must be viewed in light

of the demands to be made on the model. The data file would bypass

the need for each analyst to collect and assemble his own data set,

and in addition would encourage more general analyses than would be

undertaken were the data not immediately available. Conversion to a

time -sharing system is not essential, since the model could be used

without it. However, the advantages of having a model at one’s

fingertips without having to learn much about running on a computer

mean that DELCAP would be more accessible to the user and more convenient

to his use, providing him with a tool which could really be a major

aid in the whole planning process.

- 137 -
6.

BIBLIOGRAPHY

6.1 Air Traffic Control Procedures

1. Airman * s Information Manual , Part 1 , Basic Flight Manual and AtC Procedures , FAA, November 1969

2. Terminal Air Traffic Control , FAA7110.8A,

January 1970

6.2 Capacity Studies

3. Airport Capacity Criteria Used In Long-Range Planning,

FAA AC 150/5060 -3A, December 1969

4. Airport Capacity Handbook , Second Edition, Airborne Instruments

Laboratory, June 1969

5. E. N. Hooton, H. Bums, and M.A. Warskow,

Operational Development Techniques for Computing Airport Capacity , FAA Report Number RD-68-20, June 1969

6. Analysis of a Capacity Concept for Runway and Final -Approach

Path Airspace , NBS report number 10111, November 1969

6. 3 Simulation Studies

7. M.R. Abbott, A Summary of Some Digital Simulations Relating to

Runway Utilization , Royal Aircraft Establishment Technical

Report Number 66087, March 1966

8. J. M. Chaoken and R. H. Fowler, A Simulation of an Airport

Runway System, University of California at Berkeley, September 1969

9. R. B. Coulson and V. D. Burgman, An Investigation into Air Traffic

Control by a Simulation Method , Australia, March 1950

10. Final Report on Air Traffic Control System Simulation Study , Norden, August 1969

5

11. General Description of Computer Simulation Model Developed by

RDSA/PRC During 1968 and Presently Operable , R. Dixon Speas

Associates, December 1968

- 138 -
12. Gordon Jolitz, Simulation and Analysis of ATC/CAS System

Design , FAA-NAFEC , November 1968

13. K. W. Kowalke, The Fast Time Simulation Program , IBM,

March 1960

14. J. Ray Ruetnik and John H. Thompson, Computer Simulation Model

of Terminal Air Traffic and PWI Systems , Kaman AviDyne,

March 1969

15. Charles Sheffield, Multiple Aircraft Models in Stare Fast

Time Simulation Experiments , World Systems Laboratories,

January 1963

16 . Simulation Tests of Air Traffic Control Operations in the

Denver -Colorado Springs Area , Navigational Aids Evaluation

Division FAA, Indianapolis, Indiana, May 1959

6.4 Programming Manuals

17. Harry M. Markowitz, Bernard Hausner, and Herbert W. Karr,

SIMSCRIPT A Simulation Pro^amming Language , Prentice -Hall , Inc.,

Englewood Cliffs, N. J. , 1%3

18. SIMSCRIPT 1.5 , C.A.C.I. 66-INT-3, Consolidated Analysis Centers Inc.,

Santa Monica, California, 1967

19. UNIVAC 1108 FORTRAN V, Programmers Reference Manual , Sperry Rand

Corporation, 1966

6.5 Data Sources

20. L. N. Million J. M. Copeland, J. T. Hornsby, and W. C. Keepers,

A Suggested Action Program for the Relief of Airfield Congestion at

Selected Airports , FAA, April 1969.

21. Approach Airspace and Rj^nway Capacity Parametric Sensitivity Analysis , Boeing -Airplane Group, May 1970.

22. National System Effectiveness Measurement Program, FAA, 1965 - 1966,

- 139 -
APPENDIX A. INPUT FORMATS AND USER INSTRUCTIONS

This appendix is divided into six sections, (1) preprocessor

input formats, (2) sample preprocessor output (simulation input)

(3) simulation input (system specification card) , (4) exogenous

event tape format for explicitly scheduled flights, (5) the airport

data file format, and (6) the current sample airport file.

- 140 -
A. 1 Preprocessor Input Format

The first two cards must always be provided. Card one contains

the times for the beginning and end of the simulation. The hours

run from 0. (midnight) to 23. (11 p.m.) and the number of minutes

past the hour goes to the right of a decimal point (so that 7:45 p.m.

would be 19 . 45)

.

The second card contains the INPUT array. The input variables are

divided into six groups. The user may provide any of these groups

or request that the program supply standard data. Within each of

the six groups all or none of the data must be supplied. The INPUT

array indicates which of the groups is to be read from the user. Each

element of INPUT is a three -character code. If the code is left

blank, the program will read user-supplied data. For information which

varies from airport to airport, the three- letter code associated with

any airport (e.g. JFK, ATL) will cause the program to search its data

tape for data representing that airport. If the tape does not contain

data on the requested airport, an error message will be printed and

the program will stop. For data groups which are independent of

airport any code other than three blanks will provide standard data.

The variables in each group will follow.

Group I - includes data about each type, or class, of aircraft. It is

independent of airport. If INPUT (1) is blank, user must provide one

card for each type (up to 10) with average landing and takeoff speeds,

average takeoff and landing runway occupancy times, and the presence

or absence of distance -measuring equipment. The largest type number

must be placed last, followed by an end-of-file card. The next card

- 141-
contains an average turn-off speed for all types.

Group II - includes percentages of each type of aircraft in the

takeoff and landing mixes. It is airport -dependent. If INPUT (2)

is blank, two cards must be provided: the first with the take-off

mix, the second with the landing mix.

Group III - contains the average numbers of takeoffs and landings

per hour. It is airport -dependent. If INPUT (3) is blank, user must

provide data for every hour to be simulated plus one hour previous

to the beginning, up to a total of 24 hours. The takeoff rates

come first, twelve numbers to a card, on one or two cards as needed, followed by the landing rates.

Group IV - includes three separation distances,

1) distance to the departure/arrival fix.

2) radar separation between airborne landing aircraft

3) radar separation between a landing and a takeoff from the

same runway.

All three distances are in nautical miles. This group is independent of airport. If INPUT (4) is blank, user provides one card with

these three distances.

Group V - includes the description of the runways and the operation

of the airport. If INPUT (5) is blank, the following cards mist

be supplied:

- 142 -
1) number of distinct departure paths from the runways.

2) one card for each runway, up to 9, with its heading, its left/

right designation if it is one of a set of parallels, its

operation code (1, 2, 3, or 4, see later), and the distance

to its outer marker, followed by an end-of-file card.

3) one card for each runway containing the time for each type of

aircraft to fly from handoff to outer marker of that runway,

4) for each intersection, the numbers of the intersecting

runways, the distance, in feet, from the first to the

second, and from second to first, followed by an end-of-file

card.

5) for each pair of runways which are not independent, the numbers

of the runways and the dependence code (1 or 2, see later).

[Note -- this may change from VFR to IFR. Two runways which are

VFR independent may well be IFR dependent.] These are followed

by an end-of-file card.

Group VI -- includes percentages of each type of aircraft using

the runways and departure paths. It is airport -dependent. If

INPUT (6) is blank, one card for each type must be supplied giving

the fraction of total takeoffs of that type using each runway,

and the fraction of total landings of that type using each runway.

[Note: if there are more than six runways, two cards will be needed

for each type.] These are followed by one card for each runway,

giving the fraction of all takeoffs from that runway using each

departure path.

- 143-
Card

No.

Column

Nos. Variable

No. Decimal

Places

FORTRAN

Format

1 1 - 7 TBEG - beginning of

simulation

2 F7.2

8 - 14 TEND - end of simulation 2 F7.2

2 1 - 18 INPUT (1 - 6) , 3 columns

per element

- 6A3

GROUP I

one per

type

1 - 3 number of type ( < 10) 0 13

4 - 6 = 0 if type has DME

> 0 if type does not have

DME

0 13

7 - 13 aver, landing speed (knots) 2 F7.2

14 - 20 aver, takeoff speed (knots) 2 F7.2

21 - 27 aver, runway occupancy

time - landing -(seconds)

2 F7.2

#types + 1

28-34 aver, runway occupancy

time - takeoff - (seconds)

end-of-file

2 F7.2

#types + 2 1 - 7 aver, turn off-speed,

all types

2 F7.2

GROUP II

1 6 per

type

decimal fraction of takeoff mix, of each type

4 12F6.4

2 same dec. frac. of landing mix

of each type,

4 12F6.4

GROUP III

1, 2 6 per

hour

number of planes taking

off per hour

1 12F6.1

3, 4 same # planes landing per

hour

1 12F6.1
Card

No.

Column

Nos. Variable

No. Decimal

Places

Fortran

Format

GROUP IV

1 - 7 distance to departure/

arrival fix

2

F7.2

8 - 14 required separation between landing planes in

air

2 F7.2

15 - 21 required separation

between arrival and

departure

2 F7.2

GROUP V

1 1 - 2 number of departure paths 0 12

one per

runway

1 - 2 number of runways

(1 - 9)

0 12

3 - 6 heading of runway 0 14

7 - 8 left/right designation - A2

9 - 12 operation code: 1- takeoffs

only, 2 -landings only,

3-

both, alternating

4-

both, landings preferred

0 14

#rw +2

13 - 19 distance to outer marker

Cnaut, miles)

end-of-file

2 F7.2

one per

runway

7 per

type

time, in minutes, for

each type to fly from

handoff to outer marker

2 10F7.

one per 1 - 2 first runway number 0 12

intersection

3 - 4 second runway number 0 12

5 - 12 distance from end of

first to intersection

(feet)

0 F8.0

13 - 20 distance from end of se- cond to intersection

(feet)

end-of-file

0 F8.0

- 145 -
Card

No.

Column

Nos. Variable

No. Decimal

Places

Fortran

Format

one per

interference

1 - 2 first runway 0 12

3 - 4 second runway 0 12

5 - 6 interference code:

1 - simultaneous

dep/arr and dep/dep

are permitted, given

divergence, but arr/arr

is prohibited, 2 - all

simultaneous operations

prohibited.

0 12

GROUP VI

end-of-file

one per

type

6 per

runway

decimal fraction of all

takeoffs of type which use

each runway, followed by

decimal fraction of

all landings of type which

use each runway

4 12F6.4

one per

runway

6 per

dep.

path

decimal fraction of all

takeoffs from each runway

going on each path

4 12F6.4

r

- 146-
Sample Data Deck

Note: b is used to indicate a blank

bbb8.00bb20.00

XXXJFKbbbXXXJFKJFK Note: This card indicates that

the user wishes to supply only

Group III, takeoff and landing

rates. There would follow

at most 4 cards.

Group I bblbblbl65 . 00bl75 . 00bb59 . 00bb37 . 00

bb2bblbl35 . 00bl45 . 00bb52 . 00bb34 . 00

bb3bb0bl20 . 00bl30 . 00bb45 . 00bb31 . 00

bb4bb0bll0 . 00bl20 . 00bb38 . 00bb28 . 00

bb5bb0bl05. 00bll5 . 00bb31 . 00bb24 . 00

VbE0F

bb30. 00

Group II

0 . 3000b . 20bbb . 15bbb . 15bbb . 20

b . 35bbb . 25bbb . 15bbb . lObbb . 15

Group III

bbb9 . 0bbb3 . 0bbb2 . 0bbb2 . 0bbb4 . 0bbb2 . 0bbb2 . 0bbb9 . 0bb20 . 0bb23. 0bb25 . 0bb35

.

bb40 . 0bb38 . 0bb46 . 0bb46 . 0bb51 . 0bb42 . 0bbl8 . 0bbl6 . 0bbl6 . 0bbb9 . 0bbb7 . 0bbb9

.

bbl7. ObbbO . 0bbl5 . 0bbb5 . ObbbO . 0bbb5 . 0bbb5 . 0bbb3. 0bbl7 . 0bb29 . 0bb33. 0bb39

.

bb47.0bb37.0bb38.0bb40.0bb51.0bb51 .0bb38.0bbl7.0bbl7.0bbll.0bbll.0bbl6.

Note that the symbol V stands for a multipunch 7 8, The symbol

stands for the letter 0.

0

0

0

0

- 147 -
Group VI

1 . OObbO . ObbbO . ObbbO . Obbbl . OObbO .

0

b.90bb0. ObbbO . lObbO . ObbbO . 50bb0 . 50

b . 75bb0 . ObbbO . 25bb0 . ObbbO . 55bb0 . 45

b . 50bb0 . ObbbO . 50bb0 . ObbbO . 30bb0 . 70

b . 25bb0 . ObbbO . 75bb0 . ObbbO . 05bb0 .95

b . 20bb0 . 65bb0 . 15bb0 .67bb0.05bb0. 28

1 Even though runway two handles no takeoffs , giving these

data does no harm, and makes them available if necessary.

1

- 148 -
Group IV

bbb4 . 00bbb3 . 00bbb2 . 00

Group V

b lbb1 7bbbbb lbbb 8 .

5

b 2bb 2 0Rbbbb 2bb1 1 .

0

b 3bb 2 0 Lbbbb 3bbb 8 .

0

AbE0F

bblO . 25bbl2 . 18bbl4 . 10bbl6 . 67bbl8 . 33

bbb9 . 50bbll . 25bbl3. 20bbl6 . 00bbl7 . 90

bbb9 . 15bbll . 75bbl3. 33bbl5 . 50bbl7 . 40

blb2bbb8500.bbb9000.

bib 3bbb 2275. bbb 5430.

AbE0F

blb2bl 3

blb3bl

b2b3b2

AbE0F

2. Even though these data are not relevant to runway one, they should

be given, and do no harm.

3. Note that interference relates to the physical relationship among

runways, not actual interference, since in this case

operations on the runways preclude such interference.

- 149 -
A. 2 Sample Preprocessor Output (Simulation Input)

1 n n 9 n n n n n G 0 2

2 n 0 P n G n G n n 0 3 3 n n P o G n n o n 0

4 0 0 P 0 0 n n 0 0 0 3

5 n n P n 0 n n o 0 2 9

A n 1 R 3 2 n 0 0 n 0 l n ( i 2 ) 7 3

7 n l R 3 2 G G 0 0 i n ( D 3 .

*4 ) a . o n

p nn

n )

9 . nnGn

p

1 P

3

• nonn

2 n n 0 G 0 1 G ( I 2 ) 2 1 3

9 G 2 P 5 3 3 2 0 OR FO 12(01 .9 )

* l 3 p n • l 7 2n • l 3 p n . 19 3 0 ,1790 • 1 9 30 .1^90 .19^0 , 1590 • 1 790

.2090 • 2550 . 209n

1 n 0 1 P 5 3 0 n 0 0 o 10(12)

1 1 1 n 0

1 1 n 1 p 5 3 o n 0 0 o 10(03. 9 ) 95, nnGn 190. 0000130, 0000 11 1 5 .0000 9 p , 0000

12 0 1 R 5 3 0 0 0 0 0 10(03. 9 ) 55 , 0000193 , 0000190, 0000123.00001 1 0 . 0 0 0 0

1 3 n 1 R 5 3 0 0 0 n 0 10(03. 9 )

• 01 9 0 0 123 0 1 OP .0092 .008 1

1 9 0 1 p 5 3 n n n 0 0 1 0 ( D3 • 9

)

.009 1 .008 3 .0^77 ,0069 • 0058

1 5 G n R n 0 n 0 0 0 0 25.000

1 6 n 0 p 0 0 n o o n 0 9 ,000

1 7 0 0 P 0 0 o 0 0 0 0 3.000

1 8 0 0 R 0 c 0 0 0 0 0 2,000

1 9 n 1 P 3 2 o 0 0 0 0 1 n ( 03 • 9

)

.1297 . 13 3 8 ,19 3 7 2 G 0 2 R 2 1 5 3 0 0 R FO 12(01.9)

.1900 , 7700 .7900 . 93nn \ • on on , 1900 . 7 7nn , 7900 ,9.3001.0000

2 1 0 2 R 5 3 3 2 0 0 R F 0 12(01,9)

.oonni

.

noon i . on On \ ,00001 9 r ono 1 , noon . 9 0 0 0 ,90001 ,nnoo ,9non

.7000 . 7000 1 . OnOO

22 0 2 R 5 3 3 2 0 0 R FO 12(01.9)

.oonni • oonni . noon , n o n n i , 0000 1 • 0000 ’. noon ,9oooi .onno ,nnoo

,oo on • 70001 ,0n0n

23 n 2 R 3 2 3 9 0 0 R FO 12(01,9)

•3300 - 6 7 0 0 1 .0000 • 3 3 n 0 • 6 7 0 0 1 • nooo , 75f)0 • 7500 1 ,0000

29 ?9 1 Z 3 2 n 0 0 o 0

25 0 1 R 3 2 0 0 0 0 0 10(12)

1 2 2 26 n 2 R 3 2 3 2 0 0 P FO 1 2 ( 0 1 , 9 ) ,0000 , QOno , 3 9 B n . 0000 , nooo , 9870 .27601.0730 .0000

27 ?P 2 7 3 2 2 1 0 0 0

29 0 2 R 3 2 n 0 0 0 Or 10(12)

3 3 0 0 n non 0 0

3 0 0 0 0 n o o 0 n 12 10 n 0 n o 0 0

30 0 2 R 3 2 0 n 0 0 Or 10(12)

6 5 H G C non n 0

6 G 0 0 0 0 0 n 0

6 6 5 D 0 non n n

. 2 1 70 . 17^0

• 9noru.onno

• 9onn l • onOn

2

13

2

13

- 150 -
3 l 0 1 R 3 2 0 0 0 0 0 10(03. *4 ) t 0 6 n 3 • 0670 . T 357

32 0 2 R 3

*4 3 *4 0 0 R

, F ° 1 2 ( D 1 .8)

.050n • 0 1 67 . 0 1 67 . 0 1 67 • 0500 0 0 1 67 0 1 6 7 • 0 167 • 0500

33 38 1 7 2*4 5 0 0 0 0 0

39 0 0 R n 0 0 0 0 0 0 8.000

*40 *45 1 Z 3 2 0 0 0 0 0

*46 0 0 R 0 0 0 0 0 0 0 32.000

*47 0 2 R 2 1 28 5 0 0 R

, F ° 1 2 ( D 1 • *4 ) .0909 . 3333 .5000 • 50no . 2500 • 5000 15000 • 0909 . 0500 • 0*4 1 7 • n*40O .0385

. 0 2 5 n . 0278 . 0 1 85 . 0 1 85 .0179 . 0233 . 0526 .0588 • 0588 • 1 1 1 1 • 07M .0909

.52699.9999 .0580 . 20009,9999 . 2000 . 2000 • 3333 . 6667 .0385 .0333 . 0263

.0227 . 0286 . 0270 .0250 . 0 1 96 • 0189 .0278 • 0588 .0588 • 1111 • 1 1 1 1 • 0526

|*4 8 0 o R 0 0 0 0 0 0 0 8

*49 0 2 R 3

*4 3 *4 DOR fo 12(01 .8 ) ,0 3 3 <4 • ooon _ . onOo , oOon .033*4 . 0000 • OOOO .0000 • 033*4

50 50 1 7 2 1 0 0 0 0 0

0 0 0 0 0 0 0 0 0

These cards provide initial values for all system variables

and arrays and permanent entities in the SIMSCRIPT simulation

program. The format required is rigid and may require changing

many cards to make a simple data change. Users interested in

a more complete description of the required formats should

consult SIMSCRIPT; A Simulation Programming Language , pages

115 through 128.

- 151 -
A. 3 Simulation Input - the System Specification Card

Simulation input consists of the tape output by the preprocessor

and one card supplied by the user and called the system specification

card. Its format is as follows:

Column Contains

1 the number 1

6 P, if printing of the initialization

deck is desired

11 - 12 the number 50

17 - 18 the number 60

23 - 24 the number 60

35 - 36 the tape unit the initialization deck is

to be read from; this is unit 8 if the

preprocessor is used

41 - 42 the tape unit used for the exogenous events; this is

unit 8 if the user is not specifying any

explicitly generated flights.

- 152 -
A. 4 Exogenous Event Tape Format for Explicitly Generated Flights

The first record must be for the BEGIN event.

Columns Contain

3 the number 1

6 - 7 the starting hour for the simulation

10 the number 0

12 the number 0

The rest of the records describe explicitly generated flights,

one flight per record.

Columns Contain

3 the number 2

6 - 7 the hour the flight enters the system

9 - 10 the minute of that hour

11 - 12 the second of that minute

13 - 14 1 if flight is a takeoff, 2 if flight

is a landing

15 - 16 the runway to be used by this flight

17 - 18 the aircraft type for this flight

19 - 20 the departure path if this is a takeoff

There should be an end of file after the last flight record.

- 153 -
A. 5 Airport Data Pile Format

In all of the following the number of runways is 9, the

number of aircraft types is 10, the number of departure paths

is 5, and the number of interferences is 10. Data must be

provided as if there were 9 runways, for instance, even though

there might be onlv 2. The other 7 values may be zero. They

are never used but are only place holders to space the data

items properly. The variables referenced here are described

in .Appendix B.

record FORTRAN

number Contents format

1 3 letter airport identifying code A3

2 CTYPE for takeoffs followed in

the same record by CTYPE for

landings

20F6.3

3 - 4 LAMBD for takeoffs for each hour 12F8.6

of the day

5 - 6 LAMBD for landings for each hour 12F8.6

of the day

7 number of actual runways 12

number of actual departure paths 12

operational procedure for each 912

runway

heading code for each runway 912

number of interferences for each 912

runway

- 154 -
record

number Contents

FORTRAN

fomat

8 left/right designator for each 9A2

runway

9 Interference code for each runway 8111

pair (1 if landings on i interfere

with landings on j but not with

takeoffs , and 2 if both landings and takeoffs on one runway interfere with operations

on the other)

10 RPT for each runway and interference 9011

11 TPT for each runway and interference 9011

12 DOM for each runway 9F6.3

13 - 15 FLYOM for each type for each runway

(3 runways per record)

30F4.3

16 - 20 DINT for each pair of runways

(2 runways per record)

18F5.3

21 PRWYT for each type of aircraft

for runways 1 through 3

30F4.2

22 PRWYL - runways 1-3 30F4.2

23 PRWYT - runways 4-6 30F4.2

24 PRWYL - runways 4-6 30F4.2

25 PRWYT - runways 7-9 30F4.2

26 PRWYL - runways 7-9 30F4.2

27 PDFIX for each departure path

for runways 1 through 4

30F4.2

28 PDFIX - runways 5-9 30F4.2

- 155 -
o o o o o o oooooo c c o o o o

a c- o o o

o o o o o

3 O O 3 O C

c a o o o o

o c o

o o o

c o o

o o o c- o o OOOOOO 0 0 0 3 0 0

3 0 3 0 3 0

COO o o o

0 3 0

C 3 3 O O O

0 3 3 0 3 3

3 O O O 3 C

3 3 0 0 3 3

O C O

3 3 3

3 0 3

3" C O

0 3 3 'MOO

O O 3 O O o 0 0 0 0 0 3

0 3 0 0 0 0

0 3 3 0 0 0

O C 0 0 0 3

0 3 0 3 0 3

3 0 3 0 0 0

C 3 O O O C

C O O 3 O

C O O O 3

C lO O- ^ 'O

• X O >0 CM

r'*, O' CM lTI COCO

C 3 3 O Ci

• O C 3 O -orn- o — o —

O 3" N O —

0 3 0 0 —

— CO

7 0 0

— a o c o o o

• • • 3 o O 3 m o 3 o o o o

7 0 0 • • • • — C 3

• • • 3 O O 3

CD O C 3 O O O

<*>0 03 0 0 0

—• C 3 • • • •

COO

0 3 3

3 C O

0 0 3

3 C 3

c o o o o o

3 3 0

O c- 3

c o c 0 3 0

C C O

COO

o o o

o o o

c c> o

O 3

O m

CD O O fM

rn a* rsj ji a o O' o o o c o c

• 0 0 3 0 — O 7 CO — — <*) —

C 7 N m —

.

>0 3 0 0 —

O 3 a o

rsi 3 O O C O 3

3 O O O 3

C 3 3 O O O

0 0-0 3 3 3 0

C — C 3 O- O' C 3 O O* C O

3 0 —

O O C 3 3 O

0 3 0 3 0 0

0 3 —

0 0 0 0 0 3

COCO

0 0 3 3

C — in —

c^ _ — cc —

7 — (*) —•• • o — o —

O O C O O

3 3 O C NCCCNX

• a cc >o cc

iTI iTi o m

o cc n c

c a: <-> x

O' in co lT c c <*> o

3 3 0 0

O O C 3 3 o a

o o a o o a o

0 0 0 0 0 0 3

3 O 3 O O O C

3 3 3 O C O O

• • • 3 3 3 3

C- 3 O • • • • cco

O O 3 C 3 C O

• • • O O O 3

O O C O C C C C 3 O • • • • 3 0 0

• • • O' O 0 3

O O O O O O G 3 3 C C CCC COO • • • •

in c o o c c«

lD O O CD CL O O' M O O O O O O

3 C C

3 0 0

3 0 0

3 0 0

o o O o o o

O O o o

3 3

3 O

COCO

3 0 3 0

3 3 3

3 0 0

O 3 G

a o c C C Cl

r- c

c c c coo

c c c C O Cl

o o

c c- c 3 o o

u u

c o

C C 3 3

0 3 0 0

O O O O

cr^ — in —

— — CO —

O' 7 — <*> —

• 3 — O —

0 0 3 0

O' o c a

(C C CO N

• D CO O CC

if J1 >C J1

in coco

O O' Lfl 0 3 0

0 0 3

0 0 3

a C 3 3 O O O

O O O 3 3 O O

0 0 0 3 0 0 0

0 3 0 0 0

O O O O O

C O Cl O O

o o o c o o

o c O O O C C C L C- C

C O C C C C 3

C O C C C Cl c

>C 3- Q INj O C c. 0 3 0 —

rn fM C CM O O' o o

O O O' O Cl O 3 O 00000003

C C C CO c o c a o o o o o o o

C O' 3 O' C CCO G C C 0 3 0 0 0

C C O C O' O' C 3

O O' 000030

G C- C C 3 C O G

O O O' O O' 3 O 3

cccccccc 300000 C'O

&• pH <

\D<

c c c c c 0 3 0 0 GOCOCCCC 3 CM G

C C S C fM C‘

• in 3 CM c

3 3 C 3 3 3

3 0 0 3 0

C C rr O O' <*l • c m o cr 3 CM O — —

CJ C C O C C

• O 3 0 0

3 O' O' >C 3

c o O' c m — o — c O CM c o 3

C C- C C 3

o o in c o o

C Cl CD O lT 0 0—3 CM iT

• in o cm o — cc

o o in cr cr c

• 3 cc a c — in cm o

in O O O

3 • • • C

O^ o c co c

• coco m cc O' "D 3

n N ^ CC' o <*) CM O' CM c

r> <*> 3 O' 3

0 3 3 3

3 O' 3 O' r^ —

O' O lT- >0 CM — O CM CM CM r^- • c c< in c

aoo — coooao

O O C C CM o C C 3 O Cl 0 3 0 0 • • • C C O O

c o c c rvj o o • • • • aoo • O' o o COO — 300000 o o o •••coco OOCOO'OOOOOO

3 0 0 0 ^00 • • • • O C O 3 — O C

C C C o C c Cl c

O' O'OOOO 30

o o c c c c c c O'O'OOOOCO

3 0 0 0

3 o C C

in o

r- o

3 0 0 0 3 — —

CM C' O O G CI 3 OC- 1^000330 0 3

o o o o o

3 0 0 0 0

0 0— 0 0 • C» o • • • O O O Cl o o Cl o O Cl C O c* ococoooooooooo oo COCOCC'OO • • • • • ••

o c c o c c c c c c c c c 0300000000 0 0000033

0-3 0 Ci o O O Cl o o o o • • • • • • CCO • • • *03 0 00

0 3 C« C o c •• • • *000003 CCO CO Cl oooooo 0 0 030 0 0 00000 • • • • • • O CO O • • *0 0 0 00

ooc. OO Cl ooc. OCOCC OOCCI aoo • • • • *0 30000 300 0 3 0 •••••• CCO ***00000 O CCO Cl OOOOOO Cl OOC Cl CO 0300300 C- 300 3 3 0 0 0 0 0

COC. c o o c • • • • •• • • • •• 73000000000000

3 O C O Cl O O C O Cl c 3 O COOOCMOOC 0330

C C O C 7 c o

O O O CD — C o o o — • • • C CM O C 7 o O

CM 3 C O iTO 3

o in o O O' o

• O O

O O c< Cl o o OOOO'CCOOO

c*> O m o o o O Cl o o

3 Cl

— m in o — c

0 3 0 O' <*) C O O cn

• O 1^ C o o COOO— CO —

O Cl o o o c- o o oooooo oo

ooocooooc r^o

• • •OOOOOO >03

ccc c o o o o o

o o >c C a O

c o cm o

c o in O' cm c

i/l O CM O

3 0 0 0 a o o o

o o m a

• O ro C

Cl CM c

in o cm a • • • C

0 0 0 3

• O O O

o o o

Cl o C in — o- 3 CM O O

C C Cl ooc o o m o

c o a ci C C — c

• in o cm

C o

o

>0 a

o— 3

0 0 0 3 0 —

>0 3 O O 3 rn o ci in* ai cc c*

• 3 cc CD o — m cm o

in o o o

O C o o 0 0 3 0

0 — 0 • C 0 0 0 3 —

C- O

O 3 CM 00030 OOOOOO oo O' oooooo n c k • o o in o

O' O O O Cl o

• C O O C m cd O' >c <*> m n O' co O rn fM O- CM CM

O' o o O' o

o o o o m o o o o OO'OO'f^ —

7 O in >0 fM

lfl £h N CM N n

0 3 O C O

Cl C O CM — 3 0 c

O G C — 7 C

o o

o o o o

0 0 3 *n lfl o

incoocccc- — 3 0 0 0 0 3 O

cccccccc cooooooa • 7

O CM 3

O' >c

CC— in

CM — O C O O O

• C C O 3 —

7 ro o O

— 7 3 • CM — O

03000030 OOCOOOCi 3

3 3 Cl Cl C —

— 3 0 0 0

cc 3 o

O m G 3

CM — O • 3 0 0 0

Cl C 3 C OOOOGCOOCC'OO

o o o 0 0 3 0

3 C 3 O

003 0 0030 0330 CO— 3

C C C Cl C C O c 0300300 C' COCO

7 CM 7 CM O

o in m o

7 0 3 0 0' 0 3 0 • — 3 O O CD m aoo

3 0 0 3

3 CM cn o

CM C Cl C

0 7— • C in CM CD

— rr >c cc — o c*

_J CM <*> C • • •

Cl c- o COOO

3 0 0 0

C' O C- CI coo* CM CM CM rn o n eg -

o cm <i a c in — o

o <*> in o coo* COOO'

o o o 0 0 3 0

I O fM — C o **> — o

3 — >C • C cn cc id n >c

c c c OCOOCOOO

C Cl Cl O C 3 3 3

• • *0 0 0 3 3

ccc • • • • • aoo 03000000 • • • C O 3 Cl Cl OC Cl C 0303 ooc***** 0 0 3

• • *oooco Cl O O C O' O 3 3

O O O O O O 3 o ccc*****

O'Dec 0030 0300 OCOO mc^cooooo

— — c. o>comoc3C'

rsi CM C 7 c o o o

• • • cn o o o 3 — — o • •• ••

n er o

CM CM O O O' OOO • • • O >C O 3 O

7 7 O Cl o o o — — ••••• fM CM O —

• • *07000 rvf^oooocio ooooinocio CMCMO*****

ccc.cc

o o o o o

C 3 C O C 0 3 0 0 31 3 C> O 3

Ci 3

o o

OOC

3 0 3

3' 3 Cl 0 3 0

O Cl CI o o c

in — c — mo

c C 3 coo

cco coo

o c o OOO

Cl c o C'CO

OOO OOO

3- O O OOO

3 3- o o coo

O C 3

0 3 3 coo
APPENDIX B. MODEL ELEMENTS (ROUTINES, VARIABLES, ETC.)

This appendix is divided into two sections. The first lists each

of the routines , events and functions , and provides a phrase describing

what each does. The second section lists the names and descriptions

of variables used in the model. The variables are listed under the

headings of entities , arrays , attributes of event notices , temporary

entities, attributes of temporary entities, and sets. The reader should

refer to Section 3.1 for the definitions of these terms.

B.l Routines

Exogenous Events

1. BEGIN - starts the simulation

2. EXGEN - creates explicitly generated flights

Endogenous Events

1. GEN - creates flights in a Poisson manner

2. NXTOP - finds the next operation (landing or takeoff)

for a runway

3. LAND - creates tieups resulting from a landing

4. TOFF - creates tieups resulting from a takeoff

5. FTIUP - destroys tieups no longer in force

6. ENDS - prints final output

7. CHOUR - updates current hour

8. PRINT - records delay and throughput

Functions

1. PTYPE - picks an aircraft type

2. PRWAY - picks a runway

- 157-
3. PDFIX - picks a departure path

4. FREER - finds the first time the current operation can

proceed

B # 2 Variables

Entities

1. 0 - operation (1) takeoff, (2) landing

2. RW - runway

3. TYP - aircraft type

4. FIX - departure path

5. H - hour

Variables and Arrays

1. LAMBD(O) - Poisson distribution parameter, the average

time (in hours) between operations

2. OPER(RW) - operational procedure

(1) takeoffs only

(2) landings only

(3) dual use, alternate operations

(4) dual use, landings take precedence

3. DOM(RW) - distance from the outer marker to the runway

threshold

4. NPT(RW) - greater than zero if the runway RW interferes

with others

5. FLYOM(TYP) - time to fly from handoff to the outer marker

6. DME (TYP) - (0) no DME

(1) has DME

7. VLAND(TYP) - landing speed

8. VTOFF (TYP) - liftoff speed

9. ROTL(TYP) - runway occupancy time on landing

- 158 -
10. ROTT (TYP) - runways occupancy tune on takeoff

11. VTAXI - turnoff speed for landings

12. DAFIX - distance from departure/arrival fix to the

runway threshold

13. SEPTL - distance which must separate a landing possessing

DME from a preceding takeoff

14. SEPLL - required inter landing separation

15. CALIN - minimum time between the generation of a takeoff

and clearance to leave its gate

16. CTYPE (0, TYPE) - cumulative distribution of aircraft mix

17. CRWYT(RW, TYP) - cumulative distribution of runway use

for takeoff

18. CRWYL(RW,TYP) - cumulative distribution of runway use

for landing

19. CDFIX(RW, FIX) - cumulative distribution of departure paths

20. NEXT(RW) - next type of operation on runway RW. If

NEXT is zero, the next operation has not been scheduled

21. LAST(RW) - the latest operation on RW

22. DINT(RW^, RWj) - distance from the end of RW^ to its

intersection with RW.

23. TPT (RW , NTPT(RW)) - type of tieup on RW caused by an

operation on another runway (see RPT for which other

runway)

:

(1) to maintain interlanding separation

(2) to maintain a landing separated from a preceding

departure

(3) to maintain a departure separated from a following

landing

(4) to maintain departure separation between completely

dependent runways

(5) to maintain departure separation on semi -dependent

runways

(6) to maintain separation on intersecting runways

- 159 -
24. RPT(RW, NRPT(RW1) - runway tied up as a result

of an operation on RW, Note that RPT and TFT

together describe the interference between runways;

RPT tells which runway is interfered with and

TPT tells how,

25. TDMIN(RW) - minimum time between a takeoff’s

leaving its gate and starting its roll

26. SEPTT(TIXpFDf.) - required separation time between a departure bound on path FIX^ and one departing the

same runway bound on path FIX^

27. SEP2(FIX^, FIX..) - required separation time between

an aircraft departing on path FIX^ from one runway and one

departing on FIX^ from a different runway where the two

runways are semi -dependent

28. IHOUR - current hour

29. NARR(H) - number of landings generated

30. NDEP(H) - number of takeoffs generated

31. NLAND(EI) - number of landings performed

32. NTOFF(H) - number of takeoffs performed

33. DELT(H) - total takeoff delay

34. DELL(H) - total landing delay

35. TBEG - time the accounting for delay starts

36. TEND - time the simulation ends

37. GENN(O) - the identity of the GEN currently scheduled for

operation 0

Attributes of Event Notices

1. RWAY - runway

2 . OP - operation

- 160 -
3, PT - point tied up

(1) outer marker

(2) runway threshold

(3) end of the runway

4. DLAY - delay for the current flight

Temporary Entities

1. FLT - flight

2. TIEUP

Attributes of Temporary Entities

1. TYPE (FLT) - aircraft type

2. DFIX(FLT) - departure path

3. TIN (FLT) - first time FLT can cross outer marker or

leave its gate

4. TMIN (TIEUP) - beginning of tieup interval

5. TMAX (TIEUP) - end of tieup interval

Sets

1. Q(RW,0) - landing and takeoff queues

2. CMTI (RW) - tieups in force at the outer marker

3. THTI(RW) - tieups in force at the runway threshold

4. ERTI(RW) - tieups in force at the end of the runway

- 16 i-
APPENDIX C

LISTING OF THE PREPROCESSOR PROGRAM

- 162 -
this Program i g a prf. processor w m I c h reads in the data and

PUTS It into proper FORM for USE by the SIMULATION PROGRAM.

PARAmETFR KR!Vs9,KTYP=10,KFIX 3 5.K0s2*KTPT«10

integer OPER(KR'V) ,DMF(KTYP) ,RPT(KRW,KTPT) .TPT(KRW.kTPT)

PF.AL L»Mao(KO.?'l)

0 l M E N 5 I ° N D 0 m ( K R W ) ,NPT (KRW) ,FlYOMIKTYP,KRW) ,VLAND(KTYP) .ROTL(w'TYP)

|.VTOFF(KTyP)',ROTT(KTYP).PTYpE(KO,KTYP).pRWYT(<TYP.KR«V) 1 LAST(KR/M..

?PR«.VYL ( KTYP ,KR V) ,POF I X ( KRW ,KF I X ) ,DI N T (KRVl/.KRW) , INPUT ( M , T D M I N I K » A ) . 3SfP2{Kf!X,^FTX) , S E P T T (KFIX.KFIX) . INTER (KR w ,KRW) , C A L I N ( K R W ) • N ( A 0 ) , R i m e A P ( v R l*J ) » I L R ( K R W )

1 Nr 7

C

cc

c 70S

son

l

?

c

cc

c

c

c

c

cc

cc

c 730

cc

cc

c

c

cc

c

c

TREG.TFND ARF TIMFS of PEGINNING and end OP SIMULATION

EXAMPLES aRE O.nO FOR mIDNIG h T and 17. 30 FOR S . 3 0 P*M,

READ(S,705)TREG.TEND

format

(

1 o F 7

.

7 )

uV R I T F ( A , S 0 o ) T R F G * T F M n ,

. . FORMaTmITHIS SIMULATION R h N 5 F R 0 M « F 6 . 2 , • T0»Fa.2///)

T nrG = ATNT(TBFG)-f(TBFG-AltJT (TRfG) )/fO,

TEND*AiNT(TEN 0 )4(TEND-AINT f TEND))/60.

IF (TBFG.GT.n.) GO TO 1 TRFG=TrFG+2B.

TFND=TEND+2a.

IF ( TEND «LE • TRFG ) T E N n * T E

N

n

2 R

•

IRFG=TbEG-I

.

!MOUR»MOD( I R F G , 2 *M 1 NHsTEN 0-TREG>.99

N y a - 1

I r (NH.LT.2R) GO TO 2

T l = 1 J J = 2*4 GO TO 4

I I s I H 0 U R lEND= T ENn-#0)

J J * M 0 D < I E N D 1 IF ( J J . L T . I I ) N 0 * J J

INPUT* I) - LEAV/F RLAMK IF tTH DATA GROUP WILL BE SUPPLIED BY USER

ANYTHING ELSE WILL CAUSE PROGRAM TO SUPPLY STANDARD

DATA. FOR GROUPS 2.3.S.6 SFT INPUT EQUAL TO A I R P 0 R r ID

DATA GROUPS ARE - 1) NUMBER AND DESCRIPTION OF AIRCRAFT TYPES

2) mix of Aircraft types

3) LANDING AND TAKEOFF RATES, BY HOijR

M ) SEPARATION REQUIREMENTS

5) DESCRIPTION OF AIRPORT aNo ITS OPERATION

6 ) FRACTION OF TYPES USING EACH RUNWAY AND

DEPARTURE PATH

RFAD(5,73 0> INPUT

FORMAT ( 6 A 3 )

NJTyPE - NtJ M R E R OF TYPES

OME(I) - SET TO 1 if TYPF T Has distance measuring equipment

v t o e f ( t ) - takeoff speed of type i» in knots

V L A N 0 ( I ) - LANDING SPEED OF Type I . IN KNOTS

R 0 T L ( I i - R i j N w A Y OCCUPANCY TIME ON LANDINGS FOR T yPE I, IN SECONDS

ROTT(I) - Same FOR TAKEOFFs

v t

a

x

i

- average turnoff speed for all types

AND TO 0 IE NOT - 163 -
IF(INPuT(|),EO.» • ) G 0 TO 5

D ATA NtyP Ei VLAND.VT0FF.R0TL|R0TT,VTAXJ*pME/5.1‘45.^1<40.,130..1i5.,

1 98. ,5*0. • l 55. , 198, , mm • 1 23. # 11 0 # I 5*0. , .pi 9 , • 01 23 . . Q l Oft • .00*2 . . 2.0081 .5*0. ..0091 ,.OO83,.O077».OOM,.OO5fl t 5*O.,25,.3*l'. 7*0/

GO TO 10

5 REaD(5,725*END*6). NTYPE»DME(NTYPE) .VLAND(NTYPE) ,VTOFF(NtYPE) ,

1 R'OTL(NTYPE),ROTT(NTYPE)

725 FORMAT { 2 I 3 # 9F7 • 2 > GO TO 5

6 read ( 5 ,705 ) v taxi

DO 7 III ,nTYPF

ROTL( I ) » R 0 T L ( I ) / 3 6 0 0 • 7 ROTT ( I ) =R0TT ( n / 3 A 0 0

PTYPFtl.I) - THF FRACTION OF TOTAL TAKF0FF5 WHICH ARE OF TyPE I p T Y P E ( 2 , I 1 - SAME FOR LANDINGS

in IF(INPUT(2).E0.* • ) G 0 TO 1 5

REWIND IN

11 REaD(1n,600.END*300)I

600 F09MaT { A 3

)

I F ( I .NE . I nPuT ( 2 ) ) GO TO 11

R F A D ( I N , 6 0 5 ) ( (P T Y P E { I , J ) , J * 1 , K T Y P ) •

! * 1 * K ft ) 605 FORMAT ( 20F6 . 3

)

GO TO 30

15 DO 16 1*1,2

R F A D ( 5 « 7 1 0 ) (PTYPEI I , J ) .J*iTnTyPE)

7 1 0 FORMAT ( 1 2F* . q

)

16 CONTINUE

no 25 1*1,2

n 0 20 J*2,NTYPE

20 PTyPE ( I , J ) *PTYPE ( I • J- 1) +PTYPE ( I , J

)

IF ( I N T f ( P T Y P

p ( j ,NTYPF)*#Ol ) • l 0 0 • ) • N E • 100)WRITE (6,900) I

ft 0 0 EORMATf* WARNING - PROBABILITIES of all types for OPERATION*, t2,

1* (1-LANDING, 2-TAKEOFF) DO NOT SUM TO ONE*)

25 CONTINUE

LAMBD(l.I) - AVERAGE NUMBER OF TAKEOFFS DURING ITh HOUR OF THE DAY

LAHB0(2 f I) - SAME FOR LANDINGS

30 I F ( I NPUT { 3 ) . FO .

* »)G0 TO 35

IF ( INPUT <3) . EQ • INPUT (2) )G0 TO 32

REWIND in

31 READ(lN,600^END*300)I

I F ( I • N E • INPUT { 3 ) ) GO TO 3 1 read ( I n , 6 o o ) i 32 do 3 3 1*1, K 0

R F A D ( IN, 610) (l A M B D ( I ,J) ,J«1 ,2ft)

33 CONTINUE

6 1 0 FORMAT ( 1 2FB . 6 ) GO TO MO

35 IF(ND*GT.O)GO TO 37

00361*1,2

RFAD(5,720) (LAMRDI I ,J) ,J*I I . U J,) 720 FORMAT ( 1 2F6 . l ) DO 36 J* 1 , 2q

IF(LaMr 0(I,J),LE»0.)G0 TO 35l

LAMBD< I . J ) * 1 ./lambdi I .J)

GO TO 36

35 1 L AMBD ( I , J )*9.999

36 continue -164-

G0 TO 90
37 00 3 8 ! s | , 2 R E A D ( 5 , 7 2 H ) ( L A M R 0 ( I , J ) ,J«IHnU W| ?q) , ( L A M R 0 ( I ,J) , j • i , n D ) 0 0 3 8 .1*1 ,28

1 F .( L A M R n ( ! , J ) . L. F.n.JGO TO 3 7 1 LAMRrW I , J ) * 1 ./LAMRO( I,J)

GO TO 38

371 L& m BO( I

, J

)

0, 099

38 COMTlNuF

o a f I x - distance of dep/arr Fix from runway

SFPLl. - p A o A r? S r P ^ T I 0 N REQUIRED P E T W £ E N AIRCRAFT ON SAME PATH

SFPTl. - PaDap SEPARATION REQUipfo 8ETWFEN a LANDING A/ C AND aM A/C

taking off from thf runway

Alt THpFE DISTANCES ART IN NAUTICAL MILES.

80 I F ( I NPlJT ( 8 > . FQ ,

• • ) GO TO 85

OAF I X = 8 . S F P T L * 2 . S E P L L 3 . GO TO 50

85 REAn(5,7PS)0AFIX,SEPLL,SEPTL

NF I X - NUMBER OF FlXFS

I H F A 0 ( I ) - THp HFADING OF RUNwaY I It.R(J) - FOR PARALLEL RUNWAYS, THE LEFT OR RIGHT DESIGNATION

for example, if Runway ? is 3 ir, i h e a n < ? ) • 3 l and t l r ( 2 i * R opfp(I) - opfration r o n r for runway i C 0 n f s A R F 1- TAKEOFFS ONLY, ? - LANDINGS ONLY

3 - 0 U A L IJ S E , ALTERNATING OPERATIONS

8-DUAL use. landings take precedence

DON ( I ) . DISTANCE to OUTER mApkfR for runway I F L Y 0 M ( T , J ) - TIME, IN M I N U T f S » FOR A TYPE I A/C TO F L Y FROM H A N D 0 F F TO OI.ITFR MARKER OF RUNWAY J

DINT(I*J) - r I STANCE F^OM END OF RUNWAY I TO ITS INTERSECT I 0 n WITH RUNWAY J, IN FEET

INTFR(T,J) - INTERFERENCE rO^p FOR RUNWAYS I AND J

C ° D E S ARE 1- LANDINGS ON I AND J INTERFERE AND

most be separated, rut simultaneous

TAKFOFFS ARF PERMITTED if they DlvFRGE.

2 - N 0 SIMULTANEOUS OPERATIONS PERMUTED

IF NEITHER, CnNPLETE INDEPENDENCE IS ASSUMFD.

50 IF ( I N P 1 J T (5) • E Q •

* • ) G 0 TO 5 5

I F ( I^PUT (5) • F Q . INPUT ( 3) )GO_TO S 8

lF(lNPuT(5).F0*INPUT(2).ANn.lNPUT(3),E0.* »)G0 TO 5?

RrwlnD hi

5 1 R E A D f I M . A n 0

* F N 0 * 3 0 0 ) I IF ( I , Nr, lN p UT (5) ) G 0 TO 51

RFiDf I M , A 0 0 ) T 52 DO 53 J*1

RE AD ( I N , AQO ) I 53 CONTINUE

58 READ! In.M5)NRW.NFJX,0PFR,IHEaD,NPT

A 1 5 FORM A T , A6 I 2 ) READ! I N , A 2 0 ) TLR

620 FORMAT ( J OA 2

)

READ! I M , A 2 5 ) J M T F R

R E A D ( I N , 6 2 5 ) R P T

R E A D ( In,A25)TPT

625 FORMAT (13211)

- 165 -
READ(lN,A05>PnM

READ ( I N , 6 3 Q ) ((FLY0M(J,I),J*1.KTYP)»J*1,KRW)

A30 FORMAT | READ < T N , 6 3 5 ) ((D!NT(!,J),J*1,KRW),I*1,KBW)

635 FORMAT ( 1 8 FS , 3 ) GO TO 1

1

n 55 RF AD { 5 ,700 INFIX

N R W * 0

55 1 RFAD(5~735»FNn=55?) 1 , J HEAD ( ! > • I L R ( I) *OPER f I ) , DOM ( I)

7 3

r

) FORMAT ( I2»I <4,A?,lH*F7*2)

WRiWsMR m + 1 GO TO 5 5 1 552D056-I*1.Nrw

RFAD(5,705> ( F I. Y 0 M ( J , l

) , J * 1 ,

NJ T Y P E ) DO 5 6 J 1 , N P »* D I Tvl T ( I , J ) * 0 . 56 CONTINUE

57 PEAD(5,71G*Fmd = 571 ) I , J , D I NT ( I

, J ) , D I N T ( J , I ) 715 FORMAT (2T7»?r«,0)

GO TO 57

571 READ(5,700.EK'D*572) I , J , INTfR( I , J ) 700 FORMAT f ! 0 I 2 ) GO TO 571

5 7 7 DO 5 9 I s 1 , N

R -.»j DO 5ft Js 1 , NT YPF

5 8 flyOM(j,I)=FLYOM(j % I)/AO.

0 0 5 9 j « 1 , N R W

59 d!NT(I,J)*D!NT(I > J)/A076*

DO 6 0 I * 1 , N R

W

DO 6 n J a 1 , N R w

IF ( I N T F R ( I ,J) .FQ*0)G0 TO 6 r> TNTFR(J,I)*INTFR(I, J)

60 CONTINUE

no 9o i*i , nr

w

Ksfl

no 8 0 J * 1 , N R w

1 F { I NTpR ( I , J ) . FO . 0 1 GO TO 80

IF (OPER( I ) *LT.7,0R.0PER( J) .LT.2J60 TO 65

K = K + t RPT ( I . K ) *

J

TPT( I iK)sl

65 I F ( 0 P E R ( I ) » F Q • 2 • 0;|R * 0 P F P ( J 1 • E Q • 2 ) G 0 TO 70

KsK+1

RPT ( I » K ) *

J

TPT( I t < ) » *4

I F ( I N T p R ( j *J).EQ,1)TPT(I ,K)*5

7 n IF(INTfR(I.J).E0*1)G0 TO 80

IF(0PER(I)*FQ.?.0R.0PER(J).EQ.1)G0 TO 75

KiKM

RPT ( I . K ) a

J

TPT ( J * K ) *3

75 IF(OPER(l)fF0.1.OR.0PFR(J).EQ#2)60 TO 80

K = K 1 RPT ( I i <) a

J

TPT ( I »<)»2 - 166- BO CONTINUE
no 85 J 1 , N R v IF ( D I N T ( I *J) . I F • 0 . ) GO TO 8 5

K = K 1 RPT ( I »K ) «

J

TPf ( I » K ) »

A

85 CONTiNijf

NPT ( I

) bK

K = K 1 HO 8 A L»K,10

RPT ( I i I. ) a Q

TPT ( ! » L ) =0

8A CONTINUE

9Q continue

p R W Y T ( I , J ) - T H F FRACTION OF ALL TAKEOFFS OF TYPE I A/C

which use runway j

P R W Y L ( I , J ) - THE SAME FOR LANDINGS

p

o

f i x (

i

t j ) - the fraction of all takeoffs from runway i WHICH ARE GOING TO DEPARTURE FIX J

1 10 I F { I NPtJT ( 6 ) . FQ .

* * ) G 0 TO llS

IF(INPUT(6).E0.INPUT(5))60 TO \ J M2

I r ( INPiiT ( A) • E 0 • INPijt { 3) • A N n , INPUT (S) • E Q •

*

) G 0 TO 118

_IF(INPuT(A)tF0.!NPuT(2).AN0.lNPuT<3).E0 #

* *.AND.lNPllT(5).Fo',

1 * • ) G 0 TO 112

REWIND IN

111 PEAO(lN,600*ENDs300)I

IF(I.Ne.INPUT(A))GO to 111

RF AO ( I N , A 0 0 ) I 11? DO 113 J* 1 , 8 R E A 0 ( I m , 6 n 0 ) I 113 C 0 N T I N ij E 118 00 1181 Jrl ,18

READ! I N , 6 0 0 ) I 1181 continue

1 M 2 DO 1 1 rA I I 1 , K R W , 3

J J= I I

2

R E A D ( I N , A 8 0 ) ( (PRWYTI I , J ) .1*1 .10) , J * I I , J J ) R E A 0 { IN.A80) (

( P R W Y L ( I , J ) .1*1 » 10) , J« I I ,JJ)

1183 CONTINUE

READ ( I N , A 9 0 ) (<PDFIX(!,J),J=1,KFIX),!*1^8)

READ (IN.A^O) (

( Pdf I X ( ! , J ) , J* 1 ,KF I X ) ,

J «5 ,KRW

)

A 8 0 FORMAT ( 3 0 F 9

.

2 ) GO TO 185

115 DO 120 J*1»NTYPE

120 R E A D ( 5 j 7 1 0 ) (PRWYT(j,I ) .1*1 , N R W ) ,

( P R W Y L C J • ! ) . I 1 ,NRW)

0 0 1 2 l I = 1 . N R W

READ(5*710) ( p DFTX( I , J ) , J * l , N F I X ) 121 CONTINUE

DO 122 I = 1 . M R

W

DO 122 Jal.NTYPF

!F(PRWyT(J»I).GT. o. .AND. 0 PfR(I)*EQ.?)WRITEU, 830)J,I

830 FORMAT ( • WARNING - THERE IS A POSITIVE PROBABILITY THAT A T Y P r * . 112, • aircraft will take off From / 1 2X ,* runway *, I 2 , * . which handles

2 landings only*)

IF(PRAYL(J»I).GT.0..AND.0PER<I).EQ.i)WRITE<A,A80)J,I

880 FORMATi* WARNING - T H E * E IS A POSITIVE PROBABILITY THAT A TYPE*.

ii2,* aircraft will land on •/ i

?

x ,» runway ». 1 2 ,* , which handles takf

?offs only • ) 122 CONTINUE - 167 -
no 12 0 Ja 1 • N R W

DO 123 J«2,NF1X

123 Pdf I X ( T , J

) *PDF T X ( I . J- 1) PDF I X ( I , J

)

IF(lNTf(PDF!X(!,NFIX M.Oi)*lOO.).NE,inn)WRlTEC6,ft50>I

flsn format f * warning - probabilities of Takeoffs from runway*, i 2

,

1* GOlNr, TO all FIXES DO NOT SUM TO ONE*)

12 0 continue

I F ( N R W . E 0 . I ) G 0 TO 139

DO 130 I«1,NTYPE

DO 125 J«2»NRW

PRWYL( T , J ) *PRW YL ( I ,J-1 ) P R W Y L ( I , J )

1 ?S PRWYT ( I , J ) * D R W Y T ( I . J - 1

) PRWYT ( J # J ) IF(INT((PRWYL(!.NRW )+.01)*l00.).NE.100)WRlTE(A,Rl0)I

810 FORMATf* warning - PROBABILITIES OF A TYPE*, 12, • AIRCRAFT landing

ION all runways nO MOT sum to one*)

IF ( InT ( {PRWYT ( I ,NRw )^,01)*ln0.).NE#in0)WRlTE(^P20)I

P2n FORMATft warning - PROBABILITIES OF A TYPE*, 12,* AIRCRAFT T A K T N G

i o f f from all runways do not Sum to one*)

130 CONTINUE

10b DO ISO I a 1 ,60

150 N ( I ) » I D 0 9 S T « l , N R w TdmIN( I ) * ( D 0 M ( I ) / V L A N 0 ( 1 ) ) *PT YPE ( 2 • 1 ) no 95 J«2,NTYPE

93 TDMlN(I) S{ D0M ( I)/VLAND(J))*fPTYPE(?,J)-PTYPE(2;j-i))4TDMlN(I)

D 0 1 0 0 I = 1 , N R W

C A L I N ( T )»fLYOM(i ,1 ) • P T Y P E ( 2 , 1 ) DO 100 J=2iNTyPF

too C4LIN(n»rLY0M(T,J).(PTYPE(2,J)-PTYPE(?,J-!)i+CALtN(n

DO 105 I a 1 , NRW

L AST ( I) =2

IF(0PEr(I),E 0.1 ) L AST ( I ) 1 105 CONTINUE

139 DO MO I « 1 , N F I X DO MO j s 1 , NF I X SEPTT ( j ,J)s,0lA7

I E ( I . Eo . J ) SEPTT ( I , J ) a . Q5

S F P 2 ( I ,J)rO,

IF( I ,Eq.J)SEP?( I , J ) a , o 3 3 0

MO CONTINUE

L «0

Mag

'«R!TF(m,900)N( I ) WRITf<M,900)N(2)

WRITe(m,900)N(3)

WRITf(*, 900)NM)

WRITF(M,900)N(S)

WRlTE(M,920)N(6)

WRtTE<M,930)N(7)

WRlTr(M t 920)N(8)

DO I S 5 Mi, NRW

N ( 2 ) NRW

NT YPE

NF I X N ( 20 ) NRW,N { 2 ),, OPER ( I ). MJ ~ NRW ) NRW,n(2) , (dOM{ I ) , I a i ,NRW)

NRW.NI2) , (NPT( I ) , I a 1 ,NRW)

I P ( NP T ( 1 )*EQ.n)NPT( I Ml

1 5S CONTI NUE

WRITE(h,90O)M(9).NTYPE,N(3),N-R W ,N(2),((FLYOM(j,I)

1 J* 1 , NT YPE ) WRITE(M,920)N(!0),NTYPE,N(.i),(DME(I),Ia|*NTYPE)

LVRlTE(M,930)N(ll),NTYPE,N(3)i(VLAND(I) 1 MllNTYPE)

WR I TE ( m , 930 ) N ( 1 2 ) ,nTyPE ,N

(

3 ) , ( vTOFF ( I ) # I a j ,NT YPE

)

W R I T E ( m , 9 3 0 ) N ( 13) , N T Y P E , N (** ) , ( R 0 T L ( I ) ,Ial j N T Y PE ) WRlTE(M t 930)N(M),NTYPE,N(3),(R0TT(I),Ml,NTYPE)

I a N R W ) ,

- 168 -
W R I T F ( H , 9 1 0 ) N ( ! 5 ) , V T A X I

•JVR I TE i M ,9 1 o ) N ( 16) .DAFIX

WR I TE ( M , 9 1 0 ) N ( 1 7 ) * SFPLL

WRtTFlM,9lO)N(18),5EPTL

w R ! Tr ( M , 930 ) N < l o ) , mpw , N ( 2 ) ! ( C A|_ I N ( I ) , ! a 1 . NRW ) iJVRlTF(M,990)N(20> , N ( 7 ) ,N ( 1 ) ,NtyPE,N(3)^ ( ( PT YPE ( I , J ) . J« 1 . NT YPF 1 .

1 ! * 1 . 7 ) , WRITF(m,990)N( 7 \ > , N T Y P E , N < 3 ) iNRW.Nl 2) , ( ( P R W Y T ( I , J ) , J « 1 .NRW) ,

1 T s 1 , N T Y P E ) lVR|TE<M # 9qO)N|(??>,NTYPF,N<3)#NRW,NC2).(<PRWYL(!tJ».J*I.NRW).

I I a 1 • N T Y P E ) W R I T E ( M , 9 9 0 ) M

2 3 ) , N R W , N ( 2 ) , N F I X , N ( 9) , ( ( P D F 1 X ( I . J ) . J 1 , N F I X ) *

\ tat « N R A ) WRITE(M,9S0)N(2'4).N(29),N(1 ) » N R W , N ( 7 ) WR!TE(m,9?0)N(?5),NRW # N(2),(1-aST(1)|I = 1.nRW)

« R I T E ( M , 9 9 0 ) M ( 7 6 ) , N P W . N ( 2 ) , N R W , N < 2 ) ,

( ( D 1 N T ( I , J ) , J « 1 .NRW) .1 = 1 ,mR*I

W R I T E < M . 9 5 0 ) N ( 2 7 ) . N ( 2 8 > . N C ? ) » N R W , N ( 2 ) , N ( 2 ) . N ( l ) W p I T E < M , 9 6 0 1 N ( ? 9 ) , N R W , N ( 2

) * ( ( R P T ( I , J ) . J s 1 , 10) , N P T { 1 ) , 1 = 1 , N R W

W R I T E < m , ? 6 0 ) N ( 3 n ) , m R W , N ( 2 ) , ( < T P T ( I ,J) , J a 1 , 10) , N P T ( ! ) . 1 = 1 , N R W ) WRTTr(M f 930)N(31),NRW,N(2),(TDMlN(I),|*l~NRW)

ARlTr(M.9aO)Nj(3 2).NFIX.N(M),NFIX,N{M),((SEPTT(I,j4,J*l7NF!X),

1 I « 1. , N F I X ) ’V R I T F ( m , 9 q 0 ) N ( 3 3 ) , N ( 3 8 ) , N ( 1 ) i N ( 2 9 ) , N ( 5 ) WRtTE(m,910)NJ(39).TREG

WR I TE ( M ,.9q0 ) N ( 9 0 ) , N ( 95 ) , N ( T ) » NRW , N ( 2

VV R I T E ( M f 9 1 0 ) N ( 9 6 ) .TEND

WRTTE(M,9q0)M(«47) # Nf2).N(l) | N(29),N(5) # C(LAHBn(I.J)’.J*1.2 <n.Ial.2l

W R ! T F ( M , 9 0 0 ) N ( q 8 ) , I H 0 U R WRlTE(M,9q0)N(*49),NFlX,N(q),NF!X,N(9),{(SEP2(!,J),J=l,NFIX),

1 I = 1 , N F I X ) WRITE ( M , 9 5 n ) M(B0),N(^0),N(1).N(2),N(1)

W R I T E ( M , 9 7 0 ) W R I T F ( M , 9 8 0 ) N ( 1 ) , I R F G , l. , L

900

9 1 0

920

930

990

950

960

970

980

505

F N D F I L F M

FORMAT ( I q , 5 X |

* 0

FORMAT ( I q f 5 X

, * 0

FOrMaT(1*j,5)(,»1

forma

f i q , 5x , •

FORMAT ( I 9 , 5 X , * 2

FORMAT ( 2 1 9 I I 2 .

• FORMAT ( I 9 , 5 X ,

* 2

FORMAT f • • ) F0RMaT{|3". 19, 13.12)

WRITE! 6 ,505)

FORMAT ( //35X • a TRCRAFT 0F5cRI p TI0N*//16X*TYPE , 21X*rPEED 5 ( K N 0 T «: ) »6X

l • R 1 1w A y OCCUPANCY (SECONDS)* / 3 9X»LANDI M G •9X'LIFT0FF*6X*LANDlN r, »6X

2 • TAKFOFF • // )

R V? I 3 9 ) R*,37XF7.3»

R •

,

I 6 , l 9 , 2 7 X » • l 0 ( I 2 ) * / ( l n I 2 ) ) !6.I9,27X» , 10(D3.9)*/(10F8.9))

I6.3I9,5X» *R F*,11X'»12(D1.9)#/(12F6.9))

. 15.319)

16, J9# lRX» • R * ,8X ,

* 1 0 ( 12) •/( 10I7.50XJ2) )

P» .

7 • R* .

DO 1 A 0 I s ) , NT yPF

P R 0 T L

s R 0 T L ( 1 ) * 3 6 0 0 . RROTT = ROTT ! I ) f 3600. ,, w PITE< 6,510) I ,Vt,AN D ( I ) ,VTOrF( J ) .RROTL.RROTT

510 FORMAT ( *0* 16*12, 21xF9.Q,7Xf9»0, 10XF9.0.9XF9.0)

160 CONTINUE

WP I TF ! A ,5 1 1 ) 51 1 F0RMaT(//35X*TRAFFIC DE5CRIPTiON*//31X*TYPE*5X*LAMDING*HX*TAKfOFF»

1/92X»Mtx*8X*mix*//)

A a P T Y P F. ( 2 , 1 ) * 1 00,

r=PTYPf(1,1)*100.

WRITE U,5l5)N< 1 ) ,A,B

515 FORMAT (32x12, 2(7XF9,01/) -169-
1 65

520

5 2 1 525

I 70

5 3 0

1 75

535

1 50

550

1 85

585

1 90

550

1 95

2 On

555

205

560

2 1 0

565

DO U5 !«2.NTYPF

A«(PTYpE( 2 .I )-PTYPE(? t I-l ) ) • 1 00 . p « ( P T Y p E ( i ,1 )-PTYPF( 1 , 1-1 ) ) • 1 00 . V P T T F ( 6 ,

5

J 5 ) I , A , P CONTINUE

WR I TE ( 6 , 5?0

)

FORMAT ( * 1 A I P P 0 P t configuration*

)

IF ( INPUT (B) • NE •

* * )ivR!TE(6»52l ) INPUT (5)

F0RMAT(« FOp A 3 , • AIRPORT*)

W R I T F ( A , 5 ? 5 ) M R W

rOPMATf///' NIJMRFR OF RUNWaYS «*I2)

00 190 |s| , N 9 W

J = 0 P F R (!)

GO TO (170*175, 1*0, 185). J

V’ R I T E < A , 530)1, IhEAD(I),ILR(J)

format ( *nRtlMlV4Y* 12, ' (M2,A2»*) - TAKEOFFS ONLY*)

GO TO 190

R I T E C a , 5 3 5 ) I ,IHFAD( I ) ,!LR( I

) FORMAT ( 'OR U N 8* AY* 12, • ( • I ? , A 2 * * ) - LANDINGS ONLY*)

GO TO 190

WRITE(6,5m0)I,IHEA0(I),!LR(I)

F0RMAT(*nRUM'A/A y *l2,* ( • I 2 , A 2 % ) - DUAL USE. ALTERNATING OPERATIONS

1 • ) G 0 T 0 1 9 0

W'RTTE(6,585)I~IHEAD(I),ILR(I)

FORMaT(» 0RUN’A'AY*I2,* ( * ! 2 * A 2 » * ) - D U A |_ USE. LANDINGS TAKE P R ErEDEN

IFF*)

CONTINUE

DO 195 I x ] , N R W

DO 19 5 J s T , N R

W

I F ( D I N T ( I , J ) » I. F • 0 , )G0 TO 195

A*D I NT ( J , j ) *6076

R = 0 I N T r J , I

) * A 0 7 6 • ^R!TE(6,550)IhEAD(I),ILR(I),IhEAD(J),ILR(J),A,IHEAD(I) # ILR(I)Ib.

1 I HF AD C J ) #

I LR I J

)

FORMAT f / / • 0 R U N AYS* 13, A 2 , • ANo*I3.A2.*, INTERSECT AT A P0INT*F7.0,

1* F E F T FROM T h E • / • FND OF pU n WA Y • I 3 , A?' i AND*F7.0.* FFET FROm THE

2 F N D 0 F R U N A a y * I 3 , A ? , * . • ) continue

I I = N R W - 1 00 2 15 I « 1 , T T J J * I

1 CO 21.8 JajJ t NR'A» IF(INTFR(l,J),FO.n.AND.IHEAD(I).NE.IHFAD(J))GO TO 2 1

5

L * I N T F p ( r ,J) + 1 IF(IhEaD(I).NE.IHFAD(J))GO T 0 211

GO T0( 200.205,210) , L WRiTfU. 555) IMFAD( I ) ,ILR( I i ,

I HEAD ( J ) *ILR(J)

FORMAT < / • DRIJNVJA y8 • I 3 , A 2 , * AND*I3,A2,* ARE INDEPENDENT PARALLELS -

1/' S IMijLTaNfOUS operations ARE PERMITTFD*)

GO TO 215

W R I T E 1 6 , 5 6 0 ) IHEAD( I ) . I L R ( I ) ,

I H E A 0 ( J ) *ILR(J)

F0RMAT(/»nRUNWAYS*l3,A2,* AND* J 3, A 2,* ARE SEMI-DEPENDENT PaRAiLELS

1 -*/• SIMULTANEOUS arrivals arf prohibited*)

GO TO 215

WRlTrU,568)lHEAD(T),ILR(!),lHEAQ(J),]LR(J)

FORMA T ( /*oR UnwayS* I 3 , A 2 . * AND*13,A2.* ARE DEPENDENT PARALLELS - • /

1* NO S j MULT ANfOijS OPERATIONS ARE PERMITTED*)

GO TO 215

- 170 -
II GO Tn(?15.2l2,?l3),L

212 WRlTFU,570) I HFAD ( I ) , I L R ( I ) ,

I HE AD ( J ) . I LR ( J

570 FORHaT(/»oRuNwAYS*I3.,a?,* A N D * i 3 , A 2 ,

* ARE SEMI-DEPENDENT

1 L T A N E 0 1 1

ARRIVALS APE PROHIBITED*)

GO TO 215

? \ \ WPlTF(A*575) I H E A D ( f ' lLR(t),lHEAO<J),ILRfJ)

575 F 0 R M A T ( / • n R U N W A Y 5 *

1 A % A 7 . • A N D *

I 3 , A 2 ,

* APE D E P E M D E w T - * /

* 1ANF0US OPERATIONS PFRMITTFD*)

215 CONTINUE

STOP

300 «V R I T F ( <5 .8*0 ) 8A0 FOPMaT(* WARNING - 0 A 7 A T A PF OOFS NOT CONTAIN INFORMATION

IE requested AIRPORT*)

'•STOP

•END.

- • / • S I Mi)

NO S i M U L T

A ROM T Th

.- 171 -
APPENDIX D

LISTING OF THE SIMULATION PROGRAM

- 172 -
N GEN R N R Al A Y 3 1 2 I I 0 E N N X T 0 P M N OP 32 2 I 2 R IV E M land r 3T YP E N TOFF R RF I X E

N PT R I 5 H r N FTIUPR T type 1 I A 0 P E P 1 I N PR I NJ T R N DL A Y R F 7DOM 1 F

T Ft. T q T T I N 3 F fl N p T 1 I T T I F U P R 9 FI. YOM 2 F

Nt ends 2 T TH I m 1 F 1 odme 1 I M C H O u R 2 T tmax 2 F 1 1 VL AND t E

T DFt X 2 I 1 2 V T 0 F F 1 F

\ 3 R 0 T L 1 F

1 rrott 1 F

T so R T 1 SVT A X T 0 E

UDAFIX G F

1 7 S F P L L 0 F ISSEPTL 0 F 19CALIN 1 F 20CTYPE 2 F

71CPWYT 2 F

2 2 C R 1W Y L 2 F

2 3 C D F I X 2 F

T POMTI 3

T S 0 m T i q

T P T M T i 3

T S T H T I

*4 T PFPTI 3 T SERTj q

2 R N E X T 1 I 2 51 AST l I 260!MT 2 F 27F0 2 I 2PLQ 2 I 29RPT 2 ! 30TPT 2 I 3 1 T n M I nj i r 325FPTT 2 F

33NA&R l I 3 4 N 0 E p 1 I 3 5 N L A N D 1 I 3 6 N T D F F 1 I 370ELT | F

3 A 0 E L L t F

3 9 T B F G 0 F

I ROFQMTI l I

! ‘ULOMTI \ !

I R 2 F T H T I 1 I

I R 3 L T w T I \ !

I R q F F R T I 1 I

I rslfrti 1 I R6TEND D F

M7LAMBD 2 F

RBIHOUR 0 I H9SFP2 2 F

5 H G E 1 I

0 2 F

0 M T II RTMA X THT I I RTHA X ERTIl RTMAX

- 173-

PT YPE

P R W A Y I PDF I X I freerf

LU

L
E V E m T S

2 EXOGENOUS

BEGIN (i)

EXGEN (?)

a endogenous

' gen

NXTOP

LAND

TOPE

ETIUP

CHOUR

PRINT

ENDS

end event list

EXOGENOUS event REGIN

do to i . eor each o I create gen

STORE GEn in GENN(I)

store I IN OP(GEN)

let t»time.lamrd( i ,ihOijo)*alog( i • - r a n d m > CAUSE GEn at T

1 LOOP

create Ends

CAUSE ENDS AT TEND

CREATE chour

CAUSE CHOUR at TIME*!.

RETURN

end begin

- 174 -
ENDOGENOUS EVENt gfn

C GEN GENERATES landings and takeoffs and

C A s S T G N s ATTRIBUTES TO T H E M . C 0 p ( G E N ) IS I- T A K E o F E , 0 P 2-LA N DING

S T 0 f? r 0 P { G F N ) IN I C GEN SCHEDULES ITSELF TO OCcUR AGAIN AFTER A TIm£ INTERVAL

C DEPENDING DM Thf RATE Or OPERATION,

CA'JsF GFn AT TIMF-LAMRD(IiIHOUR)*ALO<3M.-RANDM)

CREATE flt

let I TsPTYPE ( I ) 5 T 0 1? E IT in TYPE { E L T ) LET K * P

V] A Y ( 1 . I T

GO TO ( 1 , 2 ) , I C TIN(FLT) IS The time a flight is AVAILABLE to RfGIN final

C DESCENT f F 0 R LANDINGS) nR TO BEGIN TAXIING TO RUNWAylFOR TaKEOEE)

C C A L T M IS A TIME LAG INTRODUCED IN TAKEOFFS, CORRESPONDING TO

C ELYnM - THT TIME A LANDING TAKES TO ELY FROM

C HA N DOTE TQ THE 0 U T F R MARKER,

1 LET T!N(FLT)*TIME+CALIN(K)

LET DF I X ( elT ) =PqE I X ( * ) IE TIME GE TREG, LET NOEP < I HOUR ) «NOEP ( I HOUR ) 1 GO TO 3

2 let TIN(F L T)sTTME+FLYOM(IT,K)

IE TIME GE TpEG. L F T NaRR(!HOUR)»NARR(IHOUR)+1

3 IF O(K.I) IS NOT FMPTY, Go TO H CRE A TF NX Tp p

L F T P w A Y { N x T 0 P ) = K CAUSE N X T 0 P AT T T N ( F L T ) C O(K.I) - IS THE QUEUE OF PLANES WATTING TO T A K F OFF < I i ) , C OR LAND! I a?) ON RUNWAY K,

* FILE el T IN 0 { K . I ) RETURN

E N P GEN

EXOGENOUS F v F N T F X G E N

C EXGEN GENERATES EXPLICIT DfPARTURES'aND ARRIVALS

save event card

create _ flt

read !>,IT,DF!XCFLT)

FORMAT ( *4 I 2 ) STORE T T IN TYPE(FLT)

GO TO (1,2),!

1 LET TIN(FLT)»TIME+CALIN(K)

IF TIME GE TRF.G, Let NdEP<IH0UR)«NdeP(IH0UR)4-1

GO TO 3

2 LET T I N ( El T ) »T I MF + FL YOM ( I T , K ) IF T I M F GE TREG, LET NARR<IHOUR)«NARR(IHOUR)*l

3 IE Q ( K I

IS NOT EMPTY, GO TO H CREATE nxtop

LET RU'AY(NxTOP)*K

CAUSE NXTOP AT TIN(FLT)

H E I LE FLT I N 0 ( K , I ) return

end

-175 -
r>n

FUNCTION PTYPE(I)

C P-TYpe CHOOSES an AIRCRAFT type for each flight according to

C CTYPF - THE CUMULATIVE DISTRIBUTION OF A/C TYPFS IN THE MIX,

let R S r a n d

M

DO TO 1 * FOR EACH TYP J

IF R LE CTYPF < I , J ) , GO TO 2

1 LOOP

2 LET PTYPFsJ

Return

END P T Y R E

FUNCTION PRWAY( I ,M)

C PR WAY CHOOSES A RUNWAY FOR EACH FLIGHT ACCORDING TO

C CRWyL - THE CUMULATIVE DISTRIBUTION OF P RA Y l ( SEE P R E P R OC E S S 0 R ) 7

0

a

C C RWyT - SAME AS CR'VYL FOR TAKEOFFS,

LFT RsRANDM

DO TO 3, FOR EACH RW J

GO TO (

1

‘ 7 ) ,

I

J IF R LE C R W Y T ( M , J j , 60 TO <4 GO TO 3

2 IF R L.F CRWYL(M.J), GO TO H

3 LOOP

H LFT PRAAYsj

RETURN

END prway

FUNCTION prfTX(K)

PDFIX CHOOSES A DEPARTURE FIX FOR EACH TAKEOFF ACCORDING TO

C D F I X - THE CUMULATIVE DISTRIBUTION OF PDFIX (SEE PREPROCESSOR)

LFT RsRANOM

no to i * for each fix j

IF R L. F CDFTX(K.J), GO TO 2

1 LOOP

2 LET PDElXsJ

Re Turn

end pof

i

x

- 176-
ENDOGENOUS r V F N T N X T 0 P M X T n P DECIDES '*> HTH 0 p F r A T \ o N WILL P F S C H E D U L F r> NEXT

0 N P4fM PUM"MY.

S T 0 R

r R W A Y { N X T 0 P ' T

1 1 Y n p 5 t p o y NYTno

ir NEXT NT n , THE next OPERATION Has a l READY been decided upon.

IE NFXT(K) NE o , WE turn

STOpe o

p e R ( < ) i m I ie i of 3 , go to l TE RUNWAY HANDLES ONIY n N E OPERATION. FIND NEXT FLIGHT

waiting in the queue and Schedule it.

find E I R S T . FOR E A c W F L T I N 0 { K ,

I ) , I F NONE, RETURN

STOrf rLT IN E LET T=FREFR ( K , I , F

)

GO TO <4 IE RUNWAY H A M D l_ F S pOTH OPERATIONS IN ALTERNATION. LOOK FOR

Next EiIGHT A! TUG t O peR FORM THE ALTERNATE OPERATION,

1 LIT j = | A S T ( K ) IE IANDIMGS TAKE PRECEDENCE, ALWAYS CONSIDER THE

LAST OPERATION TO have BEEN A TAKEOFF.

IE T F Q M , LET J s 1 L e T T = - 1 . L F T I F I A G = O

L F T T * i IE J F Q 1 . L E T 1=2

LET TTs99?999»

e I u D fi r st, FOR fach elt In q ( k , i > , i f none, go to 2 STORE ELT IN E let I E (_ 4 G s | LET T=EREER(K,I.E)

I e T I N ( E ) is T , SO TO M

l. E T TTsT

LET M=l

2 LET !=j

ie m o flight available n o a , search the other Queue,

find FIRST, for each elt In Q ( k , I ) , i e none, go TO 3 STORE flt in e LET I E L A G S

1

L E T T = e r EERIK,I,E)

IE T I N

(

E } L 5 T, GO TO q

3 ie iflag eq n, return

IE NO FLIGHT THFRE EITHFR, CHOOSE THE flight which

WIU. PE AVAILABLE EARLIEST.

IE T L T tt. go TO q LET T = T T LET I = H

R LET M E x T { K

)

= I GO TO ( 5 , * ) ,

I 5 C

° E A T E TOEE

store K in R'VAY(TOFF)

CAUSE TOFE AT T

R E T ij R w

a create land

STORF K IN R'"AY (LAND)

CAUSE L a ND AT T R E T ij R M

E Nj D M X T 0 P

- 177 -
FUNCTION FREER(K.I.FLT)

freer CALCULATES THF FIqST time AT which flight FLT can PEpFORm

OPERATION I ON PUNWAY K WITHOUT VIOLATING SEPARATION RULES.

DIMENSION T R ( 2 S ) let J * o let TaT I me

Ir TIN(FLT) S T T . LET T a T I N ( F L T ) L F T M * T Y p e ( FLT

)

LFT erefr=t

IF T FQ 2, GO TO <4 IF E R T I ( K J I S EMPTY, RETURN

ERTi(K) IS the set OE *TIEUPS» FOR THE end OF THE RUNWAY K.

: a Ttfup is a time interval during which no takeoff may occupy

: the fnd of the runway due to interference from other aircraft,

let TFMsTomINK)

: T 0 M T N I 5 A TIME LAG INTRODUCED INTO THE SCHEDULE OF A TA<fOFF

C CORRESPONDING TO The TImE IT TAKES A LANDING TO FLY FROM ThE

C OUTER MARKER TO TOUCHDOWN* JT MAY RE LOOSELY THOUGHT OE AS

c taxiing time.

DO TO 3 , E 0 R EACH TIE UP IN ERTI(K)

LET TTsTMAX (TTEUP)-TEM

C THE end OE THE TIEuP. I,E» THE TIME WHEN THE END OF THE RijmwAY

C BECnMFS FRfE, is displ aceo backwards to give the time When

c the takeoff may begin taxi.

IF TT L S T , GO TO 1 LET J = J-M

LFT TR ( J ) aT T LOOP

GO TO 1

2

a I F OMTI(K) IR EMPTY, GO TO g

c OMT I IS The SET OE TIEUPS for the outfR marker,

do ro s» F 0 ° FACH ttfup IN OMtI(K)

let TTsTMAX (TlEllP)

IP TT lS T , GO TO s LET J = J + 1 LET TO| J)sTT

S L 0 0 o

n IE THTI(K) IS EMPTyI GO TO 12

LET TFM*DOMfK)/VLAND(M)

C T H T T IS T HF SET OF TIEUpS FOR THF THRESHOLD OF ThE RUNWaY.

DO TO 9 * FOR EACH’ TIEUP I N T H T I

( K ) c THRESHOLD TIE OPS ape DISPLACED BACKWARDS to GIVE thf time that

c THE LANDING m AY PASS the OUTER MARKER.

let tt = tm a X ( t

I

EUP ) -tem

IE TT L$ T , GO TO 9

LET j a J

I

L E T TR(J)=TT

9 LOOP

12 IP J EQ 0, RFTURN

let r REER = T Q ( 1 )

I F J EQ 1 , RETURN

c FREER is SET EQUAL To ThF end of thf latest TIfUP, WHEN THTRE is

C NO LONGER any INTERFERENCE,

DO TH 21, FOR J J a <

jl ) ( J

)

IF TR(jJ) gT freer! let FREER«TR(JJ)

21 LOOP

RETURN

.END freer

- 178 -
ENDOGENOUS FVFNT 1 . ANn

LaMiv CRKATfS AI.I TMF 'TtFUp 5» WHICH

P F S i

; l T FROM AM A I u r p a F T LADING*

S T 0 P r R W A Y ( I A M D ) I

i* IF !.) ( K % ? ) T j NOT FI"P r,n T 0 9

W P 1 T F 0 N T A Pr A , T I M F , K FoKmM ( AT T I ME •

, M 3 . ? * S? , * L AMO I MG QIJEUF FOP R U M w A Y * ,

I 3 S 2 ,

1 MS F M P T Y M

STOP

FTNn thF L ANOINT TO nr sCHFDULFn* ANn STQWF ITS ATTRIBUTES.

R F * 0 V F FIRST F L T FROM Q ( K * 2

5 T 0 P F F L T IN F L LFT MsTYPFiFL

I. F T V s V L A N 0 ( M !

I . F. T T =. F P F F R U , ? , f I ) L F T TO=T+nnMfKl/V

TTF u P THRFSHOLr TO LANDING AIRCRAFT PROM TOUCHDOWN TIME U^TIL

A F T F R RUNWAY OCCUPANCY TI m F WAS ELAPSFD*

CR^aTF TIFI'P

I. FT T M

I N ( T I rijP ) -TO

l rT T M A X ( T I FllP ) :T 0 R 0 T L ( M ) FTLf T I E U P IN THTt (K)

C R E A T F F T I

! I P S T 0 p F < IN R W A v ( F T f m p

STOPf ? IN P T ( F T T l J P > CAUSE FTIUP AT tmaX(TIEhP)

T I F ||P End OF RmNY/AY to DEPARTING AIRCRAFT FROM TOUCHDOWN i-NTIl

A F T y P R u N w A V 0 c C U P A N c

v T I M F HAS F L A P S E D . C p E a T F T I F 1 1 p

LET TMjN(TirUP)sTf)

L F

T T m A X f t j F U R ) = t n 4 R 0 T L ( M ) F I L f T I E U P IN E R T I ( K

CREaTF FtHiP

STOrf K I RWA v ( FT I UP ) S T 0 R r 3 IN R T ( F T I U P ) CAUSE F T I Up AT TMAXITIF UP)

FT No TmF FOLLOW IMG PLANE I 14 THE LANDING QUEUE

AND STORE ITS ATTRIBUTES.

FIND FIRST, FOR FACH FLT IN 0 ( K » 2 ) * I F NONE, GO TO 11

STOrt fLT in e LF T MMsTYPF ( E ) LET SsVLANn(MM)

CREATE A T T E i • P i • H I C H W I I L MAINTAIN PROPFR RADAR SEPARATION

BET F F N ARRIVING AIRCRAFT*

C R E A T E T I PUP

IF S G F v/ , GO TO ?_D

IF THF LANDING SPEED OF T H y PLANE BEING ’SCHEDULED* IS GREaTER

than that or t hf following plane, tie up the outer m a r k e r from

the time the first plane Passes the outer m a rkfr until

TwF TIME IT TAKES THF SECOND TO FLY THE SEPARATION OISTANCF

has ELAPSED.

let T M I N ( T I E LJ P ) S T LFT TMAXfT!EUP)=T+SEPLL/S

F I L r T I E U P IN 0 M T I

( K ) create ft i up

STORE K IN RWAY(FTIUP)

- 179 -
store i in pT(rTiuP)

cause: fthjp at t^ax ctifuP ) CO TO 11

IF TMF la MOT mg SPEED OF T Hf FOLLOWING plane is greater, tie up

THE THRESHOLD FROM TOUCmD°WN OF THE FIRST UN Til THE TIME IT TAKER

the SECOND TO F| Y T HF SEPARATION DISTANCE HaS ELAPSED,

70 LET TMIN(TTEUP) * TO

let t m

a

x

{

t i

e

u p ) = t n

s

e p L i / s

E I L E T I E u p IN T H T I ( K ) CREATE E t I UP

STOpE K IN R W A Y ( F T I IJ P ) STORE ? IN PT(ETIUP)

CAUSE eTIUP AT TT^AX fTIEuP)

11 IE OPEP(K) LT 3 , GO TO 2

CREATE A T ! F 1 1 P WHICH WILL MAINTAIN PROPER SFPAPATION BETWEFN

t h

i

s landing and a takeoff on the same runway,

CREATE TIFi.ip

LET TM a X ( T I EUP > =TD

IE D M E ( M ) g T 0 , GO TO 1 IF the LANDING HAS MO DT STaNcE MEASURING EQUIPMENT, TIE UP THE

END OF RUNWAY TO DEPARTURES FROM THF TIME THE LANDING PASSES ThE

D/A Fix UNTIL TOUCHDOWN.

LET TMlN(TTFUP)sT+rnOM(K)-DAFIX)/V

GO TO 1 0 1 IF THF L A N n I M G HAS ONE, FIND THE T A < E 0 E E SPFFD OF THE

DEPARTURE AND COMPUTE T W E TIE UP NECESSARY TO MAINTAIN SEPARATION.

1 F I n D FIRST, FOP EACH FLT IN Q ( K , 1 ) , IF NONE, GO TO 2

STORE FLT IN F LET M n = T Y P F ( E ) Lr T S=V T OFF(MM)

LET TmiN(T T fUP)=T+(dOM(K)-(SEPTL^,S*V##2/S*P0TT(mM) )

)

/ V mi E I L r T I E u P IN E R T I ( K ) CREATE ETIUP

STORF K IN RWAY(FTIL)P)

STORE 3 IN PT(FTIUP)

CAUSE F T I U P AT TMAX(TIFUP)

2 I F N P T ( K ) E R 0 , GO TO 10

NOW CREATE TIEUPS ON 0 T H E

r RUNWAYS, IF SUCH INTERFERENCE EXISTS.

DO TO ft » F o R Js( 1 ) (NPT(K) ) CREATE T I F u

P

KK IS THE RIJN Way affected.

LET K K = R p T (

K

. J ) IT IS THF TYPE OF TIEUP TO re CREATED.

TlEijP TYpfs 1, 2 * AND 6 APpLY TO LANDINGS.

LET I T = T P T (

K

, J

)

GO TO (3,ft,A,6,6.S) ,IT

CREATE a T]F UP TO MAINTAIN INTER-ARRIVAL SEPARATION.

* El No FIRST* FOR EACH FLT I N Q ( K K , 2 > , IE NONE, GO TO 6

STORE FLT in E

LET MMsTvpp ( r

)

LET SaVlANn(MM)

IF S GF V, GO TO 325

LET TMlN(TlEUP)t=T

LET TM A X(TIE'JP)=T+SEPLL/S

L E T J J * 1 GO TO 7

3

2 S LET THIN (TIE U P ) T D LET TMa X ( T I EUP ) sTu + SEPLL/S

- 180 -
I FT J Js2

GO TO 7 CWFA.Tr A T I r 'J P TO MAINTAIN DFP/APR SEPARATION.

'+ LFT TH A X(TJCUP)*TD

IT n«EI M ) GT 0, G 0 T 0 H 2 5

L F T TM!N(TiFUP)=T 4.(nO^(K)-nAFIX)/V

GO TO q 5 rj Vr. FlMn FIRST , FOP FA CM FlT IN Q|KK,| ) , IF NONE n 0 TO 6

store f L t in f

L F T Mm = Typf(F)

LF t SaVTOFF(MM)

lft tmin(tje:uP)=t+(dom(k)-(Septl + . 5 «v«*;?/s*rott(mM) ) i / v

G S n LFT J J 3 3 GO TO 7 TTF IIP The end or an INTF r SECTJNG runway TO Ta<FOFFS and

until a

f t e R the landing p a s s f s t H F INTERSECTION,

5 LFT T M I N ( T I E u P l sTO

L r T A*(VTAXI-V)/ROTL(M)

LFT TFM3.G*A*R0TI (M)**2 +v *R0TL(M)

if the Landing will not reach thf intersection,

tie UP UNTIL thf L A N D ! M r, TURNS 0 F F . IF TEN LE D I N T ( K ,

K. K ) , 6 0 T 0 SI

L r T Bsv**?*?,*A*niNT(K,KK)

LFT TUP=TD+ ( -V + SQRT ( R ) ) / A GO TO 5 2 SI LFT TUP*TD+ROTL(M)

5 2 LrT TmaX(TIFIJP)sTUP

FILf TlElJP IN ThTI(K'K)

C P E A T F F T I II

P

STORE KK In RWAY(FTIIJP)

S T 0 R c 2 T N P T ( F T I U P ) CAUSE FT I UP AT TMAX(TIEuP)

create T I F

l

i d

let T M I N { T I E U P ) = T 0

LFT TMaX(TIFUP)*TUP

L F T j j 3 .3 GO TO 7

A DESTROY TIFUP

GO TO B

7 GO T0(70l ,702,703), JJ

701 FILE TIFUP IN 0 M T I ( K K ) GO TO 70 S

702 FILE TIE UP IN THTI(KK)

GO TO 70S

703 FILE TlElJP IN ERTI(KK)

70S CREATE FTJUP

storf kk in rway(ftiuP)

STORF j J in PT(FTIUP)

CAUSE F T | UP AT THAX (TIFuP)

B LOOP

10 CREATE NvTO°

STORF K IN R v A Y ( N X T 0 P

)

LFT N F X T { K ) sc 0

CAUSE nxtop at t

; DTEm is thf OElay ENCOUmTEpeO BY this LANDING,

LET DTFM«(t-TIN(FL))*AO,

IF TO lS T B F G , G 0 TO SO

create print

landings

- 181 -
c STOqe data TO R F rfcordfd AT TOUCHDOWN.

STORF D T F M t M Dl AY (PRINT)

*5 T 0 p r < T Ki R 'V A Y ( p R I m t ) STORF ? I n DP(PRINT)

CAUSF PRINT AT TO

SO DFSTROY FIT CALL CD FL

LFT LAST(<)=^

ofstroy LA no

R F T (J p N

F N D LAND

- 182 -
ENDOGENOUS EVENT TOPE

ToEF- C&EATfS THf tie l- PS RESULTING From an AIRCPAFT taking off,

STORE RWAY(TOFF) in * destroy toff

If o ( K ,

1 ) I S EMPTY , GO to 16

F?No TaKEOfE To nr SrHFDULpD a no STORE its ATTRIBUTES.

REMOVE FIRST ELT E^'nN Q(K,1)

S T 0 p r F L T IN EL

LET ; i = t Y p f ( r L ) L r T VsuTOff

I

M ) L E T T«fRF£R { K . 1 , FL

)

LET Tn a TfTf)MlN(K ) Tie up the runwa v to takfOffs and landings for duration of the

P 1 1 N A v OCCUPANCY time,

create T I FUP

LET T M I N ( T T F I J P I - T [ l.rT T M A )( ( T | F U P ) = ’ r, + R r T T ( H ) F I Lf TTFi.JP IN THTinn

create e t I I ) p

STORE K In 9 W A Y ( F T I II P ) STHpr p I n PT(FTIUP)

r a U S r F T I U p A T T M A Y ( T I E U P ) r^F ate t i f u

p

L F T TMjN(TTEIJP)=TO

I . F T T M a

X ( T I E tJ P ) s T 0 R 0 T T ( M ) r t Lr T I FUP I N e w T i ( K ) CREaTF e t J

i. i P STOrf K IN p W A Y ( F T J u P ) STORF T IN P T f E T I U P ) C A 'J S f F T I u p AT T m A Y ( T I E U P ) r T Ml) r j R 5 T , FOP FAfH ELT Im Q ( K , 1) . IF NONf. G* TO ? S T 0 R E F !. T JM F L F T L = 0 E I y ( E ) L r T LLsOFIx(EL)

tie up the end nr tmf runway to thf nfxt takeoff long enough

TO MAINTAIN j n t f r - o f. p a r t u r f separation, this depends on whether

or mot thf t o takfoees dIvfrge,

create t I r I ) p

LET T M I N ( T I F U p ) = T D

L E

T TMaX(TifUP)sT()4SePTT(Ll,L)

FTlr T I E I J P IN E R T I I K

)

CRE A TE E T I IIP STORE K IN RWAy(ETIUP)

STORE 3 IN PT ( ET I U P

)

CAUSE E T I LJP AT TMAYfTIEUPl

^ IE OPER(K) L T 3, GO TO 5

find first' for EACH FLT In Q ( K , ? ) , if NONE, go to s store flt in e LET S=VLANn(TYPF(F)

)

create a t t r u p to maintain dep/arr separation.

CREaTP T I Flip

LET T m i N ( T T F !J P ) = T D

I F n M F ( T Y p f ( f 1 ) F Q fl . G 0 T n 3

let TMAX ( T T F I J P ) »TD+ (5EPTL + .S*S**2/V*ROTT (M ) I/S

go to y 3 LET T M A X f T I EUP ) =TD + D AE I X /5

'4 E I L E T I F- U P IN T h T I ( K ) - 183-
CREATE1 FTIIJP

STORE < IM R'-V A Y ( F T I UP ) 5 T 0 p r 2 IN ° T ( F T l U P ) CAU5F F T ! U p aT T^AX(TIFUP)

IF MPT(K) F 0 G , GO TO IF

CREATE T ! F 1 1

P

S 0 F OTHFR RUNWAYS AS RFQUIRED.

DO TO I S . FOP J 8 ( 1 ) ( MPT ( < )

) C p E A T F T I F u p

K

K

- RUNWAY AFFECTED

L F T KKsRPT ( K , J ) IT - TYPF of T I Flip

ONLY TYPFS 3 . M , S • AND 6 APPLY TO TAKEOFFS.

LET I T = T P T (K , J)

GO TO(l2 f 12,6.P,P.in),TT

CREATE A TIfUP TO MAINTAIN PROPER OEP/ARR SEPARATION,

A FT NO F I R S T , F 0 R FACH FLT I N Q ( K K , 2 ) ( TF NONE, GO TO 1?

STOqFFLTTNF

L F T MMsIYPf (F I LFT S = Vl.AND(NM)

let TM1N(TIEMP)*TD

LPT J J = 2

IF o

M E(TYPF(F)) E Q 0 , GO To 7 L p T TmaX(T!FHP)=Td+(FFPTL + «B*S**?/V*ROTT(M) )/S

GO TO 1

0

7 LPT TmaX ( T I T U P )

s

T D + DArlX/S

go to n

8 FIND FIRST

-

, FOR F.ACH FLT I N 0(<K, I ) , IF NONE, 6n TO \ 2

STOrf. FLT p' p LFT l s d p

I

X ( p 1 LfT LL=DFIX(PL)

ORE a

T

r A T I F I

' P TO MAINTAIN pROPFP INTpR-DEPARTURE SEPARATION.

LET TP T N ( t T Ft' p ) =TD

if tmf Runways a r f dependent, use the same separation as for one

riin^uyI i.e. those in The septt array.

L p T TM A X ( T I E UP ) sTD + SEPTT ( L , LL ) IF THF RUNWAYS allow SIMULTANEOUS DF p ARTUReS WmEN THEY dIVfRGE.

USE the SEPARATIONS IN the SEP2 ARRAY*

IP IT F Q S .LET TMAX(TIFUP)«TD*SEP2(L,LL>

LET J J = 3 GO TO 13

TIE UP ThF r N D Or AN INTERSECTING RUNWAY TO A L I OPERATIONS UNTIL

the takeoff passes the intersection.

LET TMIN(TjeUP)sTD

L F T A s V / R 0 T T ( M ) LE t TFM=.S*A*ROTT(M)**?+V*ROTT(M)

IE THE takfofe is airborne reeore rfaching the intersection,

TIE UP ONLY UNTIL AIRBORNE,

IF TEN LE D I N T ( K , K K ) , GO To SI

LFT Rrv/**2*2.*A*DINT(K,KK)

LFT TUP=TD+ ( - V+SQPT { P ) ) /

A

GO TO S 2

LET ,TUP*TD+ROT T { M

)

LET TMaX(TIFUP)«TUP

E T L f TlEtJP IN T H T I ( K K ) create etiup

STORE <K In RWAY(ETIUP)

STOrf ? IN PT(FTIUP)

CAUSF FTIUP AT TMAX(TIEUP)

- 184 -
C R E a T r T I E l ) p

L-FT TM i N ( r T PUP ) = T D

t FT TM A X ( T I FUP ) =TIJP

LfT JJ = 3

0 0 TO 13

l 2 DESTROY TIE'JP

6 O TO 1 M 13 0 0 T o ( i 4 , 1 ii ,

1 3 ? 1 . J J

13 1 FILE T j E U P IN T H T ! ( K < ) 00 TO 130

13 2 FILE TIF-Up TM ERTI(KK)

135 CRFatF FTIdP

STOPE K< IM RVAY(FTIUP)

stOwf j j I M p T ( F T I U P ) CAUSE e T i

t j P at TmaMTIFiiP)

1 q LOOP

IS CREATE nxtop

S T 0 p F < IM R W A Y (NXTOP)

LFT m f_ x t i o = CAUSE TOP AT T C DTFm - THE DELAY INCURRED By THIS T A K E 0 E F L r T DTEN*(T-TIN(FL))*60*

IP TO ES TBFO.OO TO 50

c p f a t e print

c stOpe data to be recorded at thf time the takeoff turns

c OF TO THE RlJ N Way.

STORE DTEM in DLAY(PRINT)

STORE K I M R W A Y ( D R I M T ) STUPE 1 IN n p ( P R I M T ) C A U S F DRINT AT to

SO DFSTPOY flt CALlFD FI. LET l. A S T ( < l s 1 R r T ii p m

1 A WRITE ON T A P E A , TIME, K format <• at time* ,d2*m,s2, ’Takeoff queue for runwa y • , 1 .3 »s? .

| *

T s E H P T Y • ) STOP

END toff

- 185 -
ENDOGENOUS EVENT F T I U P

FT I UP REMOVES TTFUPS FROM THFTR SETS AND DESTROYS THEM WH[ W

SIMULATED time passes the END-LIMIT of the t i e u p , STOrF RWAY (FT I UP) IN K STORp PT(FTHJP) IN J

DESTROY FTIU p

GO TO ( 1

0

, 20 , 30 ) . J

in RFMOVE FIRST TIfUP FROM OMTI(K)

GO TO 4

0

2 n r f

m

o

w

f first tifup from t h t i t k ) GO TO 40

30 remove first tifup from e R t i ( k ) 40 DESTROY TIFUP

RETURN

end f t

I

u p

ENDOGENOUS F V E N T PRINT

PRINT RECORDS DATA ON EACh FLIGHT AT THE TIME IT ACTUALLY

TOUCHES DOWN OR TURNS ON To THE RUNWAY, AS THE CASE MAY Be‘.

S T 0 r F RWaY(PRINT) IN K STOrf nL A Y f PR I NT ) IN D

STOrf OP ( PR I NT ) IN I DESTROY PRINT

NTOFF and ml AND are the TOTAL NUMBER of TAKFOFFS AND LANDINGS

D U R f N G THIS HOUp.

DELT and dell ACCUMULATE Total delay on TAKEOFFS AND

LANDINGS BY HOUR.

GO T 0 { 1 0 , 2 n ) ,

I 10 L E

T -,N T 0 F F ( I H 0 U R ) * N T 0 E F ( I H 0 IJ R ) 1 L E

T DELT! I H 0 U R ) * D F L T ( I H 0 IJ R ) + D

return

2 0 LET ML. A N D ( I H 0 U R ) = N L A n D ( I H 0 1 J R ) + 1 LET DELL! IhOUR)«DELL( I H 0 U r ) D

RETURN

END PRINT

endogenous event CHOUR

CHOiiR CHANGES the HOUR a N D BEGINS GENERATING FLIGHTS AT THE

rate or operation for TmF new hour,

LET I W 0 U R « I H 0 U R

1

IF I HOUR gt nh, LfT I HOUR® I L E T TsT I MF+ 1 • IE T L E TEMP, CAUSE CHOUR AT T DO TO h FOR EACH 0 I STORE GEnN ( II IN GEN

CANCEL GEN

CAUSE GEN aT T I MF-LAMPD ( I . IHOIJR ) *Al OG ( I .-RANDM j

1 LOOP

RETURN

END CHOUR

- 186 -
ENDOGENOUS fvfnt f n d s

IV R I T F ON TAPE A format (u SUMMARY RfPORT For THIS RUN*///S3. , HnUR*,S10,

] •OPrRATlONS GENFPaTFO»,S10, OPERATIONS PERFORMED* , S J 0 , 7 T 0 T A L DFLAY (MINUTFS)*,S8,*DELAY PER A / C (MINUTES) * / S t S , 3 ’LANDINGS TaKEOFFG TOTAL*, 55, •LANDINGS TAKEOFFS T 0 T A L • j mSG»*LANDINC,S TAKEOFFS aLl*,S7,»L ANOINGS TAKEOFFS ALL’//)

LFT MARR«n

LET MDF.PaO

irT M l A N 0 * n LFT MjOFFsn

LFT RheLTsO,

LFT R 0 F Ll. = D , 00 TO ! , FOR EACH H I LET N I N = N A R R ( I ) M P F P ( I ) L F

T mjrRsma^R + NaRR ( I)

LET M0FP*MDFP+N0FP(I)

LET m 0 p = N L A N 0 ( I ) + N T 0 F F ( r ) LET MLANDaMlAND+NLANOII)

L E

T MTOFFaMTOFF + MTOFFl I ) LET TOFLanFLT ( I ) D E L L ( I > LE t ROFLT«roFLT^oELT ( I ) LFT 8DFLl=RDFLL+DELL(I)

IF NOP E 3 0 , GO TO 3 LET AOELsNOP

LE t AOFL»ToEL/AoFL

IF N L A N D ( I ) o T n * GO TO q LFT A n F L L a n . GO TO R

q LFT A0 FLl = MLAND( I ) LFT AOFLLanFl.Ll I )/ADFLL

S IF M T 0 F F ( M G T n, GO TO A let aoflt=o.

G 0 TO ? A LET AOELTsNTOFF ( I ) LET AOFLTsdELT(I)/ADELT

GO TO 7 3 LET AOFLsO.

LET A D F L L = fl • LF t AofLT=0,

2 WRITE ON Tape 6, I , N A R R f I ) , N D E P ( I ) ,NTN,NLAnO( I ) ,NT0FF( I ) , NnP , lDELL(T),nELT(I), TOE L.ADFLL.AOELT, ADEL

format (Sq, I 2 • S t 2 • I?iS8^l2,SA, 13, S9, I 2 , S 8 , I?,SA» I3,S&»05* 1 .S3

l DS . I , S 1 , D5 . 1 . SS , DS . 1 , S3 , D& • I , S 1 , DS , 1 )

1 LOOP

LET NTN*MARR+MDFP

L E

T NOPsMLAMn + MTOFF

LFT TDFLsRDFLT^RDELL

LET AOFLaNOP

LET AOfLsTDEL / ADEL

let aoeLl=mland # let ADELL«BDELL/ADELL

L r T AOFLTsMTOFF

let AOFLTaRDELT/ADELT

write on tape a, marR.mdfP »nin,mland,mToff,nop*bdell . b d e l t ,tdfi , 1A0ElL.ADELT.ADEL

format ( • 0 . T0TA(F *.Sl0.l3.S7 i l3,S5.fq.sa.I3*57,T3.S5,I l*,S5.n6«l,

1 S 2 t D A . 1 » D A • 1 .SS.D5. 1 . S 3 , D 5 • I »S1 ,05. 1 ) S T 0 p

’ END END? - 187 -
APPENDIX E

CONVERSION TO OTHER COMPUTERS

The model described in this report is currently operable on

the National Bureau of Standards UNIVAC 1108 under the EXEC II

operating system. This conputer has 65,536 36 -bit words of core

storage of which about 53,000 are available under EXEC II. The

model consists of two separate programs, the preprocessor and the

simulation ,which are executed in succession within the same run

under EXEC II. The preprocessor output/simulation input tape is

rewound between the execution of the two programs by a system

utility routine. However, the REWIND instruction could be included

in the preprocessor program if desired. For both programs card

input is from logical unit 5 and printer output is on 6. The airport

data file tape is cn unit 7 and the preprocessor output/simulation

input tape is on 8. The airport file unit may be altered by changing

the value of the variable IN to the desired unit number. The preprocessor output/ simulation input unit may be altered by changing the

value of the variable M in the preprocessor program and putting the

corresponding new value in columns 35 and 36 (and if there are no

explicitly generated flights, in columns 41 and 42 also) on the system

specification card required as input to the simulation program.

- 188 -
The preprocessor program is written in FORTRAN V (the UNIYAC

augmented FORTRAN VI) . Several features which have been used

in the preprocessor program may not be available in FORTRAN IV

compilers on other machines.

1. The PARAMETER statement is used to define the value of

an integer constant which may then appear as a DIMENSION

size limit. Such variables as the maximum number of runways

(KRW) , the maximum number of aircraft types (KTYP) , the

maximum number of departure paths (KFIX) , the number of

operation types (KO) , and the maximum number of interferences

for a runway (KTPT) are all defined in a PARAMETER statement.

The compiler treats these variables as constants , rather

than variables , but their values may be altered by changing

only the PARAMETER statement, rather than every instance

of the occurrence of the value. The- use of the PARAMETER

may be circumvented for compilers lacking this capability

by using fixed DIMENSION limits and setting KRW, KTYP,

KFIX, KO, and KTPT equal to the appropriate constants at

at the beginning of the program.

2. The UNIVAC FORTRAN V permits an end of file condition to be

detected on input through the use of the READ (unit, format,

END = i) , where program control transfers to statement

number i when an end of file is read. This may be

circumvented by using a particular signal sequence of

characters and testing after the READ statement.

- 189 -
3. The FORTRAN V allows the use of quote marks enclosing a Hollerith field in a FORMAT statement and also in an

arithmetic statement such as JAY = ’J\

These may be replaced by the nH form if the compiler does

not have this feature.

4. Mixed-mode arithmetic is correctly performed, and thus

there are no diagnostics for mixed-mode expressions.

Therefore, although care has been taken to avoid such

expressions some may have survived.

The simulation program is written in SIMSCRIPT 1.5. The user

should check the directions for compiling SIMSCRIPT on his particular

machine. On the UNIVAC 1108 SIMSCRIPT 1.5 compiles into SLEUTH,

the assembly language, which is then assembled into machine code

before the program is executed. SIMSCRIPT 1.5 is available on a variety of computers and is quite standard from one machine to the

next since most of the compilers were constructed by the same

company. Some things are machine dependent and should be checked

when using other computers.

1. Some attributes are packed, two to a computer word. The packing

allowed may depend on the computer word size for other

machines

.

2. The SIMSCRIPT compiler on the UNIVAC 1108 allows both LT

and LS although the latter is standard.

- 190 -
3. The 1108 version of the compiler accepts Hollerith strings

enclosed in quotes in addition to the standard nH form*

- 191 -
APPENDIX F

SEPARATION BETWEEN A LANDING AND A PRECEDING TAKEOFF

A landing aircraft which possesses DME must be separated by a distance S (currently 2 miles) from a preceding takeoff on the same

runway. In this appendix, we will derive an expression for the distance

d which must separate the two aircraft when the takeoff starts its roll,

in order that the two aircraft remain S apart. We make two assumptions:

(1) The landing speed Vp is constant along to the final approach path.

(2) The takeoff acceleration a is constant along the runway

and for a short while after liftoff.

The value a of the constant acceleration can be calculated from the

known liftoff speed Vp and the takeoff’s runway occupancy time R, as

a = Vp/R.

Under our two assumptions, the distance Sp the takeoff has gone in t

units of time is

s, = (1/2) a t

2 = 0.5 v

T

t

2

/R.

The distance s^ traveled by the landing in the same time is

s

2 = V

L

Since they start out a distance d apart at any time t they are separated

by a distance D where

D = 0. 5 Vp t

Z /R - Vpt + d.

D must be always greater than or equal to S. Differentiating, we find

that D is minimum when t = R v]Vvp. Since this is the time that the two

aircraft will be closest, we set D = S at that time and solve for d, yielding

Ve assume here and elsewhere in this report that the runway threshold

and the end of the runway are gso graphically the same point. If this were

not true an appropriate distance would have to be added or subtracted from d.

- 192 -
2

d = S + .5 R/v

t

.

Therefore, if the landing is this distance d from the end of the runway

as the takeoff starts its roll, the two aircraft will never be closer

than the required separation S.

- 193-
APPENDIX G

TIEUP TIME RESULTING FROM INTERSECTING RUNWAYS

In order to compute the time at which an intersection point will

become free, it is necessary to know when a landing or a takeoff passes

the intersection. In this appendix we will derive an expression for

the time t it takes an aircraft to travel from the end of the runway

to a point a distance D down the runway, assuming a constant acceleration

a along the runway. The value of this acceleration may be calculated

from the initial speed v , the final speed Vp and the runway occupancy

time R. At any time t the speed v of the aircraft is

v = a t + v . o However, at t = R the speed is v^ so

a = (v-l

- v

q

)/R.

At time t<R, the distance d traveled by the aircraft is

d = 0.5 (v1 - v ) t^/R + v t. K 1 o

J o Setting D = d and solving for t yields

t = -v - /v " + 2D (v.. -v )/R.

o o

v 1 o

(V

1

- v

q

)/R

To ascertain which sign applies here, we note that for D > 0 we must have

t > 0, so we choose the positive sign. Therefore since t - R we have

t = min -v + /v 2 +" 2D(v1 - vj 7k ,R

o o 1 o

(V

1

- V

0)/R

- 194 -
To interpret this for a landing, v

q

is the (constant) landing

speed and is the speed at which the aircraft turns off the runway.

This yields a negative acceleration, i.e. a deceleration. For

takeoffs v is zero since the aircraft starts off at rest, and is the

liftoff speed of the aircraft. In this case t simplifies to

t = min |/2DR/v-p

- 195-
APPENDIX H

(Mock) Instructions on How to Use the KBS

Airport Capacity/Delay Simulation Model

(Note: The Model is referred to here as ’’DELCAP”.)

General Information

DELCAP is physically located within a CDC 6600 computer in the CDC office

building located at 11428 Rockville Pike, Rockville, Maryland. In order to

access it you use the time-share terminal located in Room 803 in building

FOB 10A. The instructions for turning on the terminal equipment in Room 803

and connecting to the Rockville CDC 6600 are contained in a black 3-ring

binder, entitled ’’Computer Connection Instructions,” attached by a string to

the wall of Room 803. This terminal equipment is comprised of a card-reader,

a printer and a Cathode Ray Tube (CRT) display. This equipment and DELCAP are

available for use at any time between 7 a.m. and 8 p.m. Monday through Saturday.

What DELCAP is :

DELCAP is a computer model which can be made to represent any of a broad

range of actual or hypothesized airport configurations (and traffic mixes)

Once you have specified the airport and situation for analysis - which may be

done in either of two ways , in the constructive mode or in the on-file mode -

you may then ask DELCAP for any or all of the following information:

(a) The hourly throughput of the airport.

(b) The average delay per aircraft using the airport.

(c) The average number of aircraft waiting to take off or land.

These quantities are gathered separately for each hour and over a whole

day, and may also be broken down by aircraft type.

- 196 -
How to Provide DELCAP with the Information it Needs:

This may be done by using DELCAP in either its constructive mode or in its

on- file mode . Generally, the constructive mode is to be used when analysis is

required of a proposed new airport design or runway changes to an existing airport. Any experimental runway configuration may be analyzed in this mode. The

on- file mode , by contrast, is to be used when an already -existing airport is

to be analyzed. The runway configurations and traffic forecasts for these airports will be permanently stored within DELCAP. For example, you can obtain the

capacity and delay conditions at WNA if all traffic except medium-size jets

were prohibited, or the throughput and delay conditions at O’Hare in 1985 when

subjected to the most recent traffic forecasts for that year.

The Constructive Mode:

To use DELCAP in this mode you would type in the following

(1) The description of the airport

(1-1) For each runway, its heading and the distance to the outer

marker, e.g. runway 1, heading 170 degrees, distance to outer

marker 8 miles.

(1-2) For each pair of intersecting runways, the distance from the

end of first runway to the intersection with the second, and

the distance from the end of the second runway to the intersection with the first, e.g. 3, 1, 5050., 3020. Runways 3

and 1 intersect at a point 5050 feet from the end of runway 3

and 3020 feet from the end of runway 1.

(1-3) For each pair of parallels whether or not they have independent

approaches and whether takeoff on one are independent of landings

on the other.

- 197 -
(2) The description of the traffic using the airport.

(2-1) Aircraft mix by type of aircraft e.g. 9% large jets, 371

medium jets and large propeller, 26% medium propeller and small

jets, 181 light twin engine, 10% single engine.

(2-2) Number of arrivals and number of departures per hour for each

hour of the day

(2-3) Any explicit arrivals or departures to be added to the Poisson

generated flights resulting from (2-2)

.

(2-4) Distribution of use of departure paths for each runway.

(3) Description of certain airport parameters

.

(3-1) Mix of runway use by aircraft type for landings and separately

for departures e.g. 40% of large jets land on rumay 1 and

60% on runway 2. 20% of large jets take off from runway 1 and

80% from runway 2.

(3-2) Minimum spacing rules

a. Interlanding e.g. 3 miles for IFR approaches

b. Landing following a takeoff e.g. 2 miles

c. Between takeoffs - one for those using the same departure

path, and another for those using different departure paths

9 for the same runway e.g. 1 minute between departures using

different paths and 3 miles between departures using the

same path. With noise abatement procedures in force the

1 minute might be increased to 2 minutes

.

(3-3) Aircraft type characteristics.

e.g. final approach speed, typical runway occupancy time for

each type of aircraft.

- -198 -
The On- File Mode:

To use DELCAP in this mode you must type in the following:

(1) Airport designator e.g. (JFK)

(2) Any changes to filed items (2) or (3) of the Constructive

Mode Parameters.

- 199 -