新幹線トラブルの原因　容量が一杯でした

ＪＲ東日本の五つの新幹線で１７日に起きた運行トラブルの原因について、同社は１８日、運行データの変更を行った際、
変更した数がシステムの容量を超えたためと発表した。
　ＪＲによると、１７日午前７時に新白河駅、７時４３分に福島駅でポイント故障が発生。このため８時ごろから、
列車が駅と駅の間で止まらないように、新幹線の運行を一元的に管理しているシステム「ＣＯＳＭＯＳ」（コスモス）で、計２４本の列車に対し駅で止まるよう指示を出した。
　その指示が多すぎたため、一時的に容量をオーバーし、午前８時２３分にコンピューターの画面表示が消えた。
　このトラブルで東北、上越、長野、山形、秋田の各新幹線が１時間１５分にわたり、全線で運転がストップした。(共同通信)

http://www.kyoto-np.co.jp/politics/article/20110118000092

何処のシステムだよ？

変更の回数制限なんてあるのかよｗｗｗｗｗｗ

日立じゃなかったっけ？

システムの見直しとか全然やってないんだな
たいていこの手の提案しても却下されて
そのうちシステム停止起こして、俺たちが怒られるわけだけど

日本を震撼せんばかりの出来事だったな

つまり容量が悪かったと

COBOLで作ってあるの？

なーんだ止めるの２３本にしとけばよかったのか
そうすりゃ良かったのにねえ（ガシャーーン

日立の子会社が丸投げ？

２４件で容量オーバーって何時代のシステムだよ

しょぼ杉だろ
あぶねーなー

調べたけどジェイアール東日本情報システムって子会社が作ったんじゃないの？

COSMOSじゃなくて邪神もっこすなんだろこれ

マジで2038年めんどくさいことになりそうだな・・・

コスモス花言葉→乙女の真心
おっ止めの魔心か

>>13
そこと日立だって

北海道まで新幹線ができてもこれなら飛行機のほうがマシだなー
少し遅くても定時性に優れるって触れ込みなのに。

まぁあと15年はかかるだろうからそれまでに改善を期待する

>>13
そこが発注したんじゃないの？

共同通信は記事を端折りすぎ


処理限界超すダイヤ変更が原因…新幹線障害
http://www.yomiuri.co.jp/national/news/20110118-OYT1T00728.htm
　ＪＲ東日本の全新幹線がシステム障害で止まったトラブルで、同社は１８日、新幹線の運行管理システムの
処理限界量を超えるダイヤ変更データが、自動入力されたことが原因と発表した。

　同社によると、新幹線の運行を管理するシステム「ＣＯＳＭＯＳ（コスモス）」は、トラブルなどで運行本部の
係員がダイヤ変更を行うと、その後に運行される列車のダイヤについて自動計算で変更か所を表示する。
表示は６００件が上限という設定だった。

　トラブルのあった１７日朝、雪の影響で新白河、福島駅でポイントが切り替わらなくなり、運行本部は
列車２４本のダイヤを変更。その際、自動計算で変更されたダイヤが６００件を超えてしまい、画面が
消えるトラブルが発生したという。
（2011年1月18日17時51分 読売新聞）

なんだーシナチクのハッキングだと信じてたよー

>>5
なにものだ？

普通予想される状態の2倍ぐらいの状況でも重くならないようにするだろ

これって起動してる24個のアプリに全部同時に命令したらフリーズしたって
事か？

ME並のクソOS

容量不足に気づいた時点で、HD内のエロ画像を少し削除すれば防げた事故かよｗ

なんで600件とか制限いれるんだろ。。。
無駄なアルゴリズムっぽいんだけど

>>19
自動で臨時のダイヤ組んでくれるんだな。

エピソード２は許さない

後のスカイネットである

>>24
そんなわけねえよw

エロ動画の削除の方が効果的。

カレチの時代ならなんとかなった

10年以上前、日立製の運行管理システムの開発を請け負ったな。
福岡の地下鉄だったけど。

残業が月200時間をこえたのでやめたったわ。

>>29
動画の方が容量大きいからな

まぁ、俺ならPCデポで特売の外付けHDを買ってきて対処するけどなぁ
JRってケチなんだな

一件のデータでも裏には紐付けされた膨大なデータがあるわけだからな。でも今まで起こらなかったのが不思議。そんな特殊なケースだったのか。

それでもきっと世の中にあるプログラムの中ではかなりマシな部類なんだろうな

なるほど。それで時間が経ったら勝手に直ったのか

システムは、同社とJR東日本情報システム、日立製作所が開発し、1995年11月に導入。
2008年と、昨年12月4日の東北新幹線全線開通に伴い更新された。

http://headlines.yahoo.co.jp/hl?a=20110117-00000150-jij-soci

