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

Introduction to Part 3

In this final installment of our three-part series on optimizing vehicle testing schedules with Aurora Hotshot, we focus on the specialized scheduling support and heuristic tuning that make the tool uniquely suited to the demands of destructive and non-destructive vehicle tests. While Part 1 introduced Aurora’s scheduling framework and Part 2 explored domain-specific interface and engine customizations, Part 3 highlights how Hotshot handles exclusive tasks, destructive tasks, and vehicle-constrained test series — challenges that often complicate manual planning.

We also share results from applying our Aurora scheduling solution to a real-world test schedule, demonstrating how the tool reduces vehicle requirements, increases utilization efficiency, and enables rapid “what-if” analysis. Together, these capabilities showcase Aurora’s ability to deliver measurable resource savings and faster planning cycles in even the most complex testing environments. Building on these earlier customizations, we now turn to the unique scheduling challenges of vehicle testing and the specialized solutions Aurora Hotshot provides.

Vehicle Testing Special Support

The vehicle testing scheduling had a few unusual aspects that required special handling in the scheduling framework: exclusive tasks, destructive tasks, and series of inter-constrained tasks.

Exclusive tasks represent tests that must be the first kind of test on a given vehicle. This means that they must be scheduled before anything else on a given vehicle, and nothing can be allowed to subsequently slip in before the exclusive task. Each exclusive task had a vehicle generated for it in the import phase, so the simplest way of handling this case is to schedule the exclusive tasks first in the scheduling process, and initially schedule them as early as possible so that nothing can schedule earlier in time.

Three plugins work together to accomplish this:

 

Preprocessor — Regardless of dominant scheduling direction, exclusive tasks must be set to always schedule forwards in the initial scheduling sweep.

Prioritizer — Exclusive tasks must always schedule first in the process, so that no other task will have the opportunity to schedule at the beginning of the target vehicle’s window of availability.

Postprocessor — The postprocessor is responsible for finalizing the schedule direction declared by the front end (discussed previously). When the dominant schedule direction is backward schedule, this step reschedules exclusive tasks backward, snapping them in just before the subsequent tests on the vehicle in question.

Destructive tasks represent tests that destroy the vehicle, so no subsequent tests may be scheduled later than the destructive task. Unlike exclusive tasks, destructive tasks do not have devoted vehicles. This has the advantage of allowing the system to dynamically determine which vehicle is most appropriate for a destructive task, but it also complicates scheduling support.

The basic approach is similar to that for exclusive tasks: schedule the destructive tasks backward early in the process in order to avoid conflicts. However, in order to prevent other tasks from sneaking onto the vehicle after the destructive task, the destructive task needs an additional placeholder. This placeholder locks the vehicle down from the end of the destructive task to the end of the test phase, so that nothing else can schedule the vehicle.

Two plugins work together to accomplish this:

 

Prioritizer — Destructive tasks must always schedule just after exclusive tasks in the process, so that extensive conflict resolution is not necessary to clear space for the destructive tasks.

Scheduler — The scheduler has two pieces of domainspecific functionality relating to destructive tasks. When the destructive task is performing an analysis of which vehicle to select, the default logic would simply check the destructive task’s desired window to make sure that the vehicle was available. In this case, the scheduler performs a secondary check to make sure that nothing is already scheduled to the vehicle later than the desired allocation window. Once the destructive task is scheduled, the scheduler schedules the placeholder to fill the time after the destructive task.

Vehicle-constrained test series are a series of tests that need to occur on the same vehicle. That is, once the first test selects from among the set of viable vehicles, all following tests in the series must select the same vehicle. This is a concept that occurs in other domains, especially manufacturing domains, but the vehicle-testing domain included this structural feature to an unusual degree.

The reason this complication made the scheduling more difficult is that usually each task is handled individually, checking resource availability individually. In a case like this, where a large number of tasks that are temporally constrained need the same resource, it is easy for the first task scheduled to select a resource that is unavailable for subsequent tasks.

To prevent this from happening—or to prevent a poor resource choice from causing significant conflict resolution problems—two strategies are used, supported by two plugins:

 

