Maintenance / Logistics Simulation

I spent five years as part of an integrated team performing operations research analyses on the maintenance and logistics operations associated with the operation of several models of aircraft deployed in groups in various locations. The work was performed as part of an ongoing program to evaluate proposed changes to all aspects of support operations. The same team members had been working on the same code base for over thirty years in some cases.

This framework was driven by inputs containing parameters about flight schedules, mission requirements, equipment reliability (considering thousands of components), maintenance staff by specialty, scheduled maintenance procedures, and operating rules. The framework would perform multiple runs while generating requests for maintenance and replacement parts on a Monte Carlo basis using Poisson functions. The state of repair of each part determined an aircraft's operational status and that, in turn, determined what missions it could support, if any.

The framework generated large volumes of data which were first processed using formatted tables in a multi-tabbed spreadsheet but which later grew so large they had to be processed using dedicated parsers. The outputs included statistical characterizations of repair frequency, parts usage and supply quantities, cannibalization events, readiness metrics, percentage of missions successfully flown, resource usage per flight hour, mean repair time, and so on.

We processed large volumes of information from historical databases, vetting and cleaning that data as we went, and used it to determine the expected readiness of groups of aircraft to perform assigned missions. Scenarios ranged in duration from 24 hours for specific operational concepts to one year for more general analysis. Questions posed to the group included changes in readiness due to changes in part reliability, ability to maintain operations with a limited pool of high-value/critical components, different supply and delivery concepts, and more. Given a pool of over 4,000+ parts it became clear that the overall level of readiness was only marginally affected by improvements in any one part. Still, there were a lot of benefits that could be analyzed.

The core of the system is a discrete-event simulation implemented in a purpose-built language called GPSS/H, forms of which have been around since 1960. The system was run "by hand" for most of its existence, meaning that a configuration file had to be hand-edited to specify the parameters to be used for each simulation run. Some of those parameters were files themselves.

I worked on the input and output data sets and the spreadsheet and parsing tools directly. I wrote a tool in C++ to randomly generate flight schedules having the same characteristics as the historical data in terms of distribution of flying days, missions per day, duration of missions, and the type of mission and the equipment required. I worked only a little on the GPSS code and not on the C# UI that was built as a wrapper to streamline, pre-verify, and automate the use of the framework. I also collected and integrated data from various sources, analyzing the inner workings of the model based on the outputs, performed model runs and managed outputs, updated documentation, and developed and delivered presentations of results to customers.

The program was managed at a high level with a formal configuration control board, full version control, continuously updated documentation, and an ongoing V&V process. Over the course of five years there was a lot of ongoing discussion and debate about what was going on and if and how things should be done differently. Changes and adaptations were continuously implemented and there was one major conceptual redesign while I was there.