Closed kusterjs closed 1 year ago
Noted. Will look for a workaround to keep the CTOT even if not active anymore and I will study the possibility of not invalidate plane having CTOT.
Just to clarify, this is not related to CTOT. This is an issue with a "casual" TTOT. Of course, the corresponding CTOT (if issued) should then stay as well. But the issue observed was that a slot was invalidated when it was late (TOBT or TSAT already passed), but had reported ready within the TOBT window.
I'm afraid it should be for another reason, becuse if asrt is set. It's impossible to invalidate it. So, please let me know if it happens again.
Regarding the CDT, a part from blocking a TTOT, it's showing the TTOT value in the CTOT volumn with an specific color. So depening on the color of the CTOT the value will mean a CDT only, flow CTOT or CTOT+CDT.
I'm afraid it should be for another reason, becuse if asrt is set. It's impossible to invalidate it. So, please let me know if it happens again.
That's why I reported it. Because exactly this happened.
So depening on the color of the CTOT the value will mean a CDT only, flow CTOT or CTOT+CDT.
What would be the scenario for CTOT+CDT? Will it not by either or of these two inputs anyway that determines the CTOT?
What would be the scenario for CTOT+CDT? Will it not by either or of these two inputs anyway that determines the CTOT?
Tottally agree. Thanks for that! I will figure it out.
Regarding the proposal of not invalidating a flight on TOBT+5 I have 2 options.
1. At TOBT+5 change the TOBT color to red and if the atc wants to remove it, then just add a function for it.
2. Create an option in the config to invalidate flight at tobt.
Assuming your second option is also about TOBT+5. Because definitely before that time an invalidation should not take place.
There is probably a little bit more to the issue because the TOBT is not getting updated while the TSAT has not been reached yet (like it is done in RL). But even then, once the "ready report" has been made, the TOBT doesn't matter anymore. Then it's only about the TSAT, which might be well in the future. It's important that then the slot doesn't get invalidated just because the TOBT window passed, but the TSAT window hasn't even started. But if no ready report has been made and recorded, I'm fine with the slot just being removed at TOBT+6.
Maybe check the conditions for the slot removal again, so that it really only gets removed if no ASRT is set.
Back yo the first question, How many times did you experienced that?
There's an only conditional to invalidate at tobt+5 when asrt is not set.
Don't have an exact number. But it was reported by various controllers.
Don't have an exact number. But it was reported by various controllers.
Let's keep on trying to fix that then. If there's a possibility to save an euroscope log or video screen when this happens it may help me to analyze it.
I made some screen recordings to follow up on the issue of automatically invalidated slots. The issue seems to be that an ASRT alone is not sufficient enough to keep a slot. There seems to be an additional requirement of the ground status. For gate parkings, we usually issue start-up and pushback together. So if there is congenstion on the tarmac due to multiple pushbacks, a flight might not receive pushback clearance within the TSAT window. His ground status will therefore remain empty (or ON FREQ from the GRP, which is still an empty value for ES). However, the TTOT will still be feasible in most times. And even if not, such a flight should not be penalised by losing his slot. Additionally, such a slot will not be subject to reassignment to another aircraft (due to the taxi time considered when assigning a new slot), so a removal does not improve the overall sequence. Therefore, I highly recommend to use the ASRT only as a trigger whether a slot should be invalidated or not. The ground status itself has only an indirect influece, as a START-UP or PUSH flag will also set the ASRT.
From TOBT+5 if flight has not ASRT it gets invalidated. From TSAT+5 if not ST-UP sts is set it gets invalidated.
I see you are using the ON FREQ, which is not an ES sts and can't be any of those above.
From TOBT+5 if flight has not ASRT it gets invalidated. From TSAT+5 if not ST-UP sts is set it gets invalidated.
I see you are using the ON FREQ, which is not an ES sts and can't be any of those above.
I understand. I would like to avoid these slot invalidations. Because they penalise pilots which reported ready on time. We experienced this several times and it results in high workload for controllers to make sure every pilot reported ready will also get his pushback and taxi despite the CDM slot is lost. This will be in a situation where it gets hectic anyway. And a delay gap cannot be used anymore to "save" the slots. So I would rather have them kept beyond TSAT+6 in order for the controller to better follow up on who is next. A gap can still be used to give some space after these critical flight. But we need a way to preserve the slots. Maybe an option to invalidate slots only when no ASRT is set? I still can't fully understand why a slot is invalidated in this situation, because the TTOT might still be feasible. Also, a single minute indicating the TSAT in yellow in a busy session gives the controller not sufficient time to react, considering that there might be another aircraft blocking him.
Understood. I will create an option to invalidate or not from TSAT+6.
Tested and seems to work. Only colouring needs to be updated, to keep yellow also after +6.
Tested and seems to work. Only colouring needs to be updated, to keep yellow also after +6.
Fixed accordingly ;)
Even if a pilot has reported ready and the ASRT is set, at some point the entire slot is removed. In such cases the delay is usually caused by ATC. But by removing the slot, it's difficult to track that a pilot had a slot before, it was just ATC that didn't make it work. Couldn't such slots be kept? At this point, there is usually no positive effect for other flights by removing such a slot as they would need to be already taxi or something. My proposal would be to never invalidate a slot when the ASRT has been set.