アカウント名:
パスワード:
> JR東のプレスリリースが割と詳しい
これですね(注:pdf) [jreast.co.jp]。確かに詳しいです。新聞記事のあやふやな記述を元に議論するのではなく、まずこっちを見るべきでしょう。
この問題のポイントは
ってところでしょうね。
PDFに挙げられてるような原因で発生する「データ修正が必要な箇所」の数は、大雑把に言えばチェックする時間範囲に比例しますから、4時間先までのチェックなら600件で実用上問題なかったけど、終日チェックするようにしたのに件数上限を増やさなかったのが敗因、って感じですかね。
で、どの時間範囲で何件までの入力が許容範囲なのかな。一分間毎に以前の変更箇所を処理済みっていう保証も無いみたいだし、なんだかなーって感じが。
というより天候不順のように複数の列車が運休･徐行運転を行う場合はそれらを一々入力するんじゃなく、一括してダイヤの組み替えを行うコマンドを別枠で用意しろと
１番線に止めた場合→後続列車の変更が発生２番線に止めた場合→後続列車には影響なしみたいなことまで書いてあるから、影響を考えずにとにかく止めまくったのが原因ではないかな？
通常はそんな影響が大きくなる変更自体してはいけないことなのでは？
運休にして後続列車が追い越すならともかくシステムの警告を消すために２番線に振り替えるのは余計な作業ですよね？
1は2をやるまでの間の対策じゃないの？2が恒久的な対処で、1がそれまでの間の運用での回避．
この手のシステムは問題があるからといって即修正なんてのは無理でしょ．修正しても問題を起こさないことを、事前にしっかりテストして確認しておかないと．修正してみたら、よりひどい障害が発生しましたとかいう事態はこの手のシステムだと致命的だろうし．
路線が枝分かれして行くJR東の新幹線で、終日表示させるというのがちょっと過大な要件だった気もする。
ダイヤ変更をチェックできる 600件/min の縛りがあった、というのは分かったけど、「600件オーバーした途端に白旗降参モード！」つぅのは、やっぱ甘かったんじゃね？
// 将来予測（とか終日予想とか）にこだわりすぎて、// まだ出発してない便の判定にまでリソースつぎ込んじゃって、// 今走ってる便の手当てが薄くなってたんじゃないかなぁ。
だいたい、対策の２番目みたいな話が、ひょっこり出て来るぐらいなら、600件/min という数字の根拠自体が、実はあんまり無かったんじゃないかみたいな邪推が出てきてしまうなぁ。
同社の新幹線の運行数は、コスモスを導入した95年当時の１日230本から2011年の同320本に増えた。08年にはシステムが更新されたが、処理能力は導入当時のままだった。宮下直人常務は「（容量が）足りると考えていたが、設計上の配慮不足だった。お客様に大変な迷惑をかけ、深くおわびする」と陳謝した。
ローカル線はそもそも列車密度が薄くて薄くてたまらないんだから、そんなの導入しなくても駅までは行けるでしょ。途中の線路そのものが通れなくなって駅間に停車せざるをえないのなら、COSMOS入れようが何しようが無理。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
大本営発表も見てください (スコア:4, 参考になる)
ダイヤ変更に対応で来ていないとか指摘してる人たちは是非ご一読を
これを機に未来の運行予測をしている事とか知っていただけるとありがたいです
タレコミにも追記してくれると良いんだけど…
中の人なのでAC
Re:大本営発表も見てください (スコア:5, 参考になる)
> JR東のプレスリリースが割と詳しい
これですね(注:pdf) [jreast.co.jp]。
確かに詳しいです。新聞記事のあやふやな記述を元に議論するのではなく、まずこっちを見るべきでしょう。
この問題のポイントは
ってところでしょうね。
PDFに挙げられてるような原因で発生する「データ修正が必要な箇所」の数は、大雑把に言えばチェックする時間範囲に比例しますから、
4時間先までのチェックなら600件で実用上問題なかったけど、終日チェックするようにしたのに件数上限を増やさなかったのが敗因、って感じですかね。
Re:大本営発表も見てください (スコア:2)
いや、普段赤字添削すると泣きたくなるような障害報告書が多すぎて鬱になりそうとか思ってたりしないんだからねっ
fj.jokes出身:
Re:大本営発表も見てください (スコア:1)
600件ってどういう根拠から来てるんでしょうかね？
まさか、
1分ごとに画面を消去
↓
修正が必要な個所を洗い出し
↓
ダイヤ画面を再描画
って流れで処理してて、人間の目でみてチカチカしない範囲で
処理が完了するのが600件って話なのかな？
Re:大本営発表も見てください (スコア:1)
で、どの時間範囲で何件までの入力が許容範囲なのかな。
一分間毎に以前の変更箇所を処理済みっていう保証も無いみたいだし、なんだかなーって感じが。
Re: (スコア:0)
というより天候不順のように複数の列車が運休･徐行運転を行う場合は
それらを一々入力するんじゃなく、一括してダイヤの組み替えを行うコマンドを別枠で用意しろと
Re: (スコア:0)
１番線に止めた場合→後続列車の変更が発生
２番線に止めた場合→後続列車には影響なし
みたいなことまで書いてあるから、影響を考えずにとにかく
止めまくったのが原因ではないかな？
通常はそんな影響が大きくなる変更自体してはいけないこと
なのでは？
何を目的とした変更？ (スコア:0)
運休にして後続列車が追い越すならともかく
システムの警告を消すために２番線に振り替えるのは余計な作業ですよね？
Re: (スコア:0)
４時間先までしか計算しないものを終電まで計算するようにした
一列車を一度変更かけると全てに影響を与えるのに終電まで再計算させる必要が有るの？
> 限度を超えると予想ダイヤを表示することができない仕組みとなっていた。
システムの容量が超えてしまって表示が遅れた
システムを理解していない者が此れを書いた？
ＪＲ東が出している対策って・・・？
1.は結局現場にしわ寄せを押し付けている？
システム側で対応しろよ！
2.はプログラムの変更でなくシステムの増強なのでは？
Re:大本営発表も見てください (スコア:1, すばらしい洞察)
1は2をやるまでの間の対策じゃないの？
2が恒久的な対処で、1がそれまでの間の運用での回避．
この手のシステムは問題があるからといって即修正なんてのは無理でしょ．
修正しても問題を起こさないことを、事前にしっかりテストして確認しておかないと．
修正してみたら、よりひどい障害が発生しましたとかいう事態はこの手のシステムだと致命的だろうし．
Re: (スコア:0)
路線が枝分かれして行くJR東の新幹線で、終日表示させるというのがちょっと過大な要件だった気もする。
見たけどぉ (スコア:0)
ダイヤ変更をチェックできる 600件/min の縛りがあった、
というのは分かったけど、
「600件オーバーした途端に白旗降参モード！」
つぅのは、やっぱ甘かったんじゃね？
// 将来予測（とか終日予想とか）にこだわりすぎて、
// まだ出発してない便の判定にまでリソースつぎ込んじゃって、
// 今走ってる便の手当てが薄くなってたんじゃないかなぁ。
だいたい、対策の２番目みたいな話が、ひょっこり出て来るぐらいなら、
600件/min という数字の根拠自体が、実はあんまり無かったんじゃないか
みたいな邪推が出てきてしまうなぁ。
日経の新しい記事では… (スコア:0)
Re: (スコア:0)
＞駅間に列車を止めないようにするため、短時間に24 本の列車に対して各駅に停止させる変更入力を行った。
こんな運用を行なっているとは…
ローカル線にほしいサービスだ…
Re: (スコア:0)
ローカル線はそもそも列車密度が薄くて薄くてたまらないんだから、そんなの導入しなくても駅までは行けるでしょ。
途中の線路そのものが通れなくなって駅間に停車せざるをえないのなら、COSMOS入れようが何しようが無理。
Re: (スコア:0)