【鉄道】260万人に影響した自動改札機の不具合：プログラムに潜んだ“魔物” [07/10/12]

どうせフェールセーフなんて考えは微塵もないんだろ。

単独起動できたんなら、なんで午前３時に起動不能になってから、
全復旧するのに午前１１時頃までかかったのかな。

>>203
うちのの策定した仕様、すごい厳しいんですよ。ひとつひとつに理由はあるんですけど別に要らないんじゃない？てな事までてんこ盛りでして。
今回のも単独起動というより非常扱いで駅員以下まったく周知されてなかったわけです。まあ原因が判明したので言えることなんですけどね。

>>203
「単体起動”など”」とあるから、出来なかった駅が遅延じゃないかな。
台数が4000台超ということからすると、午前中に復帰ってかなり上手くいった方だと思う。

自動改札機は、毎朝ホストコンピュータから紛失したり執行したりした IC カードのデータが
送られてきますが、データが特定の容量の場合にのみ、自動改札機が正しく読み込めない
プログラムの欠陥と分かりました。

問題のあったプログラムは、大量のデータが送られてくると２度に分けて読み込む仕組みで、
特定の容量の場合、分割されたデータの端数がトラブルを引き起こしてしまうということです。

http://www.nhk.or.jp/news/2007/10/15/k20071015000103.html

また別原稿で、日本信号以外の自動改札ではデータを一括で読み込む仕組みだったため
問題が起きなかったと言っております。

>>206

普通、この手のデータは一括送信です。今回のようなトラブルを防ぐため。
日本信号が 無能すぎるだけです。
もう少し 頭のいいエンジニアを雇ってください。

レアケースといえば　何でも許されると思ってました

今も反省はしていません

>>207
送信は一括で、読み込みが分割なだけじゃないか？

>>28
10/1に発覚するバグは期の変更かそれかどっちかだよな・・・
ちゃんとテストしようよ・・・orz

賠償は検討中か
どうなるんだろうかね？

境界値処理のバグ？ この間の Excel 2007 の問題を思い出した。

労働環境が境界上にありますから・・・

稀に事象の地平線まで行くような気がするのは気のせいか。気のせいだ。うん。

一括でとか分割してとか言うのがメモリ上でのバッファリングの話だったら、
サイズ不詳のデータを一度にメモリに読み込もうとする設計の方がアホなんだが。

>>215
> 一括でとか分割してとか言うのがメモリ上でのバッファリングの話だったら、
> サイズ不詳のデータを一度にメモリに読み込もうとする設計の方がアホなんだが。

今まで顕在化しなくて、今回だけ超偶然がかさなったっぽいところから見て、それは無いだろ。

>>216
…何を言わんとしてるか分かってレスしてるか？

組み込みソフトウェアなら、詳細を見てみないとわからない。

>>218

見なくても わかりますよ。
同業他社は一切 不具合は はっせい していません。
なぜなら、そもそもデータを分割していないからです。
この じてんで、いかに日本信号のエンジニアが低脳か理解できます。
仕様をみるまでも ありません。

ID:M78yTQeh　＝　ID:h+v0KYIQ　か？

こいつ、只のヴァカだなｗ　　あまりに理解ができていなさすぎる。

>>215 と >>219 って言ってる事がまるで違うんだが、
同じに見えるほど頭悪いのか?

ホストと言っているからヘッダにレコードサイズが付いてて、その回数分だけネガデータの
オカレンスが続くような電文と予想できるんだけど、件数不定だからループで例えば
1000 件ずつ読んで二次記憶装置に保存するんじゃない? 件数×レコード長のメモリ確保して
一括で読んで一括で保存するってリソース的な作法でやらないでしょ。全国何十年分のネガ
データなんて 255 件や 65535 件じゃ足らないだろうし。

ってのが >>215 の主旨なんだけど、何か通じない人が多いみたいなので書き直したわ。
ちなみに >>219 は他人ですよ。

賠償が無くとも、鉄道業界から日本信号は制裁でしばらくの間、取引停止になるだろうな。
少なくともJR東日本は間違いなくそうするだろうな。
倒産までいかずとも、日本信号の経営には大ダメージになるのは必至かもしれんな。

取引停止は影響大きすぎてありえない
運用契約を値切るとかそういうのはあるだろうけど

