1 Demonstrating Aurora’s basic capabilities on a larger file
Now that you have seen Aurora’s basic capabilities on a small, manageable file, I’m going to show you the same set of capabilities, plus a few others, on a much, much larger file.
2 Based on real Boeing Company data, 2,500 activities/tasks
This is based on real data made available to us by the Boeing Company. It includes the assembly model for their latest airplane, the 787. It has approximately 2,500 activities,
2 Three constraints each
each of which has usually about three constraints
2 Six resource requirements each
and six resource requirements. So it’s a fairly large, complex scheduling problem.
1 Navigating around the PERT Chart
You can see that I can navigate around the Pert Chart by clicking on various elements that will take me to the details over here.
2 Finding a specific element
Or if I want to find a specific element, I can search for it. This is especially important for such a large model, because otherwise finding various things can be quite difficult.
1 Brief orientation
- Just to get you oriented briefly,
2 Activities in a single compound task (Airplane build process)
all of these are activities in a single compound task. Basically the build process for a single airplane.
There are also a number of resources.
3 Resources not hierarchical
The reason they’re not done hierarchically as they were in the previous file is because all of this data is imported from another source, and it isn’t presently rich enough to add a hierarchy.
3 Resource sets
There are also a number of resource sets. Again, you can see that they’re quite large compared to the data that we had dealt with before.
1 No activities
And because it’s imported, there aren’t any activities. It’s also supposed to use the standard factory work schedule,
1 Three-shift schedule
which is a three‑shift schedule
2 Gaps between shifts
with gaps in between the shifts. The gaps actually express breaks within the shift, but this is an easier way of modeling it and does not degrade performance.
1 Scheduling the data
OK, with that brief introduction, I’m going to go ahead and schedule the data. Now, because this is quite a lot more data than we saw in the other file, it takes significantly longer to schedule.
2 15 second scheduling process
The actual scheduling process takes about 15 seconds for this particular file,
3 Sending data for display
and then it takes a little bit longer to send the data across for the display in the interface.
If there was much more data than this, we would send the results incrementally, so that the user wouldn’t have to sit there gazing at the screen while it processed. Aurora’s now sending the results across.
1 Viewing results
This will allow us to actually view them as if they were real data.
2 Standard Gantt Chart
OK, the first display I’d like to show you is again the standard Gantt Chart. You may recall us looking at that in the small file. This is a very different Gantt chart.
3 Preliminary milestones (left)
All of these activities off to the left are preliminary milestones. If I scroll down, you’ll see that it actually starts to spread out a little bit.
3 Gaps in the activity
Now, there are a couple of things that I’d like to point out to you on this Gantt Chart. You can see that this activity has a number of gaps in it.
3 Mechanic resource produces breaks between shifts
That’s because it actually uses the mechanic resource which is associated with that factory work schedule, and so those are breaks between the shifts.
3 Working directly through the breaks
This, however, does not use any personnel at all, and so it doesn’t have that more restricted work schedule, so it can work directly through the breaks.
3 Waiting Job
That’s because it’s not actually an active work job, it’s more of a waiting job. For example, waiting for paint to dry.
2 Histogram plot for long-range personnel planning
One of the schedules that they use the most in terms of long‑range personnel planning is the histogram plot, which is ideally suited to looking at things like the mechanic usage. They’re actually dealing with… If I scroll down, I can start to see the histogram.
3 Gaps in the histogram reflect shift breaks
Now, a couple of things to note. First, there are gaps in the histogram. Once again, those are reflecting shift breaks.
3 Zooming in on the histogram
can zoom into the histogram in a couple of different ways, either by grabbing the bars or, in a more targeted way, by holding down the Alt key and just dragging to highlight an area.
Now, one of the things that makes the histogram fairly easy to look at, if you look at it at a high level, it gives you a strictly global notion of what the usage is.
3 Highlighting given time slice
But if you highlight a given time slice, you can see what activities are using that resource at a given time, and again open them up and see why they scheduled the way they did, as we could in the previous displays.
4 Temporal constraint with 9-17
In this case, the start date was affected by 9‑17, so this basically means that a temporal constraint with 9‑17 determined where it was going to schedule.
2 Spatial plot, for unary reasons
Once again, for unary resources, the spatial plot is ideal.
3 Displaying whole resource set
You have a number of ways of determining what should be on a given plot, so I’m actually going to show a whole resource set, all of the areas that are in the left wing area.
3 Activities spread across resources
OK, you can now see the various activities spread out across all of these resources. Now, it’s important to note some of them, such as 5‑37, actually use all of them. That’s because for the user’s convenience, some of the apparently single resource requirements are actually using a number of different resources, which means that the average of six requirements I quoted earlier is six individual elements here, not the actual number of resources it needs, which makes the problem significantly more complex. In this particular case, “use full set” indicates that it’s using all of the areas in the left wing.
3 Viewing explanations as in other displays
Now, a couple of things that I’d like to point. One, you can gain the same sorts of explanations using this that you could in the other displays.
You can view the same sorts of explanations that you could in other displays, so for this particular element, for example, you can see that it was waiting for MX tray B to open up. 1, 6, 18 had finished.
1 Drag and drop schedule editing
You can, actually, edit the schedule by the same sort of drag and drop that you saw me use earlier.
1 Taking snapshot
Before I do that, I’m actually going to take a snapshot.
2 Comparing change with original schedule
And what that allows me to do, is compare the results after I have made my change, with the original schedule.
So, I’m going to grab this, and drag it down beyond here. And then I’ll reschedule.
Now, the rescheduling will take a little while, just because, for Boeing, specifically, they wanted a full reschedule every time. For a domain where they expect the user to make a lot of edits, usually just a few localized elements would reschedule, sort of shuffling things around to accommodate the new change.
The sending of the results takes a little longer, also, now, because I have various displays open, and it actually has to update those. You can see it actually updating this display. Now it’s finishing out the other displays, and then it will be done.
So you can see that that had a pretty significant impact on the schedule.
Once again, my explanations can help me determine what’s going on.
If I look at this element, for example, as you might expect, based on where it’s scheduled, carefully lined up with the end of 5:30, its start date was basically determined by 5:30, which we had moved over manually, and so now we have a gap in the schedule where there wasn’t a gap before.
1 Using Gantt chart to run comparison with snapshot
If I go back to the Gantt Chart, I can actually now run a comparison with the snapshot that I took.
OK, now you can see we have snapshot data.
2 Delay alters schedule
Now, down here it just looks like everything has turned gray, because the schedule is actually the same. But if I scroll down here, you can clearly see the difference resulting from that delay.
Now, if we do a search for element 5:30, I should be able to find it and see just what it did to the schedule.
OK, and here is 5:30. You can see that it was delayed 11 hours from its original start time, approximately. You can also see that it’s not actually the first element with an apparent change.
Now, this is because Aurora doesn’t simply go through in first to last order, scheduling everything at its earliest possible date.
3 Swap alters priority
And so things have swapped around a little bit, altering the priority based on 5:30’s movement in an attempt to gain some of that time back.
If we come down to the very bottom, and I’ll just update the timing a little bit so that we can see off to the right, you can see that it did succeed to some extent. Here, the gap is about eight hours, almost nine hours, as opposed to 11 hours. So, Aurora was able to buy back two of those 11 hours. And so, we’re certainly better off than if it hadn’t messed around with the schedule at all.
1 Slicing and dicing data
The other thing that I want to show you, is there are a number of ways that I can slice and dice the data, to try to get a better notion of what’s going on with my schedule.
2 Changing color scheme to reflect a given criteria
One of the easiest ways of doing that, because humans are very good at looking at different color patterns and whatnot, is by changing some of my color scheme to reflect a given criteria.
2 Changing color of anything using mechanic resource requirement
So, I’m going to change the color of anything that uses a mechanic resource requirement. So, I select resource requirement from the set of properties available. Requirements contain, and then I’m just going to scroll down to mechanic, and pick that out.
3 Activities requiring mechanics
And you can see, in this particular case, almost all of my activities do, in fact, need mechanics. You can also see that a little bit by the various shift breaks I have going on here.
3 Activities not requiring mechanics
But there are a couple activities that don’t require any mechanics.
2 Conducting same analysis using different attributes
You can do the same basic analysis using a number of different attributes, which allows you to get a much better notion of why things schedule the way they did, and may potentially allow you to improve the schedule model to result in a better schedule.
1 Scheduling models efficiently
The thing that’s important to realize is that although the heuristics we use tend to produce extremely good schedules, some models are definitely harder to schedule efficiently than others.
2 Producing a shorter schedule
Clearly, if you have a long line of jobs, for example, all with predecessor constraints, Aurora can’t possibly produce a schedule that’s shorter than all of those jobs, one after the other.
However, if, through that sort of analysis, you realize that some of the relationships aren’t, in fact, necessary, and change the model, Aurora can then produce a much shorter schedule.
2 Domain-dependent schedule variation
Depending on domain, what is important, then, is schedule may vary quite a bit. For Boeing, how long the schedule is, is of primary concern. But in other domains, cost may be a driving factor, or resource availability, or a number of other things.
All of this should give you some flavor of what Aurora is capable of. I hope that you have enjoyed this presentation. Thank you for your time.