Scenario-based planning takes off at Toronto's airport

They are called irregular operations: what all airports go through during big holidays, bad weather, or major construction. As Toronto discovered, having Ascent software helps.

Ask anyone who flies. All airports are scenes of constant surprises, especially during times of irregular operations, such as big snowstorms or major holidays. Even low-key events, like adding a single gate during the middle of a travel season, can cause significant planning disruptions. So, what happens during a massive airport renovation, when truly significant change becomes a fact of everyday life rather than the exception? What if, for example, an airport were to be essentially re-built with new roads, new terminals, new cargo facilities, two new runways, and a new 12,600 space parking garage (the largest in North America)? What does an airport do then?

Call it the ultimate test of an airport's ability to handle change—to have visibility into the metrics of its business operations and to control those operations.

Whatever you call it, that was the situation facing Toronto's Lester B. Pearson International Airport. How did the airport respond? Would it curtail operations until after reconstruction? Or, would it keep flying 24/7 and use the rebuilding program as an opportunity to sharpen its contingency planning? After all, if an airport can plan around the disruptions of a major renovation, it would probably do much better at handling the routine disruptions that occur even during normal times.

But Toronto's airport managers not only wanted to plan around construction activity. They also wanted to manage an airport whose capacity and configuration of resources—from check-in counters, to gates, to runway slots, to baggage belts—were in an almost constant state of transition. In many ways, it would be like coming to work at a different airport every day.

One thing was for sure—whatever the planners decided to do would have enormous economic consequences. In 2001, the airport and its associated activities generated 11 billion in revenues for local businesses, 138,000 jobs, $3 billion in personal income, and $2.2 billion in tax revenue. More than 25 million passengers travel through the airport each year on more than 60 different airlines—serving 26 Canadian destinations, 44 US destinations, and 33 international cities.

Given all this, here is the path Toronto Pearson ultimately took: It became the first airport in the world to adopt a scenario-based resource allocation strategy—one built upon the SmartAirport® suite of airport-management solutions from Ascent Technology.

What scenario-based resource allocation means

Scenario-based resource allocation means that operations personnel can develop and implement plans for check-in counters, gates, baggage belts, runway slots, and other resources—days, weeks, or months into the future—and take into account that these resources—their numbers and configuration—will change over the course of that planning period. Various scenarios, reflecting different assumptions, can be stored on the shelf and put into effect on the day of operation. The software not only recommends specific allocations (for example, which check-in counters to open for which flights at which times), but it can also automatically adjust allocations based on receipt of new information, either projected or actual. Allocations are rule-based—meaning that they reflect real-world constraints, such as whether two wide-bodied aircraft can park at adjacent gates, or how often aircraft are allowed to take off or land from a particular runway.

Because plans are typically set to cover six-month periods—say, from the spring into fall, a single period can span multiple scenarios, each with a different set of assumptions (for example, that a new concourse will open). When the time comes, the software (or human operators) can invoke the appropriate scenario to ensure optimal resource utilization despite ongoing and dramatic changes to the airport itself.

Optimal means that enough of the right resources are available to handle flights, that airlines' slot requests are processed quickly, and that resources are not over-allocated—objectives that many airports find difficult to achieve consistently even under the best of circumstances.

These were not the best of circumstances. Not only would the reconstruction of Toronto Pearson Airport be massive, it would be long.

Started in early 2001, the project is expected to take ten years and cost more than CDN$4.4 billion—a spending rate of over CDN$3 million per day during the peak construction period. The centerpiece of the project is a new Terminal 1, one of the largest airport terminals in the world. Slated to replace existing Terminals 1 and 2, the new terminal has a gross floor area equivalent to 55 football fields and boasts 258 check-in counters. With its Phase 1 (Piers D and E) inaugurated in April, 2004, and Phase 2A (Pier F) scheduled to open in the fall of 2005, the new facility will augment the existing Terminal 3, which will continue to operate. In addition, two new runways will be added to the airport, bringing the total number of runways to five. A sixth runway—already on the drawing board—would be added later as traffic warranted.

