米国で起きた航空管制システムの機能不全、メモリ不足が原因と判明

あるAnonymous Coward 曰く、

先週の土曜日、米バージニア州の航空管制センターでシステムに不具合が発生し、ワシントン空域の数百ものフライトが遅延もしくはキャンセルされるなどの被害が出た。一部ではサイバー攻撃の可能性も疑われていたが、米連邦航空局（FAA）が解析した結果、原因は今年初めに行われたレーダー施設で行われた管制システムのソフトウェアアップデートであることが判明したという（FAA、The Washington Post、GCN、Slashdot）。

問題があったのは、頻繁に参照されるデータをカスタマイズされたウィンドウに表示する機能。ここで本来なら不要になったデータは削除されるはずだったが、メモリ内にデータが残りそれが肥大化。その結果、システム全体の動作に必要な処理能力を奪ったとのこと。FAAおよび開発を行ったロッキードマーティンは、問題が解決するまでシステムの運用停止を決めたという。

システムの運用停止を決めた？

[Anonymous Coward]

そんな重要なシステムを止めてしまって大丈夫なのか？と思って
リンク先を見にいったのですが、「システムの運用停止」という記述は見つけられませんでした。

FAAのプレスリリースには以下のように書かれていて、問題の表示機能の使用を一時的に停止しただけのようです。

By temporarily suspending the use of this function, we have eliminated the possibility of this particular issue from occurring again.

Re:システムの運用停止を決めた？

[Anonymous Coward]

原因のソフトウェアアップデートが「今年初めに行われた」というのも対応する記述がみつかりません。プレスリリースで関係しそうなのは

The availability rate of the En Route Automation Modernization (ERAM) system has been higher than 99.99 percent since it was completed nationwide earlier this year.

というところですが、直訳すれば「今年のこれまでにアメリカ全体でERAMシステムが完成して以来、その稼働率は99.99%を超えている」という意味で、ソフトウェアアップデートとは関係ないし、「今年初め」という表現もありません。

Re:

[Anonymous Coward]

追加窓が別スレッドなら、解放処理忘れでは無く、解放されない時がある感じかも。。。
UIマルチスレッドは応答性とかメモリ使用量とか文句なしですが、トラブル再現とデバッグは非常にきつい。。。

タイトルの原因が違うような気がします

[Anonymous Coward]

原因 → メモリリーク
結果 → メモリ不足

こうではないですか？
部門の方はリークって書いているのに...。

Re:タイトルの原因が違うような気がします

[Anonymous Coward]

メモリリークがあっても十分にメモリがあれば大丈夫と思ってるんじゃないですかね。

slashdotでは「FAA System Runs Out of Memory」とあります。これを和訳したのでしょう。
これは正しいですが、和訳するときに間違えたのでしょう。
意訳するときに、上記のようにメモリリークがあっても十分にメモリがあれば大丈夫という
思い込みがあれば、このように間違った意訳をしてしまうかもしれません。

Re:タイトルの原因が違うような気がします

[albireo (7374)]

「機能不全の原因」としてはどっちもあり

たとえば、整備不良→ブレーキ故障→事故なら
「事故の原因は整備不良」「事故の原因はブレーキ故障」どっちでもおかしくはないでしょう。

--
うじゃうじゃ

Re:

[Anonymous Coward]

メモリ不足ならメモリを増やせばいいが
メモリリークならメモリの使用を見直すしかない
普通は対処しなければならない手法がわかるよう記載する

＞ 「事故の原因は整備不良」「事故の原因はブレーキ故障」どっちでもおかしくはないでしょう。

なのでおかしい
整備不良とブレーキ故障の因果関係があるからといって整備不良が原因とはならない
風が吹けば桶屋が儲かると似たようなもの

例　タンクに穴が開く→ガスケツ→エンスト

