Full text of "DTIC ADA011987: Simulating Maintenance Manning for New Weapon Systems: Building and Operating a Simulation Model"

See other formats

flOAOll 987

AFHRL-TR-74-97(ll)

AIR FORCE

1 99071

SIMULATING MAINTENANCE MANNING
FOR NEW WEAPON SYSTEMS:

BUILDING AND OPERATING
A SIMULATION MODEL

Donald C. Tetmeyer, Major, USAF

ADVANCED SYSTEMS DIVISION
Wright-Patterson Air Force Base, Ohio 45433

William D. Moody, SMSgt, USAF

Headquarters, Air Force Systems Command
Andrews Air Force Base, Maryland 20334

December 1974

Final Report for Period July 1971 — May 1974

Approved for public release; distribution unlimited

LABORATORY

Reproduced by ‘ VV<-> >Ia

NIATIOWAI TCrukiiSSii: m

Reproduced by

national

INFORMATION SERVtCE

M S Department of Commerce

Springfield VA 22151

AIR FORCE SYSTEMS COMMAND

BROOKS AIR FORCE BASE, TEXAS 78235

NOTICE

When US Government drawings, specifications, or other data are used
for any purpose other than a definitely related Government
procurement operation, the Government thereby incurs no
responsibility nor any obligation whatsoever, and the fact that the
Government may have formulated, furnished, or in any way supplied
the said drawings, specifications, or other data is not to be regarded by
implication or otherwise, as in any manner licensing the holder or any
other person or corporation, or conveying any rights or permission to
manufacture, use, or sell any patented invention that may in any way
be related thereto.

This final report was submitted by Advanced Systems Division, Air
Force Human Resources Laboratory, Wright-Patterson Air Force Base,
Ohio 45433, under project 1124, with Hq Air Force Human Resources
Laboratory (AFSC), Brooks Air Force Base, Texas 78235.

This report has been reviewed and cleared for open publication and/or
public release by the appropriate Office of Information (01) in
accordance with AFR 190-17 and DoDD 5230.9. There is no objection
to unlimited distribution of this report to the public at large, or by
DDC to the National Technical Information Service (NTIS).

This technical report has been reviewed and is approved.

GORDON A. ECKSTRAND, Director
Advanced Systems Division

Approved for publication.

HAROLD E. FISCHER, Colonel, USAF
Commander

THIS DOCUMENT HAS BEEN REPRODUCED FROM THE
BEST COPY FURNISHED US BY THE SPONSORING
AGENCY. ALTHOUGH IT IS RECOGNIZED THAT CER-
TAIN PORTIONS ARE ILLEGIBLE, IT IS BEING RE-
LEASED IN THE INTEREST OF MAKING AVAILABLE

AS MUCH INFORMATION AS POSSIBLE.

-tv

r :• •

REPORT DOCUMENTATION PAGE

t. REPORT NUMBER

AFHRL-TR-74-97(II)

|2. GOVT ACCESSION NO.

4. TITLE (and Subtitle) - '

SIMULATING MAINTENANCE MANNING FOR NEW WEAPON
SYSTEMS: BUILDING AND OPERATING A
SIMULATION MODEL

7. AUTHORf*)

Donald C. Tetmeyer
William D. Moody

9. PERFORMING ORGANIZATION NAME AND ADDRESS

Advanced Systems Division

Air Force Human Resources Laboratory

Wright-Patterson Air Force Base, Ohio 45433

It. CONTROLLING OFFICE NAME AND ADDRESS

Hq Air Force Human Resources Laboratory (AFSC)
Brooks Air Force Base, Texas 78235

14. MONITORING AGENCY NAME ft ADDRESSES ditterent from Controlling Office) IS. SECURITY CLASS, (of this report)

Unclassified

ISa. DECLASSIFICATION/ DOWN GRADING
SCHEDULE

16. DISTRIBUTION STATEMENT (ot thta Report)

READ INSTRUCTIONS
BEFORE COMPLETING FORM

5. TYPE OF REPORT,* PERIOD COVERED

Final

July 1971 -May 1974

6. PERFORMING ORG. REPORT NUMBER
8. CONTRACT OR GRANT NUMBERfa)

10. PROGRAM ELEMENT. PROJECT, TASK
AREA * WORK UNIT NUMBERS

62703F

11240403

12. REPORT DATE

December 1974

13. NUMBER OF PAGES

Approved for public release; distribution unlimited.

17. DISTRIBUTION STATEMENT (of the abstract entered in Block 20, it different from Report)

18. supplementary NOTES

This report is the second in a series of 5 volumes.

19. KEY WORDS (Continue on reverse aide if necessary and identity by block number)

maintenance

manpower

simulation

20. ABSTRACT (Continue on reverse aide if neceaaary and identify by block number)

There is a need for a more responsive method for predicting maintenance manpower requirements for aircraft
systems during development. This method should provide early estimates for use in trade offs and evaluations, and
should be sensitive to the ways in which the new aircraft will be employed. A maintenance manpower simulation
model was developed. In using the model, early estimates of maintenance task data for the new aircraft are based on
Air Force experience with comparable subsystems and equipment on existing aircraft, factored for the new design
and environment. These data are meshed with a detailed operations scenario and support concept assumptions in a
model run on the Logistics Composite Model (LCOM) simulation program. The simulation output is iterated and

DD i jan "73 1473

EDITION OF 1 NOV 65 IS OBSOLETl

Unclassified

L ASS I F!C AT ION OF THIS PAGE (When Dele Ent eted)

‘ ^ Unclassified

SECURITY CLASSIFICATION OF THIS PAGEfHTian Data Entered) ,

Item 20 (Continued)

analyzed in post-processor programs whose final output is a complete basic manning authorization document. This
entire effort is reported in a five volume technical report. This volume II describes the procedures developed to build
a maintenance simulation data base for a new aircraft, to run it with the Logistics Composite Model (LCOM)
computer program, and to use the results to predict the maintenance manning required for a new aircraft flying a
specific operations scenario. Computer programming knowledge is not necessary to follow and apply this
instruction. Hie procedures presented have been tested and used at the Aeronautical Systems Division of Air Force
Systems Command in building and operating simulation models of A-10 and A-7 aircraft.

• •

Unclassified

SECURITY CLASSIFICATION OF THIS PAGE(T*7i»n Data Entered)

SUMMARY

Problem

There is a need for a more responsive method for predicting mainte-
nance manpower requirements for aircraft systems during development.

This method should provide early estimates for use in trade offs and
evaluations, and should be sensitive to the ways in which the new aircraft
will be employed.

Approach

A maintenance manpower simulation model was developed. In using the
model, early estimates of maintenance task data for the new aircraft are
based on Air Force experience with comparable subsystems and equipment on
existing aircraft, factored for the new design and environment. These
data are meshed with a detailed operations scenario and support concept
assumptions in a model run on the Logistics Composite Model (LCOM) simula-
tion program. The simulation output is iterated and analyzed in post-
processor programs whose final output is a complete basic manning
authorization document. This approach was evaluated by applying it to
the A- 10 Weapon System.

Results and Conclusions

The methodology and models were successfully applied on the A-10
program and are being considered for implementation on other aeronautical
systems in or entering development. This method provides useful mainte-
nance data in a more timely manner, can be rapidly updated, and can show
the sensitivity of manning requirements ,to a wide range engineering design,
support and operations alternatives. During the project procedures were
developed to build a maintenance simulation data base for a new aircraft,
to run it with the LCOM computer program, and to use the results to
predict the maintenance manning required for a new aircraft flying a
specific operations scenario. These are described in this report.

PREFACE

This .report is the second of five volumes describing a new method
for determining the maintenance manpower requirements of new aircraft*

Volume I - Maintenance Manpower Management During Weapon System /
Development /

Volume II - Building and Operating a Simulation Model
Volume III - Maintenance Data Analysis Programs
Volume IV - Data Base Management Programs
Volume V - Manpower Programs \

. ... L

kv This volume provides a detailed description of the procedures for
using the Logistics Composite Model (LCOM) to determine maintenance man-
power required for a new weapon system. It is intended to service as a manual
of instruction and methodological source document. These procedures were
developed by a joint research and development team Oat the Advanced Systems
Division, Air Force Human Resources Laboratory (AFSC^,' Wright-Pat terson AFB,
Ohio. The team included collocated members from the Headquarters Air Force
Systems Command and the A- 10 Program Office, under the 'general guidance of
a steering group at Headquarters Air Force Systems Command. Laboratory
work was conducted under Project 1124, Human Resources in Aerospace System
Development and Operation, Melvin T. Snyder, project scientist, and Task
112404; Adaptation of Operational Research Techniques to Air Force Human
Resources Problems, Major Donald C. Tetmeyer, task scientist.

The work was initiated in July 1971 when the proposed research and
development plan was approved by the Air Force Systems Command Council.
This plan was documented in AFHKL-TR-74-31.

All members of the team and participating organizations who worked on
the simulation models contributed to the final methodology. In addition to
the listed authors, they include Mr. Frank Maher, Mrs. Sharon Nichols, and
Dr. Richard Luckew of the Air Force Human Resources Laboratory: Mr. Craig

McLean, Maj Michael Vasilik, Capt Eugene Benson, Capt Paul Verdier, Capt
Carroll Widenhouse, Capt David Welch, Capt John Mallar and SSgt Thomas
Shipley of the A- 10 Program Office; Maj Michael York of Hq Air Force Systems
Command; and Mr. Wayne Jansen, Maj Bobby Green, and Mr. Nathan Davis of the
Aeronautical Systems Division. The generous cooperation of the LCOM program
author, Mr. William Drake of Headquarters Air Force Logistics Command, and
of the Headquarters Tactical Air Command LCOM Simulation Modeling Team of
Lt Col Gerald Thompson, Maj Richard Gunkel, Mr. Robert Leckliter, and Mr.
Owen Dinger, made the work much easier. The effort might never have been
brought to a successful conclusion without the visibility, support and
guidance provided by the Headquarters Air Force Systems Command Steering
Committee: Lt Col Robert Mathias and Lt Col William Pope of the Deputy for

Systems, who served successively as chairman; Lt Col Thomas Castaldo and
Lt Col Joseph Beardsley of the Deputy for Operations (Management Engineering)
and Lt Col John Ahlborn of the Deputy for Science and Technology.

TABLE OF CONTENTS

Page

I. Introduction 9

Why Use a Simulation? 9

An Overview of the Procedure. 10

How the Simulation Works 10'

Relationship of the Input Formats 13

II. Defining an Operations Schedule 13

Coordinating the Assumptions 13

Developing a Basic Schedule ... 16

Entering Mission Data on Forms 20 17

Phase and Periodic Inspections 19

Entering Alert Missions on Forms 20 and Forms 15 20

Scheduling Total Requirements for Combat 23

Scheduling Total Requirements in Peacetime 25

Network Entry Points on Forms 17 28

Additional Scenarios 28

III. Main Aircraft Servicing Networks 28

Content and Data Sources 28

Coding the Networks 32

Coding Network Call Sections 36

Including Provisions for Unscheduled Maintenance 36

Preflight to Postflight Network 37

Networking Turnarounds and Scheduled Inspections 39

Networking Alert Missions 40

Networks for Peacetime Flying 47

IV. Corrective Maintenance Networks 47

Content and Data Sources 47

Procedure 51

Network Structure 53

Coding Conventions 55

Using the MDC Data Bank 56

Computations with MSBMA 62

Network with Expendable LRUs 65

Engine Network 71

Complex Avionics Networks 76

Table of Contents (Continued)

Page

V. Networks for Phased and Periodic Scheduled Maintenance. ... 85

Phased Inspections 85

Other Scheduled Inspections and Time Change Items 90

VI. Building a Data Base 91

Data Base Processing 91

Debugging with Phase I . 94

Translation into LCOM ...... 97

Building an LCOM Input File 100

Debugging the Input Processor 106

Establishing the Operations File 108

VII. Testing and Operating the Simulation 109

LCOM Run Parameters 109

Test Deck Setup and Checkout Ill

Establishing Run Length 113

Full Simulation with Matrix Output 115

VIII. Iterations to Constrain Direct Manning 118

General Concept and Method 118

Computing Daily Requirements 119

Allocating Daily Manning to Shifts 121

Procedure for Constraining Manning 123

Computing Direct Manning 124

Example of Manning Computations 126

IX. Determining Manning Requirements 126

Integrating Simulation Results 126

Producing a Basic Manpower Authorization Document 129

Variations and Updates 131

References 134

List of Symbols and Codes 135

LIST OF ILLUSTRATIONS

Figure Page

1 Model development and operation 11

2 How the simulation works . 12

3 Relationship of inputs . 14

4 Example of missions repeated daily 18

5 Cumulative probability distribution of takeoff

times for night alert *. . . 21

6 Form 15 for night alert missions 22

7 Alert missions 24

8 Example of a 24 aircraft combat schedule 26

9 Example of a 24 aircraft peacetime schedule 27

10 Example of Form 17 29

11 Example of mode 2 preflight to postflight network 31

12 Example of mode 2 preflight to postf light network coding . . 33

13 Relationship of mode 1 and mode 4 networks 41

14 Example of mode 4 thru flight to postflight network coding . 42

15 Example of alert mission network 44

16 Example of mode 3 network coded with preflight

and hangar dummies 48

17 Subsystem corrective maintenance network basic logic .... 54

18 Data bank printout for VHF radio on-aircraft work 58

19 Schematic of VHF radio network 59

20 VHF Radio network coding 60

List of Illustrations (Continued)

Figure Page

21 Data bank printout for VHF radio shop work 63

22 Data bank printout for external lighting

on aircraft work 66

23 Data bank printout for external lighting shop work 67

24 External lighting network coding 69

25 Schematic of engine network 72

26 Engine network coding. . . 73

27 Data bank printout for FLR on-aircraft work 77

28 Data bank printout for bombing system special inspections. . . 78

29 Data bank printout of intergrated avionics

system CND troubleshoot^^ 79

30 Schematic of FLR network .. . ■ . T 81

31 Integrated avionics FLR subsystem network 82

32 Data bank printout of AFSC 424X0 unscheduled maintenance

in phase . . . 87

33 Phase network example. 88

34 Scheduled maintenance examples ...... 92

35 Five steps in processing a simulation data base 93

36 Sample DBASE corrections using update 98

37 LCOM input processor file 99

38 Format for LCOM 10 cards 101

39 Sample update entries to supplement an FDATA file 102

40 LCOM run parameters 110

List of Illustrations (continued)

Figure Page

41 Example LCOM test run parameter cards 112

42 Representative extracts from an analysis

of run length test data . 116

43 Simulation run sequence ' 117

44 Factors determining daily direct manning

requirements for an AFSC 120

45 Work center matrix 122

46 Criteria for rounding in manpower computations ....... 125

47 Example of manning constraint tabulation 127

48 Regression and Moody manpower programs 130

49 Curve shifting 132

SIMULATING MAINTENANCE MANNING FOR NEW WEAPON SYSTEMS:
BUILDING AND OPERATING A SIMULATION MODEL

I. INTRODUCTION

Why Use a Simulation?

Any model is a simplification of reality. A model is designed to
answer a particular kind of question. Once tested and proven, the model
can be used to predict and answer rather than having to find out by trial
and error each time. The simplifications that are acceptable in any
particular model depend on the question the model was designed to answer.

The ideal model contains the minimum amount of information to give a use-
ful result.

Mathematical models are the basis of science and engineering work,
and are commonly used in many other fields as well. Mathematical models
consist of equations. The simplification made in using mathematical
models is in the number of variables and criteria that are considered at
one time. For example, manning can be computed precisely from a mainte-
nance manhour per flying hour equation: All you need to know is the MMH/FH

factor for the airplane and the number of flying hours. The drawback of
using this model is that maintenance manhours per flying hour is not really
a constant (Donaldson & Sweetland, 1968). Variables other than these two
determine the manning that will actually be needed in a given situation.

The unit size; the takeoff pattern; frequency of turnarounds; and the
sequence in which jobs by different specialists must be done; all effect
where bottlenecks will occur, and the number of people required at particular
times to overcome them. Information needed to answer questions about
required manning and the support resource mix under specific operational
conditions cannot be adequately handled in a single equation or. set of
equations.

Many people are not aware that mathematical equations are not the
only kind of available model. Simulation models utilize the tremendous
speed and storage capacity of modern digital computers to duplicate the
complex sequence of events over time. In effect, the answer is obtained
by trial and error experience run in a computer instead of in the real
world. Simulation is ideally suited to answering complex questions about
the manning and resource support mix that will be required by a new air-
craft under a range of different operational conditions. However, it is
not an answer to everything. Even large computers have capacity limits.

The more complex a model, the more costly it is to run, and the greater
the chance for preparation error. The principle that nothing should be
included that does not affect the answer is just as Important in simula-
tion as in mathematical models, or the purpose and essential logic will
be lost in a maze of sophisticated trivial data.

Preceding page blank

An Overview of the Procedure

The method described in this report is based on using a Logistics
Composite Model (LCOM) simulation (Drake et al., 1970) to predict the
manning requirements for a new aircraft. The procedures cover how to
build a data base and set up the model logic, how to run the simulation,
and how to interpret and use the results.

Figure 1 illustrates the major elements in this modeling process. The
maintenance tasks required on the new aircraft are estimated from Air Force
experience with similar subsystems on existing aircraft, factored for dif-
ferences in design. Experience data is obtained from a maintenance data
bank, described in AFHRL-TR-74-97(III) . The first block in Figure 1
represents use of the data bank programs to obtain comparable data from a
number of current aircraft.

The second block in Figure 1 represents the maintenance task and
operations scenario data bases that must be constructed for the new aircraft.
When processed through a series of translation programs, these data comprise
the input to the third block, the LCOM simulation.

The simulation model is iterated until the minimum manning necessary to
accomplish the required scenario is determined. In the fourth block, the
result of several simulation runs are taken to compute regression curves for
direct manning, overhead factors added, and a manning document produced.

How the Simulation Works

The necessary inputs (Block 2) to the LCOM program (Block 3) include:
daily mission schedules, defining when aircraft are to fly and for how
long; main aircraft servicing networks, defining the tasks, times, and
resources to prepare and launch an aircraft at its scheduled time and service
it on return; corrective maintenance networks defining the tasks, times,
and resources to fix each subsystem when it breaks; failure clocks and
derements, defining how frequently each subsystem is likely to require
corrective maintenance; and the initial quantities of each resource (aircraft
by type, men by AFSC and shift, LRU spares, ground equipment).

Figure 2 is a simplified diagram showing how the program uses these
inputs to simulate a sequence of maintenance activities that would take place
in an operational unit attempting to fly the specified schedule. When the
schedule calls for an aircraft to start preparation for a mission, the
computer checks the number of aircraft in available status (those not flying
nor in maintenance) and assigns those needed to the mission. Each of the
assigned aircraft then begins processing through the appropriate main aircraft
servicing network, using the resources needed for the simulated time specifier
in the task data. The computer keeps count of each resource. For example,
when all the load teams are already working on aircraft of equal or higher
priority, the loading task on another aircraft will be delayed until a load

Figure 1. Model

•H

«H

3 >

*rl

team becomes available. If enough aircraft are ready to go by scheduled
takeoff time, the planes are launched and "fly" for the specified mission
duration. At the end of this time, they return to base and process through
the post sortie servicing and maintenance tasks.

The program keeps a failure clock on each subsystem. A random draw is
made from a subsystem failure distribution to determine the number of sorties
until the next corrective maintenance action on that subsystem will be
required. Whenever an aircraft flies, each failure clock on its subsystems
is advanced one sortie. When the sum of sorties flown reaches the randomly
drawn number for a subsystem, the computer lists it as a required corrective
maintenance action on that aircraft. The tasks in the corrective maintenance
network for that subsystem must be worked off before the aircraft can be
returned to available status.

The lower the initial resource levels, the more tasks are delayed, air-
craft take longer to return to available status, and fewer missions are
accomplished. The extent of the mission loss depends on the timing of the
mission schedule and resultant bunching of resource demands.

Relationship of the Input Formats

The hierarchic relationships among input data are illustrated in Figure
3. An operations schedule is contained on LCOM Forms 20. An LOOM Form 17
identifies the appropriate main aircraft servicing network to be processed
for each mission type. These networks are entered into the data base on
extended Forms 11. Networks define the sequences of tasks to be accomplished
and the time and resources required for each task. The main networks also
contain appropriate clock decrement and call tasks. Decrement tasks specify
when and on what basis subsystem clocks are to be advanced, and the call
tasks specify when they are to be checked and any required maintenance
accomplished. The corrective maintenance networks and the failure distri-
butions for each subsystem are entered into the data base on extended
Forms 11.

The next four sections contain detailed instructions on how to develop
and prepare input data. Section II covers the operations scenario (LCOM
Forms 20, 17, and 15). Section III describes the main networks. Section
IV the corrective maintenance networks, and Section V the phase and periodic
inspection networks, all of which are entered into the maintenance data base
on extended Forms 11. The methods and formats described have been developed
to work with the LCOM program version and related data analysis and data
management programs available on the Aeronautical Systems Division CDC 6600
computer. Minor variations may be necessary to work with LCOM versions
programmed on other computer systems.

II. DEFINING AN OPERATIONS SCHEDULE
Coordinating the Assumptions

Often, the most difficult step in building an operations scenario is
getting agreement on the specific mission requirements. These requirements

MISSION

Figure 3. Relationship of inputs.

must be coordinated and agreed to among the decision makers and organizations
who are going to use the end results. Few combat aircraft have only a single
mission and single possible mode of operation in all situations. Operations
scenarios can range from a low sustaining rate of peacetime training flying
by a full wing at an established CONUS base, to a round-the-clock combat
surge by a single squadron deployed at a forward base. Scenarios must be
defined that are appropriate to the decisions and plans that will be made
with the model results. The CONUS wing training scenario, cannot be used to
determine manning for a deployed squadron in combat.

The requirements office in the operating command is a primary source of
information on operations plans for new aircraft. The general questions that
must be answered to define a scenario are:

Is it combat or peacetime?

How many aircraft are based at the same location?

What level of maintenance is available at the base? (e.g., do they
have field maintenance capability, or is that provided at some other
"home" base?)

Are there any other aircraft types sharing the same field maintenance
shops and facilities?

What is the desired sortie generation rate, in sorties per aircraft
per day?

What is the average sortie length?

Sortie rate x sortie length x flying days in a month gives flying
hours per aircraft per month. Is this result acceptable? '

What are the missions and load types? These should be defined in
a mission-load matrix. Consider wing tanks, camera film, gun
ammunition, pods, etc., as types of loads.

Which load configurations could be substitutes? (i.e., if a mission
requires Load A, but an aircraft cannot be prepared in time, could a
ready spare aircraft with Load B be used? If so, B is a substitute
for A.)

What proportion of the total sorties does each mission type represent?

What is the average mission length, the desired number of aircraft,
the minimum number of aircraft, and priority for each mission type?

How soon after scheduled take-off time will a mission be cancelled
if the minimum number of aircraft are not ready?

What is the policy for preparation of ground spare aircraft?

What proportion of the aircraft scheduled to fly per day will be
turned to fly a second time if possible?

What is the proportion of day and night flying by mission type?

What is a typical daily schedule (fragmentation order)? Is it basically
similar for the entire period to be simulated?

Are all available aircraft that are not scheduled to fly preflighted
and available to load and fly if necessary?

What is the variability on mission lengths?

Do any aircraft stand alert? If so, how many and for how long? What
mission types fly off alert, and what is the sortie generation rate
for alert aircraft?

How many weather days and weather cancellations are likely, and what
mission types are affected?

What is the period or schedule for major inspections (Phase, corrosion,
gun, etc.)?

Developing a Basic Schedule

The first step is to reduce the number of load and mission types as
much as possible. Missions which have substitutable loads, require the
same load times and crews, require the same pre and post sortie servicing,
and have reasonably similar mission lengths can be grouped under a single
mission type, regardless of what they do in the air. LCOM simulates what
happens on the ground. Time in the air is just time the aircraft is out of
consideration as far as the simulation is concerned.

When the number of missions types are reduced to a minimum, a daily
flying schedule is laid out. Schedule the takeoff time of each mission
and identify the mission type, the number of aircraft per mission, and
whether the aircraft are on their initial flight of the day or were turned
after a previous flight. Alert missions are not scheduled. The sortie
rate, average mission length, and flying hours per aircraft per month
derived from this schedule, plus alerts, must match the respective assumptions.
This may require several iterations and adjustments of assumptions until a
consistent set is obtained. The computation is:

Sortie rate

Scheduled sorties + Alert sorties
Number of aircraft

The assumed proportion of spare aircraft are added, distributed across
the non-substitutable mission types. These spares are put on initial flights.
In order that they are not released too early, a proportional requirement
for additional spares can be put on turnaround flights. This will hold any
spare aircraft not used in the morning for afternoon or evening turnarounds.
This method of handling spare aircraft is unique to the ASD CDC 6600 version
of LOOM.

The same basic flying schedule should be repeated each simulated day
wherever this is a reasonable assumption, since it greatly simplifies
preparation of input data on the LOOM Forms 20 (sortie generation data) .

Entering Mission Data on Forms 20

Each mission is a line entry on the Form 20 (Figure 4). All missions
which fly on the first day have a 1 in column 7. Column 12 will always be
1, since a separate line entry is used for each mission. Takeoff time, in
24 hour clock time, is entered in columns 15 - 18. The aircraft type is
entered in columns 20 - 25, and the mission type in columns 27-32.

A unique name is given to each mission type. Many missions of the

same type may fly on the same day, or even at the same time, as long as
each is a separate line entry on the Form 20. Mission types must be further
subdivided according to the kind of preflight and postflight processing
tasks required. The last digit (column 32) of the mission type identifies
the processing mode, as follows:

1 = Preflight to thruflight

2 = Preflight to postflight

3 = Thruflight to thruflight (also used for first flights when aircraft

preflight is scheduled with a separate Form 20 line entry)

4 = Thruflight to postflight

When preflight is scheduled separately from the missions, the preflight
task is followed by a dummy "sortie" with a minimum constant "mission length"
of one tenth of an hour. This is the minimum simulated time entry for
processing with CDC 6600 LCOM. The dummy sortie does not represent any
flying but is just a mechanism for scheduling a block of aircraft into the
preflight task, and getting it listed in the simulation output statistics.

The time when preflight should be completed is entered as "takeoff time" in
columns 15 - 18. ,

The minimum number of aircraft that must be ready for the mission to
fly is entered in columns 34 - 35, and the scheduled number in columns 36 - 37.
If preparation of a ground spare is to be shown with a mission, is entered in
column 39. For preflight dummy sorties, the maximum number to be preflighted
if available is entered in column 36 - 37, and a minimum 2 is entered in
column 35. No spares are ever indicated for a preflight dummy.

. Example of missions repeated daily.

Mission length in hours, with decimal, is entered in columns 41 - 45,
and standard deviation in columns 47 - 52, both right justified. An H is
placed in columns 46 and 52 to indicate that the time units are hours. The
distribution type is entered in column 53. N indicates a normal distribution.
For tactical fighters, mission times are generally normally distributed with
standard deviations about ten percent of the mean mission length, although
this may vary for specific scenarios and aircraft with loiter capability.

Leadtime on the Form 20 has a unique meaning. It is not the amount
of time it takes to get the aircraft ready, but rather the earliest time
before takeoff when work would begin to get the aircraft ready. This can
never be less than the sum of the mean task times, but must be somewhat
greater to account for randomness in the task times and resource availability.
The leadtime is entered as hours, with decimal, in columns 55 - 57, with an
H to indicate the units in column 58.

Cancel time is the amount of time that will be allowed after scheduled
takeoff for the mission aircraft to finish preparation and takeoff late, in
the event the minimum number is not ready at takeoff time. Typical policies
in tactical units are to allow a half hour to an hour before cancelling the
mission, but this depends to some extent on the missions and situation
being modeled. Longer cancel times can be used for preflight dummies. The
cancel time is entered in hours, with decimal, in columns 60 - 62, and an H
to show it is in hours is entered in column 63.

Numerical mission priorities are entered in columns 65 - 66. Priority
1 is highest, and is usually reserved for missions flown from alert. The
cycle fields indicate how the scheduled is repeated on subsequent days. A
1 in column 70 indicates the mission is to be flown at the time shown in
columns 15 - 18 every day, a 2 in column 70 indicates it is to be flown
every other day, etc. If columns 68 - 70 are left blank, the mission is
flown only on the day indicated in columns 5-7. When missions are
repeated 999 should be entered in columns 71 - 73, unless there is a specific
day when the repetition cycle is to stop. In that case, the day on which
the mission stops recurring is entered in columns 71 - 73. A more detailed
explanation of the various Form 20 entries can be found in the LOOM Users
Reference Guide (Drake et al., 1970).

Phase and Periodic Inspections

Major inspections that tie an aircraft up a flying day or longer (such
as phase or periodics), and major inspections that are done at fixed calendar
time intervals (such as 45-day corrosion wash and annual gun teardown) , are
scheduled on the Forms 20. The inspection tasks follow a dummy "sortie" with
"mission length" a constant one tenth of an hour. The dummy sortie does not
represent any flying, but is just a mechanism for scheduling aircraft into
inspections and getting data on inspections accomplished listed on the
simulation output. The inspection dummy sorties are entered on the Forms
20 with unique identifying mission names. In this case, the inspection work

will follow the dummy sortie, so the time work is to begin is entered in
columns 15 - 18. Work will not begin until the scheduled time, so a long
leadtime can be entered to "grab" an aircraft.

The inspection frequency is computed for the programmed flying hours
(scheduled plus alert) and number of aircraft. For example, if there are
72 aircraft, flying 50 hours per aircraft per month, and the phase interval
is every 100 hours, each aircraft will require one phase every two months,
and there will be 36 phases per month. This is scheduled on the Form 20
as one phase every day, and an additional line entry for 4 phase every 5
days (5 in column 70). If there are 72 aircraft, an annual gun inspection
would come up every 5 days, and would be scheduled in a similar manner.

Entering Alert Missions on Forms 20 and Forms 15

Alert missions by their nature are not scheduled. The LOOM program
provides a mechanism for launching a predetermined number of aircraft
from alert at different randomly drawn times each day. Instead of specify-
ing a takeoff time in columns 15 - 18 of the Form 20 line entry, an asterisk
and distribution number are indicated.

The distribution is then defined on a Form 15 with the distribution
number entered in columns 5 - 7 of the form. Column 9 contains an I (for
continuous interpolation) , and H is entered in column 11 to define the
time units as hours. Cumulative probabilities from 0.0 to 1.0 are entered
in columns 13-16, 23-26, 33-36, etc. The corresponding points on the
takeoff time curve are entered as decimal hours in columns 17-22, 27-32,

37 - 42, etc. Figure 5 is an example of a cumulative probability curve of
takeoff times for a night alert mission. The periods of greatest activity
are from 0300 - 0700 and 2200 - 2400. The Form 15 entry for this curve is
shown in Figure 6 . Note that it can be continued on a second line where
necessary.

When preflight is accomplished before aircraft are put on alert, and
postflight is done while they are in alert status awaiting a mission, or
after they are taken off alert, then 3 will be entered in column 25 for all
alerts, since they will all process through the networks as mode 3, thru-
flight to thruf light. The preflight tasks to prepare aircraft for alert,
and the postflight tasks after they are taken off alert, are scheduled as
dummy missions with separate Form 20 line entries.

In order to make the program keep aircraft tied up on alert between
missions, the average time between alert missions is entered as leadtime in
columns 55 - 58. This is computed as the time on alert, less the time flying,
divided by the number of sorties flown:

Leadtime = Al ert Duration - (Alert Sortie Rate x Avg. Sortie Length)

Alert Sortie Rate

1.00

00.00 03 . 0006 . 0009.00 12.00 15.00 18.00 21.00 24.00

TIME OF DAY IN DECIMAL HOURS

PERIOD OF DAY
IN DECIMAL HOURS

PERCENT OF ALERT MISSIONS
OCCURRING IN THIS PERIOD

CUMULATIVE PROBABILITY

00.00 - 03.00

0 + .10 = .10

03.00 - 07.00

.10 + .50 = .60

07.00 - 18.00

.60 + 0 = .60

18.00 - 22.00

.60 + .10 = .70

22.00 - 24.00

.70 + .30 =1.00

Figure 5. Cumulative probability distribution of takeoff times for night alert.

2 ]