Critical preparation

There was no question—all these changes would place a heavy planning burden on the airport over a prolonged period. The fact is, however, Toronto Pearson had already begun to prepare for these changes years earlier, long before the airport's reconstruction project began—preparation that would prove critical to the airport's success. That's because in 1998, the airport implemented Ascent's software solutions for gate management, slot allocation, baggage-belt allocation, and airport-capacity planning. What these solutions provided, states Marcelo Mota, General Manager of Information Technology & Telecommunications Program Management, was the capability to optimize allocation decisions over any period, for any set of assumptions.

“Prior to 1998, we could make allocation decisions. It was not that we could not make those decisions. Of course, we could. The problem was that we could not optimize those decisions. What we lacked before 1998 were the special algorithms that Ascent provides.”

Mota describes a typical example: “Let's say we have a flight arriving at two o'clock and leaving at four o'clock, and we have to assign check-in counters to that flight. Using a standard time window, we might have assigned that flight 10 counters beginning two hours prior to the estimated time of departure (ETD), even if it turns out we really don't need all those counters. But with Ascent, we can say: `Let's look at the sector: It's an international flight. Let's look at the destination. It's going to Paris. Let's look at the capacity of the airplane. It's a 767.' Based on this, we can build a profile that allows us to say: `Okay, 10% of the passengers will arrive three hours prior to the EDT, 20% will arrive within two hours,' and so on. Then, using this profile, the application will dynamically assign the resource—in this case, check-in counters-based on these factors instead of a standard period of time. It's non-rectangular, meaning that it is dynamic and flexible, based on several factors like sector, destination, and aircraft type.

“That is one of the key reasons we selected Ascent,” Mota says, “because of the innovative concept of resource allocation.”

Even though different Ascent products focus on different resources, all bring similar benefits. David Gaudin, Ascent's Vice President of Operations, compares the ARIS/GM® gate manager with the ARIS/SA™ slot allocator: “The products have the same logic. The differences are that they each consider different rules and the nature of the resource being allocated is different. For example, in the ARIS/SA slot allocator, we are looking at runway slots. Runway slots have a couple of factors to account for that are different than for a gate. For example, with runways you have a very short time period—15 minutes—that is impacted by gate changes and delays in arrival or departure times. So the rules for assigning a slot are different than for a gate, even though the logic behind the products is the same. And that's one reason the GTAA wanted to use Ascent. Because we have consistency of two things. First, we have consistency across applications—they work the same even though the rules are different. And the second thing is that there is integration across the applications.”

Product integration ensures consistency and reduces the time operations personnel spend entering data. “If the GTAA changes something in the ARIS/GM gate manager,” Gaudin says, “it is automatically taken into account in the ARIS/SA slot allocator. So all applications are in sync. More importantly, all allocation decisions are mutually consistent. For example, when gates are assigned, the software automatically takes into account the number of slots allocated. And when runway slots are assigned, it automatically takes into account availability of gates and baggage belts.”

Mota's faith in Ascent is demonstrated by how much the airport relies on the software. “Ascent software allocates all the airport resources, creates the system schedules, and creates the plans for six months ahead. Even on the day of operation, all resource allocation is done through Ascent software. The system is mission critical,” Mota says.

The Ascent scenario

It was on this foundation that Toronto Pearson decided to base operation of its new multi-billion dollar airport, both during construction and afterwards. It is the only airport that has the concept of scenarios and future configurations.

What Mota and his team needed was what they already had—dynamic, intelligent, and consistent resource allocation—except that now the resources being allocated were constantly changing. Planning across periods of change was a capability they wanted to have even after reconstruction was over.

