- Messages
- 5 555
- Réactions
- 2 392
Salut !
Ce n'est pas forcément facile à lire (c'est plus fluide sur le lien en anglais) mais c'est toujours intéressant de savoir comment un developpeur réfléchit face à un bug étrange :
Gestion de l'altitude : Une histoire de hauts et de bas dans le système ATC
Publié dans News par Jim Keir | dev ATC Laminar
Décider de l'altitude dont un segment de vol particulier a réellement besoin ne devrait pas être difficile, n'est-ce pas ? Vous décollez d'un endroit proche du sol, vous montez jusqu'à l'altitude de croisière que vous avez choisie, vous commencez à descendre lorsque vous approchez de votre destination et vous vous retrouvez finalement au sol. Qu'est-ce qui peut bien se passer ?...
... Un rapport de bug est arrivé de quelqu'un disant qu'il avait été dirigé vers une colline pendant l'approche. C'est quelque chose qui a reçu beaucoup d'attention pour X-Plane 12, donc j'ai sauté sur l'occasion et j'ai reproduit le vol.
Heureusement, la personne qui a signalé le problème avait inclus le bon fichier log (ce n'est pas le cas de tout le monde, nous recevons des tas de cas où le log montre que la simulation se trouve dans le menu principal) et avait donné les détails du plan de vol ; rien de compliqué, un simple vol direct entre deux aéroports distants d'environ 35 miles, avec une altitude de croisière de 6000 pieds.
Je l'ai configuré et laissé l'IA voler. Le décollage s'est bien passé, puis on lui a demandé de monter à 8000 pieds - au-dessus de l'altitude de croisière demandée. En regardant la carte, je me suis dit qu'il y avait une crête montagneuse sur le chemin, ce qui était logique. Puis les problèmes ont commencé. Descendre à 7000, puis descendre à 5500, puis monter à 7000, puis une boucle sans fin de montée/descente à ce qui semblait être des choix aléatoires de 5000, 6000, 7000 et 8000 pieds.
Toutes les situations "normales" - et beaucoup de situations inhabituelles - pour l'approche et l'atterrissage sont couvertes par des tests automatisés et ils avaient été passés la veille, donc je savais que ce n'était pas un problème courant mais ce serait quand même sacrément ennuyeux si cela vous arrivait.
En creusant un peu, la première chose que j'ai trouvée est un bon vieux bug.
Avant XP12, le système ATC était presque exclusivement écrit pour les avions de ligne et un vieux morceau de code avait un problème où, si vous étiez en dessous de l'altitude de croisière normale pour un avion de ligne, on pouvait vous dire de monter légèrement avant de commencer la descente. Cela se produisait parce que, lorsque l'AI était transféré de la tour au contrôleur de niveau supérieur, il était déjà suffisamment proche de l'aérodrome de destination pour être considéré comme une arrivée.
Si vous y réfléchissez, cela casse complètement le modèle d'altitude simple. Le Cessna 172 monte lentement, il abordait donc toute la séquence "descente, approche, atterrissage" par le bas. X-Plane 12 est conscient de cela, donc cela ne devrait pas être un problème.
Donc, nous avons résolu une instruction de montée inappropriée. Nouveau test.
Comme prévu, la même chose qu'avant ; une indécision totale de la part du contrôleur. Le problème suivant apparaît rapidement : l'évitement du terrain.
A première vue, l'évitement du terrain devrait aussi être simple : Si colline, monter. La plupart du temps, c'est le cas ; là où cela ne fonctionne pas, c'est lorsque vous essayez délibérément de vous rapprocher du sol, par exemple pendant l'approche et l'atterrissage.
Si vous êtes familier avec les cartes d'aviation, vous connaissez l'acronyme MSA (Minimum Safe Altitude). En gros, la carte est divisée en grands carrés et, dans chaque carré, il y a une MSA indiquée. Si vous traversez ce carré, vous avez la garantie de ne pas toucher le sol si vous restez au-dessus de cette altitude. C'est simple, ça marche, et X-Plane fait à peu près exactement la même chose. Les données d'élévation du terrain sont réduites de manière à ce qu'un seul pixel donne la MSA pour la zone qu'il couvre, ce qui rend la vérification relativement rapide et facile.
Ce vol comportait deux crêtes abruptes allant du niveau de la mer à environ 6 200 pieds qui se terminaient juste à l'intérieur d'un carré MSA, et le vol se déroulait juste le long du sommet à environ 90 degrés par rapport aux crêtes. Quelques centaines de mètres de différence d'emplacement au moment où les échantillons de terrain ont été prélevés ont suffi à modifier la MSA entre environ 50 pieds et 6 200 pieds.
Sample points giving a segment MSA
Vérifier un peu de chaque côté de la route peut faire disparaître ce problème plus ou moins, et c'est ce qui est fait dans certains endroits, mais cela ne peut pas être utilisé pendant l'approche car vous essayez activement de vous rapprocher du sol. Si vous faites une vérification large du terrain, vous ne serez jamais autorisé à atterrir sur un aéroport situé dans une vallée ou sur un terrain montagneux.
Donc, revenons au problème. Les systèmes d'évitement du terrain obtenaient deux lectures très différentes en fonction du moment et de la position exacts, parce qu'ils coupaient juste le bord des carrés MSA et que l'un de ces carrés couvrait des crêtes élevées qui se terminaient au niveau de la mer juste à l'intérieur de la limite du carré. À un moment donné, on pensait que l'on avait 5 000 pieds d'air clair sous soi, et le moment suivant, on demandait à la pauvre IA confuse de monter pour éviter le terrain.
Ce problème ne peut pas vraiment être résolu en tant que tel, mais il peut être amélioré en réduisant la distance d'échantillonnage et en utilisant des données d'élévation en pleine résolution au lieu du résumé MSA-carré. Le problème est que cela coûte plus cher en termes de CPU et que cela ne peut pas être fait tout le temps. Pensez à un vol de Londres à Delhi ; vérifier cela tous les 30 mètres le long du parcours va prendre beaucoup de temps, et toutes les données haute résolution ne sont même pas en mémoire en même temps. Cependant, les données haute résolution sont déjà utilisées dans certains cas, notamment pour les trajets courts proches de la MSA ou pour les trajets d'approche connus, mais ceci se produisait sur un trajet plus long qui se trouvait être celui précédant le début de l'approche réelle. Néanmoins, il est assez facile d'ajuster cela, alors faisons-le et voyons ce qui se passe.
Les vols suivants ont été beaucoup, beaucoup mieux. Hourra ! Je vais prendre un café pour fêter ça, mais quelque chose me trotte dans la tête.
Le café terminé, je vérifie les routes exactes sur la carte (tout le monde peut le faire - c'est dans le menu du développeur sous le titre "Toggle Air Traffic Paths"). Et oui. Le vent avait changé - j'avais activé la météo réelle - et le trajet de la traversée du pays commençait quelques kilomètres plus au nord, ce qui signifiait que toutes les bêtises avec les coins d'écrêtage dans le code d'évitement du terrain avaient simplement cessé d'être un problème.
Bien.
J'ai réglé la météo manuelle, refait le test, et... eh bien, c'est mieux, mais ça rebondit toujours entre deux altitudes différentes même si la MSA est maintenant plus ou moins stable.
Si vous vous souvenez, tout ceci se passe pendant l'approche. Lorsque ces segments sont créés, l'autorisation de terrain pour chacun d'entre eux est vérifiée et le profil d'approche global est modifié de sorte que l'on ne vous dise pas de descendre à l'altitude normale, puis de remonter pour éviter le terrain pour une partie ultérieure de l'approche. Pour ce vol, l'aéroport de destination se trouvait dans les plaines près de la côte, mais était entouré de hautes montagnes au sud, de sorte que ce système entrait en jeu et maintenait les altitudes d'approche beaucoup plus élevées qu'elles ne l'auraient été normalement. Cependant, il y a un autre point de cheminement impliqué ; il est créé quelque part entre vous et l'aéroport et utilisé comme une sorte de passerelle entre la croisière et l'approche. Le segment après ce point de cheminement est également contrôlé par le terrain, mais si des ajustements liés au terrain sont effectués sur les segments d'approche suivants, ils ne sont pas repoussés sur ce segment de pré-approche. Normalement, cela ne devrait pas se produire et même si l'approche était modifiée pour franchir le terrain, il faudrait un ajustement très inhabituel et important pour que les segments d'approche soient poussés plus haut que le point de cheminement de pré-approche.
Mais au moins, c'est un problème simple à résoudre. Correction faite puis testé à nouveau.
Cette correction est bonne et la prochaine série d'altitudes est... étrangement basse. Si basses, en fait, que le mode "oh shit" de l'évitement du terrain se déclenche. Il ignore complètement la route et utilise simplement les mouvements récents de l'avion pour prédire une position proche et la vérifier. Cela signifie que le MSA est ignoré quelque part, et qu'il manque maintenant une instruction de montée.
Après d'autres tests, il s'avère que cela est dû à une vérification, pendant l'approche, qui tente d'éviter les instructions de montée inutiles. Si vous êtes déjà à basse altitude et que vous faites appel à un aéroport pour atterrir - c'est-à-dire un vol typique de petit avion - vous ne voulez pas qu'on vous dise de monter de plusieurs milliers de pieds pour ensuite redescendre à peu près à l'altitude à laquelle vous êtes déjà. Alors, le contrôleur essaie d'être gentil et abaisse certaines parties de l'approche si vous êtes déjà en dessous. C'est très bien, mais... pas... si... l'approche a été élevée pour éviter le terrain !
Corriger ça, re-test.
Tout va bien pendant la première moitié du vol; je sais, en observant le code en cours d'exécution, qu'à partir de maintenant, la MSA devrait se situer entre 5 200 et 7 200 pieds, selon le moment exact. Des données d'élévation à haute résolution sont utilisées maintenant, les deux crêtes montagneuses sont raides de gauche à droite et assez étroites d'arrière en avant par rapport à la direction du vol, donc la MSA peut varier assez rapidement. L'instruction de montée attendue arrive : "Montez au FL080". Attendez, huit mille ?
C'était pourtant un niveau de vol. La vérification de l'altitude de transition (le point où l'on cesse d'utiliser les "pieds" pour l'altitude et où l'on commence à utiliser le "niveau de vol" et un ensemble spécifique de règles pour les choisir) pour le contrôleur d'approche montre qu'elle est fixée à 6000 pieds. Une fois de plus, de minuscules changements dans la synchronisation et la position ont affecté la MSA, mais cette fois-ci, c'est parce que les données d'altitude à haute résolution ont été utilisées. Pour l'extrémité inférieure, un simple "ajouter un peu de marge de manœuvre et arrondir à 500 pieds supérieurs" donnait soit 5500 soit 6000 pieds. À l'extrémité supérieure, les données étaient arrondies au niveau de vol et, en raison de la direction du vol, elles étaient envoyées au FL070 ou au FL080. Cela se produisait uniquement parce que l'altitude demandée dans le plan correspondait exactement à l'altitude de transition !
D'accord, celle-ci est probablement déroutante, mais pas techniquement fausse - certainement dans les limites du système.
Ainsi, la vérification originale et simple "Laissez l'IA voler sur une route et voyez si elle commence à faire du "tunneling" a pris trois jours pour être correctement résolue, entre la recherche, les changements de code, de nombreux re-tests, puis la validation des changements à plus grande échelle en utilisant les tests automatisés existants. Du côté positif, cela a été un test de torture absolu pour un certain nombre de systèmes qui fonctionnaient très bien dans la plupart des circonstances, et a mis en évidence des problèmes qui ont pu être soit corrigés, soit au moins expliqués. En revanche, le revers de la médaille... yeesh !
Pour un vol normal, rien de tout cela n'aurait été un problème. Vous auriez été bien au-dessus du terrain, descendant sur l'approche depuis le haut. Ce vol étant court, le Cessna 172, qui monte lentement, était encore en phase de montée lorsque les vecteurs d'approche ont été émis pour des altitudes supérieures à celles où il se trouvait. Entre les deux aéroports, il y avait des crêtes qui ne faisaient qu'écrêter les carrés de données d'altitude du terrain, de sorte que les vérifications MSA ont renvoyé des altitudes qui variaient de manière significative avec de minuscules variations à la fois de la position et du moment. L'aéroport de destination n'avait pas de flux défini, X-Plane les générait donc automatiquement, mais cela ne tient pas compte du terrain. Ainsi, grâce au fait que l'aéroport se trouve dans une vallée escarpée, la MSA des vecteurs d'approche est restée exceptionnellement à 4 500 pieds jusqu'en finale pour un aéroport proche du niveau de la mer. Enfin, l'altitude prévue correspondait exactement à l'altitude de transition du contrôleur, ce qui amplifiait les petites différences qui auraient normalement été arrondies.
Si l'un ou l'autre des aéroports s'était trouvé à quelques miles au nord ou au sud, ou plus loin l'un de l'autre ; si les crêtes s'étaient arrêtées à quelques miles plus au sud ; si la côte s'était trouvée à quelques miles au nord ou au sud ; si l'avion utilisé avait pu monter plus rapidement à l'altitude de croisière ; si le plan avait demandé une altitude supérieure à l'altitude de transition du contrôleur ; si les MSA du terrain n'avaient pas également chevauché l'altitude de transition ; si l'aéroport avait défini des flux qui empêchaient les atterrissages par le sud ; si le vent avait été différent. Si l'une de ces choses n'avait pas été exactement ce qu'elle était, rien ou presque ne serait arrivé.
Donc, mes remerciements à la personne qui a déposé ce rapport de bug ! Complètement par accident, vous avez envoyé plusieurs systèmes au-delà de ce qu'ils étaient capables de faire et, en déposant le rapport et en joignant le journal du même vol, vous m'avez permis de creuser dans le système et de me débarrasser d'un bon nombre d'aspérités. Cela a également donné un exemple fantastique de "Pssh, comment cela peut-il être difficile ?" pour l'hypothèse évidente de "bien, vous montez, puis vous descendez, travail terminé".
Plus quelques nuits blanches, mais bon.
Oh, le problème du "guidage dans une colline" (“vectored into a hill”) ? Je n'ai pas pu le reproduire...
Traduit avec l'aide de DeepL
Ce n'est pas forcément facile à lire (c'est plus fluide sur le lien en anglais) mais c'est toujours intéressant de savoir comment un developpeur réfléchit face à un bug étrange :
Gestion de l'altitude : Une histoire de hauts et de bas dans le système ATC
Publié dans News par Jim Keir | dev ATC Laminar
Décider de l'altitude dont un segment de vol particulier a réellement besoin ne devrait pas être difficile, n'est-ce pas ? Vous décollez d'un endroit proche du sol, vous montez jusqu'à l'altitude de croisière que vous avez choisie, vous commencez à descendre lorsque vous approchez de votre destination et vous vous retrouvez finalement au sol. Qu'est-ce qui peut bien se passer ?...
... Un rapport de bug est arrivé de quelqu'un disant qu'il avait été dirigé vers une colline pendant l'approche. C'est quelque chose qui a reçu beaucoup d'attention pour X-Plane 12, donc j'ai sauté sur l'occasion et j'ai reproduit le vol.
Heureusement, la personne qui a signalé le problème avait inclus le bon fichier log (ce n'est pas le cas de tout le monde, nous recevons des tas de cas où le log montre que la simulation se trouve dans le menu principal) et avait donné les détails du plan de vol ; rien de compliqué, un simple vol direct entre deux aéroports distants d'environ 35 miles, avec une altitude de croisière de 6000 pieds.
Je l'ai configuré et laissé l'IA voler. Le décollage s'est bien passé, puis on lui a demandé de monter à 8000 pieds - au-dessus de l'altitude de croisière demandée. En regardant la carte, je me suis dit qu'il y avait une crête montagneuse sur le chemin, ce qui était logique. Puis les problèmes ont commencé. Descendre à 7000, puis descendre à 5500, puis monter à 7000, puis une boucle sans fin de montée/descente à ce qui semblait être des choix aléatoires de 5000, 6000, 7000 et 8000 pieds.
Toutes les situations "normales" - et beaucoup de situations inhabituelles - pour l'approche et l'atterrissage sont couvertes par des tests automatisés et ils avaient été passés la veille, donc je savais que ce n'était pas un problème courant mais ce serait quand même sacrément ennuyeux si cela vous arrivait.
En creusant un peu, la première chose que j'ai trouvée est un bon vieux bug.
Avant XP12, le système ATC était presque exclusivement écrit pour les avions de ligne et un vieux morceau de code avait un problème où, si vous étiez en dessous de l'altitude de croisière normale pour un avion de ligne, on pouvait vous dire de monter légèrement avant de commencer la descente. Cela se produisait parce que, lorsque l'AI était transféré de la tour au contrôleur de niveau supérieur, il était déjà suffisamment proche de l'aérodrome de destination pour être considéré comme une arrivée.
Si vous y réfléchissez, cela casse complètement le modèle d'altitude simple. Le Cessna 172 monte lentement, il abordait donc toute la séquence "descente, approche, atterrissage" par le bas. X-Plane 12 est conscient de cela, donc cela ne devrait pas être un problème.
Donc, nous avons résolu une instruction de montée inappropriée. Nouveau test.
Comme prévu, la même chose qu'avant ; une indécision totale de la part du contrôleur. Le problème suivant apparaît rapidement : l'évitement du terrain.
A première vue, l'évitement du terrain devrait aussi être simple : Si colline, monter. La plupart du temps, c'est le cas ; là où cela ne fonctionne pas, c'est lorsque vous essayez délibérément de vous rapprocher du sol, par exemple pendant l'approche et l'atterrissage.
Si vous êtes familier avec les cartes d'aviation, vous connaissez l'acronyme MSA (Minimum Safe Altitude). En gros, la carte est divisée en grands carrés et, dans chaque carré, il y a une MSA indiquée. Si vous traversez ce carré, vous avez la garantie de ne pas toucher le sol si vous restez au-dessus de cette altitude. C'est simple, ça marche, et X-Plane fait à peu près exactement la même chose. Les données d'élévation du terrain sont réduites de manière à ce qu'un seul pixel donne la MSA pour la zone qu'il couvre, ce qui rend la vérification relativement rapide et facile.
Ce vol comportait deux crêtes abruptes allant du niveau de la mer à environ 6 200 pieds qui se terminaient juste à l'intérieur d'un carré MSA, et le vol se déroulait juste le long du sommet à environ 90 degrés par rapport aux crêtes. Quelques centaines de mètres de différence d'emplacement au moment où les échantillons de terrain ont été prélevés ont suffi à modifier la MSA entre environ 50 pieds et 6 200 pieds.
Sample points giving a segment MSA
Vérifier un peu de chaque côté de la route peut faire disparaître ce problème plus ou moins, et c'est ce qui est fait dans certains endroits, mais cela ne peut pas être utilisé pendant l'approche car vous essayez activement de vous rapprocher du sol. Si vous faites une vérification large du terrain, vous ne serez jamais autorisé à atterrir sur un aéroport situé dans une vallée ou sur un terrain montagneux.
Donc, revenons au problème. Les systèmes d'évitement du terrain obtenaient deux lectures très différentes en fonction du moment et de la position exacts, parce qu'ils coupaient juste le bord des carrés MSA et que l'un de ces carrés couvrait des crêtes élevées qui se terminaient au niveau de la mer juste à l'intérieur de la limite du carré. À un moment donné, on pensait que l'on avait 5 000 pieds d'air clair sous soi, et le moment suivant, on demandait à la pauvre IA confuse de monter pour éviter le terrain.
Ce problème ne peut pas vraiment être résolu en tant que tel, mais il peut être amélioré en réduisant la distance d'échantillonnage et en utilisant des données d'élévation en pleine résolution au lieu du résumé MSA-carré. Le problème est que cela coûte plus cher en termes de CPU et que cela ne peut pas être fait tout le temps. Pensez à un vol de Londres à Delhi ; vérifier cela tous les 30 mètres le long du parcours va prendre beaucoup de temps, et toutes les données haute résolution ne sont même pas en mémoire en même temps. Cependant, les données haute résolution sont déjà utilisées dans certains cas, notamment pour les trajets courts proches de la MSA ou pour les trajets d'approche connus, mais ceci se produisait sur un trajet plus long qui se trouvait être celui précédant le début de l'approche réelle. Néanmoins, il est assez facile d'ajuster cela, alors faisons-le et voyons ce qui se passe.
Les vols suivants ont été beaucoup, beaucoup mieux. Hourra ! Je vais prendre un café pour fêter ça, mais quelque chose me trotte dans la tête.
Le café terminé, je vérifie les routes exactes sur la carte (tout le monde peut le faire - c'est dans le menu du développeur sous le titre "Toggle Air Traffic Paths"). Et oui. Le vent avait changé - j'avais activé la météo réelle - et le trajet de la traversée du pays commençait quelques kilomètres plus au nord, ce qui signifiait que toutes les bêtises avec les coins d'écrêtage dans le code d'évitement du terrain avaient simplement cessé d'être un problème.
Bien.
J'ai réglé la météo manuelle, refait le test, et... eh bien, c'est mieux, mais ça rebondit toujours entre deux altitudes différentes même si la MSA est maintenant plus ou moins stable.
Si vous vous souvenez, tout ceci se passe pendant l'approche. Lorsque ces segments sont créés, l'autorisation de terrain pour chacun d'entre eux est vérifiée et le profil d'approche global est modifié de sorte que l'on ne vous dise pas de descendre à l'altitude normale, puis de remonter pour éviter le terrain pour une partie ultérieure de l'approche. Pour ce vol, l'aéroport de destination se trouvait dans les plaines près de la côte, mais était entouré de hautes montagnes au sud, de sorte que ce système entrait en jeu et maintenait les altitudes d'approche beaucoup plus élevées qu'elles ne l'auraient été normalement. Cependant, il y a un autre point de cheminement impliqué ; il est créé quelque part entre vous et l'aéroport et utilisé comme une sorte de passerelle entre la croisière et l'approche. Le segment après ce point de cheminement est également contrôlé par le terrain, mais si des ajustements liés au terrain sont effectués sur les segments d'approche suivants, ils ne sont pas repoussés sur ce segment de pré-approche. Normalement, cela ne devrait pas se produire et même si l'approche était modifiée pour franchir le terrain, il faudrait un ajustement très inhabituel et important pour que les segments d'approche soient poussés plus haut que le point de cheminement de pré-approche.
Mais au moins, c'est un problème simple à résoudre. Correction faite puis testé à nouveau.
Cette correction est bonne et la prochaine série d'altitudes est... étrangement basse. Si basses, en fait, que le mode "oh shit" de l'évitement du terrain se déclenche. Il ignore complètement la route et utilise simplement les mouvements récents de l'avion pour prédire une position proche et la vérifier. Cela signifie que le MSA est ignoré quelque part, et qu'il manque maintenant une instruction de montée.
Après d'autres tests, il s'avère que cela est dû à une vérification, pendant l'approche, qui tente d'éviter les instructions de montée inutiles. Si vous êtes déjà à basse altitude et que vous faites appel à un aéroport pour atterrir - c'est-à-dire un vol typique de petit avion - vous ne voulez pas qu'on vous dise de monter de plusieurs milliers de pieds pour ensuite redescendre à peu près à l'altitude à laquelle vous êtes déjà. Alors, le contrôleur essaie d'être gentil et abaisse certaines parties de l'approche si vous êtes déjà en dessous. C'est très bien, mais... pas... si... l'approche a été élevée pour éviter le terrain !
Corriger ça, re-test.
Tout va bien pendant la première moitié du vol; je sais, en observant le code en cours d'exécution, qu'à partir de maintenant, la MSA devrait se situer entre 5 200 et 7 200 pieds, selon le moment exact. Des données d'élévation à haute résolution sont utilisées maintenant, les deux crêtes montagneuses sont raides de gauche à droite et assez étroites d'arrière en avant par rapport à la direction du vol, donc la MSA peut varier assez rapidement. L'instruction de montée attendue arrive : "Montez au FL080". Attendez, huit mille ?
C'était pourtant un niveau de vol. La vérification de l'altitude de transition (le point où l'on cesse d'utiliser les "pieds" pour l'altitude et où l'on commence à utiliser le "niveau de vol" et un ensemble spécifique de règles pour les choisir) pour le contrôleur d'approche montre qu'elle est fixée à 6000 pieds. Une fois de plus, de minuscules changements dans la synchronisation et la position ont affecté la MSA, mais cette fois-ci, c'est parce que les données d'altitude à haute résolution ont été utilisées. Pour l'extrémité inférieure, un simple "ajouter un peu de marge de manœuvre et arrondir à 500 pieds supérieurs" donnait soit 5500 soit 6000 pieds. À l'extrémité supérieure, les données étaient arrondies au niveau de vol et, en raison de la direction du vol, elles étaient envoyées au FL070 ou au FL080. Cela se produisait uniquement parce que l'altitude demandée dans le plan correspondait exactement à l'altitude de transition !
D'accord, celle-ci est probablement déroutante, mais pas techniquement fausse - certainement dans les limites du système.
Ainsi, la vérification originale et simple "Laissez l'IA voler sur une route et voyez si elle commence à faire du "tunneling" a pris trois jours pour être correctement résolue, entre la recherche, les changements de code, de nombreux re-tests, puis la validation des changements à plus grande échelle en utilisant les tests automatisés existants. Du côté positif, cela a été un test de torture absolu pour un certain nombre de systèmes qui fonctionnaient très bien dans la plupart des circonstances, et a mis en évidence des problèmes qui ont pu être soit corrigés, soit au moins expliqués. En revanche, le revers de la médaille... yeesh !
Pour un vol normal, rien de tout cela n'aurait été un problème. Vous auriez été bien au-dessus du terrain, descendant sur l'approche depuis le haut. Ce vol étant court, le Cessna 172, qui monte lentement, était encore en phase de montée lorsque les vecteurs d'approche ont été émis pour des altitudes supérieures à celles où il se trouvait. Entre les deux aéroports, il y avait des crêtes qui ne faisaient qu'écrêter les carrés de données d'altitude du terrain, de sorte que les vérifications MSA ont renvoyé des altitudes qui variaient de manière significative avec de minuscules variations à la fois de la position et du moment. L'aéroport de destination n'avait pas de flux défini, X-Plane les générait donc automatiquement, mais cela ne tient pas compte du terrain. Ainsi, grâce au fait que l'aéroport se trouve dans une vallée escarpée, la MSA des vecteurs d'approche est restée exceptionnellement à 4 500 pieds jusqu'en finale pour un aéroport proche du niveau de la mer. Enfin, l'altitude prévue correspondait exactement à l'altitude de transition du contrôleur, ce qui amplifiait les petites différences qui auraient normalement été arrondies.
Si l'un ou l'autre des aéroports s'était trouvé à quelques miles au nord ou au sud, ou plus loin l'un de l'autre ; si les crêtes s'étaient arrêtées à quelques miles plus au sud ; si la côte s'était trouvée à quelques miles au nord ou au sud ; si l'avion utilisé avait pu monter plus rapidement à l'altitude de croisière ; si le plan avait demandé une altitude supérieure à l'altitude de transition du contrôleur ; si les MSA du terrain n'avaient pas également chevauché l'altitude de transition ; si l'aéroport avait défini des flux qui empêchaient les atterrissages par le sud ; si le vent avait été différent. Si l'une de ces choses n'avait pas été exactement ce qu'elle était, rien ou presque ne serait arrivé.
Donc, mes remerciements à la personne qui a déposé ce rapport de bug ! Complètement par accident, vous avez envoyé plusieurs systèmes au-delà de ce qu'ils étaient capables de faire et, en déposant le rapport et en joignant le journal du même vol, vous m'avez permis de creuser dans le système et de me débarrasser d'un bon nombre d'aspérités. Cela a également donné un exemple fantastique de "Pssh, comment cela peut-il être difficile ?" pour l'hypothèse évidente de "bien, vous montez, puis vous descendez, travail terminé".
Plus quelques nuits blanches, mais bon.
Oh, le problème du "guidage dans une colline" (“vectored into a hill”) ? Je n'ai pas pu le reproduire...
Traduit avec l'aide de DeepL