I * Interpolate

A sample Form 20 for alert missions is shown in Figure 7. In this
example, there are 8 alert aircraft, a 3.0 alert sortie rate, 2.34 hour
average sortie length, and a 24 hour alert duration, giving a 5.7 hour
leadtime. Aircraft are prepared for alert before midnight. The "takeoff
time" in columns 15 - 18 of the "on alert" dummy mission represents
completion of the preflight. Sufficient time is allowed for completion
of additional processing tasks shown in the mode 3 main aircraft servicing
networks so that the new aircraft will be ready to fly at midnight when
their alert turn begins. The "takeoff time" in columns 15 - 18 for the
"off alert" dummy mission represents the latest time for starting postflight
on aircraft coming off alert. The leadtime and "takeoff time" are both
set to 4 hours in this example. This allows sufficient time to catch all
aircraft returning from late alert flights. With this coding, any aircraft
on the alert pad at midnight, and any returning from late alert missions
within the next 4 hours, will process into a postflight. The relationship
between dummy sortie takeoff times and their associated network tasks is
discussed further in Section III.

Scheduling Total Requirements for Combat

In combat all available aircraft are usually preflighted every day,
and preflights are accomplished as organizational maintenance mechanics
can get to them, rather than at a single fixed time. Under these assumptions,
preflight tasks for mission aircraft are entered within the mode 1 (preflight
to thruf light) and mode 2 (preflight to postflight) networks. Preflight
dummy missions are only required for the remaining available aircraft that
are not scheduled to fly, and to bring aircraft up onto alert. All aircraft
that fly must receive a postflight at the end of the day. Therefore, any
aircraft scheduled for a mode _ 1 mission (preflight to thruflight) must also
be scheduled for a mode 4 mission (thruflight to postflight) later that day.
Enough time must be allowed between takeoffs to fly and do all between flights
servicing tasks.

Under these assumptions the following relationships must be maintained
on every simulated day:

Aircraft Scheduled = (mode 1 missions maximum aircraft + mode 2 '

missions maximum aircraft + mode 1 mission
spares + mode 2 mission spares + phase and
scheduled inspection dummy missions +
number of aircraft on alert)

Additional Preflights = Total Aircraft - Aircraft Scheduled

Mode 1 Missions Maximum Aircraft = Mode 4 Missions Maximum Aircraft

Aircraft must be assigned to mission and inspection requirements first.
Additional scheduled preflights will not all be accomplished, since many
of the remaining aircraft will be down for maintenance. To assure that
mission requirements take precedence, the preflight dummy missions are
scheduled so their scheduled time minus leadtime falls after the scheduled
takeoff minus leadtime of the last mode 1 and morning mode 2 missions, but

Figure 7. Alert missions

before the scheduled takeoff of the first mode 3 mission. An example combat
schedule for a 24 aircraft squadron is shown in Figure 8. The scheduled
sortie rate is 1.15 (Section II). There are 19 aircraft scheduled per day.
Phase and corrosion wash are done on alternate days.

Scheduling Total Requirements in Peacetime

In a peacetime CONUS scenario, aircraft are often preflighted at a fixed
time each day. In this case, the preflight can be scheduled separately on
the Forms 20, and all missions scheduled as mode 3 or mode 4. In a peace-
time scenario, there may not be any alert requirement. Aircraft not scheduled
to fly are not preflighted and must be taken out of the simulation with a
dummy mission that sends them "to the hangar" for the rest of the day.

However, the Form 20 entries must assign the available aircraft against real
requirements. If any aircraft are down for maintenance, it is the hangar
dummy and not the missions or inspections that should be shorted. The hangar
dummy mission is therefore given a scheduled time (columns 15 - 18) such that
the scheduled time minus the leadtime falls after the scheduled time minus
leadtime of the preflight and any phase or inspections, but before the takeoff
time minus leadtime of the first flight. This is easier to do if inspections
and phase are entered with long leadtimes.

Under the above assumptions, the following relationships must hold on
every simulated day:

Preflights = (Mode 4 first flight to post flight maximum aircraft +

Mode 3 maximum aircraft + Mode 4 first flight to post
flight spares + Mode 3 spares)

Total Scheduled = Preflights + Phase and scheduled inspection dummy
missions

Mode 3 maximum aircraft = Mode 4 turnaround to post flight maximum

aircraft

Hangar Dummies = Total Aircraft - Total scheduled

Figure 9 is an example schedule for a 24 aircraft squadron flying a 30
hour/aircraft/month peacetime program, with a 1.8 hour sortie length and
resultant .57 sortie rate. Low sortie rates are typical of peacetime flying.
For a 24 aircraft squadron, a .57 sortie rate is approximately 14 sorties
per day. Assuming 60% turnaround, and 10% ground spare policies, 8 aircraft
plus a spare will be preflighted each day, and 6 of these will fly a second
time. Since every aircraft that flies must have a postflight, there will be
6 mode 3 and 8 mode 4 missions scheduled. Enough time must be allowed on
turnarounds to complete the flight and all between flight servicing and
inspection tasks shown in both applicable networks.

Assuming a 45-day corrosion wash requirement, 16 of the 24 aircraft
must be washed each month, so a dummy wash mission is scheduled every other

0 jSHHHHSS SBE HSBBBI
0 E2Kf^GIGGKGGGGp3KG£»j
B EiSttGBSKISLJiBbSl*SSj

ra eriCECCCBCEEBBBCl

I SSS Sit ISi SS IKt SiB 18 1

AXIHOiad

^Se3S3"5**»»®®®g««gggg»“ggg|

■■HQ SHI3I^KEEflKEggggggggggg«gg"g®|g

I BSSBSpSppp wp^gpl

VESEBBSBBEBBSSSBtti

n .p.p;|. .^p:t:FFEEEBB

HEEEEEEKEEfecEIHB™*

■iili!lgiPgPi!!!!Si

CBfclEEE.fcEEEfeEEBBBl

§! EclililEilili Icfppp •: || J]

!BSu»! ««»■■

Is ■■■■■■■■■■■M StlllSfi

bB^M^HHBBBBBBBHB

;qi

I B CBEECBCEB1BEEEEBI

I E ■■■■■■■■■■■flBflBI