>>222
サーバから自動改札機に送るデータが、「ある長さ、ある件数」になった時に読み込めなくなる
自動改札機側のメモリに貯めてる配列エリアを壊すようなパターンだったと想像
送られてくるのは日々の差分データだから、「何十年分」ではない

まさか0件だったりして（笑）
0件テストを甘く見て定義情報が不足するデータが作られたとか。

相手のミスにつけこんで、そんな喧嘩腰で取引先と付き合っても、なんの得もないだろ
民間同士のこういう取引は、常に互いが恩を売りあっておくもんだ

発注元が威圧・恫喝で無理を通すのは仕様です

>>220
> ID:M78yTQeh　＝　ID:h+v0KYIQ　か？
>
> こいつ、只のヴァカだなｗ　　あまりに理解ができていなさすぎる。

あなたはコンピューターの基礎知識すら理解できていない人間のくずです。
社会の役にも立っていません。生きるだけ無駄な二酸化炭素を吐き散らしているだけの有害生物です。
あなたは現実世界で大勢の人間に嫌われています。
あなたの存在自体が社会悪ですしね。

ありがちなミスではあるよな。

>>224
> 取引停止は影響大きすぎてありえない
> 運用契約を値切るとかそういうのはあるだろうけど

そらそーだｗ
日本信号がメインなんだろ。ATCは。
京三製作所でメインを切ったって聞いたこと無いし

駅サーバ〜駅務端末のプロトコルが統一されてないのってどうよ。
1つの駅には1社しか入れないから、という理由？

>>227
必死すぎて笑えるｗ

汎用機とミニコンの中継サーバーのトラブルか

ようするにできる人間に集中しすぎるんだな

システムは使う人間を幸せにするが、作る人間を不幸にする　　−デスマ廃人

リトライ複数回数で復帰できなけば
次処理へ移行の処理が抜けていたのか。
通信異常渋滞検出タイマーでも入れておけ。

やれやれ

また日本信号製でトラブル　６５駅窓口でＩＣ券使えず

http://www.asahi.com/national/update/1018/TKY200710180344.html?ref=rss

システムを入れ替えた直後でもないのに連続トラブルって変だ。

またかｗ

>>108

時間がなくても力技の残業、徹夜作業でなんとかなる、
そう信じてやまない上層部はいまだにどこにでもいるね

プロジェクト管理の本やら講座やらで
いの一番にダメ出しされるタイプ。

本番稼動時に発覚したバグなんて本来すべてレアケースだろう。
というかレアケースじゃなかったらテスト時に見つかる。

>>236
(憶測)
ネガティブデータが分割されて送信されはじめたのが最近で、
分割の内部処理上の境界値がプログラムによっていくつかあるんだろうな。

んで、その境界値あたりのテストが欠けていた。

ありがちなパターンとしては、データ件数が分割単位の倍数のときに
終端記号だけが含まれたブロックを送り忘れるとか、不要な空ブロックを送ってしまうとか？

素朴な疑問だがネガデータのサーバーは
改札機のメーカー別にあるのでしょうか？

また同一の駅には異なるメーカーの改札機は
存在するのでしょうか？

レアケースも想定しておけば問題なし。
すごいパターン数になるけど。

>>243
つ ファズ・テスト

障害なんて出さなくてあたりまえ、出したら死ね
その意識がなくならない限りIT技術者になろうとする若者は減り続けるだろうな
短納期でバグがないものをつくるなんてどだい無理なんだよ
自業自得だ

>>245
そのあたりはマイクロソフトのおかげで昔よりよくなったよ。
失敗しても修正パッチ流せばOKって風潮だし。

はぁ？ただのﾊﾞｯﾌｧｵｰﾊﾞｰﾌﾛｰ？
どんなサルがプログラム組んでんだ？

要するにほとんどが基本情報処理技術者
資格くらいしか持っていない低脳ばっか。
ちなみに私は異種業者だ第二種ですが
取得済み。

日本信号ですらソフト開発部門を子会社待遇にする現状に絶望した！
http://pc11.2ch.net/test/read.cgi/prog/1192192069/

基本情報すら取れなさそうなのがいるのが、今のソフトウェア開発現場。
これからこういったシステム障害は頻発するぞ。間違いない。

まともな人だけ選べるほど人材いないって。