4月8日19時11分に発生した航空路レーダー情報処理システム（RDP）障害の詳しい経緯が分かった。RDPの運用に必要な「飛行計画情報」に、異常なデータがあったためにシステムがダウンした。飛行計画情報とは、便名や行き先、飛行経路などのデータを航空機ごとにまとめたもののことだ。
国土交通省によれば、「異常なデータが加わった原因がソフトのバグであることは間違いないが、どのプログラムによるものかはまだ特定できていない」という。システムを開発したNTTデータは、「原因は現在究明中でお答えできない」（広報部）としている。
異常なデータは、名古屋発福岡行きのある便の飛行計画情報を処理する過程で見つかった。この便の飛行計画情報のなかには、本来あり得ないはずの経由地のデータが含まれていた。RDPを構成する2台のハードは、異常処理が起こったとして自動的に再起動したが、異常なデータが消えずに残っていたため、19時11分から何度もダウンと再起動を繰り返した。 RDPの本番系2システムは、受信したデータの整合性をチェックするために2台のハードで同じ処理を行っているので、異常なデータを認識すると同時に、2台とも再起動の処理を実行した。
この結果、通常10秒周期で更新されるレーダー画面が、1分ほど更新しなくなった。異常に気づいた東京航空交通管制部は、このような状態のハードでRDPを運用するのは危険性が高いと判断。本番系での処理を停止することにして、待機系である3台目のハードに処理を引き継がせた。
ただし、待機系は飛行している航空機のデータを、空港の管制システムに自動的に引き継ぐ機能がない。また、航空機が高度を変えた時には、管制官がシステムにその高度を入力するが、待機系ではその情報が他の管制官が見る画面に反映されない。いずれも、管制官同士が電話でやりとりするなど、業務の一部を人手を介して行う必要がある。業務の処理速度は遅くならざるを得ず、国内の空港を出発する航空機だけで130便に30分以上の遅れが出た。
8日の21時30分になって、RDP内の異常なデータが障害の引き金になっていることが分かり、東京航空交通管制部は1台のハードから異常なデータを削除して手動で再起動した。RDPが通常の状態に戻ったことから、21時32分に待機系から本番系へ再び切り替えた。もう1台のハードは障害原因を究明するため、1度ダウンした時点でRDPから切り離している。
飛行計画情報は飛行計画情報処理システム（FDP）からRDPに送信される。FDPとは、すべての航空機の飛行計画を航空会社などから集約して一括処理し、各航空機の管制業務に必要な便名、行き先、飛行経路などの情報を、全国各地の管制部門に対して出力するシステムだ。RDPでは、この飛行計画情報と、航空路監視レーダーから送られてくる航空機の実際の位置情報とのズレがないかを判定している。
国土交通省は、「FDPが持つデータや、RDPのハードディスクに書き込まれたデータの中に、不正なデータはなかった。メモリにデータを展開した際にソフトウエアを原因とする不具合が起こったと考えている」とした。今年に入ってRDPのソフトウエアに変更を加えたことはなく、一番近い変更で昨年10月だったという。
不正なデータを取り除いてシステムに再起動をかけると問題なく復旧することから、現在は本番系の2台のハードで運用を続けている。9日の運行に影響は出ていない。
