Modeling Sortie Generation, Maintenance, and Inventory Interactions for Unit Level Logistics Planners Sponsor: Air Force Research Laboratory PI: Manuel D. Rossetti Co-PI: Raymond R. Hill, WSU and Dr. Narayanan Graduate Assistants: Todd Hausman and Josh

1
Modeling Sortie Generation, Maintenance, and
Inventory Interactions for Unit Level Logistics
Planners Sponsor Air Force Research
LaboratoryPI Manuel D. RossettiCo-PI Raymond
R. Hill, WSU and Dr. NarayananGraduate
Assistants Todd Hausman and Josh B. McGee

• Objective
• The goal of this project is to develop simulation
  modeling methodologies that will assist logistics
  managers in analyzing the effects of different
  resource allocation policies and identify
  potential risks in logistics plans.
• Activities
• Extend current simulation model to detail the
  sortie generation process
• Design User Interface
• Design test scenario
• Analysis of simulation results
• Delivery of report to AFRL/HEAL

2
Overview

• Overview of the Sortie Generation Process
• Requirements Gathering
• Site Visit/Core Requirements
• Main Actors
• Problem Statement
• Problem Areas
• Basic Decision Influence Diagram
• Scenario-based Design and Testing
• Decision Support System
• System Vision
• Model Development
• Interface Development
• Principles Guiding Design
• Persona Development
• Interface Presentation
• Interface Validation
• Scenario Development
• Reflective Requirements
• Future Research

3
Sortie Generation Process

• Two Phases
• Planning
• Coordinated drafting of the schedule by
  maintenance and operations
• Execution
• Aircraft fly the scheduled sorties

4
Sortie Scheduling

• Planning for sorties is carried out on an annual,
  quarterly, monthly, and weekly basis.
  Information was gathered for this description
  from
• ACC Instruction 21-165
• Howard, H. and Zaloom, V. (1980)
• Eglin Site Visit
• Other Air Force Instructional Documents

5
Problem Statement

• The sortie generation process is driven by the
  sortie schedule. The process of scheduling
  aircraft is an iterative process which includes
  annual, quarterly, monthly, and weekly scheduling
  meetings.
• Annual and Quarterly schedules involve rough
  requirements planning
• At the monthly planning session that a specific
  schedule takes shape
• Weekly planning involves refining the monthly
  schedule based on constraints which are met
  through the month

6
Problem Statement

• Problem
• Schedulers need a tool to evaluate the risk
  involved in a schedule or in making needed
  schedule changes.
• Decisions must be made during both the planning
  and execution phase of sortie generation.

7
Problem Statement

• How we address the problem
• Develop a simulation model which can evaluate the
  effectiveness of a schedule along with the risk
  involved in individual schedules.
• The goal of this project is to illustrate that
  simulation can be used as an effective tool to
  support sortie scheduling decisions.

8
Weekly Schedule

• Weekly scheduling is the final refinement of the
  monthly plan and results in the weekly flying and
  maintenance schedule. The weekly schedule is
  distributed no later than 1200 Friday morning
  before the effective week and will include
• Aircraft takeoff and landing times including
  aircraft tail numbers
• Sortie sequence numbers
• Configuration requirements
• Munitions requirements
• Fuel loads
• Special or particular mission support
  requirements
• Alert requirements
• Exercise vulnerability
• Deployments
• Off base sorties
• Equipment training requirements

9
Weekly Schedule

• Our focus for this research will be at the weekly
  schedule level.
• Basic Plan
• We will allow a user to input a weekly schedule.
• A simulation will then evaluate that weekly
  schedule.
• Results will then be displayed to the user in an
  easy to interpret form.
• This interface will allow a user to quickly and
  easily evaluate multiple schedule alternatives.

10
SGP Execution
Adapted from Faas (2003)
11
Requirements Gathering

• Lessons from site visit to Eglin AFB
• Aggregate information
• Integration of real data to generation
  installation times, resource capacity, etc.
• Decision must be made relatively quickly

12
RG Main Actors

• Operations
• Maintenance (AMU)
• Maintenance Operations Command
• Production Supervisor (Pro-Super)
• Maintenance Chiefs

13
RG Problem Statement

• Help the production supervisor gauge the risk to
  the phase flow and aircraft operational
  availability metrics as influenced by weekly
  changes to the sortie schedule by
• making informed recommendations of potential
  change opportunities
• identify impacts that a specific solution causes
• Thereby reducing the uncertainty associated with
  a change decision.

