What do you mean by that, and what makes tracking optimization particularly challenging?
- First of all it’s about having the right foundation in place. Our Atrium platform has been designed for supporting the optimisation use case, but it has taken its time to get here. Those who have followed our architecture know that we are firm believers in a strong separation between problem description and solution methodology. The same goes for this problem as well, but the other part is the ’live’ aspect of the information which creates a need for an advanced versioning system of the data and a clever scenario concept and conflict-handling. With the right design, a solution becomes simply a ’delta to a state’. With that, I refer to a collection of changes to be applied to a specific version of the data base. You can think of that version as a snapshot of all data at a given time. That’s a challenge in itself - and one that needs to be addressed at the lowest level in the data base. With that in place, a solution can be applied and implemented even when many things may have changed during the minutes that have passed while solving the problem using the optimiser.
And the speed requirements are quite extreme here, right?
- They are. The system must very quickly be able to propose solutions back to to the crew tracker. But, as a former Crew Tracker myself, I know that even more important is ensuring that the user stays in control by explaining the results and allowing for fast and effective evaluation of solution details and overall properties, such as costs, before implementation.
Aha... and such ’costs’ are open for configuration I assume - meaning they may include a virtual cost for planning a flight in a fatiguing way? Or a cost for a late notification to crew, not giving him/her much time to prepare?
- Of course. The business logic is as always fully controllable by the operator, easily expressed and reconfigured in Rave - and BAM sits there right in the middle. Cost is anything the airline wants it to be.
I see... Are there other challenges here that are dramatically different from crew planning optimization?
- Yes indeed. The concept of legality is very clear in planning; a ‘max block hour’ rule will need to be always respected. In the crew tracking phase, a good solution may still contain illegalities. It's about assisting as far as possible and that may include leaving some illegalities for being dealt with later.
Wohahaa! Stop right there! Knowing a bit about optimization, and the ’combinatorial explosion’ (link) - does that not mean that the 'solution space' could blow up to an enormous size if the optimizer needs to consider also illegal solutions?
- It does make it more challenging, you are correct. It may also be in part why, to date, there are no well-functioning tracking optimizers anywhere to be seen. Breaking through that combinatorial ’wall’ is a tough problem indeed, but the other aspects I mentioned are equally hard.
I heard, through the grape wine, that you are in dialogue with launching partners now. If an operator is interested - is there still room for more to become early adopters?
- Ha-ha! Well…, unless an operator is already in dialogue with us on tracking optimization, I would say that they will need to bide their time a bit. There’s still more work to do on our side - but we will definately let the market know when we are ready to onboard more operators. For now they can simply sit back and follow the development, engage in our events to learn more and provide their input. Please recall that Jeppesen has year after year been improving and perfecting crew pairing and rostering optimization - for more than 30 years. Similarly, tracking optimization is a journey, not a destination. I’m glad we’re now on our way with thrust levers in full forward position. Buckle up!
Thank you, Heidi. Sure will!
