ハクソク

世界を動かす技術を、日本語で。

プログラマーが信じる航空に関する誤解

353日前原文(flightaware.engineering)

概要

  • 航空データ は現実世界では非常に 複雑かつ不規則
  • 多くの 前提や常識 が実際には 誤り である事例
  • FlightAware や Hyperfeed が直面する課題の紹介
  • 航空業界の データ設計 で起こりやすい誤解
  • 現場でのトラブル やシステム障害の原因となる誤認識

航空データに関するよくある誤解

  • 航空データ は常に クリーン で 標準化されている という思い込み
  • データ型やスキーマ設計 時の前提が 現実と乖離 している場合
  • Hyperfeed （FlightAwareのフライト追跡エンジン）が 複雑な状況 を解釈する役割

フライトに関する誤解

  • フライトは必ず ゲートから出発 する
  • ゲート出発は 一度きり である
  • フライトは 予定時刻の数時間以内 に出発する
  • フライトは 予定日以内 に出発する
  • フライトには 必ずスケジュール が存在
  • フライトは 空港で離着陸 する
  • 飛行機（ヘリコプター以外） は空港でしか離着陸しない
  • フライトの 最大飛行時間 は十数時間、または数日以内
  • フライト識別は 航空会社コード＋数字 （例：UAL1234）
  • フライト識別は 航空会社コードまたは機体登録記号 で一意
  • 識別子（例：B6459）は 登録記号や便名で明確に区別 できる
  • フライトには 複数の便名が存在しない
  • 複数便名のフライトは 必ず“主”便名がある
  • 便名は 途中で変更されない
  • チケット記載の便名＝ パイロットや管制が使う便名
  • フライト識別子に 無関係な航空会社コード が使われない
  • 同日に 同じ便名を使うフライトは存在しない
  • 同時刻に 同じ便名のフライトは存在しない
  • 大手航空会社で 同じ便名が数分差で重複しない

空港に関する誤解

  • 空港は移転しない
  • ターミナルやゲート番号は 一貫した命名規則
  • 滑走路は一つの空港専用
  • 空港には ICAOコード（4文字）とIATAコード（3文字） が常に存在
  • 空港には ICAO、IATA、地域コード が必ず存在
  • 米国運輸省が 一意の空港コード を割り当てている
  • 空港に 複数のIATAコード は存在しない
  • 米国空港のICAOコードは 必ずKで始まる
  • ICAOコードの 末尾3文字＝IATAコード （米国空港）
  • ICAOコードで 地理的地域が分かる
  • IATAコード保有＝空港
  • ICAOコード保有＝地球上の場所
  • 空港は 何らかの有名な識別子 を必ず持つ

航空会社に関する誤解

  • IATAコードの重複はない
  • 航空会社が 複数のIATA/ICAOコード を使うことはない
  • 機体を見れば 運航会社が分かる
  • 航空会社は 特定路線に便名を割り当て
  • 航空会社は 自社運航便のみに便名を付与
  • 航空会社は 便名を自社運航便だけに割り当てる

ナビゲーション・航空管制に関する誤解

  • ウェイポイント名は一意
  • 高度の定義は一つだけ
  • 航空管制の フライト情報は正確
    • 出発済み表示＝実際の出発
    • フライトプランキャンセル＝絶対に運航しない
    • レーダーデータは正確に機体を識別
    • 重複エリアのレーダーは同じ位置を示す
    • フライトプランの到着地＝到着意図
    • ダイバート（目的地変更）は一度きり

トランスポンダ・ADS-Bに関する誤解

  • ADS-Bメッセージは機体からのみ発信
  • ADS-Bは機体や空港車両からのみ発信
  • ADS-Bは何らかの車両からのみ発信
  • GPS位置は常に正確
  • GPS位置は既知の誤差範囲内で正確
  • ADS-Bメッセージは正しい便名を常に含む
  • トランスポンダは機体種別を正確に表示
  • ADS-Bで機体登録記号が常に分かる
  • トランスポンダのMode Sアドレスは正確に設定
  • 同一機体のトランスポンダは同じMode Sアドレス
  • 便名にNULL等の変な値は使われない
  • 登録変更時にトランスポンダも必ず更新
  • ADS-Bメッセージは送信通りに受信される
  • 偽のADS-Bメッセージは送信されない
  • トランスポンダ故障やケーブル断線は起こらない

