A Schedule Optimization Tool for Destructive and Non-Destructive Vehicle Tests Part 1

Introduction

Vehicle testing is an essential part of building new cars and trucks. Whether an auto manufacturer refreshes an existing model or builds a new one, the model will undergo hundreds if not thousands of tests. Some tests are exciting, such as rolling a car over at speed and measuring the impact on the crash-test dummies. Other tests are not quite as sensational but still important, like testing the heating and air conditioning system.

What these tests have in common is that they are generally carried out on custom-made vehicles because the new factory lines for the model do not exist yet. These custom-made vehicles each cost as much as an ultra-luxury Bentley or Lamborghini, which results in pressure to reduce the number of vehicles. There are two additional complications with the test vehicles. First, the custom made vehicles take time to build and are not all available at once but become available throughout the testing process based on the build pitch of the test vehicles. An example of this is one new test vehicle being made available each weekday. Second, there are many particular types of a model and each test might require a particular type or any of a set of types (e.g., any all-wheel-drive vehicle). There may be dozens of types of a particular vehicle model to choose from, varying by frame, market, drivetrain, and trim.

At the same time, market forces dictate when new or refreshed models must be released. The result is an equal pressure to complete testing by certain dates so model production can begin.

Finally, testing personnel and facilities are limited resources that work with several models simultaneously. For example, it would be desirable to schedule all of the crash tests at the very end of the project so other tests could be carried out on those vehicles first. However there aren’t enough crash labs or personnel to support this so the crashes must be staggered throughout the project.

The work presented in this blog is extracted from a previously published paper titled “A Schedule Optimization Tool for Destructive and Non-Destructive Vehicle Tests” co-authored by Jeremy Ludwig, Annaka Kalton, and Robert RIchards of Stottler Henke, alongside Brian Bautsch, Craig Markusic, and J. Schumacher, including the references therein.

Only touching on the first half of the paper, our goal is to describe how Aurora, an existing intelligent scheduling software framework, was modified to include domain-specific algorithms and heuristics used in the vehicle test planning process. The framework combines graph analysis techniques with heuristic scheduling techniques to quickly produce an effective schedule based on a defined set of activities, precedence, and resource requirements. These heuristics are tuned on a domain-specific basis to ensure a high-quality schedule for a given domain. The resulting domain specific scheduler is named Hotshot.

The result of this work is a system that optimizes the overall given test schedule in order to complete the work in a given time window, Aurora-VT. The schedule optimization process includes determining which vehicle types are built and the order in which they are built to minimize the total number of vehicles required for the entire test schedule. Results are presented that show a reduction in required test vehicles compared to manual scheduling of the same tasks as well as increased capability to ask “what-if” questions to further improve the schedule.

In the remainder of this blog, we first discuss related work. Following this, we describe the Aurora scheduling framework and the changes made to create the domainspecific Hotshot scheduling tool. In part 2, we will provide a comprehensive overview of the methods and results sections, containing the details of our comparison between an existing schedule created manually and one created with the Hotshot tool.

Background and Related Work

Despite the invaluable role played by scheduling software in a number of industries, the cost and expertise involved in creating a system suited to each new area has restricted the adoption of such tools. Unfortunately, although there are a variety of high-quality customized scheduling systems available, off-the-shelf systems rarely fulfill the scheduling needs of any one domain. This is, in large part, because domain knowledge is crucial to the efficient and effective solution of scheduling problems in general.

The result of this is that the industries/domains that realize the advantages afforded by intelligent scheduling systems are either those that can afford a full custom solution, or those that fall within the narrow commercial off-the-shelf domain coverage (e.g., for project planning).

To make scheduling software attainable by a broader audience, it must be possible to create new scheduling systems quickly and easily. What is needed is a framework that takes advantage of the large degree of commonality among the scheduling processes required by different domains, while still successfully expressing their significant differences, i.e., with parts of the scheduling process broken out into discrete components that can easily be replaced and interchanged for new domains.

Aurora is one example of an implemented scheduling framework, which distills the various operations involved in most scheduling problems into reconfigurable modules that can be exchanged, substituted, adapted, and extended to accommodate new domains.

The artificial intelligence and operations research academic communities continue to investigate and report the benefits of heuristics as part of improving scheduling results. Aurora, to more quickly find a good schedule, leverages both domain independent and domain-dependent heuristics in addition to leveraging the hierarchical model of components.

The Unparalleled Flexibility of the Aurora Scheduling Framework

