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

Introduction to Part 2

This blog is part 2 of our series on optimizing vehicle testing schedules using our Aurora Hotshot scheduling tool. In last week’s post, we introduced the core capabilities of the Aurora scheduling framework and how it was adapted to meet the unique demands of the vehicle testing domain. This follow-up dives deeper into the domain-specific customizations made to both the user interface and scheduling engine — including support for exclusive and destructive tasks, build pitch constraints, and advanced optimization techniques designed to minimize the number of test vehicles required.

Domain-Specific Customization

Two different types of modifications were made to the Aurora framework to create the Hotshot tool. First, the user interface front end was modified to import the testing model, display and edit domain-specific properties, and to perform the optimization to minimize the number of required vehicles. Second, components in the scheduling back end were updated specifically for this domain.

User Interface Customization 

There are five features added to the general scheduling user interface that are specific to the vehicle test domain:

• import an Excel model of the testing problem,
• view and edit build pitch,
• view and edit vehicles and build order,
• minimize the number of vehicles required, and
• export the schedule to a client-specific format.

The first four of the features will be described in greater detail.

The starting point of the Aurora customization for the vehicle testing domain is importing the testing tasks, resources (vehicles, personnel, facilities), resource sets (groups of vehicles), resource requirements, constraints (temporal, sequence, and resource), build pitch information, and calendars from a set of Excel spreadsheets. These Excel spreadsheets represent a model of the overall testing problem. Once imported, the general user interface supports graphically viewing and editing most of the model elements such as tasks, resource requirements, resources, resource sets, constraints, and calendars. Changes were made to support task properties specific to this domain. For example, tasks that render the vehicle useless for future testing are marked as destructive and tasks that must be performed on a vehicle before any other tests are marked as exclusive.

A Build Pitch dialog was added for viewing and editing the general build pitch per week (number of vehicles that can be built) as well as a maximum build pitch for each vehicle type. For example, 10 test vehicles per week can be built, but only 5 all-wheel-drive can be built in a week.

A Manage Vehicles dialog specifically for managing the vehicles was also added. This dialog is used to manually change the vehicle build order as well as to manually create and remove vehicles. Vehicles with a flexible start date will be assigned a build date based on the assigned build order. Build dates are assigned based on the build order, moving from 1 to n and selecting the first available date that meets two criteria:

• number of vehicles/week is not exceeded and
• vehicle type per week is not exceeded

The build order will be assigned automatically during the optimization process.

The Optimization Dashboard is used to minimize the number of vehicles required to schedule the testing tasks (Figure 1). The upper left summarizes the current state of the schedule, showing the number of vehicles required, the number of destructive and exclusive tasks, and the utilization of vehicles in the testing schedule. The upper right shows the current status of optimization, which will change once the Start button is pressed.

This portion of the dialog also provides an estimate of how long the remaining optimization will take. The central portion of the dialog contains the four parts of the optimization process. Check boxes allow advanced users to selectively turn off part of the optimization process, but these should generally all be turned on in normal use. Buttons for starting and controlling the optimization are found along the bottom of the dialog.

There are four steps in the optimization process:

1. Set Backward Schedule. Mark all tasks to be backward scheduled. This means that the schedule will be created from the end of the project to the front, with all tasks scheduling as close to their late end dates as possible.
2. Date Optimizer. Once the tasks are backward scheduled, look at the vehicles and assign build order based on how early tasks are assigned to vehicles. That is, if the first task assigned to Vehicle A starts on Jan 15 and the first task assigned to Vehicle B starts on Jan 18, then A will come before B in the build order. The heuristic is that vehicles that are needed earlier should be built earlier.
3. Meta Disabler Optimizer. For each non-exclusive vehicle, temporarily disable the vehicle and try to create a schedule without the vehicle. If this succeeds, permanently delete the vehicle. If this fails, restore the vehicle and continue. Only non-exclusive vehicles are tested because every exclusive vehicle is required by one task. Vehicles are checked for disabling by starting with the vehicles with the greatest available time and working towards those with the least available time.
4. Set Forward Schedule. Return each task to forward schedule mode, where all tasks try to schedule as close to the project start date as possible. However, it will still be the case that (i) exclusive tasks will remain the first tasks assigned to an exclusive vehicle and (ii) destructive tasks will be the last tasks assigned to an exclusive vehicle.

At the end of each scheduling run, the vehicle utilization is calculated. This is the sum of the duration of all the tasks assigned to a vehicle divided by the total days available for each vehicle from creation to project end.

Scheduling Component Customization

The scheduling component customization focused on three central areas:

• scheduling direction maintenance,
• special handling for vehicle testing’s unusual requirements, and
• more standard heuristic tailoring for the domain.

Each area is discussed in a section below along with the impact on the scheduling plugins. Impacted plugins are noted in italics.

Scheduling Direction Management

The dominant scheduling direction is backward scheduling for most of the optimization cycle, and forward scheduling at the end of the optimization cycle. This presents a challenge because if a conflict-free schedule can be found for one direction, then a conflict-free schedule should also be found for the other direction. This is challenging given the NP-complete nature of the scheduling problem. Just because there is a solution, there is no guarantee that the system can find the solution coming at the problem from a different direction.

This would be less problematic for a less constrained domain. However, between the domain-specific complications (discussed below), and the fact that the optimization process is iteratively reducing the solution space, without supplemental logic the system would frequently encounter conflicts when forward scheduling even though there were none when backward scheduling.

The solution in this case is to always backward schedule first, given that that is the dominant scheduling direction for optimization. Once the system has backward scheduled successfully, it then iteratively forward schedules in date assigned order such that it can derive a conflict-free forward schedule from the backward schedule. This may not produce as tight a forward schedule as is theoretically possible, but provides a consistency guarantee that would not otherwise be possible.

This logic is handled by alterations to two plugins:

Preprocessor — All tasks (except exclusive tasks, discussed below) are marked to backward schedule, regardless of the current dominant schedule direction. The schedule direction requested by the front end is cached so that the postprocessor can restore it.

Postprocessor — This attempts to move tasks earlier within the limits of their temporal constraints and vehicle availability dates, starting with earlier tasks and iterating through the schedule in date order. Unrelated tasks remain scheduled while the target tasks and their tightly constrained neighbors are moved; this is done to ensure that a conflict-free schedule is maintained.

Conclusion

These domain-specific enhancements to both the user interface and scheduling engine enable the Aurora Hotshot tool to handle the unique complexities of vehicle testing with increased precision and efficiency. From build pitch management to minimizing vehicle usage through intelligent optimization, these innovations represent a significant step forward in automated test scheduling. In part 3 of this series, we’ll dive into how the tool handles some of the most challenging aspects of vehicle test scheduling — including exclusive and destructive tasks, vehicle-constrained test series, and heuristic tuning. We’ll also share real-world results from applying Aurora to an actual test schedule, revealing how these optimizations translate into measurable resource savings and faster planning cycles.