まとめ

  • 航空データの設計や運用 には多数の 落とし穴
  • 現実の運用やデータ管理 で想定外が頻発
  • FlightAware や 同業他社 でも 誤解に起因する障害 が発生
  • 柔軟で堅牢なシステム設計 の重要性
  • 現場経験と多様な事例 の蓄積が信頼性向上の鍵

Hackerたちの意見

こういうリストは、もっと詳しい説明があった方がいいよね。このリストは、少なくとも多くの主張に対して例をリンクしてくれてるけど（例えば、定刻に出発したのに40時間遅れて到着するフライト[1]）、何が起こったのかは説明してないんだよね。とはいえ、リンクの中にはすごく参考になるものもあるよ。例えば、ICAO空港コードを持つ火星のクレーター[2]について：「2021年4月19日、インジェニュイティがジェゼロから火星で初めての動力飛行を行い、記念のICAO空港コードJZROを受け取った。」

└

これはしばしば退屈な理由によるものです。例えば、2週間のフライトはGoogleの気球で、悪天候のためにフライトが40時間遅れたり、ADS-Bはパイロットによって設定されるのですが、多くのパイロットが単純に間違って設定してしまったり、という感じです。

CGP Greyによる空港コードの混乱をまとめた素晴らしい動画だよ。https://www.youtube.com/watch?v=jfOUVYQnuhw いくつかの深い理由についても（試みとして）説明してる。

フライトは空港で離着陸する。私の印象では、ブラジルの航空を管理しているすべての古い（2010年以前の）コンピュータシステムがそれを感じ取って、ハックで修正したと思う。 > 空港は決して動かない。また、滑走路も決して動かない。もし滑走路が動いたとしても、方向は変わらないし、空港や滑走路が動くなら、その前に工事があるはずだよ。そこに「航空機は滑走路にしか着陸しない」とも付け加えたいな。「そう、航空機は滑走路とヘリポートにしか着陸しない。」

└

私の印象では、ブラジルの航空を管理しているすべての古い（2010年以前の）コンピュータシステムがそれを感じ取って、ハックで修正したと思う。もう少し詳しく説明してくれる？

この記事についての別の議論だけど、FlightAwareのフォーラムでね。https://www.flightaware.com/squawks/view/1/7_days/popular_ne...

「プログラマーが信じる誤解…」のリストは、テストのソースとして見ることが多いんだ。各項目は、ソフトウェアに間違って組み込まれた仮定を根本から覆すためのユニットテストや統合テストを生むべきだと思う。

└

これらは確かにテストを生み出しました。以前そこで働いていた時、地味なものからデビッド・ブレインのスカイダイビングまで、千を超えるテストがありました。彼らは本当に良いエンジニアリングに重点を置いている集団です。

面白いのは、これらの「誤解…」投稿の共通点が、プログラマーたちが人間が設計し、人間が運営し続けるシステムが、厳密にルールに従っていてエッジケースがないと思っていることだよね。

└

プログラマーとして航空の世界をモデル化するソフトウェアを書いていると、次のようなことを前提に考えがちですが、残念ながらそうはいかないんですよね。ソフトウェアは残念ながら厳格なルールに従うので、現実を包括できる厳格なルールのセットを見つけるのが課題です。データベーススキーマを書くときには、フライトには出発空港と到着空港があるのが自然だと思いますが、残念ながらそうではありません。

└

プログラミングの職業は、柔軟な人間のシステムと厳格なルールに基づく機械とのインターフェースに関するものです。それが繰り返し出てくるのも不思議ではありません。

└

プログラマーはすべてを厳格なルールのセットに還元するのが好きです。なぜなら、それが私たちの思考の仕方だからです。確率的な「アナログ」パラメータが少ないほど良いです。でも、もちろん現実はそんな風には動かないんですよね。

└

いや、そうでもないよ。ソフトウェアは定義上、扱おうとするドメインのモデルを作らなきゃいけないからね。モデルって結局、ルールのセットなんだ。ルールがなければ、ソフトウェアは実際に問題を解決するために何もできないし、無意味になっちゃう。代わりにユーザーにNotepadを渡して「好きにやって」って言うようなもんだよ。プログラマーは、実際のドメインにはどれだけ多くの例外やエッジケースがあるかをよく理解してると思う。例えば、うるう秒みたいな簡単なことを一般の人に聞くと、たいてい「そんなこと言ってるの？」って思われることが多いよ。