| BPnB[^BI51EBEEBEBE|;;s
0 gTSEgflEBraE BB EEBEBEM

0 ggEtSEBigiB E^B EgaPjEfaBI

s E gBHgRBBBSSSBFrBI

1 fe™55w««MW® ■ ■ ™ » gggj|

0 EEEjCirCEECCg&CCC*
H pCECEEECEEBgr *^ r ^ll

gE^c|BBM|BlfiflB

B KEEEEEElEECEjCUBEEi
B BECEKECBBCCaKgp.g |

BiaiiiiiiiigBiiiiii

smmi

PBPBEEHBnpppPEBBBBBBBBBBg BBBBB BBBI

gS5S55S5S5555aBBBBBg aag gg8gM8 gga!

^^^■■IgSSSBSSSSSS&BSSSBgBBB

B5SS»S«5BSmmww™ss2222sSS1

EESlIIIKSSSBSBBaBBiBBBSKBBStBgl

LOGISTICS COMPOSITE MODEL section n - simulation model inputs

... FORM 20 ’ SORTIE GENERATION DATA

liisississiiiiifiiiiililsiiBSiil

B§BppS"pEEg B8gg8S55SSg85g5S8s8BB

p MECIECjlZaE&BEdQE
p BCBeEEEEJEEiaEEd

Is BOBgE3E<[ae5C5nsr3K5

m E^QBMKflinr

Figure 9. Example of a 24 aircraft peacetime schedule.

day. Assuming a 100 hour phase requirement, each aircraft must go into a
phase every 100 days. This equates to a phase on 7 of the 24 aircraft each
month, or one phase approximately every 4 days. Washes are scheduled on
odd days, phases every other even day. Using the relationships shown" above,
there are 10 aircraft scheduled per day out of 24, so 14 hangar dummies are
needed. Every fourth day there are only 9 aircraft scheduled (no phase or
wash) so one more hangar dummy is added.

Network Entry Points on Forms 17

The Form 17 is an index that tells the computer where to go to find the
appropriate network to process for a specified mission type and mode. All
mission names appearing on the Forms 20 must be listed in columns 5-10.

Real missions are listed first, then dummies. The mission entries are
numbered in sequence, beginning with 1, in columns 12 - 13. The appropriate
network entry node is entered in columns 15 - 20. (These are explained in
Section III). Several missions may have the same entry node.

Wherever an aircraft loaded for one mission can substitute as a spare
for other missions, they are given a common spares substitution classification
in columns 22 - 27. The substitute class is a feature of the ASD version
of LCOM allowing aircraft that have missed a mission, or spares prepared
but not flown, to serve as spares for other missions in the same class with-
out further preparation or loading. Figure 10 shows an example Form 17 to
match the missions scheduled in Figure 9.

Additional Scenarios

Once the basic scenarios are completed, variations in sortie rate can
be produced by proportionally reducing or increasing missions of each type,
and adjusting the dummies accordingly. At least 2 such variations are
needed off each basic scenario to produce a full set of simulation runs.

III. MAIN AIRCRAFT SERVICING NETWORKS
Content and Data Sources

At this point it would be a good idea for the reader to go back and
briefly review Figure 3. The Form 20, described in Section II, specify
when missions are to be flown and the preparation leadtime. This controls
when servicing and maintenance jobs must start. The task sequences, the
resources needed, and the time it takes to do the work are put into the model
in network format. These next 3 sections discuss how to prepare networks.

The main aircraft servicing networks cover work done by the organiza-
tional maintenance squadron and the munitions maintenance squadron load
teams in launching and recovering aircraft. They also include certain
scheduled inspections and service work by other specialists that is
regularly done in conjunction with preflight or postflight inspections.

Figure 10. Example of Form 17.

Maintenance data collection (MDC) data on similar systems is not much
help in modeling munitions loading or crew chief work. Work unit codes
for this area are not detailed enough, and the level of reporting is not
that accurate. ' The operations concept for the new aircraft is a better
starting point. The requirements office at the operating command head-
quarters can assist in translating an operations concept into specific
assumptions and task sequences. For example, do aircraft have to be towed
into shelters when they land or do they taxi to revetments? If towed, will
three man or five man tow teams be required? If they taxi, who guides them
in and parks them? Taxi time and maintenance man’s travel time could depend
on the distance revetments are dispersed. What kind of fueling facilities
will be available? Will aircraft taxi right to fueling pits, or wait for
a truck to come around during postflight?

Visit an organizational maintenance squadron at a base flying aircraft
of the same type and similar mission, and discuss in detail what they do,
who does it, and in what order (Figure 11). Aircraft servicing tasks and
sequences tend to be generally similar in the same command, and more so for
aircraft flying the same type of missions. The preflight and postflight
technical orders (checklists) for similar aircraft should be reviewed for
similarities and differences with the new aircraft. The time estimates
obtained from experienced line and crew chiefs on similar aircraft can then
be adjusted for these differences, to get task estimates for the new aircraft.
Published munitions loading standards can be a useful data source where loads,
release mechanisms, and loading heights are comparable. Again, judgment must
be used to factor for identified differences. Many safety standards and
policies will apply across all aircraft in a command. A detailed review of
the 04 series of special inspection work unit codes listed in -06 technical
manuals for aircraft of the same type can suggest many inspection tasks that
may be applicable. Service and inspection requirements identified by the
contractor should be evaluated and included. However, contractor task times
and crew sizes usually depict touch times rather than the time people are
tied up on the job, and their crew sizes may not reflect actual practice.
Experienced maintenance technicians from the operating command who have had a
chance to observe maintenance on prototypes or test aircraft are a good source
of information and more realistic estimates.

The access necessary in order to do each task should be analyzed as soon
as mockups, prototypes, or test aircraft can be seen. Access is peculiar to
the new aircraft design and cannot be identified from data on other systems.
A-10 manning requirement was reduced by providing an easier way to get an
engine oil sample during postf light. This change was made at an early ,
mockup review before the design was firm. Main network tasks should be
given a lot of attention because they can have the biggest impact on
manning. Servicing and inspections are done every time an airplane flies.
Cutting one man off a maintenance crew or saving time by an easier access,
can have a big payoff in the manning that will finally be required.

Figure 11. Example of mode 2 preflight to postflight network.

Coding the Networks

A network names the tasks that have to be accomplished, and shows the
order in which they are to be done. It also identifies the time and
resources needed for each task. Nodes or connection points specify the
task processing sequence to the computer. However, every task does not
always have to be done in the same sequence. Doing a task can be made
contingent on a probability or on the occurrence of some other simulated
event .

Network data is entered on an extended Form 11 (Figure 12) . The task
name goes in columns 12 - 17. Column 12 is a code identifying the action,
type. Task action codes used for main networks include:

B = Loading or downloading.

G = Fueling or defueling.

H = Inspections, servicing, scheduled checks.

J = Aircraft handling and moving.

The rest of the field (columns 13 - 17) is used to complete a unique name
for each task. In addition to the codes listed above, there are some
special task names reserved for specific uses:

Z00000 = Flying a sortie.

CALLS 1 = Interrogating the unscheduled maintenance failure clocks
and processing through the applicable corrective mainte-
nance tasks to fix anything that broke.

The starting node number is entered in columns 5 - 10 , and the next
node number ending the task is entered in columns 19 - 24. This ending
node is entered again as the starting node (columns 5 - 10) of the following
task. When no more tasks follow, the ending node is left blank. Node
numbers must be unique. If the same number is used on nodes in two
different networks, the computer will not distinguish any difference, and
will run all the tasks they connect through both of them. This causes all
sorts of errors in the simulation. A systematic node numbering scheme. by
network will reduce the likelihood of such an error. Under the scheme
recommended in this report main network nodes should be four numeric digits
preceded by letter J.

Task processing logic is specified with a selection mode in column
26, followed by an appropriate parameter in columns 27 - 32. Selection
mode codes used in main networks include:

A = Non-mutually exclusive probability. The task will be done the
indicated proportion of times and if not done the tasks that
follow from it will not be done either. The probability is
entered as two digits right justified, without any decimal point.

A probability of .2 would be entered as 20 in columns 31 - 32.

INPUT No. 2
EXTENDED FORM II

Figure 12. Example of mode 2 preflight to postflight network coding.

INPUT No. 2
EXTENDED EORM 11

Hi Hi

F3H0

Hi Hi

HI 1

flll

Bil

p 0 H

3HI

IHHB!

RIHB

HI'

■HI

IH 1

K^B

■B

IHI

^■i

^01

pHH

nam i

Hi Hi

H !

H01

■H

iH'

I^H

H0H

ISM

n^H

Hi)

E±M

^■s

□Hi

GtM

ixwsm

1^3 HR

□H

IS1

GDKIM

BSE »

E£

TL\

ESHI

HBHi

e a

i^l

IBS

E3C3E3K2

E3S3

■H

CBD

nmm

;*E

g*- M<!/itf 51 Kol

E£Ed

n^H

wr.

ElLiBB

E3Ei

BSE3

171

hibi

■B

BBC

EKEPi

IE0C1

BK*2Ei

KKEn

■B

ESC

Hii

BRIKI

ElCliflCI

c«c<

3 CH

EZiC

msKs:

1 CB

□HI

HiH

IHI

■■

DHI

IBS

nBB

Hi BE

IHI

V p l

■ K «1

•fW'I'T

dE 3

SCilvIEil^dSI

QK«d

EnaBSiaiaKsi

E 3 iai 5 naiKi 55 i^i^KK

iiFtai

IdCIEIBEEjCBgj

EEE BiaOEEEE
■■■BBI IESBDD

1 BEEEBB EBEPBEEP

I eEEeBE—

BCiWEBECaPIE'

IBClEKIlI2gg

j d ■■ mh IB

B EB EBiaEBMBKBb ^E I

IBSBBBSBSBSSSEBj

3 .

E = Mutually exclusive probability. The probability value is
entered in the same manner as for A selection mode. All E
probabilities from the same prior node must sum to 1.00, and
one and only one will be selected on any given pass through the
network. These probabilities are used for branching to one of
a series of possible paths.

D = Do the task. The probability field is left blank.

S = Sortie. This selection mode must be used with all sortie tasks
scheduled on the Form 20. The probability field is left blank.

A clock number is entered in columns 34 - 37. It is alx^ays 00010
for all main network tasks. Scheduled maintenance code 3 is entered in
column 40 for most main network tasks. The sortie task must have a 1 in
column 40, and certain dummy tasks that do not represent any flying,
maintenance, or service may be coded 5 (other) . All main network tasks
are coded with priority class 1 in column 41. The mission priorities
specified on the Form 20 (Section II) determine the actual priorities
given to class 1 pre-sortie tasks during the simulation.

The average task time is entered in columns 43 - 47 in tenths of hours,
right justified, no decimal. Two hours is entered as 20 in columns 46 - 47.
The standard deviation is entered as a percent of the average time, right
justified, in columns 48 - 50. A Tactical Air Command work measurement
study indicated that 29 percent (29 in columns 49 - 50) is a good mainte-
nance task variability estimate. It has been used in modeling new aircraft
where more precise variability measures are not available. The same study
showed that maintenance task times generally conform to a lognormal distri-
bution. Task time distribution is specified in column 51. Applicable
codes are:

L = Lognormal

N = Normal

C = Constant (variability left blank)

The people and AGE required to do the work are entered in the balance
of the extended 11 Form. If it takes two 431X1 mechanics to preflight the
airplane, this would be entered with a 2 in column 53 and 431X1 in
columns 54 - 58. If they need a B-4 stand, this would be entered on the
same line with 1 in column 60 and B4 in columns 61 - 62. All resources
listed for a task must be available before the computer will begin task
processing, and all will be utilized for the indicated task time. The
same resource must always be entered with exactly the same name throughout
the model. It cannot be coded B-4 on one task and B4 on another. If more
than 4 resource fields are needed, they can be entered on a continuation
card. To do this, a C is entered in column 80 of the first card. The
continuation card with the additional resources must be placed immediately
after it, and carry the same task name and clock number.

All the resources required for a task must be defined on the extended
Form 11 at the first place that task appears in the model. If the same

task is repeated in another line entry, the resources are not entered
again. For example, the identical preflight inspection task might be
shown in several networks for different missions. The first time it
is used all the resources must be defined. Each time the preflight
task is listed after that the resource fields are left blank.

In addition to the task data entries, header cards can be used to
enter descriptive nomenclature for individual tasks or networks of
tasks. A header card has an H in column 25, the clock number in column
34 - 38, and the nomenclature starting in column 42.

Coding Network Call Sections

A call task is a dummy representing all the tasks in a section of
network. All applicable tasks within the section must be done before the
call task can be completed, or any following task started. Tasks which
can be done in parallel but all constrain some subsequent task are coded
in call sections. In ASD LCOM, no parallel tasks can precede a sortie
unless they are in a call section. Call sections are also useful where
the same group of tasks is repeated in several networks. The call
section tasks are defined in the first place the call appears, and just
the call task used to represent them thereafter.

The call task is coded with C in column 12, and the remainder of a
unique task name in columns 13 - 17. The selection mode in column 26
must be C. The tasks comprising the call section are listed immediately
after the call task in the first place it is used. This defines the
call task. The name of the call task is entered as the starting node,
or nodes, on the first tasks in the call section (see CALLL3 in Figure
12) . Subsequent tasks in the call section are coded in the normal
manner. Any number of tasks can be defined in a call section, from one
by itself to hundreds in many parallel strings. However, a specific
call task name must only be defined once in the entire model, at the
first place it appears. After that only the call task name is used to
represent all the tasks in that call section.

Including Provisions for Unscheduled Maintenance

The relationship between the main networks and unscheduled maintenance
networks is shown in Figure 3. Aircraft break as a result of flying. The
failure clocks and the unscheduled maintenance work to fix broken aircraft
are defined in call sections. Corrective maintenance tasks are only
called where the failure tasks clocks indicate something is broken. If
nothing is broken or when it has been fixed the program proceeds on to the
next main network task.

All unscheduled maintenance that could be done concurrently is defined
in a single large call section named CALLS1. The data base processing
programs automatically provide the necessary starting tasks to define
CALLS1. Unscheduled maintenance that would conflict with other work and

must be done by itself is shown in separate sequential call sections.
Examples of such work are repairs requiring aircraft jacking or towing
the aircraft to a test cell for engine runup. These conflicting mainte-
nance call sections are defined in a different manner covered later in
Section VI. These unscheduled maintenance call sections are an exception
to the general rule. They are the only call sections not defined where
they first appear in the main networks.

When failures are discovered on a loaded aircraft just prior to a
sortie, the munitions must be dearmed (cartridge ejectors removed) before
any maintenance work is done. In some few cases, such as jacking or
engine runup, the ordinance may have to be off-loaded. This work is
shown in a change call section illustrated by CALLS5 and CALLS6 in
Figure 12. The call section is defined by a single task or linear string
of tasks with X selection modes in column 26. The end mode of the last
task in the defining string is the name of the appropriate unscheduled
maintenance call section. The X is a special selection mode for defining
call sections in this situation. It is used to "carry forward" the
failure clock from the unscheduled maintenance call section, so that the
dearm or download is only done if a clock has failed and unscheduled mainte
nance is required. If there is no failure the simulation skips over this
call and proceeds with the next main network task.

Decrement tasks are inserted in the main networks to show where
failure clocks are to be advanced. The appropriate decrements advancing
the clocks must precede the unscheduled maintenance call sections that
check to see if there is a resulting failure. Decrements can be defined
to advance clocks by a whole sortie or fractions of a sortie, and can be
set up to advance some clocks and not others. Each uniquely named
decrement task advances a particular set of clocks by a specific amount.

For the example in Figure 12, the task DCRMT1 advances the clocks by a
fraction of a sortie to account for possible failures prior to takeoff.

The three call sections that follow check the unscheduled maintenance
networks to see if any subsystems have failed as a result of this clock

advance. After the flight DCRMT2 advances these clocks the balance of the

sortie, and DCRMT4 advances certain clocks that involve work only done in
postflight. The call sections to check and fix failures follow in sequence

Decrement tasks are coded on the extended Forms 11 with a task name
DCRMT and a unique number, with the D starting in column 12. Selection
mode in column 26 is D. Probabilities and resources are left blank. The
listing of clocks decremented and value of the decrement is entered in

another format. Instructions for this input are covered in Section VI.

Preflight to Postflight Network

The remainder of this chapter illustrates main network coding and
construction using a number of detailed examples of situations that were

encountered in developing LCOM models for tactical aircraft. Figure 11
is a schematic of a mode 2 (preflight to postf light) network for an A-7D,
and Figure 12 shows how it is coded on extended Forms 11.

It takes one crew chief an average of 3.6 hours to preflight an A7.
They do not double up to shorten the time, even in combat, although this
could be done. LOX, nitrogen, and air are serviced during preflight.

These are shown as separate tasks because different people do the work.

The crew chief removes the LOX bottle and places it at the nose wheel
if it needs refilling. It is needed on about 40% of the preflights so
this task is coded with A selection mode and a probability value of 40
is placed in columns 31 - 32. On the average the task will be done on
40% of the preflights, and on the other 60% it will be skipped. To
service LOX, one 431X1 goes around and picks up the bottles. Another
431X1 refills two at a time, taking an average of 15 minutes per bottle.

The task is shown as requiring two 431Xls for .2 hours using one LOX
servicing cart. Two other 431Xls take a service cart to each aircraft
during preflight to replace nitrogen bottles as required, and to service
tire air. This task requires two 431X1 APGs for .2 hour per aircraft.

Since nitrogen and air are checked every time, selection mode D is
entered in column 26. Since the crew chief preflight, LOX Service, and
Nitrogen/air service are parallel tasks constraining start of the next
main network task (loading) , they must be coded in a call section.

The example mission involves a bomb load only (no gun or camera) ,
and takes a 4 man load crew one hour using standard loading equipment.

This time was computed by summing TACM 50-7 standards for the particular
ordinance load and adding 15 minutes for travel. The launch (engine
start) task covers all elapsed time from the point the pilot joins the
crew chief at the aircraft for walkaround until start of taxi. It takes
and average of .8 hours and includes time that the crew chief stands by
while the pilot performs his checks and runs up the engine with the
plane in chocks.

CONUS policies on download vary by base. Combat aircraft are never
downloaded if at all possible. The only situations in which an aircraft
must be downloaded are an engine problem requiring runup in the test
cell, a jacking problem involving more than one wheel, failure of Weapons
control/release systems, work on the fuel cells, or it the aircraft must
go into a hangar (phase). Of these, only engine problems and jacking
have a fair likelihood of occurring as a ground abort (between engine
start and takeoff). When a ground abort for engine or landing gear occurs,
the download and upload are shown together in one task for networking
convenience, even though the upload portion would occur much later.

This simplification should not make any significant difference in the
simulation results. In most cases, ground abort will only require a dearm
task (removing cartridge ejectors), and then a rearm and repeat of stray
voltage checks when the maintenance is completed. Dearm and rearm are
also networked in a single task. The call sections are checked in sequence,
and if there is no failure, the aircraft proceeds to taxi. The taxi task
consumes time but not resources .

Three 431R1 APGs (four in combat) are stationed at the end of the
runway for final launch check. One of these is a team chief who talks
to the pilot via intercom. Two munitions men (462R0) are also part of
the launch EOR team to pull the pins on ordinance. All EOR crews are
stationed there for a full eight hour shift. EOR check is shown in
the networks as a .1 hour task for 2 431Xls and 2 462R0s after a .2
hour taxi. A dedicated crew is not available for any other work and
must be treated as a separate AFSC in LOOM. Runway checkers are uniquely
identified by an R in the fourth digit of their AFSC.

The sortie task removes the aircraft from the simulation for a
random time according to the sortie length distribution specified on the
Form 20. The extended Form 11 does not require any time or resource
entry for a sortie task. Sortie tasks are coded with an S selection mode
in column 26 and 1 in column 40.

Two 462R0 munitions men are stationed at the other end of the run-
way to check returning aircraft for hung ordinance and to safety ordinance
not dropped. One 431R1 APG is also part of the recovery EOR team to
park the aircraft for the ordinance EOR check. While the aircraft is
taxiing in, the crew chief and an age handler are getting ready for
recovery in the parking area. Their work is shown on the taxi task. The
crew chief then parks the aircraft in the .1 hour recovery task.

Aircraft are fueled in the parking area or revetment when the fuel
truck arrives. The postflight is interrupted to allow two 431Xls and
one POL driver to refuel the aircraft. For the purpose of modeling,
fueling is shown prior to postflight. This slight disparity with the
actual time sequence makes no difference in the LCOM output since fuel
trucks are not constrained. Fueling an empty A7 requires .3 hours, and less
time if the plane still has fuel aboard. In this example the plane returns
from air refueling with partially full tanks, so the task time is .2 hours
by 2 431Xls. The POL driver is not part of the maintenance unit for which
manning is being determined, so need not be shown on the extended Form 11.

The aircraft is not to be turned for another mission and goes into a
3.7 hour end-of-day full postflight by the crew chief. End of day post-
flights on the A-7 include an oil chip check requiring one 432X0 for .3
hours. Unscheduled maintenance is done in parallel with postflight
except for engine or autopilot work requiring engine runup and/or functional
checkf light, and work requiring jacking the aircraft. These call sections
are networked in sequence after CALLS1 unscheduled maintenance is completed.
After all required network tasks are finished, the aircraft is released for
another assignment controlled by the Forms 20.

Networking Turnarounds and Scheduled Inspections

If an aircraft is to fly again the same day it is given a thruflight
inspection rather than a full end of day postflight. The mode 4 network

for the next mission then picks up where the mode 1 network left off. It
starts with the load task, which is determined by the next mission require-
ment and proceeds through sortie and postflight. Tasks shown after the
sortie in the mode 1 network are common to all flying or depend on the
type of mode 1 mission flown. All tasks which depend on the type of mode
4 mission are shown in the mode 4 network. An aircraft does not necessarily
have to turn to the same kind of mission.

An example of the interface between mode 1 and mode 4 networks is
shown in Figure 13. Figure 14 shows how the mode 4 network is coded on
extended Form 11. Resources and times are not shown on any of the tasks
because they were previously defined.

Figure 14 shows one method of networking scheduled maintenance done
in conjunction with postflight. For this aircraft there is a basic gun
postflight during end of the day postflight any time the gun is used.

Other gun scheduled inspections are based on rounds fired. If an average
combat mission with guns expends 500 rounds of 1,000 loaded, and 50% of
the aircraft flying gun missions are turned, 1.5 gun sorties are flown
and 750 rounds expended per gun postflight. The inspection requirements
for this example are:

- Every 3750 EDS (5 gun postflights) torque bolts on A/C, two men
two hours

- Every 30,000 RDS (40 gun postflights) remove bolt and change bolt
spring in shop, two men 2.5 hours

- Every 30,000 RDS (40 gun postf lights) remove and lubricate ammo
chutes, three men six hours

- Every 30,000 RDS (40 gun postflights) change six gun barrels, three
men three hours (old barrels are scrapped)

The frequency of this scheduled maintenance is related directly to
gun use by only including it in gun mission networks. The tasks are coded,
with E (mutually exclusive) selection modes because the actual inspection
cycle is staggered. With E probabilities only one of the possible tasks
will be done each time. A dummy task with no time or resources is inserted
to account for the probability that no inspection falls due.

Networking Alert Missions

The method used to network alert depends on the particular assumptions
and scenario. These can vary considerably and may be difficult to model
precisely. A representative tactical alert situation is described below,
and modeled in Figure 15. This example illustrates the simplifications
that sometimes have to be made in modeling a complex situation. The key
requirement is that the simplifications do not distort the relevant output
measures .

MODE 1 NETWORK (Unscheduled Maint.) EOR

Preflight Load Launch DCRMTl CALLS 5 CALLS 6 CALLS4 Taxi Check Sortie

(Unscheduled Maintenance)

CALLS 1 - CALLS 8 _ CALLS 9

INPUT No. 2
EXTENDED FORM II

INPUT No. 2
EXTENDED EORM 11

Figure 14. Example of mode 4 thru flight to postflight network coding (continued).

INPUT No. 3
EXTENDED FORM II

—

Hi'

KID HI

[3 Hi

IH!

Krin

3HB

■

Kan

—

BIH

*i-i -

—

— .

- .

nfli

—

■■

aia

—

•

□19

□U

1 Mi

— >

K2(

□La

K3K2H

B13J

iacH

_ ,

■ m

Kvl

V»i •*H\

M M »3CPCI^K1C|

[3H1BBI£JE31 S2E3I - -

eji ica£ rjEaiai

^■■ ■maPEECi

— i

GUI

□b9

IgBBHBEBBBj

□b SSbSSSS

■■■tGIiSfl

^^SdBSEShkBEESSBEBEBb

IB EEI

□|

□■IEBCZ

BSI Bs JK51SES

BBEBMMflHHiiil

QBCW

B ESSi

taaitu'Ei

nmwEM^t

bbee]

□BE^BEl J 85 EEEEEEE

laBEKiBuiiaEHiaEEiaSSdE

iniM— — IMBBBBiHHiEBHilM —

igHBnaHEBCiirguEBgn

e aHiBE]iHK3BSK3K3E!!E!CSK3ESE3

oBDClHOBBrieieiDDBC]

□BSE!

•p«ri*y

IBiaiaEEEBEEB

IPDEE EEC EBBl

Figure 15, Example of alert mission network (continued).

In this scenario aircraft are put on alert for 24 hour periods. Before
an aircraft goes on alert it is preflighted, loaded; (but not armed) and
towed to the alert pad. The towing takes .3 hours by a crew of five. Two
431Xls drop off after .1 hour when the aircraft is out of the congested area,
and two of the alert crew chiefs take their place to help park the plane
in the alert area. The alert crew chief assigned to the aircraft does a
.5 hour check to accept it for alert. Two 462Z0 munitions loaders then
arm the aircraft in .2 hours. For alert aircraft, engine start (launch)
requires only .1 hour, taxi .1 hour, and end of runway check .1 hour.

After flying, alert aircraft go through the same sequence of end of runway
check, taxi to the parking area, recovery, and fueling in the parking area.

If nothing is broken they are then towed back to the alert area where they
are given a thruf light inspection by the alert crew chief and loaded. Load
and thruf light are at last partly concurrent, and load may be done by a
double crew in half the normal time. If the aircraft returns needing
some corrective maintenance it is not towed to the alert pad, but repaired
and given a postflight in the parking area. Another available aircraft
is loaded and towed to the alert pad to replace it.

Since a new aircraft may be run into alert at any time, the presortie
tasks in an alert mission network should follow directly from the last
network that aircraft had completed. This would be either a mode 1 mode 2
scheduled mission network. The same alert network should also apply to
an alert aircraft that returns in good shape and goes back on alert. When
one alert network is used for both conditions load and tow tasks cannot
always be shown in the correct sequence.

An alert mission network is shown in Figure 15. It is mode 3 since
preflight and postflight are in separate networks. If various missions
are flown from alert more than one network might be required, but they
would all be mode 3 and would follow the same general logic. The network
in Figure 15 shows the aircraft towed to the alert pad, checked by the
alert crew chief, loaded by a double crew, and armed. If the aircraft is
coming onto alert after preflight, or is being run in as a replacement,
the network has load and tow in the wrong order. This is not significant
since it does not affect the time to get the plane on alert or the
resources demanded. If the aircraft came off a previous alert mission,
the alert crew chief's time for thruf lights is only partly covered in
the check shown in the network. But turn time for the alert aircraft
is about correct since at least part of the thruflight can be done in
parallel with load. The alert crew chief’s time is not a relevant
output since he is dedicated for the full shift anyway. Alert crew chiefs
are coded 431A1 in the network. No decrements or unscheduled maintenance
calls are shown before alert sorties because the aircraft have been kept
cocked and ready by the dedicated crew chief. The DCRMT5 task after the
sortie advances all clocks a full sortie. The X tasks interrogate the
failure clocks and send the aircraf.t to postflight and corrective mainte-
nance only if something is broken. None of the post sortie tasks involve
431Als, and all were previously defined in other networks, so times and
resources are not shown.

This example network does not precisely duplicate a'll the given
assumptions, but it does capture the correct aircraft turnaround times,
demands for resources, and working time that are needed to make mission
accomplishment and manning predictions. A different network and choice
of simplifications might be needed to obtain other kinds of unbiased
output.

Networks for Peacetime Flying

Examples of preflight and hangar networks with dummy sortie tasks
are shown in Figure 16. They match the operation schedule shown in
Figures 9 and 10, Section II. The Form 20 lead time for the dummy pre-
flight sortie must be greater than the 3.6 hour elapsed task time for
preflight, and allow for variability. The task time entered for hangar
on the extended Form 11 must be sufficient to hold the aircraft from the
time scheduled on the Form 20 until the end of the day. Figure 16 shows
a time of 19.5 hours, which corresponds to the Form 20 scheduled time of
0430 for the dummy hangar mission. Task type 5 is entered in column 40
on the hangar task. This code is a catchall for time that an aircraft is
tied up other than services, maintenance, or flying.

Mode 3 mission networks represent first flights of the day when
preflight is networked separately. The Form 20 lead time for these
flights must be greater than the sum of presortie task times in the mode
3 network but does not have to cover preflight. Figure 16 shows an example
mode 3 carrying air to air rockets. In this case DCM3 was the first net-
work entered, so all task time and resources were defined on the extended
Forms 11. This network shows towing the aircraft to a safe area for
rocket or missile loading. This is generally a CONUS peacetime procedure.
In wartime, each aircraft parks in a revetment for all servicing and
loading.

IV. CORRECTIVE MAINTENANCE NETWORKS

Content and Data Sources

The networks covering unscheduled corrective maintenance tasks are
organized by subsystem. They are called from the main networks via the
failure clock mechanism explained in Section I. Each network must start
with a failure clock and parameter value of mean sorties between mainte-
nance actions. This controls the frequency with which the network tasks
will be processed. It must cover all the times a specialist is called
to the airplane in the field to fix an apparent problem, including cases
where only some minor adjustment is required or the system checks out OK.
This definition of maintenance frequency differs substantially from
reliability measures of failure that consider only confirmed breakage
under controlled test conditions.

INPUT No. 2
EXTENDED FORM 11

’.t

—

■1BHB 1

—

BBBBBBI

3BK

BBBBBi

iBi

BBBBHB

^IHH

BBIBHB

3B1

C3B

L3M

BISiH

[:!■

bbisb

^ ■■

F»

BilZIBB

1BI

bkjbb

^■H

IB 119 IB

zrz

bbetibb

1231313

jgSUBBB

IBB

C3E2d

BIB3BB

***.

1HK

blbl<

BI3B

aBEUCI

bibb

'IBS

■hbje;

BBBBBi

[,_

—

bbisbi

3Bf

BBBBBi

— _

113

3E3

—

E3DE3

LiC3E3

CDE3

■ISEI£]^

■BDliDB

■C3DCIB

—

■XED1BE

■IdEIB-Jlffl

,_ ..

•

irs

EjEIKj

■1C3C3BE9

113

EliiKI

■UmCE

“»axi7»iia

aim

313

Ebses

BBBrncj

—

* <

313

■SESCaBirnESBlJ;

CICJEHBiESlHSiS^

—

•P®W •!•*■

Egggggggggggggg

1 HBEEEEJ
mBBSBBSBEBSBEE
IBBBfiBSSEEEEEEsE

lSl3WMMHDiaU3iai311glg

■

ICDtaHKim

IBBOSG]l

MBeilSM

IlildEBURId

it:iaiai3C3sia

irainiauiuiraia

LL*I

El 31

li^H

12E

■

«**

□H

i a

■

•

E1C!

■1

■n

rac

IHi

'MM

— — -

• —

—

IBB3

IE3

¥»
1 *.

EdEUlHEtJ

■

cccc

si;

— *•

Wnia

onn

SK3

□E2E2

E2E2E2E2

□KS4ETI

C(C!CIC(

ntn

—

ESKi

—

— •

niHi

i«°i

312 l 2 D 1212 E»X 215 UMiiE)l 2 Edi

QKEJUKiKaKSEEldKaEEII

•P°W •!•*■

□BJEslKniaiaiSISiaiaEJElEyi

■ESEmEIKulESlBdl
ecaiaraEiKiEriKirai
OULJI^blUESdil

IK^CI

I ll■H^II'■H^l^lllll^^ UmIMBiIIm I

■aKaEBEak^KscaniaEaKai
BDBEBKaE9EIUC]eSElBI
gE3»B=JK£]K3ft3raK3IdnEnSI
lBftaC3K£IC5iaE3K31>]V9E3B3K3l
BraE3E3E=U3E3E3l2]E3KSEJI3]l

B 5 SEE 5 Sr 3 i 51 CJCJK:ii 3 l
□DBBaCliaKIIHElCJKjKjKJI
□E3E3E3BBBL1BBBBB
DBBBBBBiaE]l3Kf!EIE]l
ssiatziisiisiisiisiBsiisiisiuigsiisi

Figure 16. Example of mode 3 network coded with preflight and hangar dummies (continued),

Figure 16. Example of mode 3 network coded with preflight and hangar dummies (continued).

The networks also contain task times for work on-aircraft and in
field shops. They represent the time a technician is tied up on the
job and not available for other work. They must consider time to get
to a job, time to fault isolate and check out the system, time to
clean up, time to get parts, and standby time on multiple crew tasks.

They are substantially different from the touch times developed in
contractor-prepared maintainability studies. A cockpit mounted radio
that can be changed in a few minutes by removing 6 screws might occupy
a man for half an hour when total job time is considered.

The maintenance crew size shown for network tasks represents the
number of people typically dispatched to the job. Crew size depends
on safety factors, maintenance practice in the operating command to
account for level of skill and qualification, the need for technical
data while working, policy on checking work, accessibility, and on-the-
job training. More people will generally be dispatched than are indicated
by a strictly touch-time task analysis.

Maintenance frequency, task times, and crew sizes are developed from
Air Force experience on similar equipment wherever possible. The Air
Force maintenance data collection (MDC) System is the basic information
source on what it takes to maintain current equipment. Air Force
engineers and experienced maintenance technicians must then evaluate
differences and apply judgment factors to the MDC data in order to
estimate task requirements for the new design. The development contractor
is the primary source of design identification and engineering information.

Procedure

The first step is to define the proposed design of the new aircraft.
Definition must be at least to subsystem level and preferably to line
replaceable unit (LRU) level. The contractor's development proposal,
submitted at the end of validation phase, will usually encompass this
level of design definition. Much useful information can be obtained .
through visits to the contractor's facility and thorough inspection
of any mockups, prototypes, or test aircraft under construction. If there
is a flying prototype, experienced Air Force technicians should be assignet
to observe and evaluate maintenance procedures and requirements.

Given suitable design definition, the next step is to identify
comparable systems and subsystems on existing aircraft. Comparability is
assessed in terms of function, design concept, complexity, operating
environment, and maintainability features. The Air Force engineers
assigned to the program office and their "home office" supporting cadre
should conduct this analysis, and it should be coordinated by the program
reliability/maintainability officer. It is essential that the analysis
and rationale be completely documented and then kept current in each
participating program office engineering group.

The comparability analysis should be structured according to
contractor’s preliminary work unit code manual at subsystem, level. The
special criteria for identifying comparability must be defined for each
subsystem at the outset. Experienced maintenance personnel in the
program office and/or operating command should be brought in to
familiarize each group of engineers with maintenance problems typically
associated with their equipment, and jointly establish appropriate
criteria. Getting both maintenance and engineering input is critical.

In one comparability study, airframe engineers initially based their
criteria on the similarity of the heavy load bearing structures to
resist stress and fatigue cracking. The maintenance people pointed out
that most day-to-day airframe repair work involves fitting skin panels,
fitting access doors, and replacing fastners; not fixing broken wing struts.
The kind of fastners, curvature, and stress on surfaces, and simple size
of the aircraft, may have more bearing than structural design on the
comparability of flight line and field shop maintenance. However,
vibration absorbing properties of the structure relate to a cause of skin
maintenance and cannot be ignored either.

Once the criteria are established, the engineers compare the designs
of similar aircraft, drawing on the experience of associates who have
worked on various programs, contractor data, and Air Force technical
orders, as necessary. The results are then written up by subsystem
(3 digit) work unit code, to include: identification of comparable air-

craft and subsystem work unit code(s) ; any additional LRUs in the new
subsystem or LRUs by work unit code in the comparable system that are
not applicable; any factors that should be applied to the comparable
subsystem failure rates or task times in estimating for the new subsystem;
and a narrative analysis specifying the criteria used and supporting
rationale for choosing the comparable subsystem and factors. Any scheduled
maintenance considerations should also be mentioned. In some cases, an
item is so new or so changed that there is nothing reasonably comparable.

In that case, the best source of data (contractor, etc.) should be
identified, and appropriate factors and degree of confidence discussed.

Study results should be reviewed in conjunction with experienced mainte-
nance personnel to be sure no maintenance considerations were missed. The
comparability study requires a considerable effort on the part of program
office engineers, but has a payoff in their better understanding and
heightened awareness of maintenance considerations when they review
contractor proposed designs, and design change proposals.

The next step is to obtain MDC data tapes on aircraft with comparable
subsystems, and process the information through a series of specially
designed computer programs. These programs and full processing instructions
are described in AFHRL-TR-74-97(III) . The program outputs are in a
convenient format for use in developing a simulation data base. However,
some base visits will be essential to verify and correctly interpret certain
aspects of MDC coding for the comparable subsystems, and help identify
requirements and procedures for using powered age.

The verified MDC data for comparable systems, factored for identified
design differences, is used to build an LCOM maintenance data base
for the new aircraft. When this data base is completed the networks,
times, and particularly the crew sizes and AFSCs, should be reviewed with
experienced Air Force maintenance personnel. Operational command
technicians on prototype or test aircraft make ideal reviewers. This
review is an iterative process.

The basic procedure of design identification, .comparability
identification, model construction with MDC data, and maintenance review
is repeated on design changes to keep the data base current throughout
the development and production phases. Test and operational evaluation
data is considered as it becomes available. An accurate and fully
developed model can be transferred to the operating command for their use
when the aircraft becomes operational.

The rest of this section explains how unscheduled maintenance networks
are developed from the outputs of the MDC processing programs, and provides
examples of networks of varying complexity.

Network Structure

The basic task sequencing for a corrective maintenance network is
shown in Figure 17. It must begin with an F task identifying a failure
clock and F selection mode. This serves as a gate controlling how often
the subsequent network tasks are done. The gate is only opened and tasks
processed when the clock on the F task indicates an apparent failure has
occurred. The F task is followed by the on-aircraft maintenance tasks
needed to describe the corrective Work:

A task to get and set up powered age.

X task to gain access to the subsystem or LRU, particularly when done
by a different AFSC than does the corrective action.

T task to troubleshoot the subsystem.

R task to remove and replace an LRU.

M task for any on-aircraft fix not involving LRU removal.

V task to perform an inspection or functional check to verify that
the subsystem has been fixed.

These tasks are coded with D, E, or A selection mode to describe the
appropriate sequence of work at subsystem level. The R task is an average
for all LRUs in the subsystem that are done by the same AFSC and crew
size. If some items are removed by a different AFSC, these must be
grouped into a parallel R task representing the set of LRUs removed by
that AFSC and crew size. E selection mode probabilities determine which
corrective task is processed.

Figure 17. Subsystem corrective maintenance network basic logic

R tasks are normally followed by a shop entry task. This is a
dummy because E and G Selection logic cannot be run out of the same
network node. It is followed by parallel L tasks representing failed
LRUs. Six selection mode probabilities determine which LRU (s) within
the subsystem were removed. The following tasks are used to represent
the possible shop actions on a removed LRU:

W to bench check and repair the LRU.

K to bench check the LRU and find it serviceable.

N to bench check the LRU, find it NRTS, prepare it for shipment,
and order a new one from depot.

An asterisk can be placed in column 39 of the extended Form 11 to indicate
that a shop task will not hold up the aircraft if a spare LRU is available.
A Q task must be included with selection mode D and no asterisk in order to
draw a spare LRU from supply. The asterisked N, W, and K tasks must be
coded with selection mode E to assure only one is processed to match each
supply demand. The asterisk tells the computer that an LRU is now being
processed instead of an aircraft, and should be returned to supply when
the task or task sequence is complete. It effectively separates the shop
network from the aircraft network unless there was no spare to draw
from supply.

Coding Conventions

Node numbers for on-aircraft maintenance tasks are 5 digits, right
justified. The first 3 digits correspond to the first 3 digits of the
subsystem work unit code, except that the first digit is entered as the
corresponding alphabetic character. The last two digits indicate the
task sequencing. For example, for the 14A00 subsystem, node numbers would
be A4A00, A4A01, A4A02, etc. For the 42C00 subsystem they would start
with D2C00, D2C01, D2C03, etc.

The mode following the shop dummy task and preceding the L task is
6 digits, with an S in the first position, followed by the subsystem
work unit code. Subsequent nodes for shop tasks are also six digits,
with I in the first position, the first 4 digits of the LRU work unit
code, and the last position used for task sequencing as described above.

For example, the prior node to the L task in the 14A00 network would be
coded SA4A00, and the next node might be IA4AA0. These node numbering
conventions may seem a bit confusing at first, but they are quickly
mastered, and if followed help prevent serious node duplication errors
when networks are modified and updated later. The node starting a task
is entered in columns 5-10, and the next node in columns 19 - 25, on
extended Forms 11.

The appropriate task action code is entered in column 12, followed
by the first four digits of the work unit code. Column 17 is reserved

for task identification. It is zero unless there is more than one task
with the same action code in the network. For example, if there were
two R tasks in the 14A00 network, the first would be coded R14A00 in
columns 12 - 17, and the second coded R14A01. Alpha characters can be
used in column 17 if needed. Two common tasks are used which do not
follow these rules. The shop entry dummy task following an R action
is simply coded SHOP in columns 12 - 15. Since it is a dummy with no
time or resources the same task name can be used in all networks. On
occasion, it may be necessary to specify a task to account for depot
turnaround time on a NRTS LRU. If the standard time is applicable, this
task may be coded PDEPOT in columns 12 - 16 and no time or resources
entered. Use of a standard depot task is discussed further in the
examples and in Section VI.

The clock number for the network is entered in columns 34 - 38.

This must match the work unit code entered in columns 13 - 17 on the F
task. The same clock number is entered on every task in the network
that follows the F task. It identifies which failure clock initially
triggered the action.