14
RG Problem Areas

• Sortie Schedule
• Resource Limitations
• Information Overload
• Minor changes can effect the overall system

15
(No Transcript)
16
RG Problem Scenario

• To prepare for the morning meeting, MSgt.
  MacNeece likes to take the monthly plan and
  review what needs to happen. He transposes this
  information into MS Excel. Then he logs into
  TASAMS to check the aircraft availability and
  weekly schedule of maintenance. To get a better
  picture of the bottlenecks that might affect the
  maintenance schedule he checks the availability
  of resources (i.e. AGE, wash house, paint barn)
  and calls a few maintenance chiefs to gauge the
  availability of personnel. He does a quick sweep
  of the aircraft available for load training to
  make sure the information is fresh in his mind.
  He goes back into Excel and selects the cells
  that contain the tail number of the planes he has
  available he bolds the numbers to make the
  numbers stand out. He does a quick calculation
  of the current wing phase flow and checks TASAMS
  again for the current cannibalization rate.

17
(No Transcript)
18
System Vision

• Two cycles
• First pass identifies change opportunities
• Second pass performs a what-if analysis to see
  what changes to resources and installation times
  may influence the metrics
• Three key components
• Input interface
• Simulation model
• Output analysis

19
Cycle Interactions
20
Second Cycle

• We will begin by discussing the simulation model
• The model drives
• Inputs
• Outputs
• User Interface Integration

21
Modeling Approach

• Modeling
• In previous research we created a model of the
  basic Multi-Indenture Multi-Echelon scenario
• Our goal for this project was to extend the
  current model, detailing the sortie generation
  process
• Proof of Concept
• We show proof of concept for a simulation based
  tool which would allow unit based logistics
  planners to effectively evaluate the risk
  inherent in
• Sortie Scheduling
• Resource Management

22
Old Simulation Model

• Multi-Indenture Multi-Echelon repairable parts
  system
• Multi-Indenture
• Aircraft made up of Line Replaceable Units in
  turn made up of Shop Replaceable Units
• Multi-Echelon
• Central Depots supplying a series of bases
• Main focus of the old model was the supply chain
• Parts inventories
• Shipping options

23
Multi-Indenture Multi-Echelon (MIME) System
An example MIME System with one central depot
serving three bases which in turn operate several
weapon systems
A diagram representing the failure/repair cycle
24
New Simulation Model

• The new model
• The focus is the execution of a weekly flight
  schedule for a single base.
• Must determine the initial state of the system
  for the user prior to simulating the weekly
  schedule
• State of aircraft
• State of supply chain
• The old model logic is used to simulate the
  supply chain.
• Shipping of parts
• Competition for parts
• The new model logic is concerned with the sortie
  generation process at a single base with a
  specific user defined number of aircraft.

25
Aircraft Initial States

• One of the challenges in evaluating a schedule is
  capturing the aircraft state at the beginning of
  the study.
• In our model the state is captured by the
  following variables
• Current Phase Hours
• Status (Cross Country, Mission Capable,
  Non-Mission Capable)
• Expected Return to Mission Capable Status
• The status of an aircrafts component parts is
  determined by the number of phase hours it has
  accrued.
• We generate a Time to Failure from the Mean Time
  to Failure distribution for each part.
• Then we simply use the phase hours to determine
  the number of flight hours the aircraft has
  accrued and subtract that from each parts TTF
• This initial data must be captured through the
  user interface

26
Supply Chain Initialization

• Once the user has supplied the required data and
  has initiated the simulation, a warm-up period
  begins.
• This warm-up period initializes the supply chain
• After the warm-up, we remove the aircraft of
  interest from the old logic and reinitialize
  them.
• These new aircraft are initialized using the data
  supplied by the user
• The new aircraft enter the Sortie Generation
  Logic and begin to execute the schedule

27
Weekly Schedule

• Sorties are modeled as entities with the
  following attributes
• Go Number  (indicates which run)
• Tail Number (indicates the aircraft)
• Scheduled Take-Off Time
• Scheduled Land-Time
• Scheduled Duration
• Additional attributes indicate the state of the
  sortie (e.g. scheduled, in progress, aborted,
  completed, late, etc.)

28
Weekly Schedule

• The schedule is modeled as a list of sorties
  (i.e. a queue that holds the scheduled sorties
  for their release)
• The user interface will prompt users to input
  this weekly schedule at the beginning of the
  simulation
