境界処理バグが引き起こした自動改札機トラブル

今月12日早朝に首都圏の鉄道で大規模なトラブルを引き起こした原因となった日本信号製の自動改札機。筆者の出勤時には駅員の対処も完了しており、みんな素通り状態で改札機を通って、特に大きな混乱もなく処理されていた。もっとも中には精算トラブルなどで、足止めを食った人もいたはずで、どうせなら今日一日タダキャンペーンにでもしてしまえば、苦情ではなく感謝を集められただろうにと思わなくもない。まあ、1日分の売上げが無くなることを思えばそんな決断はおいそれとは下せないだろうが。

さて、朝日新聞によれば、この障害を引き起こしたのは、2バイトのデータだったという。改札機は毎朝最新のネガデータを取り込むが、そのネガデータのサイズがある一定範囲内になった際に2バイトずれが生じ、データの適合性チェックでエラー、起動プロセスがキャンセルされるという感じだったらしい。

障害の引き金になったのが、2バイト(2進法で16けた)のデータだった。例えば改札機の場合、ネガデータは5451件分(6万5518バイト)を一区切りとして処理される。処理は4バイトずつ進めるため、最後に2バイト余る。全角ひらがなや漢字1文字分のデータ量だ。

半端な2バイトも、件数がこの一区切りまでなら正常に処理されていた。だが、5452件以上になると「85件増すごとに5件の割合で、余った2バイトの処理を忘れる」(同社)というプログラムの欠陥があった。

1文字分のミスで大トラブルに 首都圏改札機トラブル

また、日本信号報告によれば、ネガデータの件数がある範囲内にあるときだけ発生する不具合であったという。

トラブルの原因は、ICカード判定部を搭載した自動改札機において、中央のコンピューターから送信されたデータをICカード判定部の記憶部に読み込むプログラムの一部に不具合があり、データを正常に読み込むことができず機器異常となり改札機がダウンしました。

又、このデータ数がある件数以上、且つある条件下で発生する仕組みであった為、品質保証の過程で発見されず潜在化し、10 月12 日になって中央から配信されたこのデータ数が条件範囲にヒットした事により、顕在化したものと判明いたしました。

弊社自動改札機の不具合について

5,451件で65,518バイトということは、1件あたり12バイトで、65,412バイトとなるので残りの106バイトが制御コードとなるのだろう。確保メモリサイズを65,536バイトとするとヘッダ長は18バイト、ペイロードが65,518バイトと言うことになる。処理を4バイトずつ進めると言うことは、制御コードは先頭104バイト+終端2バイトとなっているのだろうか。まとめると次のようになる。

確保メモリサイズ(65,536バイト)=ヘッダ(18バイト)+制御コード(104バイト)+データ(12バイト)×5,451件+制御コード(2バイト)

メモリサイズの確保は64KBを超える場合、1KB(1,024バイト)単位で行われるのだろう。1,024バイトにはちょうど85件(1020バイト)のデータが入るので、1KBごとに終端制御コードの2バイトの処理忘れが顕在化すると考えるとつじつまが合いそうだ。何らかの処理を5件単位で行っていて、たまたま最後の5件の領域までデータが埋まっていた場合、2バイトの制御コードの有無が問題になると言うことだろうか。この考えに基づくと、今回の事故はネガデータの件数Nが5451+ 85*k + 81 ≦ N ≦ 5451+ 85*k + 85の場合に発生すると言うことになる(k=0,1,2,...)。

この推測が当たっているかどうかは定かではないが、不具合の原因が境界処理のミスによるものであることは確かだ。テストで見つからなくても仕方ないかと言う気もするが、1日止まると何億という損失の発生するミッションクリティカルな機器であることを考えれば、より徹底的なテストを行うべきだろう。特に12日のトラブルに引き続き、同じ原因で18日にも窓口処理機のトラブルを起こしたのはお粗末にすぎる。自動改札機ならまだ良いが、同社の取り扱うCTC(列車集中制御装置)、ATC自動列車制御装置)、ATS(自動列車停止装置)、交通管制システム、交通信号制御器・灯器などに同様の不具合が出ないことを祈るばかりだ。