Objective

1. Modeling Sortie Generation, Maintenance, and Inventory Interactions for Unit Level Logistics PlannersSponsor: 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

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.

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. Weapon2 Weapon1 Weapon3 Base2 Weapon1 Weapon1 Base3 Weapon2 Base1 Weapon2 Depot Weapon3 Weapon3 Repaired part Repair Facility Inventory Warehouse Failed part Spare part Airplanes 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 aircraft’s 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.

50. Scenario Schedule • The table below summarizes the scenario schedule.