Aurora was designed to be a highly flexible and easily customizable scheduling system. It is composed of a number of components that can be plugged in and matched to gain varied results. The scheduling system permits arbitrary flexibility by allowing a developer to specify what components to use for different parts of scheduling. Aurora has been successfully applied in a number of domains.

While the general scheduling process used by Aurora is applicable to most scheduling domains, by plugging in different versions of the components, the developer can produce widely disparate scheduling engines. The base scheduling framework is a foundation on which a number of different systems can be constructed. The steps in the scheduling process are described in detail below. All configurable elements are shown in bold. Elements that were modified for the test vehicle domain will be discussed further in later sections.

What Does the Scheduling Process Look Like? 

Let’s deep dive into this three-step process:

Schedule Initialization

1. Aurora undoes any previous post-processing (to get back to the “true” schedule result state), and applies the Preprocessor to the schedule information.
2. Aurora uses the Queue Initializer to set up the queue that will be used to run the scheduling loop. A standard Queue Initializer puts some or all of the schedulable elements—activities, flows, and resources —onto the queue.
3. The queue uses the Prioritizer to determine the priority of each element. Depending on the execution strategy, these priorities may be used to periodically sort the queue, or to schedule the element with the highest priority at each stage. Note that some priorities may change in the course of scheduling.
4. The Schedule Coordinator triggers the scheduling of the elements on the queue by starting the Scheduling Loop. In many cases, a more complex element will recursively set up and execute its own queue, allowing greater control over the scheduling process.

Scheduling Loop 

1. A schedulable element (task, project, or resource) asks the Scheduler to schedule it.
2. The Scheduler calls constraint propagation on the schedulable so as to be sure that all of its requirements and restrictions are up to date.
3. The Scheduler looks at the element, considers any Scheduling Method that is associated with it (e.g., Forward, Backward). A Scheduling Method determines how the system goes about trying to schedule an element. The Scheduler also selects which Quality Criterion to associate with the selected scheduling method; the Quality Criterion determines what makes an assignment “good.”
4. The Scheduler calls the Schedule Method on the schedulable. The process depends a great deal on the Schedule Method, but the result is that the schedulable element is assigned to a time window and has resources selected to satisfy any resource requirements. It also returns a list of the conflicts resulting from the given assignment.
5. The Scheduler calls constraint propagation on the schedulable (again) in order to update all of the neighbors so that they are appropriately restricted by the newly scheduled element. This process may result in additional conflicts; if so, these are added to the list of conflicts from scheduling.
6. The Scheduler adds the conflicts to the Conflict Manager, and asks the manager to attempt to resolve those conflicts.

Schedule Finalization

1. When the queue is empty, Aurora goes through a final conflict management step. The conflict management that occurs during scheduling is primarily local conflict management (it looks at ways of fixing the current conflict, but does not consider the broader context). In this step Aurora applies the same Conflict Manager, but this time it tries to solve all remaining conflicts, and the attempts may have more far-reaching consequences (e.g., instead of shuffling 2–3 elements, it may try to shuffle 6–7).
2. Aurora calls the Postprocessor on the schedule, so that any additional analysis may be done before Aurora returns the schedule results.
3. Aurora sends the schedule results to the GUI for display.

Conclusion

The Aurora scheduling framework represents a powerful step forward in how complex scheduling challenges are approached across industries, particularly in automotive testing. Traditional scheduling methods often falter when faced with the resource constraints, varied test requirements, and strict deadlines that characterize vehicle development projects. By contrast, Aurora leverages a modular design, advanced heuristics, and domain-specific customization to produce schedules that are both practical and optimized. This flexibility ensures that organizations can adapt the framework to unique operational demands while maintaining consistency in schedule quality.

What sets Aurora apart is its ability to balance efficiency with adaptability. Instead of relying solely on manual planning or rigid off-the-shelf systems, Aurora empowers developers to configure its components—such as the scheduler, prioritizer, and conflict manager—to meet domain-specific needs. For vehicle testing, this has translated into tangible benefits: minimizing the number of costly custom-built vehicles, reducing scheduling conflicts, and enabling “what-if” scenario exploration that gives project managers more confidence in their decisions. These features not only save time and resources but also create space for innovation in how projects are executed.

Beyond the automotive sector, the Aurora scheduling framework has the potential to impact diverse industries that face similar constraints, from pharma production to aerospace. As organizations continue to demand faster results without sacrificing quality, Aurora provides a proven foundation for building customized solutions that grow with evolving needs.