過去二回の更新がどの程度のモノなのかってことだな。
更に言えば、600回の上限設定を誰も覚えていなかった可能性もあるなｗ

東海道新幹線なんて大阪万博以降からほぼ現在に近い本数になってるはずだよな？
あの時代から処理できてることを何で今JR東日本はできねーんだよ

変更箇所を保存する領域が600件固定になっていて、
バウンダリチェックをしていなかったので601件目が入った時の動作がおかしくなったって事でしょ？

>>23
meちゃん侮辱するやつは絶対に許さないよ

>>21
普通にit土方だろ。

アウトルックエキスプレスのファイルのサイズの上限が2ギガなのを知らずに
受信トレイに溜め込みまくって勝手にやる最適化とやらで「メールが消えた！」
って騒ぐ情弱が多かったのを思い出した

朝日記事抜粋。
ＪＲ東日本の五つの新幹線すべてが一時止まった１７日のトラブルは、人的ミスが原因だったことが、同社などへの取材でわかった。
（中略）関係者によると、その後にコスモスを共同開発した日立製作所などと行った調査で、システム自体には問題がないことを確認。
人的ミスでソフトが不具合を起こしたことが判明したという。
（後略）

どういう思考経路でこんな文書になるの？朝日の貴社って莫迦？
こういう問題を起こすこと自体がソフトの欠陥だってことが分かってない？

>>37
JR東は東北新幹線から秋田とか山形に分岐してるから面倒なんじゃないの？

>>42
ソフトのミスじゃないだろ？
600の上限設定をソフトは守ったんだよ？

昔の在来線はシステムダウンしたらベテラン勢がダイアグラムとにらめっこ
しながら人力運用してたなんて話を聞いたことあるけど、在来線みたいに
ややこしくない超シンプルな新幹線で人力運用は無理なの？

これは人的ミスじゃないだろ。
エラーチェック漏れ、要するにバグ。

>>45
ポイント切り替えなどが遠隔操作である以上、
システムを介さない制御は無理だろう多分。

クラウドにしとけよ

上限を超える入力は受付たらだめだろ
そしてメッセージをだすんじゃないの
これがバグじゃなければどんな手抜き設計なんだよ

ＪＲ東日本ちゃん……

６００件の根拠はあるんだろうけど、そんなに表示されても人がついていけない。

伊達直人とぉー！早くＪＲにメモリを進呈してくれぇー！！

>>49
入れた段階ではどの程度の変更が必要になるかがわからないんじゃないかな。

マメにデフラグしないからこういう事になる

>>44
フールプルーフができてないソフトはゴミ

600 という数がどの程度のものかによるなー
各駅の時刻を全部カウントしていけばすぐに越えそうな気もするが

>>53
列車２４本の変更を入力したら、その影響で変更しなきゃいけないところが600件以上あったと。

システム開発は下請けに丸投げしていたのだから日立には何の責任もない。
全て下請けの会社が悪い。

>>57
すごいな

ソフトウェアの開発はさらに下請けが入ってるんじゃないの？

JEISと日立の人は散々どやされただろうなぁ。

多分仕様書にも書いてないな

>>61
たぶん作った奴はもういないんだけどな

容量っつうかバッファオーバーだろｗｗ

>>63
この世には・・・ってことすか・・・

パソコン蛾ぶっ壊れた

ノウハウに該当する数値なんて過去に問題がなければ長期間そのまま
時間が経過すると思考から外れてしまい、規模が大きくなったときに問題発生で原因が掴めず大慌て

再発防止といっても無理だな。
こんなバグなんてあちこち仕込まれてるし、
普段は何の問題もなく動いているシステムなわけで
それを予備的に改めてデバッグしなおせって言っても
莫大な予算がかかる。

山形、秋田だと在来線も関わるからな

こりゃ日立がわるすぎだろ
仕様くらい満たせよ

なんか神話崩壊とかいろいろ言われてて逆にびっくりしたわ
週１でトラブルある国もあるんだろ？
災害のぞいてものすごいレアケースだと思うんだが
調査で原因もわかったんだしさ

これを防ごうと思ったら
全く同じシステムを全く別会社に作らせて
日替わりで二系統常時動作させるしかないよ。

それでも系統切り替えまでの一時的トラブルは防げないけど。

前人事運用システムの開発に加わったら
お盆休みでこけ続けててワロタwwwwwwwwwwwww

最終的にお盆休み取らなければ解決じゃんという解決策が出される始末
NTTの案件でね

>>72
経験のある奴は以前からの慣例、思い込みで根拠のない標準値でつくる
初めての奴は全て確認しないと進まない、その時に発注者も気づくことがままあるんだよな