The mean sorties between maintenance actions is entered in columns
27 - 32 on the F task. It is a whole number, right justified, and
represents the average number of flights between a corrective maintenance
action of any kind on the subsystem. Task type 2 is entered in column
40 for all tasks in the unscheduled maintenance networks. Priority 1
is entered in column 41 for on- aircraft work, and priority 3 for shop
work on removed LRUs (task action codes N,W,K, and PDEPOT task). The
Q task is coded priority 1. Standard deviation 29 percent of the mean
and lognormal distribution are assumed to apply if more precise data are
not available. These are entered as 29L in columns 49 - 51.

Each network is preceded by a header card, immediately followed
by the F task. The header card has an H in column 25, the clock
number in columns 34 - 38, and subsystem nomenclature in columns 42 - 66.
Additional header cards can be inserted to change nomenclature where
desired. Each L task is preceded by a header card with the LRU work
unit code in columns 13 - 17, H in column 25, clock number in columns
34 - 38, and LRU nomenclature in columns 42 - 66. This LRU work unit
code must be used in columns 13 - 17 of the Q task to correctly identify
the item drawn from supply.

Using the MDC Data Bank

The remaining sections of this section illustrate the use of MDC
data runs on comparable subsystems to develop and code unscheduled
maintenance networks. The data bank computations and outputs are
explained in detail in AFHRL-TR-74-97(lII) .

The on-aircraft maintenance (no phase) run at 5 digit work unit code
level, and field shop maintenance run at 5 digit level contain the
applicable data on unscheduled maintenance. These runs include summaries
at 3 digit and 4 digit level. The special inspection 04 codes in the
work unit code manual and the data run showing the task data for this work
need to be reviewed and verified with technicians in the field to
identify any unscheduled maintenance that is not coded to subsystem work
unit codes. The special inspection run includes a listing of access
work and cannot duplicate (CND) troubleshoots. Access is usually peculiar
to each design and cannot be extrapolated from data on other aircraft,
but such data may give clues on what to look for and can identify where
joint removal and checkout is done. The circumstances causing high rates
of CND troubleshooting on a comparable subsystem have to be investigated
to decide whether they apply to the new aircraft flying the assumed
scenario.

The 3 digit summary from an on-aircraft data printout for a VHG-FM
radio (62ADD) is illustrated in Figure 18. It shows average reported
time for each applicable task action code by AFSC and crew size, and
the number of such actions occurring during the period of the data sample.
It does not show AGE or access. The mean job time is an overall average
time per corrective action for the full sequence of on-aircraft work. A
clock value of 39 mean sorties between maintenance actions (MSBMA) is
shown on the next line, with quantity per aircraft equal to 1. This
means that there is only one such radio on the aircraft. If the QPA were
more than one, the MSBMA rate shown could be on a per unit basis.

Conversely, if there were two radios on the new aircraft, the unit MSBMA
rate taken from the data would have to be adjusted to take this into
account. The appropriate computations are discussed in the next section.

The matrix printed after the line of stars shows the E probabilities of
an R or M corrective action by each AFSC that works on the equipment, and
the average times without regard to crew size.

Figures 19 and 20 show how this data is networked and coded on
extended Forms 11. The radio set is located in the cockpit of the aircraft.
It was determined from discussion with experienced radio maintenance
technicians that a ground power unit was required for troubleshoot and
check, and that the crew chief (AFSC 431X1) would have to remove panels
for access if the radio technician needed to check and repair the wiring.

An access task by a 431X1 is generally required wherever panels with high
torsion fasteners have to be removed.

The network shows an F task with a clock of 39 MSBMA. This is
followed by an A task, covering delivery of AGE by a 421X3 and hookup by
the 431X1 crew chief. The corrective action is either a remove and
replace (.73 E probability) by 328X0, or access by the crew chief (.27 E
probability) and repair by 328X0. The typical Crew dispatched is 2
328X0 technicians. Troubleshoot and check were reported separately less
than 15% of the time, so they are included in with the R and M tasks,
using the mean job time. Note, however, that 36 troubleshoots were
reported under a 2 digit 62000 work unit code. Including these trouble-
shoots increases the mean job times by .1 hour:

r i

■

•'

■ :

■: ■ ‘

’

ffi

00 to

(/I w

v»

•

O o

z z

Of a

o o

OIO

o o

•

a .

*-*

H W

M Ifl

X T-

1- K

f—

H •

1—

CJ o

O JO

o o

a *4

d <t

djd

d d

H-

o:iof

H II

. ..

•

<■

▼4

cn <nj

•» j-

rl H

cj r

■H

r m

CVl

H-

O' a

ofiof

Of Qf

Qf 3

X X

X! X

a. ro

< K

CJ N-

d 1 -*•

-H 00

•

-J «

•

• 0

•

• z

•

-#■

r4 r*«

r>{

•H

•H <C

•

l-l

cj ro

rj CM

ro •

•H

ii n

O G

X XIX

Of a

bJ UJ

UJ UJ

UJ II

•

CL «

or of

of Ik

Of UJ

ftj

Of G

o o

a z t<

O 0 -

■

CO 11

o d

-J Qu

X a

d •

UI O'

x ro

a. cs

d a

■*

J i

UI e

ro li

4-)

V-

o o

o r

O I

W M

w to

M ff

. o

a o

O V)

a f

«=

■ <x

d d

•t

<■

I O X

d X

O X

O' Of

Qf CO

in oc

u- h-

U. CV

> >

> d m

> H

d rr

d d

<t *z

«=

< z

ii n

X X

X «t

o o

o cj

2 2

Z U>

•

a d

3 CM

o o

ojiO

•

o u:

X X

X II

00 ao

00 Qf CJ

oo c

CJ CJ

CJ O 3

cj r;

ro ro

ro u. X

ro 3

II Ii

o o

t/1

to to

i/i

U-

li-

U. li.

U-

♦

d d

♦

«=

< «

CJ CJ

vO vjO

»0

v£

v£>

ii it

a u

3 3

x x

: Jt

INPUT No. 2
EXTENDED FORM 11

20H

vam

■

"□■

3HB

■

jOHi

hHri

liH

jGNH

IHH

IHI

»H

!□■

WM.

■

iH'

■

■i

|^H

■s]

■

HH,

■

□■

■SI

IHI

rtmtm

■Hi

■■

■

mmm

■

■■

LJ I^bL

■■

□■r

■

EJHH

BKsj

-;H

Ksll

■

tad

■

ois;

ESI

121

K2I

*£H

HH'

[

■H

lass

C1I

■H

■SJKSJKS]

□hi

■EEEDI

■£E3E3I

□HH

P^H

EJESE2I

CUE'

□hi

■E3ESE2I3J

Kzmata

■ESIulESKDI

Emma

□■■

ECU

K2K3I

E3EJE1I

01 EH

IH1

Hll

■is

IHII

HHI

□HE

HH'

KIUKSSSI

■E3!

rii

■Fll

KSI

Hll

tiEifSOI

■HI

j§H

ESI

■i3

L3BLZ1

■rarararai

IHI

rc<c

E4I

EJEslI

HHI

■i

■121

■1

□■31

■K3CJEZ13I

E31HE3I

■di

□ESI

■■asadi

■L2I

□El

cai

□HI

■1

■i

■II

Hll

□ESI

■1

■i

■1

■ESI

■USE

□El

■1

HHHI

■i

■1

■

hhi

■feat

i«nEEEEES!

IKSXHKSKtflMi

I^C!C«C!C!I

l«

WBEwa wawEMaa

llw]|

lEISClUil

naiginiini

ie"SS!

EEEKI

IEOCIC<C]l

iizDiaiai

IE3E3ddrai

I ESI

irai

icai

SHiK=]KSIB£]K£]K£JHBaK^E»]E^K 2 ]dK£]|

Il lfclB li II .il iMi II II II II

lESEHESKSIEtillH

iiaiaDBiara

miciEsrncd

iiacaiaciiai

IK* 71 dftZlK 71 EZll

Figure 20. VHF radio network coding (continu'd).

36 more T actions x 1.1 Avg. T Hours , „

e = .1 Hours

373 Total R + M Actions

There are two LRUs that show any significant frequency of removal
on the shop printout (Figure 21). Both are repaired in the radio shop.

The receiver transmitter has a G probability of .01696 and the control
has a G probability of .00056. The G probability is the per sortie
probability that the LRU will be removed. It is used to assess the
relative proportion or removals among the LRUs in the subsystem network.

It is entered in columns 28 - 32 on the extended Form 11 right justified
without a decimal. When a G probability is indicated, at least one of
the alternate L tasks must be chosen by the program.

Shop data print-outs show two types of W tasks. A WA is a bench
check and repair, but a WF is a repair following a separately reported
bench check (code C) . Two kinds of summary matrices are provided to
assist in networking.

Data in the first matrix applies when the removed unit is always
replaced from supply stock if available. This matrix shows the E
probability and elapsed times for W, N, or K actions in shop. The
NRTS is broken out to 4 digit and 5 digit level LRUs. Figure 20 shows
how this situation is coded. A D selection mode is used on the W
task for the control unit because W is the only possibility. No N
or K tasks were indicated in the data.

Figure 20 also shows 62AA0 networked by the alternate method to
illustrate the difference. This applies to situations where the unit
is bench checked when removed. If it checks OK or is fixed in a short
time, it is put back on the airplane. A spare is only drawn from
supply if a long repair is required. The repair work is then deferred
to a later time. In this case, the K task code represents a combined
bench check OK and WA bench check. It is priority 1 and is not asterisked
since the aircraft is tied up awaiting the bench check, and no units are
withdrawn from or returned to supply. The W task represents bench check
and deferred repair only. The W and N tasks are asterisked and priority
3 because the aircraft is fixed with a unit drawn from supply.

Computations with MSBMA

The MSBMA clock value may have to be recomputed or adjusted in the
course of coding a network. Since it is an inverse number, the correct
computations are not always intuitively obvious. The relationship of
MSBMA to the probability of a maintenance action on the subsystem is:

P M * 1

MSBMA

To combine two MSBMA values, interactions can usually be ignored and
their probabilities added:

in co j co

oo m *y

4- . in

WMMW
Z2ZZ
O O O O

M ^ M M

H- H* H*
OOOO
« «t «L cl

Li- U. U_

X X X ^

OJ 4- rt W

(/> C/5 V>: (/>

zzzz

oooo

uuuu

< <x «x «x

• «r

X O O X

1/^10 CO!
z'z Z|
O O Oi
m; m m!
H H- h-f
uoo

<X <C *t

X X z

i a
<o co o
ZZ|t
O O CO
M W
t- t- Z
O O W
«t «*

-j

J- Ifii «

Z Z; l-

«o cm cm in

CM f-

th — c ro i*jI ►-

X\oc oc a:
X|Z X I

oo j—t O' O'

a: oi c r ct

XXXI

K a: o'
xxx

O' ad o.

rIMWri

CM |ro J* l

II ! II M II
XiXXl:
uj ui ijj uj i
xior o: oc i
UU o O I

II II II II
X X x. X

ID UJ UJ UJ

a oi oi a:

oooo

ii> ii if
XXX
ID ID Ui
Oi Qi Oi

o a o

i N. J- II

>; • * oi
i in cm o

I I H*

: i o ■

i «t

1 CM CM U

f ii iija
: X Xi

1 Ui ID I

■ a O'

I OON

t ^

i H ’

• • •

Uh j- co
th Icm

CO CO CO CO

z z z z
oooo

oooo;

«««*«*

CM CM in

x x x xi

CM CM «H CM U.

II II II II CS

X X; X X
Ui ui ID ID i

Oi Oil Oi Oil

cJo oL

oooooodoqoo'oojir

oaOQDOOOCXOOOPtVJ

u *1 <<< <<<<[< <1 II

Q'o'c^c^ctfi^c^cfco'ctfa'ctfctft/)

i j i !«i

>=»:»>> 3 * >, ^ Z» 3 » > «t

! ! i *

II II II II II II II II II II ll| II II i UI
X X X X X X X X X X X- X X; Oi
ooooooo.oooooo
z z z z z z z z z z z z Zi

I 1 • «t

oooooaooraoooo«
XXXXXXXXXXXXXpj
cOCOoOoOOOOOoOCOOOCOoOCOCOiD
mcmcmcmcmcmcmcmcmcmcm cmcM ||
Mcowfoforoforotofofofofoo

■ o

! ! x

II II II II II II II It II II II II II Qi
OOOOOOOOOOOOQO
tOCOlO.tOlOlOlOlOCOlOIOCOlOU
U-UUiUUUU.UU.UUUU
« ,<* «X «t 4<<<X<4<<X<

ncmcmcmcmcmcmcmcmcmcmcmcm

if) v _0 i 0 v 0 10 vO i 0 10 i 0 \D iD 10 i 0 j
II II II II II II II II II II II II II
ooooooooooooo
3 3 313 000 X 000 X 0

XXXlXXXXXXXXXX

U| LD -H

3S . I

S I

3 m
co o in

Ui CL —C

l-C < _J
■t UI
O 1 CM ■

M <1 CD
I «tf O
I O CM Qi

UI 10

! UI 10 CL

> II

l > II 1

o o

; o o

s: 3

uj 3:

UI 3:

i o

o X

to 00

U. 1 (/)

tu CVJ

M U.

<t, ro

H- «t

»!

;

* 1

Qi Qi: Qi o; Qi CO|

I I -I'

> 5* ^ 3» * «t: II

«t «* < «I O > u.

j O CD

I z x co

II Hi |l II « Ui X

X X X X ID Oil

o o o o x i »-

ZZZZ jM

o o 3

! x a

O O O O 00 «*.

XKXXWN

eo oo oo co fo iD o

Cil CVJ CJ C4 HO

to fO fO W O *X

3 CM

1 II 3C

i O ! II

j II Hi II II C/5 O

lOOCOU-OD
I (a in V) (0 < u.! x.
: U. U. U- li-
es <t < o

O I

. <r !

i oj

; o o o o vO !

[OOOO II :

|< <1 <t < u
| CM CM (M CM 3
10 10 10 10 3 c
; II II II II
; o o o o a
j 3 3 3 3 O
' 3= 3 3: x U- i

1 +

MSBMA Tota j.

MSBMA 1

MSBMA.

or: MSBMA Total

( 1 + 1 \

\MSBMA^ MSBMA 2 /

If an LRU with an MSBMA of every 50 sorties is included in a subsystem
with a clock of 100, the new clock value is:

MSBMA =/_l + 1 \ = 100 = 33

V50 100/ 3

The new clock value is not the average of the two MSBMA values, but is a
number lower than either of them. This makes sense when one realizes
that if another source of failure is added to a subsystem that is already
failing every 50 sorties, it is going to fail more often. More frequent
failures mean a lower value of MSBMA.

The relative significance of MSBMA values is also deceiving. Large
differences in large MSBMA numbers are often insignificant while even
relatively small differences in small MSBMA values represent important
differences. Consider MSBMA values of 2000 and 1000. The difference in
terms of probability of a maintenance action is:

P Diff. = L. - 1_ = L_ = .0005.

1000 2000 2000

On the other hand, the difference between MSBMA values of 10 and 5 is:

PDlf£ - - 5 ■ ll ' T5 ■ • 100 °

The latter difference is 200 times greater in terms of frequency of
failure. For this reason, subsystems which fail less than once in 2000
sorties can often be ignored in building networks, but changes and
modifications which affect low MSBMA numbers may have considerable impact
on the simulation results.

When the aircraft being modeled has more than one of a given sub-
system installed, the unit MSBMA taken from the data bank must be
divided by the number installed to get the correct total maintenance
rate. For example, if an aircraft has 2 identical hydraulic pumps with
the same work unit code identification, and the data bank shows that
a single pump requires maintenance every 50 sorties, then the average
MSBMA rate for the 2 pumps will be once every 25 sorties.

If the comparability study indicates a 25% improvement in reliability
for a new subsystem, it will only fail .75 times as often. The data bank
MSBMA for the comparable unit must be divided by .75 to get the larger
. MSBMA. value for the new subsystem.

Network with Expendable LRUs

The remainder of this section give examples of some more complex
networking problems.

There are many throwaway electrical items .coded as on-aircraft remove/
replace jobs in MDC reporting which never go into the shop. These
include relays, switches, and circuit breakers throughout the aircraft.

The shop data bank printout gives the counts of items reported removed and
reported in shop, and also shows a G probability of no shop. However,
differences in these reported actions do not necessarily mean throwaways.
They could be due to bad reporting or have another explanation. LRUs
should not be networked as expendable unless it has been confirmed with
maintenance technicians in the field.

Figures 22 and 23 show on-aircraft and shop data bank printouts for
an aircraft lighting system with expendable LRUs. Only the anti-collision
lights 44AGO and 44AHO are processed in the shop. All the rest are throw-
aways. The four and five digit level shop data were examined to see who
removed the items that were processed into the shop. Since it appeared
that either 431Xls or 423X0s can do any of these removals, both R tasks lead
to a common shop entry node. The G probability of no shop work is included
as a dummy task in Figure 24. In this network there are three AFSCs who do
work on the equipment. Troubleshoot and functional checks are always done
by electricians , but either the electricians or the crew chief can repair
or replace failed lighting system components. On rare occasions, the
machinist is called out for a mechanical repair. E probabilities for the
various specialist corrective tasks were taken from the matrix in Figure
22. The 531X0 probability was rounded up so that they sum to 1.00.

The mean job times shown in Figure 22 are not much help in this case
since troubleshoot and repair may be done by different specialists.' The
R and M task times shown in the matrix are entered on the extended Form
11. Troubleshoot was not separately reported in every case, so the 14
hour average time reported is "spread" over the total number of jobs by
all specialists:

1.4 Hours x

93 Reported + Actions \ _

219 Total R + M Actions,

. 6 Hours

There were not enough functional checks reported separately to warrant a
separate task. This work was included within the electricians' trouble-
shoot time. The additional time is:

o q o
X X K X
« 10 « M » a!
wijuiNM q
J- j»j j- j- ^ uJ

. «l c «s
'■a * *
a a a
' ii ir ii
ooo
333

* X *

«I <X. <lj <£
^ -t «#■ 4

41 ^ ^ ^

II ll| II II; II

odoou

3 3 3 3 3

X * X X X

od a od or i

I S I

OJ 0>

H CVJ CNJ fQ 4

III II

II III II ;
X XI X
uj uJ uj ii>
a qj or iu
oq us

UJ Ld

U UJ

zjzz

X *

It II II

ii i

ij ii uj it 1

II II

ooo

u c

pdo

CJ o

in tA in

00 o

1 in lA V)

iA w

u_ Cl II

U. C

J u ul u

Ll) U-

<i! «x «jj t <a| «

a a 4j -4 j «4

a\ a a a a\ a

it ii m ii iij h

o o a o a o

3 a 3 3

X X X X T -e

J”

IT» II

o x;

23 4

CD . ,

,o o cr cr t-«
iao:Hdo
i a • • •

X. 03 tx

ft 5 or ir
I w

X ||

: UJ •

«* i j

4 iO O
rl 4 n

Nwr

i *"»

• ac 4 4

a. o ia to, ro

d 0 <\J r» n
J «. « « •

UJ O H H H

CD 1

o on no

Qf 0(\J ro O

OL • • » •
O' i o

X «rt H i

o^ : if» oo

a a} O CP o
<t O (VJ <o o

-J • • « •

UJ ri r< CD

Figure 22. Data bank printout for external lighting on aircraft work.

iM
* *'

'M CO

in v)
z z
o o

■ M M

!*“ t-

cm!

II !

in in in o
Z Z 2 Xi
O o o M'

M M M
►- ►“ I- 2

o oo o o m,

;«* «lj«* «t «* I

! «t'«t S

2 O O X .X I-

n m co <o t-

i CM
•t:

a a a a,a o',

XX.X

*!*

•I

•» a CM M,in II

• • • «i • 0£

m|m m tn a

O
«'
PJ u.

II II II II II O H

z x x x x «t

uj ui uj uj ui a.

or a a a a- a

o o o o o •»

PJ'

ll w
I- J-
Z CM
3 o
O a
O •

-J -J

1 “
I (/>
! 3

i ">

_i -« Li a

tUO'O o o

!M M M M M
X Of Of x Of
|M M I— M I— m
;0 O O O o cm
UJ UI UI UJ UJ
’ — J J — I ) — • II

.ui uj ui uj uj in

! -i

x x jc r x <c
u-u.u_u.U->
o

i ' x

11 || II II II UJ
X X 2 X I Of

o o o o o

z z z z z

o o o o o <
x x x x x 4
m n n m m 4 -
ll

•S

-J

a o
< o
-j •

lO o
ia o
a •!

z a

4
X o

la a
«x o

z :

4 o
Z a
« •
a o

•o o^;
fa o

ia. •;

* |

x ro

CD c
O

a ,

o '■

z
o •

<t :
•J !
UJ .

U- o

a n

■t w
-i •

.a o',

«t CM

X M

* i

I !

I i

0 1
a!

CO •»
Or

Of'

a f

<* )o

_ t

CD |

art

a «o

uj ro

4 jO

•i

ro*

%u\

•x

iCM

r •
J4

to t/> cnlto co!to coko
z z z z zz z z
OOOOOOOIO

M M M 1 - M 1 - K :m

0 0 0,0 0 0 o!o

< <1 < < <t

| \

a a

<t < 14

!«t

X 20

0 olx z z

•j

1 ”

'■ i

of ia of

a a or ar a

XjX X

X I I III

•

• t • •

vH J-

CM IA CM rO;M

l |

H |

O Ml

M CM M

CM JTj«H CM ; CM

^ 1

II i II II

II II II II II

0 III

21 X 2

a 11 * z

«Zl

UJ UJ UJ'UJ UJ UJ UJ UJ

a a a;a oc a: cc.ac

0 0 0 !

000 00

ro I

I f

ro 1

4 4 4

ofoo

MM M

a. a a
m!m m
00 o

UJ UJ UJ
•J [•«! «J
UJ LU UJ

_ «rl< 4i< 11

O Oio O O UJ

l r

oio o;

UI;UJ UJ'

O o

O •

O II
UJ CD
O
V) Of

3 a
->

a o

X X X|JL-

u-j U. a u.

1 !

11 11 ti ! 11
X X XX
o o 00
z z z z

o o 00
X X XIX
ro ro ro'fo

CVJ .fv» CVJ-CNJ

:«a m

uj a
J a
uj uj uj uj a

♦

„

u- o > U:
O CD
Z X CO
II II Hill < UJ X

ixr'iajft:

00 our m

Z.Z Z z M

1 Z

i , o O O
XX
OOW<

X X CSJ 4

ro fO 4 4 o

CSJ CM II X

XX I

Ll U- u.

o o <
X x
fO ( fO I
CM CM <

4 4 4

4 4 0

«t

X' X '0

! J-

-r j-jj-

4 O

iLU

UJ z •

-3

M. JM

II X

H O

-j

•

m;o CD

•

II I

II If II

11 11 a

i«t O

II II ! II

h 11

11 co a

OOO

000

O 4

0 j- a

0 0 00

0 0

0 u» 0

3’

tO {/) (0

w wu.

UJ 4

uj j- a

l/t (A tA

O') 0

C />

(/)< u.

u. u. U-

a u_

> II

> 11

U-

u_ u. u_ a a

< < <

«* <

O O

0.0

4 O

*■ O

X 3

UJ X

a 0 1

0 X

a 0 0

0 0

O 4

000

0 0

u. coiro |

XXX

X x

X H

< < «

M a CM

«t

«t <t <x

«* «t

4 O

4 4 4

4 4

♦ <14 ,

444

4 4

4 3

4 4 4

4 4

* . !

444

4 4

4 X

II II II

II II

II II II

II II

OOO

O O

* •

000

O O

0 a

0 3 0

O 3

♦

» ■

3 3 3

O 3

3 0

I 2 X

X X

2 2 2

X 2

* u.

l-l

•H

«d

•u

♦ ****IF REMOVED ITEM ALWAYS BENCH CHECKED BEFORE REPLACEMENT^

WUG=44AH

AFSC PR08 KWA ... KWA E.LAP .PRO.B. NOX_KWA C.OND. PROB_WF ELAP.WF COND__ERQB NJt ELAP N4

423X0 *92 3.19 .08 .50- 4.23 .50 1.05

•

■

■•j

A-

4 IA

! z °

a. *h

(/)

(/) Irt

CO (A

V) V)

(/) V)

Z Z

z z

Z Z

o o

O o

o o

(/)

•

M M

M H

I *

h- H

a I-

1- ►-

1— H-

i. .

UUUUiUU

O O

4 o

d d

Z (A

-J

•

Li-

«t.4

3^0 0

O X

3 Z

ih ro

CM N

ri O

r-» tvj

■

cr>

a a: a a;

O' a

O' O’

X X

•

•4

•

[

flo 4

LA N

yi a

M a

•

• •

• .

a ro

CM Ti

in ro

n t*

Z IA

•

O *4

a ro

CVJ y-i

y-i CM

4 «H

cvj aj

ll.

-J

II II

ii II

a h

XKXZ

X x

x x

UJ! UJ UJ

UJ ui UJ UJ

UI UI

j‘

K or

a: oc ot o'

O’ on

• •

a o

o o o o

o O

o o

X IA

•i"

•

►-

y :

II CO

h- cr>

Z IA

«•

3 a

O o

U •

-4

Q II

Ui CD

H O

=> 0-

d |A

-I

-J -1

-1 -J

-1 _l

a o

-J

•

X o

• d

< <

«* «

«* <

^ •

o o

O O

M M

a ar, or a

O' oc

o' a:

•

►- H H »-

*- H

i- i-

ro ro

o o o o

o o

LA S-

-J

UJ UJ

Ul UI

UJ UJ

UI UJ

■

-J

-J -J

-1 _l

_l -J

UJ Ui UJ Ui UJ UJ

UJ UI

•t

X X

x. x

X X

« II

U. U. U. U. U. L-

u u

> u

•

O CD

■

X CO

C*i

a <r

ii ii ! ii it

II It

II II

UJ z

d *4

z r r z

X X

-J •

o o

a o

uj ro

z z z

z z

UI!

■

a o

o o

O o

X X

X KX X

X X

-J

ro ro ro

ro ro: ro ro

ro ro

•S’

cm; cm cm

CM CM CM CM

<M CVJ

d | ft

4 J- J- 4- 4 4; 4 4

O d

X O'

^ 4-

X •

►

X 4-

■

-1

•

in it n

n ii

It II

II II

QC O

d UJ

o a o o o o o

o o

0 3

Q!4

O 4

i/i

V) V) </) l/T 1/3 (/I

CO to

U. X

UI 4 Z

UI 4

a a

U. U. U. UJ U. U-

> II

d d

•c <

O O

X z>

Ui X

u x

coro

oo ro

d d d d d d

«* «t

h-4

a cm

4 4

4 4 4 4

4 4

d 4

4 4. 4 4 4 4 4

■M

II III II II

o; o o o o o o! o o

D|DDbDDD;D3

♦

X X( X x. X Xi X X

(

*T3

P *

■

3 IB!

HI 1

,L”.

3 Hi

W '

—

u —

3ISi

3 HI

■

3 IB

3 HI

" *

3IHI

IBS

■■

—

*4fJO<Jkd

I|IDX

•‘“•I**

■SSSSDpraugcinng

KZiHDOcaaiacaicaHDBiraE]
■ W H H ill ill I II II i IH ■■■! Il l

dSdduduuusdsqu

lElHmZIEaBdESgIHgBJgg

□SSSSDgcigggggu

■■nnniaanPHa—nH

ISiBEEC3CaEIgaC3MITSgg

inSSSnggigggBBng

joSHSSSSSSSuSniS

go
go
SB
p n

gEg

DO
BO

□og

aMP^siumsBciBln i ii i im

□■EEi^iaiacia™gg it3

gBBBBBBBBBBBfiiiii

!■ !■■! II Hull II I
in^BEPcigM

■■ Kapp

■MODgl

Sbbi

•p°w •i*sj

IClBiaglClEICJPlEiT IBB

ESI

jdEitai

ipnr:ni

incitimi

inucici

inpBEEnpEgcacjcata

irstar:t:r3nnc!HC3C3nn

IHBj BEBBBBgjBggg

SMESBrararaorani civile

icidB

[gggglgggggjJBBH

Figure 24 , External lighting network coding.

■—

—

!■

rtri !■ riWA riril HHHH BE ISS

AHMlIltalMtiMUHIHl

IQHiK*J!MKiilH^IIg8RifW

li— 1

smwmmmmmmm

Ll taril It A HH HI HH MM MM HH

OMEiHIIIHHHiS

ElHESHHiMMIHBi

UBHEJ^Hkd ■■■■§■ HI

“

□HftSIHBflISJHHH

“" T 7

EIHKHHEK3HHH

□HKaHKSECHHH

BHNBHKaEMHH

OHDHEESmB

DHK2BCIR«fiB

BBDHHHHFilM

BHtaHKSK'lHft'ZlH

□■UBLiCHtt

ini

■j

*••

' '

□HK3HCiK5HE3H

■

tJMh^2HiBiMiHHB?'MK!

i !■ i ildBBHCl

□KWKI'CHLkJKIMKJ

TT”

bbeeeeeBBB

eeceebceb!

i®

—

jbih^hHHHO

Ei^gicmnc]i

SBmSCSKSKdnKm

BHE-HHHHE3HI

— ■

—

-p— 1

—

MWEHWWI

BEjHBBHHHHI

BkdHBEa ■■■§!■ HI MM

— |

■i

[JldHF^lllHBiHHiHI

BBI

■1

q g-j g-i r «i r-A g.i r-: ■>; g-j i

9KQE3@E3E3E3BBI

—

■HI

■hi

■HI

—

= i

|E3K3E3EaE3E3C3E3l

— 1

3cacat3^ancaracai

3E3C3E3E3E3EaE3E3l

H j

iBBRilBEjDiai

— 7

HI i

3KdHK2K3E3E£HK2l

3E3HE]E3E3E3Hra

3C3HE3E3C3BHE3I

acBBcncno

1I IIIBI II II !■ !■■■ II

II 1— ’ill II "II MU'ill

—

— S

—

w*»

= i]

.5 Hours x ( 38 rep ort ed V , Act i ons. \ = ml Hours
\^219 Total R + H Actions/

The average troubleshoot time over all corrective actions on the subsystem
is .7 hours. These times computed from the data bank runs are only the
initial cut at networking. They should be factored for any significant
design differences and verified by experienced maintenance specialists.

Engine Network '

MDC data is of relatively little value in developing a network for a
basic engine. Data bank print-outs are available to show engine work on
aircraft, work on entire engines in the engine shop, shop work on components
removed from the engine, special inspections, and removals for access.
However, so much of the unscheduled maintenance is reported against 04
inspection codes and even 09 shop general that the data bank probabilities
often are not meaningful.

It may not be feasible to determine the frequency of engine removals
from MDC data since there is no standard way of reporting an engine
removal for failure. For example, on the A7D work unit codes 23B, 23AJ,
and removal for access (to the internal parts) are variously used. The
AFLC depot engine managers require separate reporting of each engine
removal for cause, and these are listed in the monthly base K-18 mainte-
nance summary. The average K-18 count over the past year from bases of
interest may be the best estimate of mean removal rate for a comparable
engine.

The engine removal task sequence through functional check flight,
and the proportion of on-aircraft troubleshoot-adjust-fix to removal, should
be based on information obtained from the engine shops maintaining comparable
engines, and modified for the maintenance concept and requirements of the
new engine.

An example engine network is shown in Figure 25. When an engine is
changed, the aircraft is towed to the test cell for trim and runup, and
then taken up for a functional check flight. The engine goes into the
shop for teardown. Portions of the engine may be removed and replaced,
and the engine reassembled for use as a spare on the next aircraft requiring
and engine change. The parts that were removed from the engine are
processed through the field shops, and when repaired are returned to
stock.

Engine network coding is shown in Figure 26. The example only depicts
one of the engine sections in the shop to illustrate the technique. The
first asterisk is on the engine teardown task. This tells the computer
it is now working on an engine (WUC 23000) and no longer holds up
the aircraft. A Q task draws the replacement engine from spare stocks if
available. At the next stage the Q task draws an assembly to be replaced
on the engine. The asterisk at this level tells the computer that the work
is on the removed assembly and does not hold up the engine.

Figure 25. Schematic of engine network

26. Engine network coding.

iai

§31

ESI

BQI

IBI

JQI

(31

□I

101

IBI

IBHO
If ill li

■■ IH II II 'Ml !■!

IKEMBEHEWCnH
MUUMIS1E3E3HE3MB
IE*«E3E»Em;jMlB

lEjHDKlUHKaEI
lEIBBBSaCHCI
IHZ]BII^C3kdHVJaiEu]l
I E 3 H CS IS Eu WM E^HI K 9 1
ECMKHEELMElHira]

i«a «3

■□B&HMBIClMEaKsEaSEES

■■■■3 eBEEE BEBEEEe

|BEEg«£Hrswwggi»gigag^^|g^irJg=i

|B^C]MMMiaiifliHiai5]i5]EaiaE]