• Aircraft are modeled as entities with the
  following attributes 
• Tail Number
• Configuration
• In the model a dispatcher entity releases the
  scheduled sorties to be executed daily. 

29
Execution of the Schedule

• Sorties for a day are scheduled at the
  beginning of the day
• 2-3 hrs before the scheduled takeoff time the
  sortie signals the release of the aircraft for
  pre-flight operations
• Pre-Flight operations include
• Configuration
• Refueling
• Weapons Load
• Exceptional Release
• Pilot Show
• Dash 1 Checks
• Engine Start
• Taxiing
• End of Runway check

30
Execution of the Schedule

• Once pre-flight operations have been completed
  the aircraft flies the sortie.
• In the new model failures are modeled in the same
  way as the previous simulation model.
• Operational time is decremented from each parts
  Time to Failure (TTF) values
• A failure occurs when one or more parts TTF
  values reach or go below 0
• When a failure occurs the aircraft enters the
  repair cycle as modeled in previous simulation
  model.

31
Execution of the Schedule

• When a failure occurs and an aircraft cannot
  complete a scheduled sortie, spares are used to
  fill in.
• If there are no spares available the sortie is
  cancelled.
• In each case when a sortie is not executed as
  scheduled a change opportunity is captured.
• Change opportunities are instances where the
  maintenance officer would have had to directly
  change the schedule in order to continue
  operation without taking a deviation.

32
Schedule Changes
There are three types of changed which can be
made to the weekly schedule after its
distribution Pen-and-Ink are intended to allow
for minor changes to the weekly schedule which
arise due to fluctuation in aircraft
availability. Allowable changes include tail
numbers, takeoff/landing times,
etc Interchanges or swapping tail numbers are
intended to prevent unnecessary reconfigurations
and expenditure of work hours. Configuration
changes in the required configuration of units
can be made to reduce man hours as long as the
requirements of the sortie can be met.
33
Schedule Deviations
Ground Deviations Addition The addition of an
aircraft/sortie to the schedule not previously
printed on the weekly schedule. Cancellation
An aircraft that is removed from the printed
schedule for any reason. Early Takeoff A
scheduled sortie launching more than 30 minutes
prior to the scheduled takeoff time. Ground
Abort An event preventing a crew ready
aircraft from becoming airborne. A ground abort
by itself is not a deviation, but can cause a
deviation in the form of a cancellation of late
takeoff. Late Takeoff A scheduled sortie
launching more than 15 minutes after the
scheduled takeoff time. Spare A spare aircraft
launched instead of the scheduled
aircraft. Interchange Tail number swaps can be
made up until the crew ready time.
34
Schedule Deviations
Air Deviations Air Abort An sortie which
cannot be completed after takeoff for any reason.
Air aborts are considered a sortie flown when
reporting total sorties. Air Abort, IFE An air
abort resulting in a in-flight emergency Early
Landing A sortie landing more than 15 min
before the scheduled landing time (not used when
computing FSE). IFE A situation resulting in
an in-flight emergency after the mission has been
accomplished. Late Landing A sortie landing
more than 15 min after the scheduled landing time
(not used when computing FSE).
35
Schedule Deviations

• As illustrated by the previous slides there are
  many deviations that can occur and a number of
  ways to make schedule changes to avoid them.
• By tracking change opportunities we try to
  capture the risk inherent in a particular
  schedule without inducing modeling risk.

36
Performance Measures

• Flying Schedule Effectiveness is currently used
  by the Air Force
• We use Change Opportunities to capture all times
  that a change must be made to avoid a deviation.
• Deviation From the 450 Phase Flow across all
  aircraft
• For each plane, plot the accumulated flight hours
  sorted in ascending order by plane
• A 45 line indicates an even dispersion of flight
  hours across aircraft
• Planes with less available flight hours before
  phase inspection are higher on the line, planes
  with more available flight hours before phase
  inspection are lower on the line
• Goal is to keep enough flight hours available to
  meet sortie requirements

37
User Interface

• The user interface is designed to
• Capture model input requirements
• As developed in the previous slides
• Display model results
• The goal is to maximize
• Ease of use
• Time required
• Tractability of results

38
Interface Development

• Usability Specifications
• Evaluation Heuristics
• Transparency of calculation for complex actions
• Support internal locus of control
• Match between system and the real world
• Flexibility and efficiency of use
• Simple and consistent
• Aid the recovery and diagnosis of errors