Ａ「ガスケツで車が動きません」
Ｂ「じゃあガソリン入れとけ」
Ａ「ガソリンつぎ足しましたがガスケツで車が動きません」
Ｂ「そんなばかな」
Ａ「やっぱタンクに穴が開いてたらいくら入れたってムリっすよね」

＃状況がわかってない人がよくやる必要な情報を伝えることができない例

Re:タイトルの原因が違うような気がします

[albireo (7374)]

別に読んだ人が解決しなきゃいけないわけでもないし、あくまで見出しであって詳細は別に書かれてるんだからそこまでこだわらんでも(;´∀｀)

--
うじゃうじゃ

Re:

[Anonymous Coward]

僕もあなたと同じ感覚を持っていて、どちらも自然に読めるのだけれど、
最近の揚げ足取りの風潮から、初動の印象はとても大事です。

最初の一発で誰を悪者にするかで、その後の展開がずいぶん違う。
要は分析力、洞察力不足なのに批判力だけは強い人が多いのだけれど。

チャチャ

[Anonymous Coward]

まぁ、エンストはエンジンストールの略で
ガス欠でエンジンが止まったのはエンストって言わないんですけどね。

Re:

[Anonymous Coward]

(エンジンストップじゃなかったのか…)

Re:

[Anonymous Coward]

「不足」という言葉には、どこかに「十分」レベルがあり、それよりも少なかったというニュアンスがあります。

しかし、メモリリークが原因なら、「十分」レベルはどこにもありません。
どんなに大量のメモリを用意しても、いずれは使い切ってしまいますから。

なので、「不足」という言葉は不適切だと思います。

Re:

[Anonymous Coward]

何言ってんの。
毎日再起動すれば問題ないじゃん。

Re:

[Anonymous Coward]

？？「メモリ不足ならツクモで買って足すしかないよね、しかたないね」

Re:

[Anonymous Coward]

ツクモだと不良品をつかまされて「相性保障がないからもう一度購入して」と言われますよ。

Re:

[Anonymous Coward]

交換保証を付けたいから、メモリモジュールと液晶はツクモなんじゃないかと

1日1回再起動

[Anonymous Coward]

これでだいたい解決するんじゃね？

Re:1日1回再起動

[Anonymous Coward]

「フライト中ではありますが、本機はただいまより再起動するのですべての機能が停止します。墜落する前に復旧完了する予定ですので問題ありません」

Re:1日1回再起動

[copper (2040)]

マジレスしておくと、機体の制御系もエンジンも２重系で２台以上積んでるから、１つずつの再起動は可能。

Re:

[Anonymous Coward]

おおぉ、空飛ぶ航空管制センター！！

というかクラウドベース（スペクトラム基地）？

Re:

[Anonymous Coward]

民間機は空中給油機能がないから、余程頻繁に再起動が必要でない限り、給油着陸時に再起動すれば間に合うだろう。
問題は軍用機で、整備上・政治的理由等で地球を1/4周程を往還する爆撃機で爆弾満載の往路や、地球最後の日に飛行する予定の国家空中作戦センター機（例：E-4Bナイトウォッチ）が再起動が必要では困るだろうな。
特に後者は退役も検討された様だが、中共がDF-41（東風41 MIRV車両移動型ICBM 弾頭10基 射程12000km）やJL-2(巨浪2号 SLBM 3個以上のMIRV 射程8000km以上)の実用化配備が迫っている以上、相当任務機は装備され続けるのでは？

Re:

[Anonymous Coward]

Windows Updateがバックグラウンドでパッチ適用しちゃって操縦中にいきなり再起動ウィンドウが……

# 念のため言っておくとネタなのでAC

Re:

[Anonymous Coward]

ついにUnixもWindows相当になったということですね。

1日1回再起動が有効な例

[i_i (22332)]

B787型機 [reuters.com]

Re:1日1回再起動

[Anonymous Coward]

再起動したら、そのまま動かなくなる可能性も。

＃動いているものには触れるな

Re:

[Anonymous Coward]

