O-Lab +Ossan Laboratory+

Ossanの研究所です。

改札機で電源が入らなかった話

極東ブログ: 首都圏改札トラブル
http://finalvent.cocolog-nifty.com/fareastblog/2007/10/post_218b.html


はっきりとわかりづらいのだが、
バグ付き改札機は、センターからの正常メッセージを、
「電源断せよ」と理解して動作したということなのだろう。


率直に言えば、そんな電源断の機能が遠隔操作で
可能なシステムとして設計されていたのかというのが、やや驚きだ。

改札機…。
この手の仕事をついこの前までしてたので、言及してみる。


通常、駅では朝、以下の手順の作業を行います。
1.駅構内の電源を入れる
2.駅構内の機器の電源を入れる
3.各機器を利用可能状態にする


で、今回のトラブルは
電源投入→利用可能状態にする
の間で発生したんでしょう、おそらく。


電源投入後にIC対応改札は「ネガデータ」を受信します。
この「ネガデータ」は各駅へ配信後、改札機へ転送が行われます。


データは
・毎日定時に各駅へ配信されるデータ
・即時に使用停止にさせるための随時配信のデータ(緊急ネガ)
の2通りがあって、朝に改札機に転送されるデータは
定時配信のネガデータになります。


この定時配信のデータは随時配信のデータよりもデータ量が多く、
何らかの拍子に破損データになることも結構頻繁にあります。
(センター→各駅、の転送中に破損するのが一番多いですが)


そのため、改札機側でデータチェックを行う仕組みがあるのですが、
そのデータチェック時に異常データ受信を
検出した後の処理にいくらか問題があるようです。

260万人の朝の足を直撃 プログラムに潜んだ“魔物” - ITmedia News
http://www.itmedia.co.jp/news/articles/0710/12/news117.html


調べたところ、ネガデータに「ある長さ、ある件数」といった条件が重なった時、
データが読み込めなくなるプログラム不具合が判定部側にあることが判明。
このため、判定部はエラーを返しながらネガデータ読み込みの
リトライをひたすら繰り返す状態に陥り、起動処理が止まった。


通常、改札機は
1.データ受信
2.データチェック
3.メモリに読み込み&記録
4.次のデータ要求
5.次のデータがなければ、受信完了で利用可能状態へ移行
が大雑把な処理手順になってます。


今回はデータチェック時の処理に異常があったので、
利用可能状態へ移行できなかった、つまり、厳密に言うと
「電源は入ったけど、利用可能状態へ移行しなかった」
が正解だと思われます。





この手のトラブルを避けるには改札機を納品させるメーカーを
2社以上にして、各駅に異なるメーカーの機器を
バランスよく設置する、っていうのが最適解です。


が、機器数を増やすと、テスト工数が単純に考えて倍以上になる、
(異なる機器同士のクロステストが追加されてしまう)
という問題があって、それだと反ってバグが見つかりにくくなったり、
とか、別の課題が発生しかねないわけで、なかなか踏み込めないのが現状です。