search

openscope / openscope

openScope Air Traffic Control Simulator
http://www.openscope.io
Other
623 stars 178 forks source link

Explain "no altitude assigned" readback in response to descend via star command #1455

Open JPmAn24 opened 4 years ago

JPmAn24 commented 4 years ago

According to This reddit thread , whenever you tell an airplane to do descend via STAR and give no altitude (I.e. AAL123 dvs), it says no altitude assigned.

I’ll be asking the user what airport, route, etc. this happened on.

tl;dr by @cake-pie:

"unable, no altitude assigned" readback at EGCC in response to dvs is not a bug. In the absence of any altitude constraints in the STAR and no explicit clearance from ATC, aircraft do not know what altitude to descend to.

Example of another similar situation: KMIA.

To resolve: simply clear aircraft to desired altitude e.g. a 70. Issuing "descend via" with explicit altitude e.g. dvs 70 will also work, but since the STAR has no crossing restrictions, the effect is indistinguishable from a simple altitude assignment.

Todo:

erikquinn commented 4 years ago

Strange. Should be able to just say dvs and have them find the bottom altitude and descend to it while complying with all the restrictions along the way...

Marcel510 commented 4 years ago

Would be good to know the involved airport. I've done some testing and 'dvs' worked fine for me. It only said "no altitude assigned" when the star doesnt have any altitude constraints. Which is the way it's supposed to be like if I'm correct.

odiferousmint commented 4 years ago

Which is the way it's supposed to be like if I'm correct.

You are correct:

Not all airports have published STARs, but most relatively large or hard to reach (e.g., in a mountainous area) airports do. Sometimes several airports in a locality share a single STAR; in such circumstances, aircraft follow the same arrival route until the final waypoint, diverging thereafter for their chosen destination.[1]

However, you might want to take this into account:

Although the route segment of the filed flight plan does not usually change during the flight itself, the STAR to be flown might well vary according to the weather, the runway or approach in use, or the need to safely separate air traffic, among other factors. Thus a filed flight plan typically ends some distance from touchdown, where a STAR begins, and that is usually assigned and communicated to the pilot during the flight planned portion of the flight.[1]

In any case, probably should read the entire Wikipedia article and see what is relevant to the currently implemented features. :)

[1] https://en.wikipedia.org/wiki/Standard_terminal_arrival_route

kaitsu71 commented 4 years ago

Should the planes descent with dvs command at LOWW? Nothing seems to happen, all the planes stick with their original FL 160-180.

Fechulo commented 4 years ago

@kaitsu71 In Vienna (and most of Europe), altitude restrictions are for planning purposes only and actual descent clearances are given by ATC, so aircraft will stay at their spawn level until given further descent.

OlaRune commented 3 years ago

@kaitsu71 In Vienna (and most of Europe), altitude restrictions are for planning purposes only and actual descent clearances are given by ATC, so aircraft will stay at their spawn level until given further descent.

Wouldn't it be more transparent to the user if they either got some kind of "unable" reply from the pilot, or some other notification that "dvs" is not doing anything at the current airport? Right now it seems like they accept the command but just doesn't comply.

erikquinn commented 3 years ago

@OlaRune currently that's what it does in the cases where there's not enough information to descend via the arrival, for example at miami, where there is no descend via:

image

OlaRune commented 3 years ago

Hmm okay. Maybe I just don't understand things fully, but I think I have tried both "dvs" and "dvs 50" on Oslo Gardemoen and the aircraft seems to accept it but just stays at FL 100. I will try it out more next time I'm at the computer.

lör 2 jan. 2021 kl. 20:13 skrev Erik Quinn notifications@github.com:

@OlaRune https://github.com/OlaRune currently that's what it does in the cases where there's not enough information to descend via the arrival, for example at miami, where there is no descend via:

[image: image] https://user-images.githubusercontent.com/5103735/103464823-b19d0e00-4d04-11eb-8bb6-69dce5cc62c0.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openscope/openscope/issues/1455#issuecomment-753517609, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBFNWQLKF44SP3XA2QSZYLSX5V6ZANCNFSM4I4ASLIA .

OlaRune commented 3 years ago

Hmm okay. Maybe I just don't understand things fully, but I think I have tried both "dvs" and "dvs 50" on Oslo Gardemoen and the aircraft seems to accept it but just stays at FL 100. I will try it out more next time I'm at the computer. lör 2 jan. 2021 kl. 20:13 skrev Erik Quinn notifications@github.com: …

I tried it out now and I guess it's working as intended. The STARs takes them down to FL 90, 100 or 110, even though their flight plans all say FL50. I guess it's my responsibility to manually take them down to 50.

erikquinn commented 3 years ago

@OlaRune no, you are misunderstanding the meaning of "descend via STAR"... it literally means to descend in accordance with the altitude restrictions posted on the STAR. So they can start descent whenever they want, as long as they reach the charted altitudes/speeds at the appropriate fixes.

For example, at ENGM, on the RIPAM3L arrival (from the southwest), an aircraft with a descend-via clearance will enter at 12,000 and will stay there until they have to start descent in order to reach GM410 at 110, then will stay at 110 until they have to start down to reach VALPU at 5000. So they are assigned 5,000, and they will get there at the appropriate time. If you want to cancel the descend-via and tell them to descend directly to 5,000, as the controller you obviously do have the option to do that.