どこのシステム使っているんだよ。
と真っ先に思ったが。
日立か。
三菱のシステム使っとけよ。

ＪＲ東日本
　・COSMOS(新幹線)　　　　 ＪＲ東日本情報システムと日立製作所との共同開発　　←
　・ＡＴＯＳ（首都圏在来線）　日立製作所開発
JR東海
　・COMTRAC（新幹線）　　　日立製作所開発
JR西日本
　・COMTRAC（新幹線）　　　日立製作所開発
　・SUNTRAS（在来線）　　　 日立製作所開発
JR九州
　・JACROS（在来線）　　　　 日立製作所開発

http://ja.wikipedia.org/wiki/%E6%96%B0%E5%B9%B9%E7%B7%9A%E9%81%8B%E8%A1%8C%E7%AE%A1%E7%90%86%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0

ワロタw
sirei［22］こんな感じにしてたのか？

ガソリンスタンドで使ってるPOSシステムも固まりすぎて使えない
タッチディスプレイはもちろん
キー操作すら受け付けなくなることが多いよ♯

>>38
普通、そんなバグは境界値テストで見つかるはずだろうに

>>44
限界値を超えた時に画面が消えるのが仕様通りであれば、プログラムの問題ではない。
だが普通は警告文を出すなりするだろ。

>>79
現地デバック、試験員のレベルが低すぎたんだろ。
きっと上限なんて頭になかったんだろうな。

>>72
三系統で多数決だ

>>76
明らかにＪＲ東日本情報システムが余計なことしたんだろうなぁ

なんだ、列車への指示が止まっただけじゃないんだな。
画面も消えちゃったのかｗ
これはかっこ悪い。

>>19
表示の限界の計算の限界がごっちゃになってないか?

>>19
>列車の到着予定時刻などを示す部分が、断続的に消えたという。
こっちは全部じゃない。
計算出来ないんだから計算結果が表示されなかったのはわかる。
共同通信の記事ひどいな。

>>85
記事はあってるな、あくまで問題は「表示が消えたこと」

http://www.yomiuri.co.jp/national/news/20110118-OYT1T00038.htm
“同社では、運行に必要なデータが正常に駅などに送信されているとして
「当面は問題なく運行できる」と強調。”

こういうのって原因を誰にでもわかるように簡潔に報告するように
求められるから、一見すると単純ミスのように言われるのだけど、
おそらく複雑な要因が絡み合っているんだろうな。

>>87
表示の限界のデータを送ったのかな。計算はできてたのかもしれない。

火消しの臭いがするな

だからこの手のものを完全に防ぎたいなら
もうシステム自体使うなってことだよ

どうせ日立の糞システムなんじゃねえの？知らんけど

>>92
あたり

つまり便秘によるう〇こトラブルだったわけか

海外に新幹線を売り出そうとしてる矢先のこのトラブル
はたしてこれは偶然なのだろうか

>>93
マジかｗｗｗｗｗｗ

どうしようもない会社だな・・・

最新のニュースを見ると、
600件超えた時に画面に一部表示が消えたのは仕様通りのようだったな。
で、その仕様を知らなかった運用者が不具合だと勘違いしたと。
http://www.asahi.com/national/update/0118/TKY201101180470.html

そもそも運用者が勘違いしやすい設計にしたのも遠因ではあるがな。

何年前のシステムつかってんだよ
化石かよ

>>96
前レスぐらい読めよ
>>76

今回はシステムの不具合ではなかったようだが。

>>76
天下り組が癌だっといういつものオチ？

ｼｮﾎﾞｼｮﾎﾞｼｽﾃﾑやんか

>>55
どっちかというとフェールセーフ

そこで止めるという選択させるシステムなら全然おｋ
大抵暴走モードになるから

>>97
一部表示を消す事でエラーを伝える仕様になってたのか。
実際の画面を見てみないと何とも言えんが、設計がおかしい感はあるな

最初のニュースでは運転席のモニターが消えて運行不可能とか言ってたけどな。

>>97
通常でない状態なのに無表示が仕様なんて考えられ無いよな

これのせいでハロワ息そこなったわ
責任とれよクソどもが

東京駅に各新幹線の専用ホームとか作ればいいんじゃないの？

>>76
昔、日立にいたけどJRのシステムはうちなんだぜ？って得意満面の先輩がいたな
やめて正解だったか

外付けHDD付けろ

>>109
拝承

>>110
おまえの家のP2P用PCと一緒にするなよｗ

子だくさん石田家の長男が勤めてるところ？

低スペすなぁ
日立もアコギな商売してますね

>>109
共同だからじゃないの？
日立は一応歴史は長いぞ＞ＪＲのシステム

だっせええええええええええええええ
一日の本数全部やってもコケないように設計しとけよｗｗｗｗ

