| ★先日のドイツの航空機事故で、スイスの管制官が事実上、航空機2機を衝突進路に誘導したことがデータにより判明。 |
| 2002 年 7 年 20 日 ( 土 ) 12 時 52 分 [ ベルリン 19 日 ロイター ] ドイツ当局は、今月 1 日にドイツ南部上空で発生した航空機空中衝突事件について、スイスの航空管制当局が、 2 機が衝突の直前、コリジョンコース ( 衝突進路 ) を降下していたことに気がついていたとの調査結果を発表した。 この事件では、ロシア人の児童を含む 2 機の乗員・乗客計 71 人が死亡している。 ドイツ連邦航空局の事故調査部門によると、スイスの官制当局は、ロシアの旅客機に対し、輸送機との衝突を避けるために、 2 度にわたって高度を下げるよう指示したが、その直後に、輸送機から降下しているとの報告を受けた。 輸送機の乗員は、機内に搭載されていた自動衝突防止装置 ( TCAS ) の指示に従って高度を下げたと報告したという。 |
大手電算機メーカーに勤務する制御システム部長 S 氏 ( 48 歳 ) は、航空機事故ニュースに接するたびに身の縮まる思いがする。ここ 20 数年間ずっとである。そう、あの出来事があって以来ずっと・・・。
S 氏 28 歳、仕事というか、まさにコンピュータが面白くてたまらない。
電力、官制など制御系システム開発に配属されて 6 年、設計から開発、検査までを小チームながら任されるまでになった。 開発したシステムで描いた思い通りに制御機器が作動し、人間系を動かしそして全体としてコントロールが出来るさまは圧感である。
制御系システムは、リアルタイム処理が命であり、最大のスループットが要求される。
排他制御、優先制御、メモリ制御、入出力制御、ロールインアウト、割込み制御、タスク分割、マルチ制御、ブート処理などまっさらなコンピュータ上に、目的とするシステム機能を実現するためのすべてのプログラムを手作りで 1 つ 1 つ開発して組み込む。
今で言うなら、 BIOS 、 OS 、ミドルウェア、通信、データベース、アプリケーション、マンマシンのすべてをフルスクラッチで 1 から開発することに相当する。
大変な労力であり、頭自身がコンピュータと化し、フル回転しないと開発も検査もできない。その結果、生まれたシステムについて、その動きのプログラムの 1 つ 1 つ、命令の 1 語 1 語が手にとるように判るのである。したがって、どんな異常、どんなプログラムバグが発生しても、入力データからの前方追跡、結果からの逆追跡が頭の中でシミュレーションできるので範囲を限定しやすく、たちどころに修正ができる。
28 歳 S 氏まさに自他ともに認めるプログラムの天才 ( ？ ) 、システムの救世主、 「我が世の春」である。
S 氏の設計、開発能力を遺憾なく発揮できるかっこうの獲物 ( システム ) がまた舞い込んできた。しかも ODA がらみの海外案件である。
会社が受注したフィリピンのマニラ航空設備に関する ODA にいくつかのコンピュータシステムが含まれており、その中の 「航空固定情報自動中継システム ( 通称 ATMS )」が S 氏の担当になったのである。
ATMS の概要は以下の通りである。
国際民間航空が安全に健全に経済的に運行されるよう国連に ICAO ( International Civil Aviation Organization ) が設置され、 185 ヶ国が加盟している。
各加盟国がその運営に責任を有する情報通信のための世界的規模の航空固定通信網 ( AFTN ： Aeronautical Fixed Telecommunication Network ) が ICAO により設置されている。
ATMS は AFTN を支援するためのコンピュータシステムで隣接する各国の空港、内外航空会社、国内の関係機関 ( 管制機関、気象関係 ) に通信回線を接続し、これら相互間で交換する飛行計画 ( フライトプラン ) や気象通報、遭難通報、ノータムなど電文メッセージを自動中継するシステムである。
簡単に言えば、AFTNは飛行機が世界の空を安全に飛ぶための情報 ( 除く軍事関係 ) を交換するためのインターネットであり、 ATMS は各国に設置されるメッセージスイッチングの為のノード、いわゆるサーバーシステムである。現状は、紙テープ付テレタイプにより人間がメッセージスウィチャとして手動で中継している。
人命の安全に関わる情報を最大のリアルタイムで間違いなく管制室や各国に中継する緊張感のあるシステムである。システムの性格上 「ごめんなさい」が許されるものではない。綿密に設計しもちろん OS もふくめ全てを 1 から手づくりした。約 10 ヶ月の開発期間を終えシステムが完成し、現地マニラ航空での操作教育も終了、順調にグランドオープンを迎えた。
運用後は、評価も極めて高く、隣接諸国からの視察も頻繁である。
3 ヶ月の運用支援もほぼ終え、帰国まで残り1週間となったある日、国内航空会社の事務所Aから次の要請が入った。
「事務所を今日引っ越す。回線の手続 / 接続までに今日 1 日かかるので、今日の電文メッセージは仮事務所へ FAX で流して欲しい。 」
事務所移転を当日に連絡してくるなど、まさにフィリピンらしい。当日はフィリピン現地友人が観光地タガイガイへドライブ案内してくれる日でもあり楽しみにしていた。思案したが、当然自動 FAX 転送などの機能は装備してない。回線不調の時に備えて国際間のメッセージのために別のノードを経由させる代行機能や一時保留処理は装備しているが、航空会社 A 事務所としては、この ATMS 1 回線のみであり、他からの代行手段もとれない。一時保留処理では、 1 日の滞留は長すぎる。時間も追っており、緊急事態ということでプログラムへのパッチで対応することとした。
対応策
ATMS では、入電されたメッセージに対し解析してルーティング処理を実施して複数の中継先をビットパターンで表現している。
そこでおのおの電文のルーティング結果としてA事務所に中継するものは、その中継ビットをオフ ( 0 ) にして、代わりに ATMS 室内にある予備機に中継出力させる。この予備機に出力したものを人手により FAX で送信することとした。プログラムパッチはもちろん 16 進数による機械語である。
14 ビット目がA事務所への中継の ON / OFF 、 0 ビット目が予備機である。
A 事務所宛のテスト電文を作り試行したところきちんと予備機に出力され、それを操作員がFAXでA 事務所へ送信し、A 事務所も確認できた。
そこで、予定通り友人とともに、観光地タイガイタイにドライブに出かけた。夕方 5 時位までには戻り、回線開通とともにこのパッチをはずせばよい。
充分に楽しみ手みやげのバナナをかかえて夕方 17 : 30 頃戻ると現場では大変な事になっていた。
システムを止め、昔ながらのテレタイプを総動員して人手による中継をやってるではないか。
テープが山のように貯まり、その中継に四苦八苦している。
帰ってきた S 氏の顔を見ると、ざわめきにも似た歓声が上がり、操作責任者が事情を説明し始めた。
それによると、
青い顔で事情を聞く途中から S 氏はもう原因が思いあたった。
当然、今朝のプログラムパッチであり、何かしら論理演算のビット指定に誤りがあったのだ。
調べて 15 秒でとんでもないミスを見つけた。
AND 命令であるべきところを XOR 命令 ( Exclusive OR ) でパッチしていたのである。論理演算のマシン語は以下の通りである。
| 命令コード | 16 進数コード |
|---|---|
| AND | ” 52 “ |
| XOR | ” 53 “ |
| OR | ” 54 “ |
” 52 ” とパッチすべきを ” 53 ” としていたのである。このマシンの 16 進数マシン語は全部暗記していただけにまったくの人為的ケアレスミスである。
しかし、この 16 進コード設定の間違いがルーティング先を根本的に変える結果となった。ルーティング先ビットに対して ” 1 ” で AND か XOR をとるかによって結果が逆転する。
| 0 0 1 1 | 0 0 1 1 | ||
| 結果 | 0 0 0 1 | 結果 | 0 1 1 0 |
これにより、中継すべきビットとそうでないビットのオン / オフが逆転してしまった。
パッチ時のテストでは A 事務所宛てのみのテスト電文であり正常であった。その他宛てには影響ないものとしてテストは省略した。
調査開始後、ものの 5 分でシステムを正常化させた。システム復帰時には本当の喜びの歓声が沸いた。人為的ミスであることを正直に説明すると、現場責任者は理解してくれ、報告書にはマニラ特有の電源異常でコンピュータ不安定としておくとウィンクしてくれた。お詫びを兼ね、 S 氏は今回の FAX 送信などのケースが将来的に発生した場合の対処として、予備機にも中継が代行できる機能拡張を無償で実施した。
このシステムはパーツ部品を交換しながらも 16 年間の長期運用を達成した。新システムのリプレース時 ( このシステムも社で受注 ) には、 S 氏は偉くなりすぎて担当できなかったが、聞くところによると現地係官から 「前のシステムで S 氏はどんなシステムトラブルでも 5 分で修復させた、今度の新システムでは誰が 5 分で修復させられるのか」と聞かれたそうである。
そういえば最近のシステムは複雑怪奇、必要も無い機能満載の OS 、ミドルウェア、人間はバカであるを前提としたビジュアル入出力画面などメモリ満載のとても醜いシステムに思えてくる。高度に進化した成果なのか、商業主義に踊らされた結果なのか、トラブルが発生しても 5 分で修復などとても考えられない。
Simple is beautiful. システムはシンプルで見えるものがいい。その点今注目されているオープンソースの流れは是非、テクニカルカルチャーとして定着して欲しいものである。
ところで S 氏は 20 年前のこの経験を教訓とし、その後のシステムに次のように生かしている。