image

OlaRune commented 3 years ago

@OlaRune no, you are misunderstanding the meaning of "descend via STAR"... it literally means to descend in accordance with the altitude restrictions posted on the STAR. So they can start descent whenever they want, as long as they reach the charted altitudes/speeds at the appropriate fixes.

For example, at ENGM, on the RIPAM3L arrival (from the southwest), an aircraft with a descend-via clearance will enter at 12,000 and will stay there until they have to start descent in order to reach GM410 at 110, then will stay at 110 until they have to start down to reach VALPU at 5000. So they are assigned 5,000, and they will get there at the appropriate time. If you want to cancel the descend-via and tell them to descend directly to 5,000, as the controller you obviously do have the option to do that.

image

Then I guess something is wrong with the STAR, or there is something else going on, maybe it's me doing something wrong. I tried the exact STAR you mentioned. An aircraft entered via RIPAM3L and I immediately told it to "dvs". It stayed at FL 120 for a while, then descended to 110 before GM410 as you said. Then it stayed at 110 through GM409, GM408, GM407 all the way to VALPU. Then it did a 180 right turn and entered some kind of holding pattern still at FL 110 and stayed there forever.

erikquinn commented 3 years ago

@OlaRune Ah... I now see if we look closely at the chart, it says to "cross GM407 at 11,000, then cross VALPU at or above 5000", and there are no fixes after VALPU.

So this is one of those weird cases where a STAR is designed strangely. By crossing GM407 at 11,000 and staying there, the aircraft is "at or above 5000 over VALPU", and therefore is complying with all the restrictions. Since no restriction forced them down, they stayed up.

So in the case of ENGM, I guess knowing the specifics of the arrival would be the key to knowing what the aircraft will do. And after all, you will have to descend them lower than 11000 manually.

Upon further investigation, it works like that because approach will likely be giving an instruction of "at VALPU, cleared ILS Runway 1L approach", which would permit them to descend as low as 5000 on the STAR, and upon passing VALPU, to descend in accordance with the approach chart:

Screenshot_20210103-194535

OlaRune commented 3 years ago

Thanks for the clarification!

mån 4 jan. 2021 kl. 01:48 skrev Erik Quinn notifications@github.com:

@OlaRune https://github.com/OlaRune Ah... I now see if we look closely at the chart, it says to "cross GM407 at 11,000, then cross VALPU at or above 5000", and there are no fixes after VALPU.

So this is one of those weird cases where a STAR is designed strangely. By crossing GM407 at 11,000 and staying there, the aircraft is "at or above 5000 over VALPU", and therefore is complying with all the restrictions. Since no restriction forced them down, they stayed up.

So in the case of ENGM, I guess knowing the specifics of the arrival would be the key to knowing what the aircraft will do. And after all, you will have to descend them lower than 11000 manually.

Upon further investigation, it works like that because approach will likely be giving an instruction of "at VALPU, cleared ILS Runway 1L approach", which would permit them to descend as low as 5000 on the STAR, and upon passing VALPU, to descend in accordance with the approach chart:

[image: Screenshot_20210103-194535] https://user-images.githubusercontent.com/5103735/103492966-9dd4d300-4dfc-11eb-80f2-5929190edc3f.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openscope/openscope/issues/1455#issuecomment-753704875, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBFNWQA2YRW6CIBLKTO4KLSYEF6TANCNFSM4I4ASLIA .

cake-pie commented 3 years ago

Multiple airports and multiple issues were brought up here. Here's an attempt to get this better organized.

tl;dr:

This issue:

Branch off into new issues:

Details summed up below.

EGCC

OP by @JPmAn24, on behalf of reddit thread

issue reported

when issued dvs, aircraft report no altitude assigned
at Manchester, SE star [DAYNE]

behavior (v6.22.0)

In the EGCC airport file, none of the STARs include any altitude constraints, therefore aircraft respond to dvs command with "unable, no altitude assigned".

This is working as intended: with no information in the STAR and no explicit clearance from ATC, aircraft do not know what altitude to descend to.

If an altitude is specified e.g. dvs 70 then aircraft respond with affirmative readback "descend via STAR and maintain 7000" and immediately begin descent until assigned altitude is reached. Behavior is identical to stratightforward altitude assignment a 70.

This is also working as intended: without any constraints to "cross at or above" fixes along STAR, aircraft is permitted to descend immediately to the assigned altitude. There is no need to "step down".

In charts I found online (Jeppensen cycle no: 03-2020) the STARs have no crossing restrictions, but do include descent planning notes to "plan for possible clearance" to certain altitudes by certain fixes. These notes are for planning purposes only and actual descent clearance must come from ATC. So the airport file is correct in this respect.

However it appears that the holds at the end of the STARs do have altitude constraints that are not reflected in the airport file:

DALEY: MHA FL70 MAX FL140 DAYNE: MHA FL70 MIRSI: MHA 6000 MAX FL140 ROSUN: MHA FL70

