アカウント名:
パスワード:
日立製作所などと行った調査でシステム自体には問題がないことを確認され、人的ミスでソフトが不具合を起こしたことが判明したと書かれているのだが、おそらくシステム容量という仕様を超える入力をしたのは人的ミスということなのだろう。正直なところ、多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが。
まさにこの部分に尽きると思うの。
データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の2倍程度の負荷で済むはず。それで落ちるってことは、普段から「想定される最大負荷の50%以上」で運用してたってことになるわよね。新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの?
電車が「止まる」だけなら人命に直接は関係しないからいいけど、安全対策とかの部分も「結構ぎりぎり」なのだとしたら怖いわよねぇ。そんなことは無い、と思いたいけど。
誤動作もしてないしダウンもしてないし、
平成7年のコスモスの運用開始時に比べ、新幹線の輸送量が約4割増加していることなどが背景となったようだ。JR東では「これまでトラブルはなく、600件という上限を変更する必要は感じていなかった」(JR東)という。http://sankei.jp.msn.com/affairs/news/110118/dst11011821360040-n1.htm [msn.com]
といった背景は無視ですか?
5年くらい前の年末にも今回みたいなことがあったでしょ?。キャパプラをきちんとやってない東&JEISがまずはおバカなんです。常識では考えられん。ダイヤ改正して運行密度上がってるんだし、キャパプラは年次が無理!ってんだったら整備計画に合わせて拡張するしかないと思うんだけど、元お役所の方々はそう考えないんですな。
#もともとそばで見てたのでAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
ぎりぎり運用やっちゃいけない分野 (スコア:1)
まさにこの部分に尽きると思うの。
データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の2倍程度の負荷で済むはず。
それで落ちるってことは、普段から「想定される最大負荷の50%以上」で運用してたってことになるわよね。
新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの?
電車が「止まる」だけなら人命に直接は関係しないからいいけど、安全対策とかの部分も「結構ぎりぎり」なのだとしたら怖いわよねぇ。そんなことは無い、と思いたいけど。
Re:それはチョット違うよな (スコア:3, 参考になる)
読売 [yomiuri.co.jp]だと
>同社によると、新幹線の運行を管理するシステム「COSMOS(コスモス)」は、トラブルなどで運行本部の係員がダイヤ変更を行うと、
>その後に運行される列車のダイヤについて自動計算で変更か所を表示する。表示は600件が上限という設定だった。
>トラブルのあった17日朝、雪の影響で新白河、福島駅でポイントが切り替わらなくなり、運行本部は列車24本のダイヤを変更。
>その際、自動計算で変更されたダイヤが600件を超えてしまい、画面が消えるトラブルが発生したという。
プロコンでオーバ
Re: (スコア:0)
それくらいだったということで、別に問題ではないと思うんですよね。
入札とかして、一番安いところに発注したら、一番安い給料で雇える技術者
たちが開発したってことなんでしょう。
安さだけを求めて入札するとか、値下げ圧力をかける無思慮な発注元は
少なくないけれど、安かろう悪かろうという言葉も忘れずにね。
それよりも問題は、600件超えたらシステムが誤動作してダウンしてしまうような
仕様なのに、600件以上の入力ができるようになっていたのが不具合なのであって、
人為的ミスではないと思うんですよ。
Re:それはチョット違うよな (スコア:2, 興味深い)
誤動作もしてないしダウンもしてないし、
といった背景は無視ですか?
Re: (スコア:0)
5年くらい前の年末にも今回みたいなことがあったでしょ?。
キャパプラをきちんとやってない東&JEISがまずはおバカなんです。
常識では考えられん。ダイヤ改正して運行密度上がってるんだし、
キャパプラは年次が無理!ってんだったら整備計画に合わせて
拡張するしかないと思うんだけど、元お役所の方々はそう考えないんですな。
#もともとそばで見てたのでAC