“What we are trying to do,” says Mota, “is to create alternative scenarios that reflect different resource configurations. We want the ability to do this not only during the reconstruction but also during what we call irregular operations. We want to be able to create a specific scenario for a holiday peak or a bad snowstorm or for any irregular operation. Then we can create plans for utilization of airport resources based on the huge demand peaks that typically happen in those periods.”

Accordingly, in 2001, Ascent began to help Toronto re-engineer an IT makeover in its Airport Traffic Information Management System (ATIMS) every bit as comprehensive as the physical transformation going on around it. Ascent revamped virtually its entire product line, and worked closely with Toronto to introduce scenario-based planning into the airport's environment. Ascent also contributed actively to a baseline review of the airport's traffic management software requirements and objectives prior to commencing the actual implementation.

“While the entire development team worked from Ascent's Cambridge [Massachusetts] headquarters,” states Mota, “We had routine on-site meetings here with Ascent to discuss progress. We also had monthly meetings with the Ascent project manager to discuss major milestones.”

Gaudin recounts what some of those milestones were: “First, the infrastructure had to be prepared. The communications, the integration of the different modules of the system—all had to be made scenario-aware. Data also had to be available in several different ways, allowing operators to consider all factors in each scenario. This required expanding the database and incorporating the logic to recognize different scenarios at different points in time. The infrastructure also had to be integrated to allow scenario-based data to flow among the system modules—to be recognized and processed appropriately.”

Part of this work included development of a new product by Ascent, called the ARIS/SE™ scenario editor. It allows planners to create new scenarios by editing a base version of an existing scenario and storing just the updates, rather than duplicating common data in all versions. Updates are also synchronized, meaning that a single revision to a parent scenario automatically and instantly updates all child scenarios as well. It is a strategy that not only conserves system resources but also, once again, ensures planning consistency.

Planning for common use

That's a good thing because now there is a lot more to keep consistent than there used to be. Toronto Pearson is not just moving to new and bigger facilities; it has also moved from dedicated gates and check-in counters to common-use resources—the move that prompted Toronto to adopt Ascent's SmartAirport suite in the first place, back in 1998.

“Prior to the new construction, we already had three terminals in Toronto. Two of them were dedicated mostly to Air Canada, but in Terminal 3, we adopted the common-use concept [i.e., any airline can use any resource]. The tools we had before allowed us to allocate resources based on requests—in other words, on the flight schedules—but we did not have the flexibility to look at demand and apply the algorithms that Ascent provides in order to exploit or maximize the use of those resources. Now we look at the flights, we look at passenger volumes, the capacity of the airplanes, and we look at the arriving passenger profile. With the recent modifications, we actually have two new modules, the ARIS/IQ® queue manager and the ARIS/SE scenario editor, which give us the ability to deal with the profiles of the passenger flows and the configuration of the airport at a particular point in time. Together it gives us the means to define the best allocation possible for each of our resources."

The new tools went online in November 2003, several months before the new terminal opened, so users could become familiar with scenario-based planning right away.

“We were already getting these benefits in the existing terminal,” Mota says. “That's why we decided to migrate the system to production immediately and not wait for the new terminal to open. In Terminal 3, for example, we can exploit the functionality of the software in the allocation of check-in counters and baggage belts.”

Now that the new software is at work, Mota intends to find out exactly how efficiently airport resources are being used. “Measuring results will be part of the project. Ascent has been chosen to deliver a dynamic reporting tool to measure the performance of the airport and the application of resources. Right now, Ascent is writing all the functional specifications for the next set of deliverables, which will allow us to measure performance.”

The most important performance report, of course, will be the one that comes from the software's end-users—the managers who actually run Toronto's ever-expanding airport.

Here's what Mota wants: “I'd like the user to tell us: `You know what? Now, I have the plans from the check-in counter application, I can compare it with the request I am receiving from the airline, and I can prove that the plan is more efficient and that instead of 10 counters I only need to assign seven, and seven is enough. There are no long queues, no lineups, and no wasted check-in counters.' ”

And no more surprises either. At Toronto Pearson, that's the ultimate scenario.