There is no AIRAC indicated in the airport file; some updates may be needed considering it looks like it was last revamped 2018.

(Also, there have been improvements to hold syntax that that will allow improvements, e.g. specify radial for ROSUN /DALEY holds.)

suggested resolution

Bug: invalid -- dvs without altitude argument is behaving correctly as per airport file, "no altitude assigned" message is intended in this case

Documentation: consider improving documentation to explain the cause of "no altitude assigned" message

Airport work: to bring up to date to more recent AIRAC: file as separate issue

KMIA

comment

No issues here, this was raised by @erikquinn as an example of another airport where there is not enough information to descend via STAR.

STARs do not include any altitude constraints; behavior of dvs with and without altitude argument is identical to EGCC.

LOWW

comment by @kaitsu71

issue reported

despite being issued with dvs command at LOWW all the planes stick with their original FL 160-180.

behavior (v6.22.0)

Airport is configured with arrivals on RWY 34. When issued dvs all aircraft respond with readback "descend via STAR and maintain 3000". This is due to corresponding transitions having fix WW971 with A030+. If a specific altitude is supplied as an argument e.g. dvs 40 or dvs 20 aircraft will readback with the given altitude. However, in all cases, aircraft do not descend despite the affirmative readback.

In the LOWW airport file, most fixes altitude constraints along STARs and transitions are of "at or above" Axxx+ type. This is in accordance with reality (Austro Control eAIP). As @Fechulo explained here these altitude restrictions are for planning purposes only and actual descent clearances are given by ATC.

Due to absence of "at or below" crossing restrictions, aircraft are technically remaining in compliance with STARs and transitions.

However it is a problem if aircraft respond with readback in the affirmative but never actually begin descent.

suggested resolution

Several problems with dvs behavior here, to be consolidated and filed as a separate bugfix issue.

Desired behavior is as follows:

ENGM

comment by @OlaRune

issue reported

Aircraft when issued dvs takes them down to FL 90, 100 or 110, even though their flight plans all say FL50

behavior (v6.22.0)

As reported, aircraft readback with "descend via STAR and maintain 5000", but settle at a final altitude of FL 90, 100 or 110.

As explained by @erikquinn, dvs without altitude specified tells aircraft to descend as compelled to by STARs, which have crossing restrictions at A090, A100 or A110 respectively, hence the observed final altitudes. Holding at VALPU and INSUV have "at or above" restriction (A050+) and aircraft are thus not compelled to descend to FL50. Airport file is accurate (Avinor eAIP).

Same as LOWW, there is an issue of misleading readback.

As for dvs xx with altitude specified explicitly, aircraft reply with the given altitude in readback. Actual behavior: if issued dvs 51 (or above) upon entering the airspace, aircraft will descend to FL51 after crossing GM407 / GM455 / GM414 / GM454 at FL 90/100/110. Aircraft will not descend past FL 90/100/110 if issued dvs 50 or lower, despite affirmative readback.

This is very odd, I was originally expecting aircraft to not descend past FL 90/100/110 at all. It seems the problem isn't quite so simple as "refuse to descend if not compelled by crossing restrictions".

suggested resolution

Bugfix + needs further investigation, consolidated in same issue as LOWW issues.

Fechulo commented 3 years ago

Part of the problem is the inconsistency across airport files. At some point, the decision was made that European airports, where descent clearances are given by ATC explicitly, rather than via a "descend via" instruction, should not include any altitude restrictions in the STAR definitions. While this is good for realism, it means different airport work differently in the sim, which isn't ideal. It also causes issues where aircraft never make it into the airspace because they don't descend into it. The workaround is to have aircraft spawn at unrealistically low altitudes which I personally hate. I think we should add altitude restrictions to all airports that are missing them for this reason, and possibly even make the IAF restrictions hard restrictions, rather than at or above as they currently are. This would mean dvs would work consistently across all airports in the same way.

cake-pie commented 3 years ago

different airport work differently in the sim

I don't see a problem with that, if it is indeed an accurate reflection of real world differences in ATC practices in different places.

causes issues where aircraft never make it into the airspace because they don't descend into it. The workaround is to have aircraft spawn at unrealistically low altitudes

I'm aware this problem exists, but have not looked deeper into it yet. Agree that unrealistically low spawns is not a satisfactory workaround. However, I'm not sure that lack of altitude restrictions can be blamed as primary cause of this problem. There are definitely issues with descent logic, e.g. #569.

add altitude restrictions to all airports that are missing them ... and make the IAF restrictions hard restrictions

Would be less of a kludge than unrealistically low spawns, but ultimately it's still only a workaround that doesn't get at the root of the problem. For a durable solution it's better to actually fix the erroneous behavior in code rather than hack the input data to something that diverges from reality, in the hope of coercing the desired behavior.

erikquinn commented 3 years ago

I thought we already had one (maybe I'm going crazy), but added #1746.

The planned solution from way back when we said "keep the procedure definitions accurate; don't add fake restrictions" was to address it by defining a set of user commands for a given spawn pattern, to be executed against the aircraft when they spawn. This would eliminate the need to spawn people level at 10,000 like 100 miles from the airport.