Aurora is a general-purpose scheduling framework that has been successfully applied in a wide range of settings, including aerospace, manufacturing, defense, and service industries. Aurora derives its success in such sectors from its ability to minimize the time and cost associated with large complex projects. The customizability of the framework allows the software to develop a valid schedule that reflects each domain’s specific preferences and constraints. In all domains, the software quickly solves a complex scheduling problem (generally in less than two minutes) and produces a schedule that is significantly better than those reached by previous methods.
The following poster from 2018 provides an overview of some of Aurora’s complex scheduling decision capabilities. Text from the poster is provided below with references to further information. Note that Aurora’s capabilities have continued to be enhanced since 2018 and further improvements are an ongoing process.
Let’s take a look at a scheduling model so we can establish a better understanding of what kind of information Aurora typically works with.
To begin, there are typically a set of tasks that need to be completed and constraints that need to be considered. It is important to take note of the fact that some constraints interfere with and/or overlap one another, which adds another layer of complexity.
Aurora combines graph analysis with heuristic scheduling techniques to quickly produce an effective schedule based on this defined set of tasks and constraints.
Tasks: Jobs that need to be completed, e.g., InstallCockpitDoor.
Constraints: Limitations on when a task can be completed. E.g.
The framework distills the various operations involved in creating a schedule that respects all of these constraints into reconfigurable modules that can be exchanged, substituted, adapted, and extended. This framework acts as a foundation for creating scheduling tools that respect domain-specific constraints and use heuristics tuned to each domain to ensure a high-quality schedule.
The scheduling framework consists of two primary components: the engine and the user interface. The scheduling engine is responsible for creating an explanation for each task, describing why the task was placed in its particular position (which includes both time and resources) as the schedule is created. The user interface is responsible for presenting the explanation to the user and helping them understand why a task was scheduled here and not there. This information helps direct the user’s attention to the driving constraints and supports carrying out what-if analysis on how changing these specific constraints might improve the schedule.
The Aurora scheduling engine generates explanations for each of its decisions, which is especially helpful when trying to understand why certain tasks were scheduled in a particular way. Ultimately, schedulers across a variety of real-world domains often ask: why was a task scheduled here and not there? The transparency to see why inspires greater confidence in the results and facilitates understanding of how constraints affect the schedule, enabling the user to further improve the schedule by assessing specific constraints.
The scheduling order determines when a task is given a chance to schedule relative to the other tasks, where it will be placed in the first available time slot in which all of its constraints can be satisfied. An explanation is composed of multiple text descriptions that describe the decisions made and why they were made leading up to the assignment of a task to a particular time and set of resources.
In the initialization phase, the Prioritizer assigns the schedule order, which is an integral part in understanding why scheduling decisions are made. Initial constraints are also applied to each task by the Preprocessor in this phase. For example, one constraint is that a task’s late end date (the date it must be finished by) can be no later than the project end date. This constraint narrows the schedule window and is recorded in the explanation.
The scheduling phase adds to the explanation in two ways. First, constraint propagation is applied before any tasks are scheduled and again after each task is scheduled. The temporal, calendar, and resource constraints (and their interactions) will further narrow the early start dates and/or late end dates of each task. Any time the scheduling window is narrowed an explanation is recorded, as seen in lines 3-5 in the explanation field. Second, when a task reaches the front of the scheduling queue it will be placed at the first available time that meets all of the constraints. If this time does not match the early start date, then the constraints responsible for the delay are recorded in the explanation. Lines 6 and 7 in the explanation field were generated when the task was actually scheduled. Finally, in the finalization phase the Postprocessor may move scheduled tasks and record the reason in the explanation. This supports domain-specific finalization of schedules.
Please enter your contact details, company name and a short message below and we will answer your query as soon as possible.
Contact Us