ibEEBEE!

□*2131 IKvMBg
PC3EaE3C3i

E3E H5H-JI2JE] |

BcaiaKiidEii

□hmSImi'mm!

W£ Zl u1

BKSElEJBdi

BEJElBEOWal
BCiHulEnCdCtli
BESESESdKSJi
pElHBBBj

BE3K I l 5 ev 4|

3151 El Cl Cl ia i
□raraggigi

iBEiaiaiaMiaial
iEi3nic«cB

l l^]g;ll I f M| || ||

IK51K51l5]MECHiElE]|
ir i ii ibi im n ij

■BcaiaiafcaiaEdCd
■■acaiacasa m iciei
iccaiaKsaBciBiEa
ICIBBBCdHBe

iKsiLsiacjEawfiB]

IDCDDDDHUEl

ICinOClEIBEilED

llulBEDCOElHICDd

lEdBKiaEilEdHEIE)

tgine network coding (continued).

The engine work center may be subdivided into different sections
which do not do each other's work. This is one of the maintenance
concept assumptions that must be obtained from the operating command.

■ In Figure 26, the flight line dispatch crew is coded 432X0, technicians
assigned exclusively to shop work are coded 43250, and the crew
dedicated to the test cell is coded 432T0. The pilot who does the
functional check flight is coded 1115K. He is treated as a dedicated
resource and is normally only available during daylight shifts. The
functional check flight is coded as a maintenance task rather than as
a sortie task because it is not scheduled on a Form 20. Note the use
of header cards to supply nomenclature for the string of check tasks
following engine change or on-aircraft fix. Also note that resources
are not shown for these tasks when they are repeated.

Engine accessories and accessory systems removed and replaced on >.
aircraft are shown in separate networks (engine fuel system, engine
electrical system, engine oil system, etc.). These networks can be
satisfactorily modeled from MDC data and were not illustrated for this
example.

Complex Avionics Networks

The A7D forward looking radar (WUC 73AOO) is one of several integrated
subsystems comprising the A7D bombing avionics. - It is one of the most
complex networking problems a model builder is likely to encounter. Some
of the troubleshooting and radar boresighting are reported under 04 series
work unit codes. Much of the troubleshooting is reported as cannot-
duplicate (CND) . If the initial troubleshoot does not locate the fault,
another specialist will be called in to check his subsystem, until the
problem is found or clearly cannot be duplicated. Some corrective actions
require multiple removals for access, and some access removals are checked
in the shop. When NRTS items return from depot they are given a full
bench check, and in some cases may be NRTS back again.

The 3 digit on-aircraft data bank summary output is shown in Figure
27. The FLR is maintained by 322X1 technicians. The few instances of
work by other AFSCs total less than 1% of the maintenance actions and can
be ignored. Part of the special inspection data bank output is shown in
Figure 28. The 04128 and 04129 codes report troubleshooting and/or
boresighting of the whole bombing system. Some of these involve work on
the FLR. Figure 29 shows the CND troubleshoot matrix for the whole
bombing system. The subsystems and special inspection codes are listed
on the vertical axis. The first column shows the number of CND trouble-
shoots reported against these codes in the data sample. The next columns
show how many of these CNDs were associated with a corrective action on
another of the integrated subsystems. The last column shows how many
were true CNDs not associated with any subsequent corrective action. The
matrix shows 162 true CNDs for 73A in this data sample.

: l

)! to toj co v

VJ 1/

(/) V

1 :

i to to to (/> ■ to v

l|C0 u

vj! vi

V) V

o c

O G

» o

rizzlz:

Z 2

Z Z Z Z,Z 2

Z 2

;

Z 2

cl r

a c

); O 0 : O C

O OO C

O O O OlO oo o o

o o

o c

•

(IN HjH h

H L

l|HH

IHHIHK

I'M 1"

M M M <r

M M K H

IP®

M »-

< o

•Ihhh H

H •-

H »■

- *- H

1— 1-

1- 1-

M •

Sari

1- H

- •

I o o o c

IUUC3L

MO 0(0 C-> O O O O O CM

O O M U

o c

> a

<t C

<3 <

C <C «!,< <1

<X c

<t <!C C3

t;C

i **!

<r «

Z 3

: z a

;l a a;! o' a

> 5

.-H

1- H

■j*- it

CL |

J Z

z z

1 UJ

• UJ

«*

i fo ti

3 00 lC

l|Cr N CVJ ir

o c

a in v

< 4* CVJ S. lO cm z

M X

3 o.

vD 0 -

1 z

: XI 0-*! O CV

1 u» co

M U\ CVJ

CM h-

O' M

1 x or

<o cv

ro m

V-

■

•

'airiro

or or a; o:

ororaror arorora

or t

or -

or a

i .•

I 3

X X

iiiii

X X X X I X

X X

0. IT

ioo.o

< CV

10 4 0

cvj; cm 4 10 cv

CVJ 4 4 «H <U 0Ou*fO 0 H »£)

in c

■t

0 1

ani

o oc

i •

•

• • • €

•

• z

•

U tH

O 0-

▼-

1 CVJ CVJ CVJ th

M -H

CM 4

4 <t

tH «a

CM 0 -

▼H

cvj ro 4 ri cm ro

4* in

0-| CV

ro 4

•H CM

ro 4

in «

ii i

II II

i 11 II

H H

II II

II N

II II

ii ii

o o

o a

X 3

x X

X X

X 3

X X

CL K>

o a

LU Ul UJ UJ

UJ u

Ul u

UJ u

UJ II

UJ u.

CL 0

0 •

a: a: or a: a

or or

a or

O' 0

or or

CL CL

CL UJ

or u.

CL CL

o o o a

o o

o g

o o

o a

a z

o X

O CJ

OJ II

«X

3 a-

X CP

ro o

CL 4

-1

.j -

-1 _

-J -J

-j _j

-1 -1

-J «J

~J <t

o c

o o

o C

o o

o c

o a

o o

o c

o uj

UJ CP

a a

ar ar

or or

or z

CL 4

ro o

1- h-j H-

h h

J- H

f— i-

K »-

»- »-

i- *-

M *•

•*

o. a

! <r cm

N» o

z z'z Z

z z

Z •H

V> H

o o

_l 0

o o o a

O O

o o

o X

M X

I X

0,000 c

o o

O CM

Z IA

vj to

UJ CM

co on

to VI

V) v

to VI

VI V)

V) co

on ro

Z 00

UJ (J

in ii

2 :

z z

Z H

Z z

z z

o o o o

o o

M *-*

0- CL; CL CL

cl a

a. a

CL CL

a cl

a a

a. a.

X X*

<£ <t: <X <T <J <f

«T <1

«X <1

< <c

« Ct

<r <t

o o

0-4!

0-1 0-4

UJ UJ UJ UJ|

UJ UJ

LU UJ

UJ UJ

Ul u

Ul o

z o

-J

< «t

O X

O X X x

S3S 3

X X

X ^

X X

X XIX CO

M ifi

X X

to cm in 0 -<

▼4

IL M

Ll CM,

cm ro

> =>

> >

> <

> ^

z z

< M

•x to ro 4

«* <t

<r <t

< <1

<t <

< <

<r <t

< <1

<X »

« 1

••

u. u.

r S

II II

li li

II II

ii H

II II

n ni

II II

n i

II II

X X

z z

X X

z z

z <t

X «aj

«r

z z

o o o o

o o

o ro

o o

z z

Z z

z z

z s.

zol

N-

a <

■

3 n

N-

M -H

0 H M

▼H "H

■H tH

rl M

T-| M

M X

▼*

Ti X

X X

X x

X X

CVJ

CVJ CVJ

CVJ CL

CVJ CVJ

CM CM

CM CVJ

OJ OJ

CM CM

OJ CM

CM CL

in'

in a

CL O

<M fV

CVJ CL

CVJ CVJ

CVJ OJ

CVJ CM

CM CM

OJ OJ

CM O

CM c

O 3

ro ro

ro oo

ro u.

ro il

in in

U. X

li li

ii ii

n n

ii ii

M ii

II II

ii ii

o o

o c

o u\

o o

o a

o o

CO CO

on c/

to t/>

CO co

co c n

(/> CO

00 CO

CO CO

CO 00

U_ L_

Ul U

U. U.

u_ u_

u. u_

u_ U-

IL U.

Ll. U.

Ll. Ul

<t <1

•sc «3

<1 <t

<C <1

< <

«t <z

< <

< «r

♦

<t <

<c «x

< <t

< <

*t <t

< <x

ro ro

r-J ro

ro ro

o ro

ro ro

K K

N. K

n. n-

0- K

N- K

S-

K N-

ii n

H ii

n ii

II II

ll II

O G

O C

o o

L5 O

O O

3 3

3 -

O 3

3 3

3 3 1

3 3

X X

X x

X X

Figure 27. Data bank printout for FLR on-aircraft work.

*') p - = 3.Hl24 A e SC = 325X1 NQH = U l TVSTRU MFNTS C^-^= 1 1.5 HR 15 V ACTIONS

W'|-; = 0h124 A"SC= 325X1 NO 1= *V TN3 TRJ MFNTS CREW = 2 1.5 HR 354 V ACTIONS

H'I0 = Q412.4 . APSC=_ 32.5X1 NO H= AV TNS TR.UH r NTS CR5W = 3 1 . ft HR 5 Q y ACTIONS

H'»3=0**l?4 4^50= 325X1 N0 V = ay TNSTRl) MFNTS CREW= 4 1.3 HR 2 V ACTIONS

co on

OO M

W 0 r

oo on

00 w

(/I

00 oo

z z

o o

o a

o o

M M

b-i

l-H

M HH

W M

M M

W M

h-i

*- 4-

H-

h h

1— ^

t—

V— h*

1— h-

1 —

O O

o a

o o

d d

<* <C

<£

d d

> >

in oo

in ro

CD T-

*■*

aO aD

PJ PJ

o n-

■

•4

(v' a'

V O'

cy cy

D' cy

«y

X X

X T

X X

•x

X X

(\J

N O

4 co

■H PJ

v£>

▼H

■

CM tH

. ^

CM CM

■H PJ

cm ro

44 in

cm ro

•s

ro -4

II 11

n ii

ii ii

II li

ii ii

X T

X X

III HI

iii

lit

Ui Ul

fWWjjT

lil Ul

lil

lil lit

III

a" of

cy cy

ii<l^

cy cy

o o

to o

o o

> >

•>

<t <t

7 Z

-J

-J — 1

«j

-j

-4 _J

<x <t

«j

-j

-i -j

«4.

n o

o o

4-1

cy tv

<y cy

K t—

cy cy

4—

. h

H- »-

l~ 1—

cy cy

►-

»-

h- h-

UJ tu

t/>

z z

Id Id

z rr

u.t

z z

i»

o o

z z

o o

i—

M M

4-1

o u

o o

»-»

HH t-l

►H

o o

4-1

-J -1

-J

Lt!

li.

1 1

•

00 oo

oo to

cy ry

o y

CP 00

4~ 4-

I—

z z

tu l;J

1—

X X

o c

o o

-J

_J -1

-J

e e

-J

t0 CO

(J5

4 -

0. Q

Q Q

a o.

c a

M M

4-<

1 — *

*X er

<r «r

0 0

4-1

«T

cr cr

-J _J

-J

lil lit

I!' Ul

o c

!«’

Id UJ

U U

-z

X X

o c

X X

> 5»

> >

■>

■> >

n n

i.i

I'-

«3 «r»

«rr «rT

«B*r

•Cl

III

»~

•rr

Cl Cl

«-r

11 li

II It

II II

If 11

X J

«*- T"

i X

’r- y

X-

x y

o o

o a

o o

7 X

z z

. z

r z

. •*

*H <H

**“l

H H

<H -H

-4

.4 -4

»H .

rl rl

X X

X x

X X

rl H

CM CM

m oo

•h!

CM:

PJ CM

<r>

ro ro

CM CM

r-l

ro 1

CM :

PJ CM

ro ro

ro ; ro ro

c ■

ii ii

II 11

II II

n it

II II

o e

a o

o o

o c..:

O <3

00 00

oo to

t^j

to l/l

l/l

to 00

</)

u u

U Ii

u u

U IL

u u

d <t

<T <t

<r <i

«TT <7

<r a

-a- t

aO *0

cr on

rc *0)

c n

ni cn

cm m

Cm Cm

CM (M

P.; P!

p.j

PI PI

•H

rH r-<

r-l

■*— 1 rH

^i|

rl rl

r-l

4 t

4 4

*4 t

4 *t

-4

4 4

CD O

O CD

CD O

CD CD

' o

CD!

o o

II II

II !

II II

•*

o g

o to

t‘ O

C> t'

C_> O

X Z

—>

— — .

— *i

— • ^

— ~

— *

-TV

— ■

— ’

—

X Z

•V

X 7

7 *»■

X X

■U

•H

* OF JCNS 72A00 73A00 -73000 73C00 73000 73E00 " 73FOO “ 73GQ0 7AE00 CNO OR

WITH RCOS R OR M R OR M R OR M R OR M R OR M R OR M R OR M R OR M R OR M NO R/M

Figure 29. Data bank printout of integrated avionics system CND troubleshoot.

The CND matrix is also used to determine the probabilities that a
corrective action on a specific subsystem was preceded by CND trouble-
shoots on other parts of the bombing system. This is found by summing
CND actions by each AFSC in the column representing corrective actions
against the subsystem. The AFSCs have been noted on the vertical axis.

The FLR (73A) is found in the third column. Summing from the top,
there are 4 prior CNDs by 46240, 87 by 328X4, 218 by 322X1, 9 by 325X1,
and 7 by 328X1.

The 162 true CND troubleshoots for the FLR are actions over and
above the corrective actions that went into computation of the failure
clock. If it is determined that they should be included, the clock
must be adjusted. Figure 27 shows a total of 1652 R and M actions.

There were 14,386 sorties in this particular data sample. The revised
73A clock is:

liiiM = 8 MSBMA

(1652 + 162)

The CND is networked in parallel with the 73A troubleshoot, and of course,
leads to no further action. The E probabilities on these troubleshoots
are simply:

1652

e 73A = (1652+162) = - 92

162

e CND = (1652 + 162)

The preceding CND on other subsystems that were determined from the
matrix do not affect the 73A clock. These are simply additional actions
in sequence leading to a networked R or M corrective action on 73A. They
are shown before the 73A access task as parallel E probabilities. A
dummy represents the probability that no prior CND troubleshoot was done.

The probabilities are:

.. 87

E 328X4 * (1652 + 162) " * 04

218

E 322X1 " (1652 + 162) ~ ’° 9

E 0 = 1.0 - (.04 + .09) = .87

These networks are diagramed in Figure 30 and the coding is shown in Figure
31. It is important that prior CNDs be shown in the networks containing the

■1

p^KId^Ql

pUBIBMI

l^i

SHMH

'Hi

IHI

hhi^h

i 4 Mfjj

Hi!

IHH

nMIH

Hil

plHBiHH

1^1

IHi

pman

IHI

□EJB

I HI

IHI

□EJB

d£

IHI

Hil'

□k=b

E3E3BS

□ejb

EEksj

EBC

■

j ^H

SSScJ

EEEE

bemb

CIEIia

■aiaiaia

■a

□E3B 1

■

\wm

D«3B

□ejb

nwsm

□E3B

BfcJB

□kJB

QDB

□BS

ESIBEi

E3E3E2

BEIE

dinra

E3EBW5]

BIEQES

BBS?

esesb

ESKSE

IE3E2E3E3BS

lE3E3E3K£E3

EtMBEQEHlS

EEaKSELlE3EB

BKSE3K3KH

ECPCIgi

:E3E2E^E3Ej!

Ksrcraisitt

i E3 K @5! K5S EJ3

EJHI

■23 E3

GtJCJ

B9E1

IBSS

E3E3

KjH

bes

□L3B

DEB

□B3B

Cld

SSB

■sIISI

E3K3

□E2B

iiH

BkJB

IHi

IBB

AliJOIjj

VoI~5K r

□EEI

GCU|

beeBBBeiBBB SoSSSI

□UBBBBRBKg g^g^d

BBSgaEBMEiiaBB BSBI

□ S 5 SI SE !■ ■■ ■! 51 IS mi ■■ Si
□■BBBBBBBBBcaB BSI

BHEdKulEillSDKtlHEHUHra
HCElEIBEipBHCIHBHg

|rBBKi]BKw]|
lEB El HEll
iBrjiMI

jlQISlEDEil^^^l

miPiMPiPl Flini

IBEIBESBKSIBEICIBHgE^ I
IESlKfilE£ldlE5imCSKu]EulKwlk^G]Gl

iiaEaiaiaiasaiaiata^Eai
'T 'aSaraRwoiEaEaftza^iBi

iiaiaiaraiaifflraiacifsiiiai

□

lira

IE3

inn

IELJ

Figure 31. Integrated avionics FLR subsystem network (continued).

•p°w*i»y

^■1

—

•

■i

■ii

inHi

jnMs

hhi

hhb

....

r '

PHI

nmm

naas

nai

!PIH

nmm

HBB

nna

HBM

DBG

RBI

nmm

inHH

"• "

f^BI

—

nmm

P9H

QBH

KSJBnen;

nfli

ELI

nil

ESI

KSSI

inH9

—

3H|'

ESI

Tsl

S'*

99 1

■SI

ina

■a

Inn

inn

fffi

■

.. __

it]

■ —

nan

■F*

■a

•

ini?*

EBE&HUEj

IHIS]E51E3R3E^E»1

warn

jnr<e ^w^otawi 4

PEtMSBBISlESld

• . •

lOEBESEHESEaB

inn

■

•

»• fc

IDES

inn

3LZ

offii

ft*

E S

ran

•fd

wni

i=n

inn

■1

IHI

—

M-?ara*51K«®*3Kslla3

(HKSEZ

1 z

laiara

aBK-jQlBEeiE

iQBSCtldlKflEBCZI

siaraaBian

insvin

IBECiE

■Bn

■ PK*

||M

IBi

ims

]■

>IC«]E>JE3E«1

□mn

I1E>]E?JEs1E«J

DEn

iir

bbb

ITZCBPIE

cMSM

liaEIE3E

■ Hi

■ nraaa