Preprocessor — When the tasks in question are exact-constrained (one must start as soon as the other finishes), a “follow-on” property may be used for easy look ahead. The preprocessor calculates what the “follow-on” duration should be for a given resource requirement, based on which requirement(s) have a constraint to use the same resource as another task. The preprocessor also marks the resource-constrained series (exact-constrained or otherwise) for special handling.

Scheduler — A special schedule method isolates the backtracking and search logic necessary to handle a series of tasks that are resource constrained where some are not exact-constrained, since in that case the “follow-on”-based look ahead is insufficient. This method schedules everything in the series in order, and maintains reasoning about which resources have proven problematic, in order to reduce the conflict resolution and search time.

Heuristic Tuning

Any new domain requires tuning of the heuristics that dictate scheduling order and resource selection. The most notable of these for vehicle testing was the heuristic and supporting maintenance relating to vehicle selection. The various tests are highly variable in terms of their degree of vehicle flexibility. Some tests can be run on dozens of vehicles; others on one or two.

In order to ensure that vehicles are selected appropriately based on vehicle availability and remaining tests, a vehicle load heuristic was added. This heuristic influenced both scheduling order (preferring to schedule tests with very limited vehicle options earlier in the process), and resource selection (preferring to schedule tests away from vehicles that had a large block of highly constrained tests that had not yet been scheduled).

Keeping the vehicle load information up to date and applying it effectively required adjustments to several plugins:

 

Preprocessor — Initialized vehicle load information based on all resource requirements and their options for all test tasks.

Prioritizer — Apply load information to detect cases where the choices for a test had narrowed dangerously, forcing a test to force-schedule.

Scheduler Quality Criteria — Apply load information to try to schedule away from vehicle bottlenecks when selecting vehicles.

Scheduler Post-Processing — Update load information based on scheduled selections.

Comparison

The starting point for the comparison between manual and automated planning was a small test schedule that had recently been created and carried out by the client. Planners at the client test facility manually converted the original schedule to the custom Aurora Excel model format. To provide a rough description of the scope of the scheduling model, it included 60 tasks. Of these tasks, 18 were destructive tasks and 1 was a destructive and exclusive task. The sum of the duration of the tasks is 680 days to be carried out over the 55 days allocated to the project.

The manually created schedule only contained vehicle resource constraints; it did not contain facility or personnel resource constraints. Similarly, the Aurora model contained vehicle resource constraints but not facility or personnel constraints. The test schedule called for 25 vehicles to be built, where the initial Aurora model contains 26 vehicles to be built. This overestimate on the number of vehicles required was done purposely to test the Aurora optimization process. The build pitch supplied to Aurora was the build pitch used to create the schedule. Given the build pitch and the number of vehicles, there would be 1105 possible workdays in the schedule and the initial vehicle utilization is 62%.

The resulting model of the testing process was then imported into Aurora and the optimization process run to create a schedule that minimizes the number of vehicles required to complete the test in the given timeframe. The model was used repeatedly to test and refine the domain-specific heuristics, aiming towards a known lower bound that was calculated for the number of vehicles required. The absolute lower bound of vehicles based on the task definitions was 22 vehicles, based on 19 destructive tasks and 3 tasks that require vehicle types not included in the destructive vehicles.

Results & Conclusions

When the actual test schedule was carried out, 25 vehicles were used to complete the tests and some of the tests went beyond the project deadline. Initially, Aurora created a schedule that required only 22 vehicles to complete the tests in the same timeframe. The 12% reduction in vehicles resulted in intense scrutiny of the scheduling model being imported into Aurora and planners discovered several errors such as missing constraints, too aggressive build pitch, and destructive tests marked as non-destructive. With the improved model of the actual schedule, Aurora was able to complete the schedule using 23 vehicles — an 8% reduction. The model withstood additional scrutiny and the resulting schedule equates to a measurable savings for this small test schedule.

Being able to generate a schedule in under two minutes as opposed to days of labor resulted in the side effect of being able to generate numerous “what-if” scenarios. Planners were able to quantify the effect of compressing or extending the schedule in terms of how many cars would be required. Planners also demonstrated the effects that steeper and shallower build pitches have on the number of cars required for a given set of tasks and project end date. The ability to quickly examine these types of effects will support planners in future test schedules in the task of presenting options with various tradeoffs among manufacturing resources, time, and number of vehicles required.