システム屋はいくら損害賠償受けるんだ？

ただのバッファオーバーランかよ。


あほくさ〜。

タイトル　新幹線トラブル、運行担当者の誤解原因　ＪＲ東が謝罪
（前略）１８日に記者会見したＪＲ東の宮下直人常務は「人為的ミスだった」と謝罪した。
（中略）ＪＲ東によると、この日朝、雪で福島県内の東北新幹線のポイントが故障し、２４本の列車のダイヤを変更することになった。この際、修正必要箇所がシステムの上限の６００件を超えたので線が消えたが、担当者は不具合と勘違いした。

担当者は表示の仕組みも修正上限数も知らされていなかった。また、システム導入から１５年以上たち、列車本数は４割増えたのに、上限数は当初のままだったという。 （以後略）

おい、朝日の記者、この内容のどこが「運行担当者の誤解原因」なんだよ。お前ら、こんな記事書いてて良心が痛まないのか？

>>6
正しくは
震撼させん
だからシャレとしては無理があったな

これ気づかねえのは運用のミスだろ
ちゃんとマニュアル更新チェックしてんのかよ

あくまでも仕様通りか。
なら、JR東が承認したんだな。

>>115
みどりの窓口が完全人力作業だった時代に初めてシステム化された時から
日立が関わってるんだよな

>>120

>>123
そうそう

>>112
テヘッ　☆

> 東北、上越、長野、山形、秋田

別に多少止まってもよくね？

>>1
>容量を超えたため
俺の人生かよw

ちっ

>>109
日立やめたの？
勿体無い

>>76
J束情報システムとやらが糞って事なんじゃねーの？
みんな日立製じゃねーかｗ

エロ動画ばっかとってるからだろ

よくわからんがこんなの最大件数こえた場合の表示とかって、
JRの目の前でテストしてるんじゃねーの

すげー古そう・・・
16KBとか？

容量ってなんの容量だよ。
曖昧すぎるんだよ記事。

テストが杜撰すぎワロタ
予算いっぱいありそうなのに

>>134
今使ってるシステムは１５年前から運用始めたもの

jarticが止まったのも同じ？

たぶん600件の上限は東北新幹線と上越新幹線のみの時代に設定された仕様だね。
その後、秋田・山形・長野の追加と今回の青森延伸で600件じゃ対処しきれなくなった。

85年当時の仕様がそのまま生きているとは誰も思っていなかったんだろうね。
ハード自体はリプレイスして高度な処理に対応しているんだろうけど、
当時の「600も発生すること無いわなぁｗｗｗこんだけ設定しておけばおｋだろｗｗｗ」が、
今になって事故に繋がったってことだわな。

JR西さんも鹿児島直通とかで同じ轍を踏まないように。

ヒルベルトエフェクトを展開すればトラブルは防げた

福島・盛岡での連結・解放や、2階建て新幹線とか車種も様々。
東海道みたく16両で統一されてシンプルなシステムではないからな。
去年か一昨年にも年末にダイヤ変更がらみでシステム止まってたろ。
早朝5時までのデータ入力が間に合わなくてシステムが起動しなかったとか。

>>139
東海道、山陽、九州の３新幹線は東海道の超過密ダイヤをさばいている
COMTRACで一元管理するようになるからこういうことはないと思いたいなｗ

>>139
もうひとつのスレで安定してたら一生変えないって騒いでる奴がいるよ

>>142
途中駅での連結とかは無いだろうから、さほど管理もややこしくなさそうだけどね。

普通この類の障害はシステム検証で見つかるもんだが
バースト試験してないのか

>>109　意味が分からん

新聞記者が総じて計算機科学に疎いのはなんなんだよ。

>>147
そりゃ新聞社じゃ電算機使わないだろうからよ。

>>147
科学系の記者じゃなく、普通の記者が書いてるからだよ。

>>145
本番環境しかないのでテストできません＞＜

>>149
普通の記事でも見る人が見れば同じ感じをもつんじゃないの？

>>147
疎くても飯が食えるからじゃねえの
突っ込まれても技術者の説明がヘタとか逆ギレすれば何故か自分らの体面が立ったことになるし

これスパコン並の処理能力があったら無問題だったの？
それとも、ハードの処理能力関係無く止まっちゃう仕様だったの？

元はと言えばふぐすまが悪いんだよね

>>147
和文タイピストが失業したから

処理できないのになんでもハイハイ仕事受ける自分達みたいなシステムなんだな
蓋を開けてみればデスマ確定のうんこ案件でフリーズ

>>3
プログラム内で静的に確保してる配列の数とか
あると思うよ

更新したばかりだろ？
更新時に想定されなかったのか

よくある話で良かった