The scenario begins on day D+0, as the Cyberland deployment is about to get underway. A feasible schedule has already been developed, but we receive a forecast of severe weather that will close a needed airbase. By using DITOPS/Visage to predict the impact of this closure, we learn that some vital munitions will arrive in theater late.
We develop a partial solution to this problem by sourcing these munitions from an alternative airbase. This eliminates much of the lateness, but some lateness still remains. I.e., the alternative airbase is farther away, so additional lift is needed.
To develop a complete solution, we first determine the additional lift that is needed by the late munitions. We then locate a different unit of equivalent tonnage, and allow it to arrive in theater early (by changing its EAD constraints), thus making additional lift available on the days when the vital munitions must move.
We also develop an alternative complete solution, in compliance with the original EAD constraints, by having DITOPS/Visage determine how many additional planes would be needed in order to make the vital munitions arrive ontime.
On day D+0, the Cyberland deployment is about to get underway. We have already developed an initial feasible deployment schedule (i.e., all shipments will arrive on time).
Figure 1: The DITOPS user-interface shows the flight schedule for the feasible deployment. Time runs along the x-axis, and tail numbers appear along the y-axis. Each blue bar represents a flight into theater. The left and right edges of a bar denote the flight's departure and arrival times. The height (thickness) of a bar denotes the percentage of the plane's carrying capacity that is being utilized on that flight.
In this schedule, most flights are nearly 100% full, but the last flight involving plane C141B-0011 is less than 30% full. The color of a bar indicates whether that flight is delivering any cargo later than its required delivery date...such flights would appear as red bars, instead of blue.
Figure 2: The DITOPS user-interface also shows the airport utilization for the feasible deployment. Time runs along the x-axis, and airports appear along the y-axis. The height of the blue bars shows the percentage of an airport's handling capacity being utilized at a particular time. In this schedule, airports utilize no more that 50% of their handling capacity.
Figure 3: The Visage user-interface shows an analysis of the feasible deployment. The analysis summarizes what shipments are arriving in theater each day. The top chart shows the number of people arriving, and the bottom chart shows the weight of material arriving in "short-tons" (a.k.a. "stons", 1 ston = 2000 lbs, in contrast to the heavier metric ton = 1000 kg ~= 2200 lbs).
We are informed that an ice storm will hit Hill AFB in 24 hours, and it will shut down Hill for 3 days (from the start of D+1 to the start of D+4).
According to the JFACC IFD 2.0 "overall" scenario, we are informed of this event via the METOC weather desk. For standalone purposes, we just assume that someone tells us directly.
We use DITOPS/Visage to predict the impact of this closure.
Figure 4: We use a "Find Port" frame to retrieve "Hill AFB" from the Visage data repository.
In general, the subwindows of the Visage user-interface are called "frames". The frame that is labeled "Visage-DITOPS Frames" is called the "frames palette", and it contains "tear-off" icons. The "Find Port" frame was created by grabbing the "Find Port" tear-off icon with the mouse, and then dropping the icon into position, where it expanded into a frame.
Also, visualizations of data objects in the Visage user-interface are called "elements" (e.g., the string "Hill AFB" in the "Find Port" frame). An element can be grabbed with the mouse, copied, and dropped into a different frame, in order to shuttle its underlying information into a new interface. This drag-and-drop technique is at the heart of Visage's "info-centric" approach to user-interfaces, which makes information
Figure 5: We use a "DITOPS Port Editor" frame to zero-out the port capacity of Hill AFB on the impacted days. First, we tear-off a "DITOPS Port Editor" frame. Next, we drag "Hill AFB" from the "Find Port" frame, and drop it into the "DITOPS Port Editor" frame. We then edit the capacity curve, and finally click the "Commit" button to transmit the change in capacity to DITOPS.
Figure 6: The change displays a grey band within the airport utilization graph on the DITOPS workstation. The 5 red stripes indicate 5 schedule conflicts.
Figure 7: We click the "Reschedule" button in the "DITOPS Collaborator VD2" frame, which tells DITOPS to reschedule the 5 conflicting flights to occur after Hill reopens.
Figure 8: We see the result of the rescheduling. The 5 red stripes have disappeared from the airport utilization graph...the airport conflicts have been resolved. However, because of the delays involved, some of the cargo that is being moved on these flights is now scheduled to arrive late, as indicated by the red bars in the DITOPS flight schedule.
We now use Visage to identify the late cargo.
Figure 9: The updated analysis graph shows that late cargo is arriving in theater on days D+5 and D+6 (the red vertical-bars).
Figure 10: We tear-off a "TPFDD Edit" frame, and drag-and-drop the late cargo into it (i.e., we drag-and-drop the red vertical-bars). The late cargo appears in the new frame as the strings "for 005" and "for 006" (i.e., the late cargo that is arriving on days D+5 and D+6). Then, we drill-down into the members of these "aggregates", in order to identify the individual move-requirements that are late.
In general, Visage provides a consistent suite of tools that allow the user to aggregate and decompose data.
Figure 11: We see that the late cargo consists of 9 AGM-88 Stamp Packages (standard munition packages). The "TPFDD Edit" frame shows schedule information about each move-requirement on the y-axis. Time runs along the x-axis.
The schedule constraints for each move-requirement are shown as follows:
orange triangle - the ALD (available to load date). This is the date that the cargo is "ready to go" at the POE (port of embarkation).
yellow band - the window for arrival in theater. The left triangle is the EAD (early arrival date) at the POD (port of debarkation). The right triangle is the LAD (latest arrival date) at the POD.
light blue rectangle - the RDD (required delivery date) at the DEST (deployment destination).
Detail - All of these constraints have a 1-day granularity. I.e., loading/arrival/delivery at *any* hour of that day will satisfy the constraint. If several constraints (e.g., LAD and RDD) are equal, then they will be "squeezed" into the same "day" on the graph, but the constraints will still have a 1-day granularity (*not* 1/2-day!).
The actual movement of the cargo is shown as a narrow horizontal bar, either dark blue or red in color. The left end of the bar indicates the time of embarkation from the POE, and the right end indicates the time of debarkation at the POD. The color of the bar indicates whether the cargo is ontime (dark-blue) or late (red). We can see that these Stamp Packages are all arriving late. Detail - Movement times have a 1-hour granularity.
We don't have the air operations plan that we are trying to support at our disposal. But, if we did, we would be able to detect that there is now a shortfall of AGM-88 munitions. I.e., if we cannot get some AGM-88's into theater sooner, our air operations plan will no longer be supportable.
We are informed that we can alternatively source these AGM-88 munitions from Darby (in Italy), and we use DITOPS/Visage to analyze the options that this opportunity presents.
According to the JFACC IFD 2.0 "overall" scenario, the "Force Support Planner", a Synergy-supplied tool, would somehow determine that Darby can provide AGM-88 munitions, and asks DITOPS/Visage to analyze this opportunity. For standalone purposes, we just assume that someone tells us directly.
Figure 12: We tear-off a "Find Port" frame, and retrieve the Darby storage facility from the Visage data repository.
Figure 13: We tear-off a "POE Changer..." frame, and drag-and-drop the "CP DARBY" storage installation into it. (The other element represents an army installation ("AIN").)
Figure 14: We drag-and-drop all of the late move-requirements into the "POE Changer..." frame. This re-sources the move-requirements from Camp Darby.
Figure 15: Using the TPFDD Editor, we confirm that the move-requirements are now being sourced from Camp Darby (note the "CP DARBY" element).
Figure 16: We drag-and-drop all of the late move-requirements onto the "Load DITOPS" button in the "DITOPS Collaborator VD2" frame. This will download the re-sourced move-requirements into DITOPS.
Figure 17: We see that the re-sourced move-requirements are unscheduled by DITOPS, and the corresponding (red) flights are erased from the flight schedule on the DITOPS workstation.
Figure 18: We click the "Reschedule" button in the "DITOPS Collaborator VD2" frame, so that DITOPS reschedules the re-sourced move-requirements.
Figure 19: We see that some of the late flights have been eliminated, as indicated by fewer red bars in the DITOPS flight schedule. But due to the longer travel time needed to reach Darby, we still cannot get all of the required munitions into theater by their required dates using the lift-assets (planes) previously allocated.
Figure 20: We make a copy of the "TPFDD Edit" frame with 9 late Stamp Packages, to serve as a record of the original severity of the problem. We then refresh the upper "TPFDD Edit" frame to reflect the new schedule. We see that there are still 3 late Stamp Packages, so we still need to perform further analysis.
In general, Visage allows the user to effortlessly create a copy of any frame, with the copy having the same interface functionality as the original.
If we could free-up some additional lift, we might be able to get the remaining late munitions into theater by their required dates. We can accomplish this by identifying and adjusting the constraints of some other, "less critical", move-requirements.
Figure 21: First, we determine how much additional lift is needed to move the late munitions. We tear-off an "Outliner" frame, and drag-and-drop the remaining late move-requirements into it. We then display the "total_weight" attribute, and see that we need to free-up about 30 stons of lift capacity to accommodate the late munitions.
Figure 22: In order to reallocate lift, we need to consider the cargo as it is being shipped-out from the POE. We use the "TPFDD CDay Analysis" frame to see that the late cargo ships-out on days D+4 and D+5. If we can ship it on the morning of day D+3, it should get to theater on time, so we decide to analyze the large batch of cargo that is scheduled to ship-out on day D+3.
Note - the attribute name "pod_est" is a database typo...this attribute actually contains the "poe_est" (the Earliest Start Time that a unit will ship-out of the POE).
Figure 23: We tear-off a "Weight" frame, drag-and-drop the large batch of D+3 cargo into it, and decompose the batch into individual move-requirements. We locate five requirements that move an appropriate amount of tonnage (i.e., more than the needed 30 stons, but not *too* much more).
Figure 24: We tear-off a new "TPFDD Edit" frame, and drag-and-drop the five candidate move-requirements into it. We see that 2 of the 5 move-requirements are actually available to load on day D+0 (as depicted by the orange triangles), but are prevented from arriving in-theater until day D+2 because of EAD constraints ("earliest arrival date", as depicted by the left yellow triangles). If we "relaxed" these EAD constraints, then these movements might be scheduled earlier, possibly freeing-up lift-assets for the munitions on day D+3. We decide to try relaxing the EAD of the "ARS 08 KC135R" move-requirement.
Figure 25: We drag the EAD constraint from day D+2 to day D+0, and lock-in the change by clicking the "commit" button.
Figure 26: We drag-and-drop the "ARS 08 KC135R" move-requirement onto the "Load DITOPS" button, so that DITOPS unschedules this move-requirement and downloads its new EAD. We also drag-and-drop the three late Stamp Packages onto the "Load DITOPS" button, so that DITOPS unschedules them. Finally, we click the "Reschedule" button.
Figure 27: We see that everything (all munitions and other changed move-requirements) is arriving ontime. [We see the red flights disappear from the DITOPS flight schedule, and new "blue" flights appear.]
We now have one option...namely, we can get the AGM-88 munitions from Darby into theater in time to support our air operations plan *if* we allow ARS 08 KC135R to arrive early.
Perhaps it is not acceptable (for some reason) to allow ARS 08 KC135R to
arrive in theater ahead of its original EAD constraint, or perhaps we
simply want to present an alternative option to the commander. So, let's
change the required dates for ARS 08 KC135R back to their original values,
and then explore another option.
Figure 28: We drag the EAD constraint back to day D+2 and click the "commit" button.
Figure 29: We drag-and-drop the "ARS 08 KC135R" move-requirement onto the "Load DITOPS" button and click the "Reschedule" button.
Figure 30: We see that it is not possible to schedule "ARS 08 KC135R" on time according to its original dates (as expected)...this move-requirement is now scheduled to arrive a day or so late. [In the DITOPS flight schedule, we now have "red" flights again.]
Figure 31: To develop an alternative option, we ask DITOPS how many additional lift-assets it would take to get ARS 08 KC135R into theater on time again. We use the DITOPS interface to instruct the scheduler to add additional C141B planes as needed.
By setting the "Due date" slider (at the top) all the way to the left, we are indicating that the due date is not relaxable. Before, the scheduler was configured to relax deadlines if all constraints could not be satisfied. We have changed that assumption; now all deadlines must be met.
Instead, we are allowing the scheduler to add additional lift-assets as necessary to meet all required dates. In essence, we are asking the scheduler how many additional C141B's it will take to close the schedule on time.
Figure 32: Once again, we drag-and-drop the "ARS 08 KC135R" move-requirement onto the "Load DITOPS" button and click "Reschedule".
Figure 33: We can see in the "TPFDD CDay Analysis" frame that everything
is now ontime.
Figure 34: Finally, we can see that one additional C141B has been added (highlighted in orange) to the deployment in the DITOPS flight schedule.
So, we now have two alternative solutions that get the AGM-88 munitions from Darby into theater ontime, in order to support our air operations plan.
(1) We can allow ARS 08 KC135R to arrive early. -or-
(2) We can add one additional C141B to our set of lift-assets.
We've shown how Visage supports flexible navigation and exploration of information, using techniques such as aggregation, drill-down, and visualization in a drag-and-drop environment.
We've also shown how to make powerful use of DITOPS's ability to perform reactive scheduling under a variety of different constraint configurations.
Finally, we've illustrated the type of iterative scheduling process that DITOPS/Visage is able to support.