COPX with more than three sectors involved

[Raffael WALTHER]

Hello

 

I'm about to create the ESE file for vACC Switzerland.

There is a problem defining COPX to one destination with more than three sectors involved.

 

Situation

Airspaces

On our side there are the following sectors:

• LSAS_CTR-050_245 from 05000 to 24500
  
• LSAS_E_CTR-ZE-245_325 from 24500 to 32500
  
• LSAS_U_CTR-ZE-325_660 from 32500 to 66000

 

On Frankfurt side there is the following airspace:

• EDDS_S_APP-145 from GND to 14500

 

LoA

The LoA defines, that aircraft with destination EDDS shall be handed off from Sector LSAS_CTR-050_245 to EDDS_S_APP-145 at 14000ft.

 

COPX

I've defined the following COPX:

1. FIR_COPX:*:*:ARSUT:EDDS:*:LSAS_CTR-050_245:EDDS_S_APP-145:*:14000:ARSUT
   
2. COPX:*:*:ARSUT:EDDS:*:LSAS_E_CTR-ZE-245_325:LSAS_CTR-050_245:*:25000:*
   
3. COPX:*:*:ARSUT:EDDS:*:LSAS_U_CTR-ZE-325_660:LSAS_E_CTR-ZE-245_325:*:33000:*

 

That means, traffic with destination EDDS via ARSUT shall be handed over from LSAS_U_CTR to LSAS_E_CTR on FL330, from LSAS_E_CTR to LSAS_CTR on FL250 and from LSAS_CTR to EDDS_S_APP on FL140.

 

Problem

Let's [Mod - Happy Thoughts]ume the following:

• an that an aircraft is on FL280 in sector LSAS_E_CTR-ZE-245-325.
  
• Sector LSAS_E_CTR-ZE-245-325 is controlled by LSAS_E_CTR
  
• Sector LSAS_CTR-050_245 is controlled by LSAS_CTR

 

I'd expect COPX 2 from the list above to be used. But in fact, no COPX is applied at all.

COPX 2 however works after removing COPX 1 from the list. It seems to me, that the program [Mod - Happy Thoughts]umes COPX 1 to be the correct COPX, stops searching for further COPX, tries to apply it but fails.

 

Just changing the order of the COPX by the way doesn't solve the problem.

In that case it will be COPX 3 that causes the same problem as COPX 1.

 

Am I doing something wrong or is this a bug/missing feature in ES?

Does someone know a workaround for it?

[Martin Loxbo]

I'm not sure I follow: What if you have an aircraft in the high sector, destination EDDS. Is this descended to FL330, transferred to the middle sector who descends it to FL250, and then transferred to the low sector who descends it to FL140, and then transfers to EDDS APP?

 

If this is the case, it seems strange to me that they would use the same COP, but then I have not seen what the airspace actually looks like.

[Raffael WALTHER]

Hello Martin

 

They actually don't use the same COPX. The only thing defined is that traffic with destination EDDS must be on FL140 at ARSUT. LSAS_U_CTR and LSAS_E_CTR are just expected to descent traffic with destination EDDS to FL330 respectivelly FL250 in a way that the traffic can cross ARSUT on FL140. So there are actually no COPX for the transfer LSAS_U_CTR > LSAS_E_CTR > LSAS_CTR, therefore the COPX name is left empty in the definitions above. My intension is to use COPX 2 and 3 to indicate LSAS_U_CTR and LSAS_E_CTR, that they need to descent traffic with destination EDDS to FL330 resp. 250.

 

Best regards

Raffael Walther

 

vACC Switzerland

Leader Operation Department

[Todor Atanasov 878664]

Raffael the COPX work line by line, but only the first will be taken in consideration if it is true. You have the same "COPX:*:*:ARSUT:EDDS:" for two lines, so if line is true, the second line will never be executed (ES stops to check if it finds a true line, sort of speak).

[Raffael WALTHER]

Hello Todor

 