電気設備の法定点検で帰ってこなくなったサーバーが何台あったかお題にするのも良いかもしれない。

# ヤバイのでAC

Don't forget to FAA

[Anonymous Coward]

Free() after assignment, please.

Re:

[Anonymous Coward]

JavaなどのGCのある言語で、参照を消し忘れたに一票。

Re:

[Anonymous Coward]

static Map<LoginInfo,Dialog>で、new LoginInfo("user1").equals(new LoginInfo("user1"))=falseな実装なんて、いくらでもあるよなー。

Re:

[Anonymous Coward]

C言語では配列にゴミが残っていても(長さを管理していれば)別に問題ないが、Javaでは配列の使わなくなった要素にはnullを代入しないと参照が残ってGCされないというのは盲点だった。

富豪的プログラミングの成れの果て

[Anonymous Coward]

ちょっとした図表入りでもたかだか10MBとか20MBそこらのワープロ文書を作成するのにメモリ10GB搭載マシンを使う今日この頃
数値シミュレーションするのにメモリ不足など気にせず、ジャブジャブとリソース使いまくりのお気楽プログラミングが出来るのはハッピーだ

だが長時間連続運転する計測制御システムみたいな製品を作る時にメモリーリークとかがあったら怖い
短時間のテストではメモリ不足に気がつくはつずがない

ああ、そうか、メモリは有り余っているから仮想マシンを２つ動かして片方はホットスタンバイ状態にしておく
もう一方がメモリ不足になったらマシンを切り替えて処理継続、その間にメモリ不足の方はリセットして次の切り替えに備えてスタンバイしておけば良いのか.......

Re:

[Anonymous Coward]

普通（日本の航空管制システムの場合ですが）、人命に関わる事でもあり、開発したシステムは利用者（航空管制官（業務）、航空管制技術官（システム））の習熟も兼ねて何か月も評価してから、システム切替えします。航空大国である米国ではいきなり切替えしても大丈夫、という事なのでしょうか。

もしかして、今回のケースではシステム評価期間中に頻繁にシステムアップデートしていて長期運用試験はやってないけど、やった事にしてたとか。（異国の開発者の皆様お疲れ様です。・・・本当の地獄はこれからだ？）

Re:

[Anonymous Coward]

数ヶ月程度では顕在化しないような問題だったのかも。

Re:

[Anonymous Coward]

実際、稼働後5年経って発生なんて障害、多々あるしね。
でも、ロングランテストならリソース状況くらい毎日確認する…つーか、それがなければロングランの意味がないと思うんだけどなあ。

Re:

[Anonymous Coward]

知ってる限りだと、ログの行数（通し番号）が21億ちょっとを越えたところで死んだシステムってのがあってな
毎日平均で40万件弱ぐらいの処理をやってて、稼働15周年を目前にフリーズしてみんなで慌てたことがあったなぁ

# 符号つき32bitの最大値越えてオーバーフロー

Re:

[Anonymous Coward]

ある値が増え続ける場合、最大いくつか、行ったらどうするかってのは、基本設計だよなあ。
と言いつつ、特定のウインドウを上げて落としてるだけである連番が桁溢れ（3桁）して、障害通知された例が最近あった。
普通に使ってれば10も行かないので、誰も気にしてなかったのかどうなのか。
保守で入った人間には分からん。

Re:

[Anonymous Coward]

おっと、UNIX time の悪口はそこまでだ。

Re:

[Anonymous Coward]

真に富豪的なら、動的に取得解放を繰り返さず、静的に一括して取っておけばよいのではないだろうか?

Re:

[Anonymous Coward]

１日１台ずつ使い捨てでいいんじゃない？

Re:

[Anonymous Coward]

一方ロシアはアセンブラでシステムを組んで4重化した

Re:

[Anonymous Coward]

VMwareFTの様なホットスタンバイだったら、いざと言うときにスタンバイ側もメモリ不足を起こしていたりして…。 :-)