High-Level Introduction to Aurora Timestamps

00:00               Overview of Aurora

Aurora is a sophisticated scheduling system that was designed for easy customization. Stottler Henke has successfully applied it to a number of disparate domains. Everything from NASA space station processing preparation, to missile intercept scheduling, to airplane assembly scheduling and shipyard scheduling.

00:26               Scheduling Problems

Scheduling problems in general are highly variable and an out of the box scheduling system rarely performs very well. Aurora was designed to help satisfy this lack in general scheduling systems.

00:42               Overview of Demonstration

00:44               Reference to high-level overview of the various objects involved in scheduling

00:50               Reference to very small sample of the way scheduling system works

00:56               Reference to much larger scheduling sample

1:22                 Overview of various objects involved in scheduling

To start off, I would like to give an overview of the various objects involved in scheduling.

1:28                 Basic unit involved in scheduling (Compound Task) (Radar installation))

1:38                 Subtasks (Atomic tasks (activities))

1:46                 Resource Definitions

1:49                 Given Duration

1:51                 Given Name

1:53                 Assumption of Single set of resources for full lifespan

The assumption is that an activity has a single set of resources for its full lifespan. This allows the user a great deal of flexibility, but also gives an atomic unit on which to build the schedule.

2:08                 Ways of constraining the schedule

2:14                 Resources

One of the primary ways is through resources. A resource is something that is needed in order to accomplish a given activity.

2:21                 Modeling resources

Usually you only model those resources that could potentially constrain schedules. You wouldn’t, for example, model a paper clip. You mainly model large things, expensive things; dry docks, equipment, personnel, things that you can’t get more of at the drop of a hat.

2:41                 Resource Characteristics

Resources have a number of characteristics

2:44                 Resource Attributes

and attributes that influence the way in which they schedule,

2:48                 Resource sets

and you can also group resources into resource sets.

3:12                 Simple example: Large dry docks

Now, various resources have a huge number of attributes that indicate when they could be used for what purpose. It’s not always practical to model all of those attributes, and so resource sets give the user a very easy way to define which resources are interchangeable in a given context. In this particular example, you have large dry docks, which were made up of all the large dry docks, or you also have a large dry dock with crane set which only includes two of the large dry docks.

3:25                 Adding a crane attribute to all dry docks

Now, I could have done this by adding a dry dock attribute to all dry dock… Excuse me, a crane attribute to all dry docks. However, that would involve a very specific attribute for which I would have to add some logic on the back end indicating how it should be used.

3:43                 Defining resource sets

Instead, the user can simply define two resource sets, indicating that in one context with an activity that needs both a large dry dock with crane, these two are interchangeable and that in another context with an activity that only needs a large dry dock, these three are interchangeable. This gives the user a tremendous amount of flexibility without having to meddle with back end logic.

4:09                 Defining activities

Activities, as I mentioned before, are the atomic unit involved in scheduling. Now, these activities here are basically templates for the activities that are actually defined as part of the compound activity in the scheduling problem. The reason you may want to define these here, is, first, they can derive off of each other. So, if you have a standard type of activity, you can define some of its resources in a single place. The other reason you may want to define activities here is so that you can reuse them over and over again. For example, pre‑work inspection will be used with almost any sort of shipyard task.

4:59                 Calendars

Finally, you have calendars. Now, in this particularly simple example, I don’t have any calendars to find. However, if I slip over just for a moment to the much more complex example that I will be addressing later, we do have a calendar. Calendars define when various things can happen.

5:20                 Calendar 1

So, this particular calendar, calendar one, basically defines a standard factory shifting structure. Now, here it’s defined as seven days a week. Normally, it would actually be defined as five days a week. You can see how this displays updates to indicate when I can do what work. So, the calendar basically indicates when things can happen.

5:46                 Calendars identified with activities

Calendars can be identified with activities, which basically indicates that that specific activity has a limited window of opportunity.

5:55                 Calendars defined with resources

5:57                 With Personal Resources

6:00                 With equipment resources

6:03                 Calendars defined with compound task itself

or they can be defined in association with the compound task itself, and that would indicate that overall there is sort of a standard project schedule, if you will.

6:12                 Cross-referencing calendars

Those three calendars sources are cross-referenced in the scheduling process to make sure that things only schedule when the full calendar indicates they can.

6:28                 Associating resources with activities

In terms of associating resources with activities,

6:33                 Resource requirement sub-tab

all activities have this resource requirement sub‑tab that allows you to add one or more requirements.

6:41                 Require a specific resource directly

You can either require a specific resource directly if you know exactly which one you want,

6:48                 Request one element or multiple elements out of a resource set

or, more commonly, you would request one element or multiple elements out of a resource set.

6:54                 Associate different atomic activities, using constraints

You can also associate different atomic activities with each other using constraints.

7:00                 Pre-work inspection-two successors

So, in this particular case, pre‑work inspection has two successors ‑‑ these two elements. I can gain more detailed information about the constraint by looking at this.

7:11                 Finish equals start constraints

In this particular case, it’s a finish equal start, which means that the shipyard processing has to start as soon as pre‑work inspection is finished.

7:21                 Finished less than or equal to start constraints

A more common sort of constraint is finished less than or equal to start, which is a standard predecessor constraint. It basically means that once pre‑work inspection is done, at some time after that, I can start the large equipment installation.

7:39                 Concluding Remarks

That covers the basic types within Aurora. I’m now going to run the demo involving this smaller sample file. That’s going to be in another recording and that will be followed by a third recording that will cover the scheduling of this much, much larger scheduling problem.