39
ID Persona Development

• Persona (Cooper, 1999)
• Small user pool
• Constrained access to user pool

40
UI Prototype Step 1
41
UI Prototype Settings
42
UI Prototype Step 2
43
UI Prototype Step 3
44
UI Prototype Step 4
45
UI Prototype Step 5
46
UI Prototype Step 6
47
Interface Evaluation

• Upon completing the user interface, the interface
  itself was evaluated using
• Heuristic Evaluation (Nielson et al, 1990)
• Review by User Representatives

48
Scenario Development

• Upon the completion of the model a scenario was
  developed to test the effectiveness of the model.
• This scenario was developed using multiple flight
  and maintenance schedules provided by the Air
  Force.
• This is not an actual scenario, but simply an
  example schedule to test the model
• The following slide outlines the initial state of
  the 24 aircraft in the scenario.

49
Tail Number Availability Delay (hours) Flight Hours Config.
010101 Available 0 56 Clean
010102 Available 0 57 Clean
010103 Available 0 96 Clean
010104 SM Triangular(12,15,20) 17 Clean
010105 Available 0 246 Beta
010106 Available 0 191 Clean
010107 XCO Triangular(24,25,27) 94 Gamma
010108 XCO Triangular(24,25,27) 95 Gamma
010109 Available 0 7 Alpha
010110 DEMO Triangular(169,175,180) 102 Alpha
010111 Available 0 51 Beta
010112 CANN Triangular(200,224,280) 30 Alpha
010113 SM Triangular(80,84,91)0 134 Clean
010114 DEMO Triangular(12,15,20) 115 Clean
010115 NMC Triangular(50,58,60) 144 Alpha
010116 Available 0 167 Alpha
010117 Available 0 70 Clean
010118 PHASE Triangular(60,63,67) 0 Gamma
010119 Available 0 21 Beta
010120 Available 0 266 Alpha
010121 Available 0 238 Alpha
010122 Available 0 91 Alpha
010123 Available 0 30 Beta
010124 Available 0 80 Beta
50
Scenario Schedule

• The table below summarizes the scenario schedule.

Day Turns
Monday 12/10
Tuesday 12/10
Wednesday 12/10
Thursday 12/10
Friday 10/8
Saturday 10/8
Sunday OFF
51
Scenario Schedule

• Below is a listing of the schedule for Monday and
  Tuesday for the first 10 tail numbers.

Tail Mon. F1 F2 Tues. F1 F2
Config. TO Land TO Land Config. TO Land TO Land
10101 Clean 0800 0905 1600 1730 Clean 0800 0905 1600 1730
10102 Clean 0800 0905 1600 1730 Clean 0800 0905 1600 1730
10103 Clean 0800 0905 1600 1730 Clean 0800 0905 1600 1730
10104 Clean SM Clean SPR
10105 Beta 0750 0915 SPR Beta 0750 0915 SPR
10106 Clean SPR Clean 0800 0905 1600 1730
10107 Gamma XCO Gamma XCO
10108 Gamma XCO Gamma XCO
10109 Alpha 0805 0940 SPR Alpha 0805 0940 1605 1720
10110 Alpha DEMO Alpha DEMO
52
Scenario What-If

• The scenario also included the following what-if
  analysis.
• Due to other demands within the system, supply
  will take approx. 5 longer
• Maintenance will take 5 longer
• Installation will take 5 longer
• Repair has 10 more capacity

53
Summary

• Analyzed the issues involved in using simulation
  technology for sortie flight generation
• Developed and tested a prototype simulation model
• Developed and tested a user interface prototype
• Both students will be continuing the effort as
  part of their Masters Thesis work

54
Future Research

• Enhance Simulation Model
• Incorporate more change logic into model
• Extend model to other aspects of flight line
• Develop and capture additional performance
  metrics
• Enhance User Interface
• Explore portable issues so it can be used on the
  flight line (i.e. PDA, web-interface)
• Allow the user to modify the simulation so it
  more closely matches their specific situation
• Additional visual or multi-criteria displays of
  schedule risk
• Additional user testing
• Examine ways to generate heuristic or optimal
  schedules to the user
• Model schedule as optimization problem
• Examine deployment issues
• The Air Force has a large amount of data
  available in multiple formats.
• Connecting decision support tools such as the one
  developed in this research to those data sources
  could be very valuable
• Access to AF data formats (i.e. CAMS, TASAMS)

55
Questions?