The question is what parameters are used to check if a line is true or not. To me a line should only be considered to be true, if the sector in which an aircraft is currently flying is controlled by the same ATC as the first sector in the COPX-Definition. Thus if LSAS_E_CTR only controls sector LSAS_E_CTR-245_325 the 1st COPX should not apply.

[Stephan Boerner 945550]

That won't work the way you are trying to do that.

I've defined the following COPX:

 

1. FIR_COPX:*:*:ARSUT:EDDS:*:LSAS_CTR-050_245:EDDS_S_APP-145:*:14000:ARSUT

2. COPX:*:*:ARSUT:EDDS:*:LSAS_E_CTR-ZE-245_325:LSAS_CTR-050_245:*:25000:*

3. COPX:*:*:ARSUT:EDDS:*:LSAS_U_CTR-ZE-325_660:LSAS_E_CTR-ZE-245_325:*:33000:*

 

 

That means, traffic with destination EDDS via ARSUT shall be handed over from LSAS_U_CTR to LSAS_E_CTR on FL330, from LSAS_E_CTR to LSAS_CTR on FL250 and from LSAS_CTR to EDDS_S_APP on FL140.

What you are trying to do is, to define the handover steps sector by sector, but the handoff from U to E and from E to CTR does not happen at ARSUT, as all aircrafts are supposed to be handed over FL140 @ ARSUT. For those COPX to work, you need to define individual COPXes for the waypoints where those handoffs take place, which is not ARSUT.

[Raffael WALTHER]

Hello Stephan

 

We don't have internal COPX defined for handoff from U_CTR to E_CTR and from E_CTR to CTR. U_CTR and E_CTR should just be "informed" in some way that traffic has to cross ARSUT at FL140 so they know where they should descent there traffic to FL330 resp. 250. So it is simply not possible to define something like that in ES without defining separate COPX?

 

For the time being, I'm using the following workarround: LSZH_U_CTR, LSZH_E_CTR and LSZH_CTR will all have ARSUT displayed with a level restricion of FL140. LSZH_U_CTR and LSZH_E_CTR simply need to be aware that they can descent traffic only to the lower limits of their airspace.

[Stephan Boerner 945550]

Yes, so what you could do is, create a COPX for the point where they know they have to initiate the descend. That's the only possible workaround for now, to get individual results, as the lateral reference for the COPX is the waypoint. ES has no way of knowing, which COPX it is supposed to chose, if waypoint and destination airport are the same for several COPXes, so it can just take the first one.

 

There are plans for a far more detailed way of defining COPXes, but those are not more than plans for now. Don't expect them to get implemented for the time being.

[Raffael WALTHER]

Ok, thank you for the clarifications!

[Martin Loxbo]

This reminds me of something I requested long ago: the ability to use custom (non-published) coordination points. These are coordination points that are internal, for ATC use only. What we would need to be able to use them is for ES to know when they should be part of an aircraft's route.

[Gergely Csernak]

This reminds me of something I requested long ago: the ability to use custom (non-published) coordination points. These are coordination points that are internal, for ATC use only. What we would need to be able to use them is for ES to know when they should be part of an aircraft's route.

 

Yes, it is in my TODO list, but I am afraid it will not ba available in the next public release.

[Martin Loxbo]

That's okay Gergely. I know how long your todo list is, and it's about time all the normal users get to play with the stuff us beta testers have become used to.

[Hans Utne 813128]

Martin,

Think I stated that myself in a private mail to Gergely

 

However, not being a beta-tester, but a regular user:

It's time to say stop -, provide an updated release -, and then continue with the to-do-list

 

Delaying a new version further will only ensure that your to-do-list will become longer, providing less oversight, taking longer to complete, and us the users being less interested in using the application

[Todor Atanasov 878664]

I think G has drawn the line for new things and all has been implemented. He is fixing the bugs now.

[Hans Utne 813128]

Todor,

That is really good news to the ATC community if this info is correct

Looking forward to an updated version.