面白い実話を一つ… 航空機には時間に依存しないユニークな識別子がないんだ。航空機には機体に発行されるシリアルナンバーがあるけど、それだけではユニークじゃない。航空機のライフサイクル全体で唯一のユニークな識別子は、製造者、機種、シリアルナンバーの組み合わせなんだ。これは、航空機のユニークな識別子を定義する特許に関わっているから知ってるよ（良くも悪くもね）。ICAOの航空機タイプデザインator + シリアルナンバーの組み合わせが、機体にとって最も永続的な識別子だと思う。でも、もし機体が十分に改造されて以前のタイプでなくなったら、この識別子も変わることがある。個人的には、航空機のような大きなものにシンプルで時間に依存しないユニークな識別子がないのが不思議だったよ。P.S. 航空機の登録番号はナンバープレートみたいなもので、変更されるからね。テールナンバーは、どこに何が描かれているかによって曖昧で誤解されることもあるし、ICAOの24ビット航空機アドレスはADS-Bトランスポンダーボックスに結びついていて、技術的には航空機間で移動したり再プログラムされたりもできるんだ。

└

テセウスの船

└

滑走路のIDも時間とともに変わりますよね。

└

「本当の」ユニーク識別子って、めっちゃ一般的な問題だよね。解決策はほぼいつも「モデル、メーカー、シリアル番号」だし、必要なら製造年も加える。プログラマーが言語で人を重複排除しようとするのを見たこともあるよ。

└

エンジンについても同じことが言えると思うよ。

└

製造者、メーカー、シリアル番号の組み合わせ。 > 航空機のユニーク識別子としてそれを定義する特許。これが特許になるほど新しい理由がめっちゃ気になる。

└

個人的には、航空機のような大きなものにシンプルな時間不変のユニーク識別子がないことが信じられなかった。普遍的なシステムがなくても、物事がこれほどうまく機能しているのが驚きだよね。航空業界は比較的閉鎖的に成長してきて、航空機製造をしていた国は最近までそれぞれ独自のやり方をしてた。航空の歴史の前半は、ある意味フリーフォールみたいなもんだよ。今はほとんどが何らかの基準に従っているグローバルな航空業界があるっていうのが、私にとっては驚きの部分なんだ。もし、ほとんどの旅客機が十数社のメーカーに絞られていなかったら、そうなってなかったかもしれないね。

私はフライトデータレコーダーを作っている会社で、フライトデータ分析のソフトウェアを開発しています。主にヘリコプターが中心ですが、固定翼機も扱っています。基地や病院、屋上、駐車場、サッカー場、空港、ゴルフ場などで離着陸する航空機を扱っていると、航空に関する様々な誤解に日々振り回されている気がします。

うーん、シニアソフトウェアエンジニアで商業パイロットの私としては、ちょっと混乱してる。リストの中のすべてのことではないけど、いくつかは知ってるからね。地球の磁場の変化によって滑走路番号が変わることは見逃してたかもしれないけど、それも事実だよね。滑走路22？今は滑走路21になってる。でも、なぜプログラマーだけがこれを信じるのか、航空業界以外の職業はどうなんだろう？

└

著者はFlightAwareの開発者で、航空ソフトウェアを書く難しさを紹介してるんだよね。

└

いろんな分野についての直感に反する事実を列挙した記事のジャンルがあるよね（人の名前とか音楽とか）。プログラマーとの関連は、こういった事実が関わるソフトウェアシステムを作ることが多いからなんだ。例えば、いくつかの値をプライマリキーや外部キーとして使ったりする。

└

この記事は、プログラマーだけがこれを信じるっていう意味じゃないよ。ただ、「プログラマーが信じるXYZについての誤解」みたいなニッチな記事が人気になっただけで、プログラマーは現実のシステムとやり取りするソフトウェアを作ることが多いから、普段考えないようなエッジケースに直面することがあるんだよね。

ハハ、いいね！このリストを読んでると、プログラマーとして頭が爆発しそうになるよ。これらは全部合理的な前提だと思うし、実装が進むにつれて痛いほど気づかされるのがわかる。自分がすごくバカに思えてくるしね。素晴らしいまとめだ、ブラボー！