[■:

:s:ib?

199

__ —

____

IBB

—

eventual corrective action so that the simulation clocks and frequencies
of dispatch are not distorted. ^

Access problems are peculiar to each design and usually cannot be
extrapolated from data on another aircraft. However, this example of an
A7D access problem is shown to illustrate the impact a poor design can
have, and emphasize the importance of a thorough review of mock ups,
prototypes, and test aircraft to highlight and correct any such condition.

The FLR Air Navigation Multiple Indicator, WUC 73AE0, is mounted in the
cockpit. There is no difficulty in removing and replacing this indicator.
However, there is a small plug behind it that sometimes needs replacement.

It does not even have a work unit code. This plug can only be reached if "
the windshield is removed. Changing windshields is an 11-hour job by
three 431C1 Aero Repair Specialists. Before they can do it though, two
322Xls must remove the HUD and two 328X3s must remove the RHAW indicator.
After the multiple indicator and plug are changed and all the rest put
back together, the 422Xls must do a cabin pressure check. This requires
322Xls to swing out the forward looking radar system so that pressure lines
can be hooked up through the nose. After everything is connected, there is
a 24 hour cure time for the test. Because of poor access, the failure of
one small plug can tie down an aircraft for about two days.

Only two of the nine FLR LRUs are illustrated in Figure 31. The shop
entry for the indicator coming off the long access goes directly to the
appropriate shop tasks, bypassing the G probability. The NRTS task is
followed by a depot turnaround time dummy. The time for this task is set
by the program and no extended 11 time entry is required. A task is
shown for bench check on return from depot. This task does not appear in
MDC data runs. A maintenance concept assumption from the operating command
and/or the opinion of experienced technicians should be sought to determine
whether such checks ought to be in the data base for a new aircraft.

One more unusual network feature is shown in Figure 31. When the mount
breaks or is damaged, the radar set has to be realligned by dry boresighting.
This is a six hour job. It is shown in parallel to the Q task following the
G probability that determines whether the mount had to be changed.

V. NETWORKS FOR PHASED AND PERIODIC SCHEDULED MAINTENANCE
Phased Inspections

The number and frequency of phases is a policy assumption to be provided
by the operating command. Networks for phased inspection work are based on
phase procedures for similar aircraft under a similar inspection concept and
must be developed through interview with experienced technicians in the field.
The inspection work cards are too detailed to network directly and MDC
reporting is far too gross. The work done in each phase and the task
sequences, times, and crew sizes for each AFSC who has a scheduled task, must

be set out In network form. A linear series of work card tasks by the same
crew should be networked as a single task. The simplest phase network
would show each specialist crew's work as one task and all these tasks;
would be shown in parallel. It is not usually so simple since there may
be constraints and access requirements among the work by various specialists
that must be identified and shown in the network. Any scheduled removals
which go to the shop for servicing must also be shown. For example,
hydraulic filters are regularly replaced and sent to the shop for cleaming,
generating a task workload in the hydraulics shop.

The phase tasks for comparable systems must be carefully reviewed in
terms of the new aircraft design and maintenance concepts in order to delete
inapplicable tasks, modify others, and add any new tasks. Contractor
recommendations, engineering evaluations, opinions of experienced mainte-
nance personnel, and operating command policy assumptions need to be sought
arid considered in making these judgments.

Unscheduled corrective maintenance in phase may be estimated from MDC
data on similar systems and subsystems. An MDC run of corrective mainte-
nance in phase is shown in Figure 32. Data are grouped by AFSC to match
the way the inspection portions of phase are networked. For each AFSC
and work unit code it shows the frequency of R or M corrective actions per
phase and the average time per action. The summary also shows manhours
per action, which can be converted to average elapsed time by dividing by
typical crew size.

Portions of an example phase inspection network are shown in Figure
33. The frequency (e.g., every 100 hours) is scheduled on the Form 20s.

The main networks include a phase dummy sortie followed by tasks for
aircraft washing and ending with the phase entry node (SPLIT). The phase
network follows after the last main network task. It starts with the
phase network entry node and an E probability split into the various phases.
The examples in Figure 33 show the main network portion, the beginning of
the phase network, the beginning of the phase 3 portion, and the 424X0
work in Phase 3.

In coding phase tasks, type task is 3 (scheduled) and priority is 2.

The organizational maintenance personnel dedicated to phase are coded
431P1. The recommended task' and node naming convention is P action code
followed by a sequential task number for inspection tasks, and UNS in
columns 12 - 14 followed by a sequential task number for corrective actions.
J node numbers may be used, provided that they are a different series than
are used in any of the main networks. In the Figure 33 example, numbers
under J1000 were used for other main networks, so J1000 and over were
reserved for phase.

Unscheduled maintenance can be entered as a single task for each
AFSC. This task represents all the corrective work done by that AFSC
in one phase. Tasks in flight line unscheduled maintenance networks des-
cribed in the previous chapter had to be broken out by action type and
work unit code to correctly simulate the job frequencies and dispatch

I'v

u. K

l(X v

! *

pi N

N 0J

O X

o X

-X

1 X

P x

X o o

u. X

£ x

X Ll

i 11

i ^

iro

•H

|H .

•

: •

•

■ •

•

1 •

•

1 •

loo.

*■ ■

t/)

Ito

•d

P-

r |

. .

^ l

:to

•

• (O

• 00

CO •

•

x !

O X

o x

jx o

X 1

Z T.

2 X

X 2

s x

^ r

•

d ro

id kD

4- ■=£

•

-1

•

-i •

•

H •

•

• -J

' Jj tH

■>-

^ UJ

A-

<•*

J-

— <

•

UJ (A

00 Ui

A (A

00 00 00 00 UJ 00

A t A

00 UJ

►—

h»

|h-

H-

00 1-

H-

—

h- f-

A 1-

—

h- 00

o o

O <

<r o

o o

O O

o o

o a <r o

a a o <t

X d

«t <1

«* «

=i <

X d <t d

d X

lL I

a. cl

°l

Ll X

X X

u. x

IX £2 > Ll. u.

:.!

O 1

•

■

•

' •

• •

•

T-J

• OJ

n <h

• CM

o to

z |z

X |

-L

\ \

*■

T- .

y-i

□o

CVJ

•

• •

•

00 VJ

/) 00

/J Ml

to to

o to

;

a a

O' ac

x or

O' X

X Of

x : x

X X

r i

n. ro

J- CD

3 J-

•

• •

•

*■

•H CO

LfN

▼H «H

▼H

d j

ro !

]

H II (H \A
tiJ

a. a jo. oo

«* <i\<t <

UJ LUjUJ CL

II loo II III II
liJ -I
a- \U) CL
«X i<C <t
-JlX -J

\a. a_|u-

|uj uj [cl uj

] *4 OjjfO o jCM
! ii II (h v. In

jI2!3 X !X
Ui LU .UJ T 'UJ
CkT i* \CY T
O O O O
vD

UJ UJ |UJ UJ lUJ UJ

II II

II tl

|o -r-1 (cm ro
|v II III II III
UJjX UJ l»J UJIUI

iy. iz. or. la a ‘u:

Uloop O
no

.X rl WH

p°f 5

* a op

* ItH H M
it . H H ;H

* tl It *l»

'' ■ o

-J

■■•J

, ii

«T

X I

jin co I cd mflo

U> UJ UJ U) UJ UJ

> r x > *
M it ju H hi

o lo o buuubo

O |C5 H3 lu T> 3

2 12 2 j.r 2

Figure 32. Bata bank printout of AFSC 424X0 unscheduled maintenance in phase.

pSSSSj

j|SES
BEE

□■■IE]

Bmwmms

[■■K

■dudBII

B 0 K 3

pKn
Ebej
HQES
Bans
incn
Ebej

QB !

: DE 3
-□El
iBE

^[inBin^EOIBLiEiniafl

BbSEEEeS|K!!IK 3 I!DE!»IEE

IKSEtlEZli

IESBEJI

IE1CC1I

Hi Hi

■■

E 3

mm3

—

E 3

■

fll

■Cl

■9

HKD

■

EU 1

■

HE 3

K 2

I 1 L 3

■■IT

■IK 2

IIBEI

IIIEU

IHO

ICCIO

IBEE]

ihbe/]|

IHHE3I

IIEE

IIETES]
■IEE|
IIE 5 H

■■eb]

■IKS! ESI
■ ■■EH |
■■EM
■■HM
■■13 Bl
■IEBH

□

EBSBIIEDE 3 E 1 IEE]

oKUKKKjgMjgagnagnKEl

IHI

lEddlll

USEHSIIII

•wit

IIEEEEEEBEEEEKEigl

iBBCliilBUHBEEI^HBB

BEEECDHBEEgllBB

]BEEEEBHBEEEjlBB

]BBBEBDIIBIEEBHBiB

MraiaUlZUHHUESUHHISlI

isaiaisiisiEaiBi

3EDE1EIII

3 HEflElE 1 IHKaiBj
' iksCflEIBI

iisisisiarai

1 I 3 HBEEE 1 IBC

3 EIIBEBSEHBB

|E 3

IEEEI

□BiHiHHBBB^'IBlMHMb'll
^■■■■■ElMiaE EHl
^■■■■■BIIHHEkSlI ■

□ HHHH|a|aa| ^

B™EBI3EWE I3BEii

EHE?ME3HMBBE3M^^^^H

□BMi .' IS

SraBSSB^BSS&^SSSSSBi

■■■■■■■■■MHDEIIli

ISSSSSSSSSnSSraSS

|SS™”SS9HBI|

|EtlH^aiKw]E]BaHEaK3E3CaH|
iE3MB2HBEZIBIflBB3B3EZlK2!Mi

network example (continued).

of crews to the flight line. This is not necessary for phase since most
of the corrective work is generally done by the same dispatched crew in
conjunction with their inspection. The corrective maintenance task is
shown with an A probability following the inspection. Most phase repairs
are on aircraft fixes, but if something does go to the shop, a SHOP
dummy task is shown with another A probability.

Assuming all the subsystems listed for the 424X0 fuel specialists
in Figure 32 are comparable, a corrective action is required every 18
phases. It takes an average 6.4 manhours, which is equivalent to an
average 3.2 hours elapsed time by the typical crew of two indicated in
the data. If there were a fuels inspection task in each of the three
phases, the corrective maintenance task would follow each 424X0 inspection
with an A selection mode and .18 probability. .Resources would only be
listed to define the task in the first of these three entries. If there
were no fuels inspection, it would be shown once from the phase entry node,
also with an A selection mode and .18 probability. In this instance, the
only fuels inspection is in Phase 3. The corrective task is networked
following this task. Since it can never occur on Phases 1 and 2, the
appropriate A selection mode parameter is the average number of actions in
three phases, or three times .18. Figure 33 shows the task with a .54
probability of occurrence in the third phase.

Most phase corrective actions are on aircraft repairs. The data bank
run shows only one in-phase removal rate by 424X0s that is even marginally
significant. They reported seven in-phase unscheduled removal actions
against subsystem 46B in the 14,386 sortie sample. This is .14 of the 47
total 424X0 in-phase R and M corrective actions. Figure 33 shows a
dummy shop task with an A selection mode probability of .14 going into
the 46A shop entry node in the unscheduled maintenance networks. The same
tasks apply for shop processing regardless of where the item was removed
from the aircraft. Scheduled removals in phase that are processed in-shop
are networked in a similar manner. The ejection seat an filters are
typical examples.

Corrective actions by 431Pls are generally minor repair of seals,
gaskets, etc., and are an inherent part of their disassembly, inspection,
and reassembly tasks. It is probably more accurate to get a total job
estimate from experienced technicians that covers all inspection and repair
than to try and break out corrective work with MDC data.

Other Scheduled Inspections and Time Change Items

The lists of 04 inspections in the work unit code manuals, the data
bank runs on these inspections, and the data bank runs for scheduled removals
should be carefully reviewed for all comparable aircraft. A list of
inspections and time changes applicable to the new aircraft must be
developed, using these data as a starting point but adjusting for
differences in design and maintenance concepts. Contractor recommendations
can be helpful if available, but should be verified by Air Force
engineers and technicians.

Inspections that occur at calendar intervals may be scheduled on the
Form 20s. Examples are the 45-day corrossion wash for fighter aircraft
of the annual teardown and inspection of the M-61 gatling gun on the A7D.
Only major inspection that tie up an aircraft for half a day or more should
be handled this way. The network does not include a failure clock. It
is entered through a dummy mission in the main network, in the same manner
as shown above for phase.

There are many other scheduled inspections that are done in conjunction
with postflight when they come due. Section III included an example of
gun inspections entered with E probabilities in a main network. This method
is cumbersome except where the inspection is only done after certain kinds
of missions. The more general way is to use scheduled inspection networks
with failure clocks based on the inspection interval. These clocks are
only decremented and interrogated on missions going to postflight. Coding
is similar to unscheduled maintenance networks except that task type is
three, the work unit codes and clock numbers have an S in the last position,
and nodes are six digits starting with X. These conventions avoid any
unintended duplication of nodes or tasks used in unscheduled maintenance.

Two example networks from an A7D model are shown in Figure 34.

Every 50 flight hours the water collection bag on the air conditioner
must be emptied. This is done in 100 hour phase and during a postflight,
half way between phases. The 422X1 technician must remove the water
separater (41AAL) to do this. The whole job is generally coded in MDC as
a removal for access. The postflight check is shown in the network as a
scheduled check every 36 postflights (100 flying hours at 1.8 sortie length
and 50% average successful aircraft turnaround).

The cabin pressure regulator (41BCA) and pressure valve (41BCC) are
replaced every four years (every 550 sorties at peacetime flying rates) .

The job requires radar swing-out by 322X1, access removal of armor plate
(11AAL) by a 431X1 crew chief, and a pressure check after the components
are replaced.

The postflight clock values on scheduled tasks must be adjusted when
scenario assumptions are changed.

VI. BUILDING A DATA BASE

Data Base Processing

The steps in building simulation input files are shown in Figure 35.

In step 1, the extended Forms 11 are keypunched, and after careful checking
to correct coding or key punch errors, they are run into a computer file
called DBASE. These cards and the corresponding DBASE file are the basic
maintenance data base for a system, with all the data pertaining to a single

INPUT No. 2
EXTENDED EORM II

: i

5 r

„ c

«K

< 2

z. 5

IE2

■■

HI S

IE3

EBI

VSMI

u 3

ZLJ

£ 8

IKS

< 2

Z S

BBi

§p

Ifc 2

<a
z a

IKS

-—

Sbb

E3KB

C3KLM

CIE3H

BgB

«•!<! 5

BE3BB

« I

* < *

BEB

K3BH

K2E2K2E2I

dkhkbbi

dOCIgl

DLicr:i

K3E3K2K3I

itaia ni
■■cii

BBd^sa^ggggJgjjJj

oScSISlEQi^ESESISlCHESlBI

□

I Kill

It3

IDIflBBI3E]l
MBkae bsibbi

i »^T ■■ I — ■MBMB ■■ !■ 'i IB’i IB 'i II

n !■ iw i ' irrm

IB II MB II II li 1 11 II

IHHHBHHHEbi

IKdBSKiEdESKQI

IP1B1P1P1WE1I

IBI3EJEaElI2fl

IPBEPPP!

Figure 35. Five steps in processing a simulation data base

task contained in one record. Once on file they can be readily updated
using either a computer terminal or the update, procedure described in
this section. The basic card deck should still be maintained and kept up
to date as a control and backup even though faster computer update methods
are used. After the extended Form 11 card deck and DBASE file listing has
been checked again and all coding and keypunch errors identified, the
corrections are run through the first part of the Phase I program. This
is step 2 on Figure 35. The PI program provides a number of useful
diagnostics which may detect additional errors. The procedure of updating
the deck and checking diagnostics is repeated until a clean result is
obtained.

In step 3 the corrected DBASE file is run through both parts of the
Phase I program; programs PI and P2 translate the extended Form 11 file into
LCOM formats and place the translated data an update file called FDATA. P2
also prints out resource data needed to make further additions to the
FDATA File.

In step 4 the FDATA file, along with certain additional LCOM input
cards and any corrections, is run through the LCOM input processor program.
This ZAP run sets up the maintenance data input file for simulation and/or
provides further diagnostics. The process of correcting the file, rerunning,
and rechecking diagnostics is repeated again until a clean run and output
file is obtained. The last step is to run the operations data through the
LCOM input processor and check the resulting output file. The form 20
deck is corrected and the process reported until a clean set of operations
data is on file.

The programs used in these runs are maintained on "permanent" CDC 6600
system disk files at the ASD Computer Center. They are accessed by the
DBS, PI, P2, ZAP, and 206 control decks referred to in Figure 35. Authorized
users can obtain these decks from a designated programmer in the ASD
Computer Center. The first card of each deck will contain the deck name
in Columns 3 - 4 or 3 - 5. The user must also establish a CDC 6600 permanent
file location name. This provides for the five cycles in disk storage
needed to process the data base and simulation output. The following sections
explain the procedures for steps 1 through 5 in detail.

Debugging with Phase I

The extended Form 11 data base may be set up on either an UPDATE
permanent file and updated with change cards or be set up on an ordinary
permanent file and updated directly from a remote terminal keyboard using
EDIT mode. A slightly different version of the PI deck is required in each
case. The procedure described in this section presumes that the UPDATE
mode for processing change cards is used.

Step 1 is to put the extended Form 11 card deck on file using the DBS
control deck. The user must enter his file location and Cy=l on the
"catalog" control card. One run parameter card is also prepared for the
entire run. The format is:

.'M ■■

Cols 1-3 Any three digit number (used to identify run)

Cols 4-6 Aircraft (e.g., A-10)

Cols 7-12 Any six digit number (used for run data)

Cols 14-17 X001

Cols 23-24 Pre-flight Decrement (e.g., 04 to decrement .04 sortie)
Cols 29-30 Post-flight Decrement (e.g., 96 to decrement .96 sortie)

Col 32 "2" for constant time distributions, "1" for time

distributions and standard deviations specified on
extended Forms 11

Cols 34-36 Multiplier on G probabilities (e.g., 010 to increase
the probability of a multiple occurrence 10 times
over chance) . The multiplier can be used to show the
impact of sympathetic failure and/or reduce simulation
run time.

Cols 38-39 Average time to get resupply from depot in days after
NRTS action.

This run parameter card is entered immediately after the deck card, followed
by all the extended Form 11 cards in this sequence:

main networks

phase networks

scheduled maintenance networks

corrective maintenance networks in ascending order of clock number

All networks must include appropriate header cards. Carefully check an
80 - 80 listing of the deck to be sure all data and keypunch errors are
corrected before entering it into the computer. The DBS run will provide a
listing showing each record on file and its DBASE identification number for
update. Subsequent corrections and additions can be made through CDC 6600 .
update by referencing these numbers.

In step 2, the PI test deck is used to obtain a diagnostic of the DBASE
file. The attach and catalog cards in the PI deck must specify the DBASE
file location and Cy=l. The *ID card on the first run should specify MODI.

The program provides the following error checks and warnings:

a. Data must be in appropriate numeric format. The system will halt
and print an error diagnostic if alpha data appears in any column designated
as numeric format.

b. Action and work unit code on a trailer card must match action and
work unit code on the preceding card with C in column 80. If it does not,
an error is printed and the record is not processed.

c. Only selection modes A, B, C, D, E, F, G, S, or X are accepted.

If selection mode is omitted, or any other letter used, an error message
is printed and the record is not processed.

d. An A, E, F, or G selection mode must have a non-blank MSBMA or
probability value indicated or a warning message, is printed.

e. If a record has an F selection mode, work unit code and clock
number must match. If not, an error is printed and the record is not
processed.

f. If the input record specifies any time or resources when
repeating a previously defined task, the program prints a warning. This
usually indicates that the same task name was inadvertently used to define
two distinctly different tasks.

g. If an asterisk is not found in column 39 for a task with action
code W, K, or N the program prints a warning. This does not necessarily
indicate an error. There are situations where an N, W, or K card should
not have the asterisk, such as bench check on return from depot. The
message is a warning to double check and be sure that the omission was
intentional.

h. If sequentially encountered E probabilities in the same network
segment do not sum to 1.00, the program prints a warning. This is not
necessarily an error. If H cards for nomenclature are inserted within

a sequence of E probability tasks it will upset the computer's tally and
produce this message. However, any time the message appears the preceding
E probabilities should be double checked.

When corrections for all the errors have been determined, the correction
cards must be keypunched and entered in another run of the PI program.

This time the *ID card number will be M0D2. Each update run must carry a
new ID MOD number. CDC 6600 update allows the user to delete and/or replace
individual records in the file without having to reenter the entire card
deck. This is done with delete control cards. A delete control card is
made up as follows:

Col 1-2 *D

Col 4- DBASE. XXXX

where XXX is the left justified DBASE identification number of

the record to be deleted.

The replacement card or cards, if any, follow right after the delete control
card. A series of adjacent records may be deleted with one control card
specifying the first and last numbers of the sequence. For example, the
control card to delete records 95, 96, 97, 98, 99, 100, and 101 would be:

*D DBASE. 95, DBASE. 101

It would be followed by any replacement cards. Cards can be added to the fil
without any deletions by specifying *1 instead of *D on the control card and
indicating the number of the record the insertion is to follow.

Each PI run produces a revised listing of the file. Changes are
identified with HOD numbers instead of DBASE numbers. If an error was
made in M0D2 and it was to be fixed in the M0D3 run, the delete control
card in the MOD 3 run would be:

*D M0D2.XX

where: XX is the indicated M0D2 identification number.

The corrected record would be placed in the PI deck immediately after this
control card. An example setup of PI control cards and changes is shown
in Figure 36.

The PI run is repeated with change cards and a new MOD number until the
diagnostic output and careful checking of the deck show no further corrections
are required.

Translation into LCOM

When the PI output is free of errors, the full Phase I can be processed
(step 3) . The PI and P2 decks are submitted together as a dependency run
and the COMMON card is included in the PI deck. The PI deck also requires
a new MOD number even though no change cards are entered. The catalog card
in P2 must specify the file location and CY=2 for the FDATA file that will
be created. Outputs from this run include a listing of the new FDATA file
or records translated into LCOM format and a sorted list of all AFSCs and
AGE identifying crew sizes and the tasks they perform. A complete LCOM
input processor file must contain the following kinds of records in the
order listed:

LCOM 10 cards specifying report column headings for the simulation
output

LCOM 13 cards specifying the number and type of aircraft, types of
AFSCs, types and quantities of AGE, types and initial stock of
spares, and all failure clock distributions
LCOM 12 cards defining each task
LCOM 11 cards defining network sequence

LCOM 14 cards defining which failure clocks are advanced by which
DCRMT tasks and the amount of advance
LCOM 16 cards giving shift policy and shift manning by AFSC
LCOM 18 cards giving priority and decision rule parameters
99999 card to signify the end of input

All of these data are not included on the initial FDATA file produced from
the Phase I program, as indicated in Figure 37. The FDATA file will have
LCOM 10 cards specifying the first 99 LRUs as report column headings and
placing the rest in "other"; LCOM 13 cards for all clocks and spares, with
an initial spare level of 100; LCOM 12 cards for each unique task; LCOM 11
cards for each DBASE extended Form 11 task entry; and three sets of 14
cards specifying clock decrement values taken from the DBASE run parameter

IK1I

ini

IBE2I

IBTCII

lEZISI

■Sell

ICOI

ICICI

iSIk^i

Ibbebsssb&bbssb

sats t ss^ssss
issssssssssssss

QasBS^aB^SgHHg

nMMBTifcTI nil 'MM

QBHEHElK!QlBiaEBHHHa

BHiMidBiCSIHfcJCacaC/Mggg

IBBSBraEaKiEMiSHHHH

nBBtIBBBBEBBBlll

DIulCUKdKIlICBlIIiEIlKSCaESBSgB

wr5«mB-»3rii^irnr^gT l ■■■■

gs3E3df3saiae3C^E^EHSBBB

BCTEScagEEMgMMMMW

REQUIRED FOR
INPUT PROCESSOR

PRODUCED BY
PHASE I

SUPPLEMENTED
IN ZAP RUN

LCOM Forms 10

Forms 10 for Spares

Forms 10 for Reports,
Missions, Aircraft,
AFSCS* , AGE*

LCOM Forms 13

Forms 13 for Spares
and Clocks

Forms 13 for Aircraft,
AFSCS*, AGE*

LCOM Forms 12

All

—

LCOM Forms 11

All, with every
unscheduled maintenance
network connected to
CALLS 1

Modifications to
reconnect unscheduled
maintenance networks
to be called from main
network tasks other
than CALL SI

LCOM Forms 14

Three sets with
decrementing task
not specified

Modifications to
specify decrementing
task and delete
records not needed

LCOM Forms 16

All*

LCOM Forms 17

•

All

LCOM Forms 18

—

All

9999 End Card

—

Yes

* Cards that can be used for supplementing are produced in Phase I

Figure 37. LCOM input processor file.

card. The exact translations performed by the Phase I program detailed in
AFHRL-TR-74-97(IV) . The LOOM forms are described in detail in the LCOM
users guide (Drake et el., 1970).

Building an LCOM Input File

The supplemental LCOM inputs are set up in update format and entered
into FDATA with the ZAP control deck. The update control cards are pre-
pared as shown in paragraph above, except that FDATA numbers are specified
instead of DBASE. The changes are described as follows in their order of
entry in the ZAP deck. Sample entries are illustrated in Figure 38.

Format for the LCOM 10 series cards is shown in Figure 39 . The required
entries are:

Card giving the initial report cycle and summary report
frequency. Enter 30D in columns 8-10 and 4 in column 14.
These parameters can be changed later through the simulation
run control deck.

Card specifying the number of mission names listed on the
Forms 17. (Form 17 preparation was explained earlier in
Section II of this report.)

Card(s) specifying all the mission names listed on the Forms
17. Each mission name must be entered in the report column
heading field that was indicated for it in columns 12 - 13
of the Form 17. Dummy missions are included. If more than
ten names need to be entered, a second card is prepared in
the same format but represents report column headings 11 - 20.
A third card would be used to enter report column headings
21 - 30, etc.

Card specifying the number of aircraft types (usually 1)

Card specifying the aircraft name in columns 7-12.

Card listing the number of different AFSCs found on the AFSC/
AGE printout from step 3. This card is punched out by the
P2 program.

Card(s) naming each AFSC found on the AFSC/ AGE printout from
step 3. Additional cards in the same format can be used for
entries under column headings 11-20, 21-30, etc. These
cards are punched out by the P2 program but the user may want
to alter the order in which AFSCs appear.

The 10 08 and 10 09 cards are already in the FDATA deck. Only the first
99 LRUs are listed and the rest covered under "other." If different LRUs
are to be displayed, appropriate changes should be made with *D cards at
this point. Comparable changes must then be made in the 13 cards discussed
later in this section.

The rest of the 10 cards are entered after the last 10 09 card in FDATA
using a *1 UPDATE control card. They are:

10 01

10 02
10 03

10 04
10 05
10 06

10 07

100

101

IBJI

ibbH

iksbhi
i mil ii
hczbbi

IE9BBI

mwm

HF5B6H

mmmwnm

H1IH

Ihhi

BBESBBBG

■IBBIB

H|HI

![]■

■HHHi

HIIHH

If ms

BHEZ2BBB

MB !■■

HHHI

IBM

BSBKgBBB

H||HH

HI Hi

BB3BBBH

■BBSBBBB

■BE3BBBB

BHriBBW

CIIHK

\nwm

■BBBB

CBBBBI2

■u

Ifihh

■

■IIHH

wmwa

mwm

■ESHBI

■EilHH

■HHEMKSID

■1

mwmmm

mwsram

■KSBBB

BBBBHEEBB

■EGBBH

■BBBBBMBBE3EJ

BCIIIBI

■BIE^flBI3E2

Irik

BBISBBB

■BBBBBB1K3C3

|QH

■BBBH

IMiSHiBBIEira

■C3BBCI

DBBBBBBKJaia

mmm

■HQBBB

HHflBBB^HBB

BEi3

low

■BBBESIBBflrSBBi

■CEB IB

IZ1B BCDBB BEKS

BBKaBDBHE2BBCaK±]B BK4E5B IDCD
□■■BBIC1IBK3HBE11IIHU
□DB3EiirSBBBiaK3BBC|EBBCfcj
□E3E3 BHBBBBH2 BIB BB5EJB BDO
□KJDBHBifliriBiB BBBIBGC]
Ql^E1BaK^Ei]BBElMBBr£]EJBBr:lI>l

isncaKaKsiDiicaniBBDHBBQpi

PQHUE1EIHBC1HHDHHE3

DClClBBBHKaBBBiaESBHEslESI

supplement an FDATA file

10 10 Card specifying the number of different AGE items found on
the AFSC/AGE printout from step 3. This card is punched
out by the P2 program.

10 11 Card(s) naming each type of AGE equipment found on the
AFSC/AGE printout from step 3. Additional cards in the
same format can be used for entries under column headings
11-20, 21-30, etc. These cards are punched out by the
P2 program.

The 13 cards defining resource variables for aircraft, men, and AGE are
entered immediately after the 13 header card in the FDATA run, using a *1
UPDATE control card.

A 13 card must be entered for the aircraft. Column 12 is I, and the
aircraft name is specified in field 5-10 exactly as it was entered
on the Forms 20. The number of aircraft in the simulated organization
is entered in field 24 - 27. This may be modified later in the
simulation run.

A 13 card must be entered for each AFSC. listed in the AFSC/AGE print-
out from step 3. The AFSC is entered in columns 06 - 10, column 12
resource type is M, and the report column heading set up in the Forms
10 07 above is entered in columns 14 - 15. The rest of the card is
normally left blank. However, if one AFSC can always substitute for
another it can be entered in columns 30 - 34. Substitute resources
should be used with caution. A set of cards without substitute
resources is punched out by the P2 program.

