Q-GERT(ID:7433/)Graphical simulation systemgraphical simulation language Related languages
Samples: References: Extract: Aircraft Facility Model 2. Aircraft Facility Model A few comments about where we started from and a short history of what happened. In April 1980, the original aircraft input schedule for FY82 was just beginning to be build when the problems were first posed by the Aircraft Division Chief. "Why don't we know weekend overtime is needed in the paint shop before Thursday afternoon?" "Why is it we work overtime in Flight Prep only to be out of work there in five days?" "Why don't we know when we can't make an AMREP date until its too late to recover?" The Planning Section of the Engineering Branch builds the initial aircraft input schedules on 2 large (4 x 20 ft) magnetic boards. The horizontal axis of the boards represent time (e.g. FY 82 in months and days) while each aircraft tail number takes up a row. The different MDS are grouped on the boards to aid theplanner to see each major program together. The time each aircraft is expected to occupy a facility is displayed with a magnetic color-coded strip. Potential bottlenecks at facilities are identified by a planner noting "too many strips of the same color" lined up on the vertical axis. Other constraints are identified in a similiar manner. The input schedule is usually firm one to two months before a new fiscal year and once the new year begins, changes to the input dates are handled by the Scheduling Branch. Four separate scheduling sections monitor and adjust the schedules for the F-Ill, A-lO, F-106, F-4D and T-39 aircraft. Since all aircraft use common resources i.e. flight prep, fuel, wash rack and paint; schedulers often make decisions about their aircraft which impact the other types of aircraft. Considering the variety of interactions that occur daily in a large industrial complex and what they have to work with, the people in the planning and scheduling branches do a very good job. It was decided that diagraming aircraft flow through the various facilities in a Q-GERT network would be instructive. (Q-GERT is a network modeling and computer analysis tool developed by Dr. A. Alan B. Pritsker. GERT is an acronym for Graphical Evaluation and Review Technique. The Q indicates that queueing systems can be modeled in graphic form.) After about an hour of basics in Q-GERT and the loan of the book (ref l) for the weekend, two Captains began building the network. Within two weeks, they had build a credible network description of the Aircraft Division flow processes. (It should be noted that neither of the two Captains had formal training in Q-GERT). A series of frustrations began in June. The version of Q-GERT on the AFLC CREATE (Computational Resources for Engineering and Simulation, Training and Education) system could only handle a lO0 node network - we were up to 185 nodes so the model had to be partitioned into smaller sets to check the network logic. Unfortunately during the next weeks, CREATE DESTROYED more than it created. Equally unfortunately, the three people working the project were reassigned to other Jobs. But before the team totally disbanded in July, key aircraft division people and the Director of Maintenance were shown what results we had. The ten foot network stretched out on a table and a couple of Q-GERT simulation runs of the pieces that CREATE finally gave us were convincing enough to pursue the simulation approach further. A contract with Pritsker and Associates was negotiated to: (1) run our model on their computer, (2) improve our data input procedures and demonstrate applications of a simulation data base system, (3) develop and demonstrate computer graphics capabilities, (4) conduct a computer sizing study, and (5) provide a briefing and demonstration of their findings. Briefly, the events on the contract went like this: In September 1980, Dr. Ken Musselman visited McClellan to look over our model, tour the maintenance facilities, talk to people in planning, scheduling and management levels of the Aircraft Division and outline an initial plan of attack. Activities during September and October consisted of telephone coordination on model improvements and data inputs. We gave the contractor a copy of the September 23rd aircraft status report along with the remainder of FY 80 and the FY 81 input schedules to use in testing and the demonstration. During the first week of November, five Sacramento people went to West Lafayette, Indiana to see what was being developed. Many of the graphics in the next section were run during the November visit. We knew we were on to something when "Red" Slater, an avowed computer hater, began to talk about "queues" and "user-friendly" inputs. The interaction between the Mr. Bob Hannan who did the programming and our people was truly remarkable. As a result of the in dialogue, several new products turned out, literally overnight. On the second of December, an all AFLC meeting was held at Sacramento where Ken Musselman briefed the project and Bob Hannan gave an on-line demonstration of the system. The demonstration was conducted by linking a borrowed Tektronix 4054 graphics terminal via commercial phone line to the VAX II/780 minicomputer at Pritsker and Associates offices in Indiana. The demonstrations were structured to show all of the graphics capabilities that had been developed but also included time to demonstrate some of the program flexibility by fielding on-line queries from the audience. On January 15th the final report (ref 2) was delivered. Extract: Specific Results 3. Specific Results Figure 1 depicts the overall relationships between data inputs, the simulation data base, the network model and the outputs products. There are four inputs needed to run the Q-GERT simulation: An aircraft input schedule, the status of aircraft at the beginning of the simulation to load the network, the expected duration of each work package at each work center and the space limitations at each work center. The incoming aircraft schedule requires the MDS, tail number, scheduled completion date for each aircraft. The aircraft status requires all of the elements required for the schedule plus identification of the aircraft's current location and the remaining service time for the location. The Work Center/Work Package Activity Durations are loaded into a table such as shown in Figure 2. The columns labeled resource indicates the Q-GERT resource number used for the specific work center, the column labeled UF number indicated the user function (a FORTRAN subroutine) used to obtain the activity time, and the numbers under the work package columns are the durations in flow days expected at each facility. For example, the mod assembly area will be used 53 days on work package 72. The space limitations are entered in the model directly with Resource type definition cards. The original network model has been improved and now requires ll8 nodes and 14 resource types (compared.to the original 185 nodes and 12 resource typesl. Figure 3 shows a typical work center configuration in Q-GERT notation. Each work center in the model is basically represented the same way. The right hand of each node is the node number. Node 50 is a queue node (denoted by the tail which makes the node look somewhat like the letter Q). Upon arrival to the work center, the aircraft waits on a first in, first out basis (denoted by the letter F in the middle of the Queue node. NOTE: Other queue disciplines are easily accommodated) until space is available. Node 51 is a resource allocate node and the 5 in the middle left box denotes the resource number that is to be allocated. The l in the lower left box denotes how many units of the resource are to be allocated to each transaction. As mentioned earlier, the space limitations are entered in the Resource type definition card. If 9 spaces were to be assigned as resource 5 the entry would look like this: RES, 5/F4 NOD, 9, 51" Thus to change the spaces to some other value all that would be needed is to change the 9 in the entry. Node 52 is a regular node to denote the start of the activity. Activity duration (i.e., the time required to move from node 52 to 53) is a function of aircraft type, work package and work center performing the activity. The individual times are called from the data base. Node 53 is a Free node. It releases 1 unit of resource number 5 at the end of the activity for use on another aircraft that might be waiting back at node 50. With these basic blocks, the entire aircraft maintenance complex was modeled by linking them together with logical branch operations. Each transaction (i.e., aircraft) carrier attributes which identify what type aircraft it is, what its tail number is, what work package it has and some additional routing information. At the many places in the network where route choices must be made, such as which MOD center should the transaction go, attributes are checked and the branch decision is made accordingly. The standard Q-GERT analysis program outputs a wealth of system information providing major queue and resource utilization statistics for each run and for multiple runs. When changes are made to model parameters or input schedules, the output products show the changes in system performance. We were delighted to discover for example, that one type of change in the paint facility not only corrected the bottleneck in paint and improved the flow in the T-39 mod center; but it also can be expected to make queues in the fueling area WORSE, which hadn't been considered before. Some other unexpected (to us) things happened by using the SDL/I simulation data language (ref 3). While we knew our initial data inputs to the model could be improved, the ease and flexibility offered by SDL/I both in data input and in manipulating output data from simulations were astounding. Without getting overly technical, SDL/I is a data base management system that interfaces with the simulation model. One way of looking at SDL/I is that it gives the modeler the capability to trace actions in the model - without rerunning the model. For example, we were interested in knowing which types of aircraft were waiting at the paint f a c i l i t y after a run was made. I~e just queried the data base to provide the information sorted by aircraft type. We were even able to get details on individual tail numbers (Figure 4). This level of detail was an unexpected bonus, because tail number schedule is currently produced by hand. We were able to select out details to build a schedule for each major facility (a task we don't even attempt to do long range) just by sorting and listing relations in the data base. The simulation data language also allows the modeler to store data from the different sceneros he would like to model. He can then simulate them sequentially without destroying the other results for comparison. The data base language also provided the interface to the graphics capabilities that were developed for us. The graphics developed for the project were probably worth the price of admission alone. In the three months development time virtually any information in the data base relations could be plotted. The graphics package allows the user to: (1) define a new plot through a series of prompts at the terminal, (2) select plots from a list prestored plot routines, (3) edit a plot to either generate a new plot or change a parameter on a current plot, and (4) designate the plots to be generated at the terminal--up to 4 plots may be generated on the CRT at once and they may be superimposed. Figure 5 is a sample of the graphics that were available. The top plot represent the baseline conditions at the paint facility. The top plot shows up to three aircraft are expected to queue up at the paint facility during the time frame displayed. The bottom two plots show the expected queues at the paint facility after the number of spaces in the paint facility is reduced from 4 to 3. During the study there were over lOO different plots generated, not counting the scale changes, combinations of plots, etc. The final report (ref 2) and the presentation notes (ref 4) have additional examples of the graphics. One further point about the graphics. All graphics were drawn on the terminal within about a minute of the user's request. Another analysis and graphics program AID, was demonstrated as part of the contract. AID is an interactive data characterization program designed for the validation of statistical distruptionso It is useful for a pictorial representation of data, percentile estimation, sensitivity analysis and statistical as well as visual goodness-of-fit testing. Figures 6 and 7 are examples of AID plots. Further information and illustrations are found in the final report and in reference 5. Extract: 4. Future Application/Modifications 4. Future Application/Modifications Lest anyone be led astray, the demonstration is over, We are back to manually building schedules, etc. because we haven't a computer to run the software. Efforts are underway to obtain computer time, graphics terminals, the communications links and the software licenses to begin real use of these simulation capabilities. However, the Data Automation Request route is slow and strewn with obstacles. Even if we had the hardware, a few enhancements to the demonstrations model are needed. In the demonstration, Julian dates were used throughout. The programs would be more useable if a data input and output transformation were developed to transform calendar dates to flow (i.e., simulation) time and the reverse. As the model is currently configured,.errors will result unless the input schedules and output are manipulated off-line to account for weekends and holidays. Another enhancement is needed to allow resource allocations to be altered for limited periods during a simulation run. As the model is configured now, any changes in resource levels must be in effect for the entire simulation. Resource altering is allowed in standard Q-GERT, but with the DSL/I interface some reprogramming may be needed. Our wish list for desirable software enhancements includes: providing additional interfaces and edits to make the graphics even more interactive and "user friendly," expanding the number of work packages, and modifying the SDL/I input to include stochastic activity durations (the standard Q-GERT has stochastic time, but some minor reprogramming of the SDL/I interface maybe needed). Once the stochastic features are included, decision risks and variance studies could be done. We will be working to obtain these software enhancements while we wait for the hardware to run them. Once the hardware and software enhancements are obtained, a series of recursive models might be done. For example, a more detailed model of a mod center or any other aircraft maintenance facility could be attempted. We already envision interactive simulations between the current Aircraft Division level model and the more the detailed lower level models using SDL/I data base capabilities. Also, variations on the current level model should be attempted is to use the different maintenance manpower skills as constraining resources instead of facility resources. Manpower, space, equipment, parts or even money could be modeled as resources either singly or in combinations. These types of simulation models can be used to give a quick way to forecast production bottlenecks and a means of predicting the effects of redistributing maintenance resources. They also could help to introduce more vigorous decision making techniques and help to integrate some of our currently fragmented planning, scheduling and production control processes. The Sacramento demonstrations proved that modern modeling, data base management systems, computer graphics and computer aided analysis techniques can be applied in a depot maintenance environment. It is no longer just a theoretical formulation. However, the next steps will probably be the hardest. Not just demonstrate feasibility; but using these modern management techniques day to day. |