As anyone who’s been to an airport recently can attest, queueing is part of the experience. We queue to get through security, we line up to order food or drinks, and last we wait our turn to board the aircraft. Most simulation models revolve around contention for resources or constraints with limited capacity, and the modern flying experience has its fair share of contention.
One of the first issues for any modeler is the wide variety of flyers; there are the road warrior business travelers, the leisurely vacationers, and the families with young children in tow. While all of these passengers may share an airplane, there are vast differences in their behaviors as they navigate the airport. Last month’s newsletter shared recommended approaches to this type of customer differentiation using skill-based routing. Unfortunately, the TSA hasn’t been as successful with this technique – several years ago, they experimented with having passengers join particular lanes depending on whether they were family, casual, or expert travelers. As it turns out, it’s much easier to route a caller when you have complete control over who assists them than it is to suggest that they self-evaluate and pick the appropriate lane.
In Arena, attributes can be used to assist with modeling these variations. An attribute can store indicators for characteristics such as number in party, type of traveler, scheduled flight time, and boarding zones. When clearing security, these attributes can be used to index into an arrayed expression to assign a faster time for the seasoned business traveler to get through the x-ray process as well as differentiating between the passengers with and without TSA Precheck.
The same idea can be used to move some passengers to the Precheck line after their identification has been checked. A random percentage can be assigned based on the passenger type. A Decide module using both an arrayed variable and the same passenger type attribute can handle this.
Another common queue behavior is balking. Balking would be done using the same techniques demonstrated previously. If an entity has a flight that leaves in an hour and arrives to the airport to find that there are 300 people in line for security already, that passenger may choose not to join the line since they would never make it through in time for the flight. The model would need to use the number of passengers already in line, NQ(Wait for Screening.Queue), plus the passenger screening processing rate to calculate the amount of time that it will take to get through security. This value can be compared to the time remaining before the passenger’s flight, (TNOW – a ScheduledFlightTime), to see if there is enough time to complete screening or if the passenger should just go home and rebook the flight.
The last queue modeling technique to be covered is reneging. Reneging is more complicated since the passenger will join a line and then decide at some point to leave the line without being serviced and therefore will need to be removed from the Arena queue. Typically, this will be done by creating a duplicate entity before the original joins the queue for service. The duplicate will wait for the specified period of time and then check to see if its original entity is still in line. If it is, the duplicate entity will remove the original from the queue. The original can either be disposed, or proceed to a different or later section of logic. For a detailed example, check out Queues Remove Entity Based on Reneging Logic.doe in the Arena SMART examples. In the SMART example, the longest that entities will wait is 10 minutes. This delay can be based on a statistical expression so that some entities randomly choose to wait longer than others. The expression can even be set up as an arrayed expression with different distributions and parameters depending on the passenger type.
One more note about any model, especially one dealing with human behavior: it is critical to have accurate data inputs. While it is possible to create logic to model balking, it is usually difficult to capture data measuring it. Gathering data on reneging can be easier since it is possible to study lines and record when people leave them, but determining a reasonable wait time standard is still difficult. Humans are notoriously bad at estimating time while waiting and will often overstate how long they waited in line before receiving service. Because of this, it’s important to not only understand the actual wait but also the perceived wait. When choosing a wait time goal for your model, you need to keep in mind not only how long customers are truly waiting, but how long they think they are waiting. So if your customers have told you that they’re willing to wait up to four minutes, your wait time standard may need to be three minutes since that feels like four.
And our last piece of advice for working with lines at US airports? Sign up for TSA Precheck.