A 13 card must be entered for each AGE type listed on the AFSC/AGE
printout from step 3. The AGE title is entered in field 06 - 10

exactly as it appears on the listing from step 3. Resource type in

column 12 is A, report column in columns 14 - 15 is as specified on
the Form 10 above. A set of cards with authorized quantity initially
set at 100 in columns 32 - 34 is punched out by the P2 program.
Resource quantities can be adjusted later in the simulation run deck.

The FDATA file already contains 13 cards for the clocks (C cards) and LRU
spares (P cards). The P cards should be changed for duplication, and any
duplicate eliminated with a *D UPDATE control card. If the LRU report
columns in the Form 10 were changed above, comparable changes must be made

in the Form 13 P decks using *D UPDATE control cards. The initial spare

levels are automatically set to 100, but these can be adjusted later in the
simulation run deck.

The next modifications that may be required are in the LOOM 11 cards.

The Phase I program automatically chains all F tasks back to CALLS1 through
a three digit numeric dummy mode. In some situations, call tasks other
than CALLS1 may have been set up in the networks to handle conflicting
maintenance contingencies. In the examples shown in Section III, CALLS9
and CALLS 8 represented the CALL tasks for engine maintenance and for landing

103

gear maintenance requiring jacking. The F tasks that are to be called from
these specific CALL tasks must have the connecting 11 card that was created
by Phase I deleted, and a card connecting it to the correct CALL section
substituted. The record to be deleted will show a three digit number in
columns 8-10, columns 11 - 18 will blank, and the prior node of the F task
that needs to be reconnected will appear in columns 20 - 24. The record
is deleted with a *D update control card and an 11 card in the following
format entered in its place:

Col 2 - 3
Col 5-10
Col 20 - 24

Col 26

Name of call task desired

Prior node of the F task to be called from the call task
specified in columns 5-10
F

A connecting card change must be made for every clock that is to be called
from a main network call section other than CALLS1.

The next set of changes is made to the LCOM 14 cards. These cards
specify which clocks are to be advanced and by how much of a sortie each
is to be advanced when a specific DCRMT task is processed in a main network.
These 14 cards are grouped by DCKMT task. The first 14 card in a group
lists the DCKMT task name, a clock it advances, and it is followed by a
card for every other clock advanced by the same DCKMT task. These cards
specify clock number and advance but do not list the DCRMT task name.

After all clocks advanced by the first DCRMT task are listed, the 14 cards
for clocks advanced by the second DCRMT task are entered in a similar
manner.

The Phase I program creates three series of 14 cards. Each series
lists every clock. Two lists have the preflight and postflight decrement
advances that were specified on the DBASE run control card, and the third
series has a decrement advance of 1.00. The user must enter which main
network DCRMT tasks are to advance which clocks, and delete the 14 cards
that do not belong with a particular decrement advance. Also, the first
14 card in each list of clock advances must specify that DCRMT task that
triggers the advance. The mechanics of the change are to delete the first
applicable 14 card in each list and substitute a similar 14 card with the
DCRMT task tame added in columns 5-10 exactly as it appeared in columns
12 - 17 on the main network extended Form 11.

The procedure is best explained with a specific example. The main
network for a ground attack mission shown in Chapter III had a DCRMT1 task
for unscheduled maintenance before the sortie, a DCRMT2 task for unscheduled
maintenance after the sortie, a DCRMT4 task for scheduled maintenance in
postflight, and a DCRMT3 task for unscheduled gun maintenance after a gun
mission. If the specified preflight clock advance was .03 and the post-
flight advance .97, FDATA will initially show a series of 14 cards with

104

.03 in columns 24 - 26 for every clock, followed by a series of 14 cards
for with .97 in columns 24 - 26 for every clock, followed by a series of
2.4 cards with 1.00 in columns 23 - 26 for every clock. The *D UPDATE
control cards are used to delete all scheduled maintenance and gun clocks
from the .03 list. The first unscheduled maintenance clock in the .03
list is also deleted with a *D card and a similar card substituted that
has DCKMT2 entered in columns 5-10.

The same thing is done with the .97 list, except the new card for the
first unscheduled maintenance clock has DCRMT2 in columns 5-10. The 1.00
list applies only to the gun and to scheduled maintenance. The 14 card
• for the first scheduled maintenance task is deleted with a *D card and a
similar card substituted that has DCRMT4 entered in columns 5-10. The 14
card for all unscheduled maintenance clocks in the 1.00 list are deleted
with *D UPDATE control cards. The gun clock 14 card is reentered with
DCKMT3 in columns 5-10. The end result of the deletions should be a set
of 14 cards with clock advance values .03, .97, and 1.00 still in ascending
order. A card specifying each DCRMT task is followed by cards for all the
clocks decremented by that task.

The optional "PM" program may be used to determine the probability of
a maintenance action before and after flight for various values of clock
advance. The 13 cards are read from the FDATA file and run through the PM
program. A control card specifies five trial clock advance values . The
program may be run for the whole aircraft or for individual subsystems.
Another optional program is available to read and repunch the 14 cards with
new clock advance values. The old 14 cards would then be deleted and new
cards entered in a ZAP UPDATE run. The probability decrement value change
1 programs are not usually required, so are not shown in Figure 35. They will

be described in a future AFHRL TR.

The final step in building an LOOM simulation input deck is to enter
the LC0M 16, 17, 18, and 99999 cards. These follow the last 14 card in
the deck and may be entered in a block using a single *1 card.

The first LCOM 16 cards specify shift policies. The rest give the
initial unconstrained manning for each AFSC entered on a 13 card above. The
16 card entries are as follows:

A header card with 16 in columns 2-3

A shift definition card with * in column 5 and the number of hours in
each shift starting at midnight. Three eight-hour shifts would be
entered with eight in column 17, eight in column 21, and eight in
column 25. Two twelve-hour shifts running 0600-1800 would be entered
with six in column 17, twelve in columns 20 - 21, and six in column
25. Entry of more complex shift patterns is described in the LCOM
Users Guide (Drake et al. , 1970, pp 8-15).

A card with R in column 5 and seven in column 25 for a seven day work
week.

105

A card for each AFSC that was listed on a 13 card, giving very high
values for. totally unconstrained shift manning. The format is AFSC
in columns 8-12 and number of people in columns 15-17, 19 - 21,
and 23-25. A set of cards with 200 people per shift is punched
out by the P2 program.

The LCOM 17 cards were described in Section II. A header card with 17
in columns 2-3 and all the 17 cards are inserted at this point.

The LCOM 18 cards specify various simulation parameters. Their correct
values are difficult to estimate but they can have subtle but significant
effects on the result. When in doubt, the best approach is to render them
inoperative. Suggested entries are as follows:

18 header card with 18 in columns 2-3

18 04 card with two in column 7, one in column 13, and 0 in column 19.
This limits preemptions (stopping a job to task resources for a
higher priority job) to two per task for the flightline and one per
task for phase.

18 06 card with .48 in columns 7 - 9, 13 - 15, and 19 - 21. This
limits maximum overtime at the end of a shift to just under half an
hours. If it is a half hour or more, it distorts the matrix output
discussed in the next chapter.

18 07 card with 50 in columns 8-9, 100 in columns 13 - 15, and 100
in columns 19 - 21. These values practically nullify the LCOM
option of increasing priority in proportion to delay, and force the
program to follow the established AFM 66-1 priorities.

18 08 card with .99 in columns 7-9. This practically nullifies the
LCOM option of shortening task times when delays occur.

The final card entered in the ZAP UPDATE run in an LCOM end card with
99999 in columns 1-5. The ZAP control deck must specify the file location
name and CY=2 on the UPDATE attach and catalog cards and the file location
name and CY=3 on the "TAPE9" catalog card for the LCOM input processor.

The PI and P2 programs are undergoing continual improvement to produce
more of the LCOM input processor deck on the initial FDATA file. Changes
to include all 13 and 16 cards in FDATA may be operations in the near future
simplifying the above procedure.

Debugging the Input Processor

The LCOM input processor printout from the ZAP run contains several
additional diagnostic checks that were not made in Phase I. The first step
in checking out the results is to see if the output cataloged in Cycle 3.
Then check whether the run ends with the statement, "initialization tape
produced." If the tape was not produced, it means the program detected a
fatal error. Go through the run, find the diagnostic, and make the neces-
sary corrections.

106

Check the listing of deletions and inserts at the beginning of the run
to verify that the modifications were made as intended. The printout starts
with a listing of input cards. The next list show all records deleted
indicated by D on the far right side of the page and the records added
indicated by I.

Carefully check each page of the following output for error messages
and entries that look out of place. Producing an initialization tape is no
guarantee that the data base is completely error free. Some diagnostic
messages are not fatal in the input processor but warn of entries that
might cause problems in the simulation.

Some SIMSCRIPT initialization data follows the data on changes. This
need not be checked. Next are listings of the "Report Specifications"

(LCOM 10 cards) , "Resource Definitions" (LCOM 13 cards) , "Task Resource
Requirements" (LCOM 12 cards), and "Task Network-Input Data" (LCOM 11 cards)
Some useful diagnostics follow that should be thoroughly checked. The
first is titled, "The Following Nodes are Network Entry Points." The
list under this heading should contain all the entry nodes listed on the
Form 17, plus the call tasks, but nothing else. Any other node listed
indicates a networking error. Check the DBASE listing and find why the
task record leading to such a node was incorrectly entered in the run.
Frequently the cause will be a keypunch error in the node number, such as
a letter 0 instead of zero.

The output, "The Following Nodes are Undefined," lists nodes entered
as next nodes on an extended 11, but never as the beginning node of any
following tasks. Check the DBASE listing and find out why. Such next
nodes are either unnecessary or should be leading to something.

"The Following Nodes are Multiply Referenced," is followed by a list
of all the nodes that have more than one task leading to them. There is
nothing wrong with this, but a careful check of each one in DBASE will
often disclose an unintended error. They should at least be checked out
in the first ZAP run.

No tasks should appear under, "The Following Tasks are Constrained."
This refers to use of the B selection mode not previously mentioned in
this report. The B was not recommended because it can only be used in
restricted situations without introducing errors. Both B selection mode
and call sections handle parallel task constraints, but the call sections
are more generally applicable.

All the nodes leading to more than one task are listed after the
heading, "The Following Nodes are Multiply Defined." Multiple definition
is common in networking logic and does not indicate any error. The
listing of "Resource Clock Decrements" (LCOM 14 cards) should be checked
to see that each DCRMT task is listed once and is followed by the list of
the clocks it advances and correct amount of advance. After listings of
"Shift Policies," (LCOM 16 cards), "Mission Entry Points-Classes , " (LCOM

107

17 cards) , and "Priority Specifications" (LCOM 18 cards) , there is a
list of "Resources Never Referenced," this should only contain the
aircraft name. Check anything else in the AFSC/AGE list produced by the
P2 program to trace the error.

The next heading is, "The Following Tasks were Not in the Task
Network." Anything appearing here other than call tasks indicates
an error made in the ZAP UPDATE control cards. After a meaningless list
of cost values there are various tables and indexes used in the simulation
program; the numbers assigned in the "Resources" list will be an important
reference when setting up the simulation run decks. Any resource level
changes made at that time must refer to the resource numbers in this
index list.

If the input processor contained any errors, go back to step 3 and
rerun Phase I with the necessary DBASE correction cards. The part 2
control deck must now include a purge card for CY=2. Host of the same
ZAP change cards will be used in rerunning step 4, except that the UPDATE
control cards must refer to FDATA identification numbers on the new FDATA
run. This same procedure (rerunning steps 3 and 4) is followed for all.
UPDATING changes to the data base. The DBASE file serves as the master
control deck of maintenance input and model configuration.

Establishing the Operations File

Form 20s are run through the LCOM input processor using the 20s deck
with a catalog card specifying the file location and CY-4. The input data
preparation was covered in Section II. These data are entered in the
following order:

LCOM 15 header card, with 15 in columns 2-3 (use only if Form 15
is required)

LCOM Form 15, if required to specify alert mission distributions

LCOM 20 header card, with 20 in columns 2-3

LCOM list card, with list in columns 1-4, the number of days of
operations data to be generated on file specified in columns 5-7,
and a scenario title starting in column 9.

LCOM Form 20, ordered by day and take-off time within day. Alert
missions with a distribution number In the takeoff column are placed
at the end of the indicated day. Ordering the Form 20 card input by
day is essential or missions will be missed.

A summary table should appear at the end of the 20S LCOM input
processor run. It gives missions, sorties, and flying hour totals (including
dummies) and breakouts by mission type. Be sure the totals for 20S real
missions match the intended program and scenario, and that the proper number
of dummies are included. If the Form 20s need to be updated and rerun, a
purge card for CY=4 must be included in the 20S deck.

108

VII. TESTING AND OPERATING THE SIMULATION

LOOM Run Parameters

Before proceeding with this section, it might be useful for the reader
to go back and briefly review Section I on how the LOOM program works.

The LOOM simulation control deck MM must include appropriate attach
cards to access the maintenance and operations files. The attach TAPE7
card must specify the location and cycle of the operations data file,
and the attach TAPE9 card must specify the location cycle of the maintenance
input file. If data is to be stored for a matrix program run, the deck
must also include a catalog Tape 11 card specifying the location and cycle
of an empty output file.

The LCOM parameter cards are placed behind the SIMSCRIPT initialization
cards at the end of the control card deck. Formats for all the cards
normally required are shown in Figure 40. Additional options are described
in the LCOM USERs guide (Drake et al., 1970, pp 8-34).

The RFREQ card specifies the interval in simulated days between
performance summary outputs. The RCYC card gives the number of successive
reports to be included in an overall summary report. The STOP card
specifies the run length in simulated days, plus one tenth. The extra
tenth assures that the last day is completed and included in statistical
outputs. The SWICH 101 card as shown must always be included in runs with
the ASD CDC 6600 LCOM program. The PCT card specifies the factor for
increasing the remaining time on a job interrupted for a shift change or a
higher priority preemption. Experience with in running several LCOM
simulations shows that results can be highly sensitive to this value. The
PCT card must be included in every run with a parameter value no greater
than 1.05 and no less than 1.00. The 45 card indicates the cutoff time, in
hours to takeoff, for starting to process an unprepared aircraft for a
mission. Experience indicates that one hour is a reasonable value when
simulating operations with tactical fighter bombers. It might be wise to
recheck the sensitivity of this parameter if a different kind of aircraft
is being simulated. The 47 card releases all ready spare aircraft at the
specified interval of days. Ready spares are held for the next mission of
the same substitution class. Normally, this parameter should be set to equal
or exceed the simulation. run length so that it is inoperative. -It may be
set to release spares at break points where the scenario shifts to a different
mission mix. A 47 card must be included in every run.

The AUTH and 46 cards are used to change resource quantities for each
iteration of the constraining process. The AUTH card is used to change the
number of aircraft, spares, or AGE. The 46 card changes manning by shift.

The resource ID number found in the ZAP input processor is used to identify
the resource to be changed. The SWICH 123 card turns on output to the
matrix tape at the specified time and SWICH 120 turns it off. The man-
power and backorder matrices are important tools for the contraining process
discussed in Section VIII.

109

PARAMETER

NAME

LEFT JUSTIF
COLS 1-6

INTEGER

VALUE

RIGHT JUSTIF
COLS 7-12

DECIMAL

VALUE

DEC PT IN 19
COLS 13-21

ALPHA

YALUE

COLS

26-31

INTEGER

VALUE

RIGHT JUSTIF
35-37

RFREQ

INTERVAL

RCYC

FREQUENCY

RUN

NAME

STOP

TIME*

SWICH

101

0.1

PCT

1.05

1.0

INTERVAL

AUTH

RESOURCE ID NO

QUANTITY

RESOURCE ID NO

SHIFT NO

QUANTITY

SWICH

123

TIME*

SWICH

120

TIME*

MNSTAT

TIME*

BOSTAT

TIME*

ITEM

TIME*

I SEED

SEED

ISEED

SEED

I SEED

t SEED

*TIME entries are in decimal days. The fourth day at 0600 hrs would be
entered as 4.25 in Cols 18-21

Figure 40. LCOM run parameters.

110

The rest of the parameters listed in Figure 40 are only used for
debugging, checkout, and sensitivity tests. MNSTAT, BOSTAT, and ITEM
give detailed "snapshots 1 ' of what is going on in the simulation at the
specified point in time. MNSTAT provides a mission status output, BOSTAT
displays delayed jobs, and ITEM gives the status of all resources. The
three seed cards are used with any different numbers between 1 and 99
to alter the sequence of random numbers drawn during model processing.

Test Deck Setup and Checkout

Sections II through VI explained how to develop and check out the
individual elements in the simulation data base. These must now be
checked out together before proceding with the full simulation runs. A
30 day form 20 file is constructed for the first test. The Form 20
cards up to Day 30 are duplicated with 30 inserted in place of any
number of 30 in columns 71 - 73. The 20S deck is then run with these
test Form 20s, using a list card specifying 35 days, and set to catalog
the file in CY=5. This will put a 37 day schedule on file with scenario
missions for 30 days followed by five days with no missions at all.

A 35-day simulation with diagnostics is then run against this
schedule. The LOOM control card deck is set up with:

run time approximately 1,000 seconds

attach TAPE7 card specifying the file location and CY=5 for the
test LOOM operations input file

attach TAPE9 card specifying the file location and CY=3 for the LOOM
maintenance input file

no catalog TAPE11 card

The LOOM run parameter cards are set up as shown in Figure 41. This gives
a 35 day unconstrained run with reports every five days, a 30 day summary
at the end of the flying schedule, mission, resource, and backorder
diagnostics on day 21, and again at the end of the last nonflying day.

The operations output on the LOOM performance summary should show at
least 98% of all real sorties accomplished and 100% accomplishment of all
phases and scheduled inspections. Mission accomplishments should approach
100% for this unconstrained run. Preflights and hangar dummies may have
a lower percent accomplished since they are affected by the number of
aircraft tied up in long repairs. If these rates are not achieved look
at the pattern across each five day period. If the percentages are
approximately constant after the first five days, it indicates an operations
data problem. If they continue to decline, it indicates a problem in the
maintenance input.

The MNSTAT diagnostics are helpful in debugging an operations data
problem. Data are shown for each mission in preparation at the time of
the report. The type column indicates the aircraft resource ID number.

If it is negative, no aircraft is yet available to start processing.

Status is 0 if the aircraft is still being prepared and 1 when it is

111

PARAMETER

NAME

LEFT JUSTIF '
COLS 1-6

INTEGER

VALUE

RIGHT JUSTIF
COLS 7-12

DECIMAL

VALUE

DEC PT IN 19
COLS 13-21

ALPHA

VALUE

COLS

26-31

RFREQ

5.00

RCYC

0.00

SW1CH

101

0.10

1.00

36.00

MNSTAT

21.20

MNSTAT

21.30

MNSTAT

21.40

MNSTAT

21.45

MNSTAT

21.55

MNSTAT

21.60

MNSTAT

21.65

MNSTAT

21.65

ITEM

21.75

ITEM

21.45

BOSTAT

21.75

MNSTAT

34.95

ITEM

34.95

BOSTAT

34^95

PCT

1.05

RUN

0.00

TEST

STOP

35.10

Figure 41. Example LCOM test run parameter cards

112

ready to takeoff. If aircraft appear to be available and the performance
report shows a high percentage of missions but not sorties accomplished,
the Form 20 leadtime is probably too short. If aircraft quantity on the
13 card is correct and mission computations check out but aircraft are
not available, the schedule may not allow enough time between first flights
and turnaround flights.

The resource status and backorder status outputs are useful in
debugging network problems. The resource status report shows the number
authorized (AUTH) , available for assignment (OH), out on jobs (DIB), and
needed but not available (DOB). Resources are identified by ID number
listed in the ZAP input processor output. The backorder status report
shows the resource ID numbers and quantities required for delayed jobs.

The job number shown can be traced to a task through the task index in
the ZAP input processor output. 'If a problem is traced to a particular
resource and the available quantity (13 card input) is correct, the AFSC/

AGE list output from Phase I may be useful to help trace the network tasks
causing the problem.

♦

In addition to showing high percentages of sortie accomplishment, the
performance summary should not show any unsatisfied demands for personnel
or there is a network error. The number of reparable generations for each
item in the shop repair summary should equal the number of units demanded
for the same item in the supply summary. If not, there is an error in the
equivalent relationship required between 0 tasks and asterisked W,K, and N
tasks for that item. The number of items in repair and backlogged should
not show any continuing pattern of increase after the first five days. There
should not be any cannibalizations , supply backorders, or unsatisfied supply
demands. Any unsatisfied demands for equipment, indicate that an AGE 13
card or network task is in error. The diagnostics for the last day of no
flying should show no missions, no resources working or needed, and no jobs
delayed in backorder. Anything else indicates a data error.

When all the problems have been analyzed and corrections identified,
go back to the DBASE file or supplement to FDATA, as necessary, to make
the needed changes. Make sure that any Form 20 changes are made to both
the full operations file and 30 day test file. Repeat the process of data
base building and simulation checkout from the point corrections were made
and get another test run. Continue debugging until an unconstrained
simulation is obtained that checks out perfectly in all respects.

Establishing Run Length

Simulation runs must be long enough that results clearly measure the
long run effects of input conditions, and not change occurrence of random
fluctuations. If the model is rerun with the same input but different
random seeds, the conclusions should still be the same. An example of
criteria for run length would be that sorties accomplished will vary less
then 1%; total wing manhours will vary less than 3%, and manhours for any
single work center will not deviate by more than 5% (or by the equivalent

113

of one man if under 20 people) . Run lengths can be shorter if less
precision is satisfactory for the specific questions to be answered with
the simulation run.

Adequate run length is different for each scenario and maintenance
model. It is more a function of processed and sorties flown than
simulated days. To compound matters, it can also depend on the degree of
constraint. A reasonable procedure is to make an initial unconstrained
test to approximate an adequate run length (in simulated days) for running
a new LCOM model. Use this length for the first simulation study. When
final results are obtained, redo the run length test with the final
constrained manning and different random seeds. If the approximated run
length was too small, the recheck will provide enough data to correct the
results and also establish a better fix on run lengths for subsequent
simulations of the same aircraft.

Factor this run length by an inverse ratio of total sorties scheduled
when simulating different scenarios or unit sizes. The run length in days
for simulating a 24 aircraft squadron must be three times the run length
for simulating a 72 aircraft wing flying the same sortie rate.

Run length for the initial unconstrained run length test is estimated

by:

Run length (days) =

27,000,000

Jobs Processed in 30 Days

The number of jobs processed in 30 days is shown on the last page of the
LCOM performance summary from the 30 day test run. The test Form 20s can
now be purged and the original deck (with 999 in columns 71 - 73 where
appropriate) cataloged in its place using a list card specifying the
number of days required for the run length test. The simulation control
deck is set up with:

Attached TAPE7 specifying the run length test Form 20 file location
and cycle

Attach TAPE9 card specifying the LCOM maintenance input file location

and cycle

Not catalog TAPE11 card

The LCOM parameter cards are set for:

A performance report every 30 days
A summary every third report
SWICH 101 card
45 card

47 card equal to run length to nearest 30 days
No diagnostics
PCT card

Run name = length

Stop at run length to nearest 30 days plus .1

114

Sorties and manhours by AFSC are representative run length criteria.

A 30-day whole man equivalent is the number of manhours per month avail-
able for direct productive work (e.g., 85.2 in peacetime, 144 in wartime).

Any difference less than 144 manhours per month would be less than a man
in a wartime scenario. The results from the performance summary are
transcribed to a table similar to Figure 42. The differences between
various combinations of 30-day periods, 60-day periods, 90-day periods,
etc. are calculated. The smallest time period that shows all differences
within their respective criteria is selected. Thirty days are added
to allow stabilization before taking data. This estimate can then be
used to set run length for the first simulation study.

In the example (Constrained run final check) shown in Figure 42, all
measured except engine shop manning were within criteria at 90 days. Engine
manhour variability is 6% slightly less than or two equivalent men. It
was decided that improving precision by one man in one shop was not worth
the cost of simulating another 30-day period on each run, so run length was
set at 120 days (30 day stabilization + 90 days accumulating data).

Full Simulation with Matrix Output

Figure 43 shows the run sequence for a full simulation. The LCOM
program is run for the number of days determined in the run length test.

A catalog TAPE11 card specifying a file location and empty cycle is
included in the control deck to produce a matrix data file. LCOM parameter
cards SWICH 123 and SWICH 120 are used to specify the days matrix data
output is turned on and off. These should match the periods of performance
summary data that will be analyzed, discarding the first month of data
for stabilization. The report frequency specified in the LCOM run deck
is the number of work days in a calendar month. Normally, this is
equivalent to the number of flying days. For combat simulations, there are
30 days in every month but there may be only 23 work days per month in
peacetime.

The MX control deck is run with an ATTACH card specifying the location
and cycle of the cataloged matrix file. The program prints matrices show
demands and backorders for each AFSC by time of day. These matrices are used
in determining manning levels by the methods described in the next section.

The first parameter card at the end of the MX deck is set up as follows:

Cols 2-4 Total number of AFSCs as specified on the LCOM 10 06
card in the input processor file

Cols 5-7 Start day of matrix, as indicated on the SWICH 123 card
in the LCOM simulation run deck. Entered as the nearest
whole number, right justified, no decimal

Cols 8-10 Stop day of matrix, as indicated on the SWICH 120
card in the LCOM simulation run deck

The rest of the parameter cards for the MX run specify the AFSCs and
report columns in the order entered on the LCOM 13 cards. They are entered
in eight column block across the entire card. The first five columns of
each block give the AFSC and the last two specify report column. For example:

115

PERIODS

SCHEDULED
SORTIES
% FLOWN

TOTAL
MAN HRS.

30 DAY

97.8

106,532

PERIODS

98.2

100,702

98.4

103,142

97.5

105,463

98.3

105,283

98.1

107,602

30 DAY

2-1

WBM

5,830

DIFFERENCES

4-3

2,321

6-5

mam

2,319

60 DAY

(65)- (12)

5,651

DIFFERENCES

(65)- (34)

4,280

(34) -(12)

1,371

90 DAY

(456)-(123)

DIFFERENCES

(246)-(135)

(136)-(245)

WITHIN

Figure 42. Representative extracts fron

WITHIN
1 MAN

Figure 43. Simulation run sequence.

Cols 1-5
Cols 7-8
Cols 9-13
Cols 15 - 16
Etc.

First AFSC
01

Second AFSC
02

additional cards follow specifying report columns 11 - 20, 21 - 30, etc,
as needed.

An appropriate version of the matrix program must be used to provide
summaries for the assumed shift pattern. The designated ASD programmer
can provide a deck to give summaries at 0800, 1600, and 2400 (for eight
hour shifts) or at 0600 and 1800 (for 12-hour shifts).

VIII. ITERATIONS TO CONSTRAIN DIRECT MANNING

General Concept and Method

Manning for certain work centers is determined by existing command
standards rather than by the simulation. Examples are work centers such
as the crash recovery crew, the machine shop, and the personnel equipment
shop. These are treated as an overhead requirement in the Moody manpower
program (Section IX) .

The simulation is used to determine daily manning requirements for
those AFSCs and work centers whose workload is generated by aircraft flying,
and who report their work against aircraft work unit codes in MDC. This
covers the majority of the field and organizational maintenance AFSCs and
includes all those with large manning requirements. The daily manning
requirement in these work centers is the greater of:

Manning dedicated to fixed posts, such as runway checkers, alert pad
crew chiefs, and engine test cell operators. They must spend a full
shift at their assigned posts regardless of workload, and are not
available for assignment to any other work during that time. They
are Included in the simulation rather than treated as fixed overhead
since their work directly constrains aircraft availability.

Manning to accomplish the number of direct hours of work required on
the aircraft and equipment removed from the aircraft.

Manning to cover the minimum crew sizes for every shift on the flight
line and at least one shift per day in the shop. For example, if it
takes four 432X0s to change an engine, the engine flight line dis-
patch crew must have at least four people on each active shift.

Manning to meet peak workloads that are essential to accomplish the
required flying program.

The sortie rate determines which of the above factors drives the
manning requirement for each AFSC under a given maintenance model and set

118

of operations and maintenance assumptions. This relationship is illustrated
in Figure 44. Post or minimum crew manning must be provided to fly and do
the required maintenance at all. It is shown as a horizontal line represent-
ing the fixed portion of the manning requirements.

Another independent curve represents the manning equivalent of the
direct labor required to service and maintain aircraft. This is a nearly
linear function of sorties flown. The increasing slope at high sortie rate
represents a certain amount of rework on jobs preempted by higher priority
demands. This "PCT" factor was discussed in Section XII. The likelihood
of such interference increases with sortie rate.

The third independent curve in Figure 44 represents manning required to
meet peak demands for people working at the same time, which if not met will
prevent accomplishment of the required flying program. This depends on a
number of interacting factors. Indirect work is assumed to be deferable
(i.e., can be done in slack periods) , and if adequate spares are available,
shop work is deferable also. Under an AFM 66-1 concept where flight line
and shop work can be done by the same people as needed, these deferable
manhours provide a buffer to cover all except the most severe flight line
peak demands. The larger the organization, the more random demands average
out and the larger the buffer available to absorb them. However, if the
flying program is highly irregular with massed flights at particular times
of the day; if there are few or no spare LRUs; if the indirect work
allowance is small; or if the flight line and shop work are handled by
separate cadres; more people may be needed to cover peak demands than are
provided to cover the manhours of work at the assumed percentage of direct
labor utilization. The slope and shape of this curve depends on the inter-
action of the various factors 'involved. It is entirely simulation determined,
as discussed in the fourth paragraph of this section.

Computing Daily Requirements

As discussed above, the number of people required per day is the
greater of the number needed for post manning, the minimum number needed to
voer crew size requirements on each shift, the number needed to accomplish
the manhours of work, or the number needed to meet peak workloads. In the
initial computations peak workloads are ignored; they are only brought into
consideration if manning based on the other factors proves insufficient.

Minimum crew sizes per shift are found on the AFSC/AGE printout that
was produced on the Phase I Data Base Translation Run (Section VI). The
largest crew required for a flight line task is usually put on every shift.

The largest crew required for a shop task (action type N, W, or K) need only
be put on one shift if spare LRUs are available and shop work is deferable.
Some judgment is necessary in minimum crew assignment. If only one flight
line task needs a large crew size, and it is very infrequent, it may be
feasible to man only one shift with the large crew size.

119

PEOPLE REQUIRED PER DAY

SORTIES/AIRCRAFT/DAY
(ALL OTHER ASSUMPTIONS HELD CONSTANT)

Figure 44. Factors determining daily direct manning requirements for an AFSC

Post manning is determined by the operations and maintenance
assumptions obtained from the using command. End of runway checkers and
alert crew chiefs are typically dedicated to post manning. The pilot of
the functional check flight may be assigned as post manning for daylight
hours only as a way of modeling the constraint that test flights are not
done at night.

The daily mantling needed to accomplish the required manhours of work
on the aircraft and equipment removed from the aircraft depends on the
proportion of the maintenance man’s available hours that can be used
for direct work. Ideally, this is determined by measuring the actual
requirement for indirect work and allocating the rest as direct. Lacking
such data for new aircraft, the current Air Force AFM 26-3 standard of
.60 direct utilization has generally been assumed, but the manning
requirements determined can be quite sensitive to this assumption. The
operations and maintenance concept obtained from the operating command must
define the number of workdays per month and the number and length of shifts
per day. The number of people by AFSC that are required per day across
all workshifts is:

_ Direct Manhours Required/Mo.

s (Direct Utilization) (Workdays /Mo. ) (Shift Length)

Where direct manhours required per month are obtained from the LOOM per-
formance summary. This is the shift loading, not the total manning
requirement .

Allocating Daily Manning to Shifts

Where the daily requirement is based on post manning or crew size, the
shift allocation is already determined. However, where it is based on man-
hours of required work, the total number of people per day must be allocated
to shifts. This is done with the aid of the work center matrices. These
matrices show how the workload for an AFSC varies with the time of day.
Separate matrices are provided for flight line and shop work.

The matrix displays the number of times during the simulated period
that the number of people shown on the leftmost vertical axis were working
at the time of day shown on the horizontal axis. The time is in half hour
increments. The cumulative sum of these data over a workshift is shown in
a vertical column at the start of that shift.

An example of a flight line matrix for three eight hours shifts is shown
in Figure 45. It shows, for instance, that on 10 of the 90 simulated days
there were 17 43lXls working at 1000 in the morning during the second shift
(number of people working is indicated on the extreme left vertical axis) .

The greatest demand for 431Xls occurred at 0300 during the first shift. Once
on the 90 days, 35 people were required at that time, and the fewest ever
required were 15, which also occurred only once. On 12 of the 90 days, 24
431Xls were working at 0300.

121

r— CM

i— r— r— CMSOIOOS

— in o mo in id 9 03 ui s i- r-
<5- cr> »— oo os *— co *J-

»— I— t— CM r-

cm to *cr- ir» in

r— f— C\jcsic0t-00f0f0000«00»«t0
r— CM Mr-i-C\J^5>NC*)NN«NJ^-lf»r-0

CM Mi— ^NtOOOfOinOiCMNr-CVJ O

cnjMi-Oi— co«-coir5Inco?f— o

K csj o pi co u> ^ cm O

f— »— CM (cm ^ n N N ffl M O OS CO r — 'S’ CO CM I— o

Mfl-|Ni-U1OsOsOtC0OS'O*JO>NCSJi- »— *— O

(Ml'tM’i-iflOUIOOlCMONOCSJ CM CM O

M^ , ^«t» 00 >OWlftin«J'S 0 CM^CMCMMf-

-—•fM^fSOq-NM-OtNMCDCMSDMCMMr-i-

CMi — ^-M»fMC\JMCOMCOlrt CM r—

r— r-|MM''fSDCOSDOlCCOf-Ml«i-CM r—

«— CM

CM^^M«f^-tDCOOff(NNCMCOin^^r- CM
CM CO r— OS OO f— CO in CM SO r— r— O

— 1 -i-i-lOCMlOrNlMSOi-Oi-MM-M

r-CMCsMt<tCMCOMU)COCOlf)SOCO^

r-CMli1*t^*OOCMi-«ONC
kr-t£)inCMr- 0 >M-OMJn«tCMr-

CM r-MMr-

CSJ r- CM CSI M M M- M
«— CM CO CO CO ST)

CM CM CM CO CM > — CM CM
r- r- «— f— CO •—

i— r- f— CM

-t

*-• 3 :
+ so OO

r>. ■*3- **■ O

<tMOiNM-COOOOinOM<OCMlDTftMM O

M^lOCMCOlONlCNCTS^UIMi-r- O

lOlOCJIMSOpsi-MTONM-i- < — r— r— O

UlMCO'tOOMlCJr-SDSOCMMi-r-N O

(OCMOsr*.OvO>OCOinMCMM-Mp-r- »— O

co r^. bs r^. co cm so co «— os *— so r— o

CSlinCMOOr— niONONIfl^i-r- CM o

CMr-COCsJCMr-CMCOSOsOOSOCOOSr^OSCO
i-r-NM>on^oinsto^ros

'OOOOOOr-MOOCMCM«tC7SM|CMO>OOS^<MOlflCO^a3CMCOO^MMT-Nrs
- CM CO U0 f^. Os KM so CM OO SO O CO SO IT) SO ^ CO CO O SO O SO CO I-* O
r-.— tMCMCO* 3 -**-lOSOr*»GOOS* * * * * * * «

■ — cm ■ — *— ossn^cor-.osinr'vcom**-**-

r— < — 1 — «3-i—-«3-COr->.CT>^f-COr— COSO^TCMi—

i— *— cosososoososr— m^j-uor-NCocM r—
cm i— i— nic«3'CMcoOnuisj'icfOCMni — cm

CM - — r— OCMM-lCM’^OOUCNr-M-lOM O

CM niO'OCOMMNOSC7>fOM-sJ'r-i— i— CSJ O

COstCOOCOCOOMOOfOCI f— o

coiOTfocMcor-.ascosoioincMi— mi— < — o

snoOOO*e*SOCMtOincOinuO«— o

COCSI^-CMOOM-NlOCMIMn CM CM O

CO SO «s-

i — co»— ^J-coco^-io

*********

|Oi OS CM r-« r

in so eM cm cm i —

CM r— CO Wl^SSOf-OOlONsJ-r- C

r— 1— r— < — jco niflNin^O>iniOC0CMNCMf-CM(- I — c

r— cocMCMincococo^w^T- so rs oo cm in so r— c

SO ji — - *— (OCMCMCOCM^f COfOlf)stSD00C0^00stN<OCO»- C

I— I— I — CM in . — M , CMr-lOiOCM'7l'J-lOl v )r^»t»J I — c

|co«Mco<ocosoirtocMinONOso^i-rNOso'OincMinsfiocM
WSMNCMCOSOCOOunONCMNCMr- CO Ifi fO OMO O lf> CO >“ <M «
i- ^ CM CSI (O St St UHO so N N CO ai C7S * *********

[« *************************

122

Figure 45. Work center matrix

The concept for using data in this form was originally suggested by
the RAND Corporation (Bell & Stucker, 1971, pp 227-229). The criterion of
deferred demands per shift (X) is computed as a function of aircraft avail-
able hours using the equation shown on Figure 45. An example computation
with x = .05 is illustrated. The closest value not exceeding this computed
criterion is located in the summary column for each shift, and a horizontal
line drawn below it. The shift manning for that criterion is indicated
immediately below this line on the extreme left axis. For the example
shown in Figure 45 the computed criterion is 96 demands or "ticks." The
closest number in the first shift cumulative sum column that does not exceed
96 is 68. A line is drawn below 68 and carried over to the left axis. This
indicates a relative shift manning of 26 431Xls.

These matrix results are used to determine the proportion of people
to put on each shift. The total number of people to be assigned is
determined from the direct manhours of work required, as described in
paragraph 2 of this section. For the example shown in Figure 45, the number
of 431Xls required per day would be multiplied by 26/65 to determine first
shift manning. A little experimentation can often locate an X value that
corresponds to the total manning to be allocated, and cuts down the amount
of manual computation.

Procedure for Constraining Manning

The simulation is first run with no resource constraints, defaulting to
the high resource levels originally set in the input processor on LCOM 13 and
16 cards (Section VI) . Work center matrices and monthly manhour requirements
are obtained from this run and used to compute the first daily manning
constraint, as described in paragraph 3 of this section. These constrained
levels of shift manning are punched on 46 cards (Section VII, paragraph 1).

The simulation is rerun with the 46 cards included in the run deck.

This time the matrix output will include a set of backorder matrices showing
the number of demands not satisfied by time of day. The performance summary
from the constrained run is checked to see whether any AFSCs show a higher
manhour utilization than the assumed utilization criteria for direct work.

If so, the manning must be recalculated based on manhours shown, and the
simulation rerun until utilization in all work centers falls within the
utilization criteria assumed.

If the real sorties accomplished dropped more than 5% from the uncon-
strained run, additional people may have to be added in one or two bottleneck
work centers to meet the required flying program. The bottleneck candidate
is picked from an analysis of the backorder matrix, of percent demands
unsatisfied from the performance summary, and the difference between the
numbers shown on the matrix and actually manned on shifts during the initial
shift allocation. Those work centers with the least buffer of indirect and

123

deferable shop work are the most likely to be the bottleneck. For a given
"X%" criterion, they will show the greatest difference between flight line
matrix determined manning and computed manning to accomplish required man-
hours of work. The 43lXls are a likely bottleneck candidate since they do
not do any shop work.

The bottleneck work center is constrained using the matrix figures
rather than the Ms computation to determine daily manning requirements.

The simulation is rerun with new 46 cards giving matrix manning for this
work center. The other 46 cards are left as is. The process is repeated
using different X values for the matrix manning computation until the sortie
loss is close to but not exceeding 5% of the unconstrained run. The 46
utilization rate for the other AFSCs is checked and the simulation rerun
for any "fine tuning" adjustment on the final manning constraint.

Computing Direct Manning

The number of direct authorizations necessary to provide the required
daily shift manning that was determined by constraining the simulation
depends on how many hours per month a man is available to work. Additional
people may be necessary to provide full coverage of all shifts for the
entire month.

The available hours per month to be assumed in manning computations
are established by AFM 26-3 standards. Examples are 242 hours per month
for sustained combat flying, or 144 hours per month in peacetime. The
direct manning requirement for an AFSC is:

M _ Mg (Workdays/Mo.) (Shift Length)

Available Hours /Man/Mo.

Where Ms = required daily manning determined from the final constrained
simulation run rounding off in these computations is done in accordance
with AFM 25-5 criteria (1, P 7-8) shown .in Figure 46.

Note that with eight hour shifts in a 30 day per month sustained combat
situation where the standards are .6 direct work and 242 available hours per
month, these factors will cancel out and:

M = Mg

This is a reasonable set of assumptions for many tactical combat scenarios,
and eliminates one step in the manpower computation. However, if shifts
are varied to match workload total requirements may change.

124

Authorized

Manpower

Fractional

Manpower

Cutoff

1.077

2.154

3.231

4.308

5.385

6.462

.7.539

8.616

9.693

10.770

11.847

12.924

13.999

Over 13

Authorized Manpower +.999

Figure 46. Criteria for rounding in manpower computations.

125

Example of Manning Computations

A recommended format for recording and tabulating data is shown in
Figure 47. The example illustrated is for a peacetime scenario in which
there were 23 flying and maintenance workdays per month with three eight
hour shifts per day. The direct utilization criterion was .60 and avail-
ability was 142 hours per man per month.

The first column of the tabulation lists the AFSC and the second
column gives the resource ID number from the LOOM input processor. This
number must appear on the "46" cards for each AFSC. The next three
columns give the monthly manhours shown on the LCOM performance summary
report for months two, three and four. Note that 23 day months were one
of the assumptions of this scenario. Data from the first simulated month
is always omitted. The three month manhours are summed and this total
divided by 331.2 to get the daily requirement. This figure was obtained
by:

M - (3 Mos. LCOM Manhours) 3 Mos. Manhours

^ ~ (3 Mos.) (.6) (23) (8) " 331.2

The next column gives the daily total of crew or post manning. The labor
of the daily manning columns is used to allocate manning to the three
shifts according to the proportion that were shown as an unconstrained
matrix program run. Note that daily manning for AFSC 328X3 is determined
by crew size rather than manhours.

The computation of direct manning required is:

M = Mg = 1.295 Ms

^ 142

This would not normally be done until the final iteration. M g values to
two decimal places are used to avoid rounding twice with the AFM 25-5
criteria. The X column would be checked in the final tabulation if the
AFSC were constrained by Matrix to meet peak demand and the M column would
indicate the card number for Moody manpower program input (Section IX) .

IX. DETERMINING MANNING REQUIREMENTS
Integrating Simulation Results

Manning requirements should be determined with the simulation for three
different sets of form 20s, holding everything constant except sortie rate
and corresponding flying hours. The results of these runs are then combined
in the regression program to produce manhour and/or matrix based manning
equations for each work center. These equations are similar to the curves
shown in Figure 44, except that the axes are direct manning requirements
and flying hours per month. The conversion is equivalent since the manning
assumptions and sortie length are held fixed for a given series of runs.

126

127

Data from the simulation runs on three scenarios are entered in the
following format, one card per AFSC:

Col 5
Cols 8-10
Cols 11-15
Cols 18-20
Cols 21-25
Cols 28-30
Cols 31-35
Cols 38-40
Cols 45
Cols 48-50
Cols 51-55
Cols 59-60
Cols 61-64
Cols 69-70
Cols 75

intercept (normally zero)
flying hrs/mo, scenario #1
final direct MHR/matrix manning scenario #1
flying hrs/mo, scenario # 2
final direct MHR/matrix manning, scenario #2
flying hrs/mo, scenario #3
final direct MHR/matrix manning, scenario #3
0

intercept as entered in columns 8-10, normally zero

AFSC

function code

minimum crew or post manning direct manning constant
card number for entry into Moody manpower program

The AFSCs entered on these cards are ''real" AFSCs corresponding to the
work centers defined by the operational command. LCOM AFSCs broken out to
distinguish requirements for dedicated cadres or post manning must be
combined back together to fit the operating command's function code structure.
The minimum crew size requirements and manhour requirements must also be
summed when LCOM AFSCs are combined.

If direct manning within any set of LCOM AFSCs being combined was
determined on different bases, the post manning or minimum crew size deter-
mined direct manning must be added to the manhour determined direct manning,
and this total entered as manhour determined direct manning. In this case,
the post manning determined direct manning component is entered instead of
zero as the intercept. For example, LCOM AFSCs 431A1, 431R1, and 431X1 must
be combined as 431X1. The direct manning (431X1 manhours, 431R1 and 431A1
post manning) is all summed and entered as manhour determined direct manning
for 431X1. The sum of the post manning determined fixed components for 431A1
and 431R1 is entered as the intercept in this case. The fixed component
entered for 431X1 is the sum of minimum crew and post manning for 431X1,
431A1, and 431R1.

Parameters and data are put into the RGR control deck in the following
order:

a card with zeros in columns 1 and 5
end of file card

data cards for each AFSC, entered in card number order

128

The regression outputs are a series of punched cards giving work center
equations for input to the Moody manpower program, and a printout showing
the degree and goodness of fit of these pylonomial regression equations. The
run sequence is shown in Figure 48.

Producing a Basic Manpower Authorization Document

The direct manning determined in the various simulation runs and expressed
as a regression equation is not a complete manning requirement. All the work
centers are not covered by the simulation (Section VIII, paragraph 1).

Only direct manning requirements are considered in the simulation but a
maintenance organization must include provisions for shop supervision and an
administrative staff. Finally, a complete manning document must consider
grade levels. The LOOM data base described in this report identifies AFSC
by specialty only.

The Moody manpower program is initially set up with standards for work
centers not simulated, supervision rates, overhead organization requirements
for various unit sizes, and grade spread criteria. This information is
obtained from the operating command for the aircraft being simulated. AFHRL-
TR-74-97(V) describes how standard data is structured and entered into the
manpower program.

To run the Moody manpower program, the user must input a desired flying
hour program and unit size, and a matching set of cards that were punched out
by the regression program containing direct manning equations and fixed post
or crew manning components for each work center. The Moody program then
uses the greater of manning from the equation or fixed manning component in
each work center, figured at the specified flying hours, as the direct work
center manning. It adds in other work centers, at standard, and figures
the necessary provision for supervision. After adding in the appropriate
overhead structure for the unit size, it figures grade spread. The output
is a complete basic authorization document for a maintenance organization,
in printout and on punch cards.

The parameter card for a Moody manpower run is prepared in the following
format:

Cols 2-6

Cols 7-8
Cols 9-11

Cols 12-13
Cols 14-16
Cols 17-23
Cols 24-25

Flying hours per month for which a manning document is
desired (e.g., for a 72 aircraft unit flying a wartime
program of 50 hrs/AC/MO, enter 3600)

Unit size (e.g., 72 aircraft)

AGE manning factor (e.g., 75 spaces per aircraft) as obtained
from the operating command. This factor is not used if AGE
maintenance is modeled and AGE work center manning is
simulated.

A format control: +1 = print and punch, 00 = print

999

Alpha-numeric run title

Hours/aircraft/mo (if unclassified, otherwise 00)

129

130

Figure 48. Regression and Moody manpower programs.

Cols 26-28 Sorties/aircraft/day (if unclassified, otherwise 00)

Cols 29-31 Average sortie length

Cols 31-34 Aircraft MDS

The parameter card is followed by the set of work center regression cards
for appropriate unit size.

To get a full complement of outputs for manpower planning, three flying
hour schedules for each of three different organization sizes should be
simulated. A set of regression cards would then be obtained for each unit
size.

Use of the regression and manpower programs permits manning for a
range of flying programs to be quickly obtained from the simulation of
three consistent points. The simulated hours scheduled or flown on any
of the three do not have to match the flying hour inquiry, but should be in
the same range. The procedure has the further advantage of assuring an
optimum scheduling. The answer for any given scenario can vary with the
percent of aircraft scheduled over and above the target flying program and
the simulation results seldom hit exactly on target. By redefining the
flying hours achieved as the scheduled program for regression program input,
overschedule becomes an output of LCOM and is consistent through the range
of the regression equations.

Variations and Updates

The regression and Moody manpower programs eliminate the need for many
additional expensive simulation runs to determine the impact of alternative
flying programs, provided other scenario assumptions remain constant. A
change in these assumptions does not necessarily require a complete rerun.
The regression program includes an option for proportionate shifting of
direct manning equations based on the simulation of one new point . The
curve continues to pass through the same origin, as shown in Figure 49.

The RGR deck setup for the curve shifting mode is as follows:

Card with 0 in column 1, and three or four in columns to indicate which
field new data will appear in

Set of AFSC cards with regression equations that were punched out on
original RGR program run

End of file

A set of AFSC input cards with the third (Columns 21-30) or fourth
(31-40) data fields changed to show manning and flying hours for
the new simulated points, as indicated on the first card above

The curve shifting feature is particularly useful for sensitivity
testing, since all results can be brought back to the same baseline. It is
applicable for most changes where manning is determined from the constant or
manhour derived curves which are known to be nearly linear. It should be

131

WORK CENTER DIRECT MANNING

TOTAL FLYING HOURS /MO.

Figure A9. Curve shifting.

132

used with caution when extrapolating manning on portions of the curve that
are matrix determined, since the general shape of peak demand functions is
not yet well defined. Neither does this feature eliminate the need for
periodic updates of the whole model.

The method of shifing curves in the regression program is explained
in AFHRL-TR-74-97 (V) .

133

REFERENCES

Air Force Manual 25-5. Management engineering policies and procedures .
Washington, D.C.: Department of the Air Force, 8 August 1973.

Air Force Manual 26-3. Air Force manpower standards . Washington, D.C.:
Department of the Air Force, 27 February 1973.

Air Force Manual 66-1. Maintenance management policy . Washington, D.C.:
Department of the Air Force, 1 August 1972.

Bell, C.F., & Stucker, J.P. A technique for determining maintenance
manpower requirements for aircraft units . RAND Report R-770-PR,

RAND Corporation, Santa Monica, California, May 1971.

Donaldson, T.S., & Sweetland, A.F. The relationship of flight-line
maintenance man-hours to aircraft flying hours . RAND Memorandum
RM-5701-PR, RAND Corporation, Santa Monica, California August, 1968.

Drake, W.F., et al. Logistics composite model users reference guide .

Air Force Logistics Command Report 70-1, AD-703 328. Headquarters
Air Force Logistics Command, January 1970.

Hicks, V.B., & Tetmeyer, D. Data base management programs . AFHRL-TR-
74-97(IV). Wright-Patterson AFB, OH.: Advanced Systems Division,

Air Force Human Resources Laboratory, December 1974.

Maher, F.A., & York, M.L. Maintenance manpower management during weapon
system development . AFHRL-TR-74-97 (I) . Wright-Patterson AFB, OH. :
Advanced Systems Division, Air Force Human Resources Laboratory,
December 1974.

Moody, W.D., Nichols, S.R., & Tetmeyer, D.C. Manpower program . AFHRL-TR-
74-97 (V). Wright-Patterson AFB, OH.: Advanced Systems Division, Air

Force Human Resources Laboratory, December 1974.

Nichols, S.R. , & Tetmeyer, D.C. Maintenance data analysis programs .

AFHRL-TR-74-97 (III) . Wright-Patterson AFB, OH.: Advanced Systems

Division, Air Force Human Resources Laboratory, December 1974.

Tetmeyer, D.C. Estimating and controlling manpower requirements for new
systems: A concept and approach . AFHRL-TR-74-31 , AD-778 838.

Wright-Patterson AFB, OH.: Advanced Systems Division, Air Force

Human Resources Laboratory, April 1974.

134

LIST OF SYMBOLS AND CODES

LRU: Line replaceable unit

Main Network Types:

Mode 1 - Preflight to thruflight
Mode 2 Preflight to postflight

Mode 3 Thruflight to thruflight

Mode 4 Thruflight to postflight

Task Codes :

A - Obtain and set up powered AGE.

B - Loading or downloading.

C - CALL Section
D - Decrement failure clocks.

F - Failure clock.

G - Fueling or defueling.

H - Inspections, service, scheduled checks.

J - Aircraft handling and moving.

K - In-shop bench check of LRU, find it serviceable.

L - Dummy task for probabilistic determination of
which LRU was removed from a failed subsystem.

M- On-aircraft repair not involving LRU removal.

N - In-shop bench check of LRU, find it broken

determine repair can not be made at base level,
prepare for shipment and order replacement form
depot .

P - Dummy task representing time to obtain replace-
ment LRU from depot.

Q - Draw LRU from base level stock.

135

R On-aircraft remove replace of an LRU.

S Dummy task representing shop entry point.

T On-aircraft troubleshoot.

V Inspect or functional check to verify on-aircraft
repair.

W In-shop ; bench check and repair LRU.

X On-aircraft gain access to subsystem and/or LRU.

Z Fly sortie.

Selection Modes Specifying Network Processiing Logic:

A Do the task when indicated by a random draw
against the specified non-mutually exclusive
probability .

C Do all required task in the defind call section.

D Do the task.

E Do the task when indicated by a random draw against
the specified mutually exclusive probability.

F Do the task only when the indicated clock has failed.

G Do the task when indicated by a random draw

against the specified non-mutually exclusive
probability, with such draws repeated until
at least one task in the set has been selected.

X Do the task when the following X or F task in the

network sequence is to be done (clock within a
subsequent call section has failed)

Type Resource Codes:

I - Aircraft

P - Parts

M - Men

A - AGE

136

Type Task Codes:

1 -Sortie

2 - Unscheduled maintenance

3 - Scheduled maintenance

4 - Depot repair

5 - Other

137