アカウント名:
パスワード:
日立製作所などと行った調査でシステム自体には問題がないことを確認され、人的ミスでソフトが不具合を起こしたことが判明したと書かれているのだが、おそらくシステム容量という仕様を超える入力をしたのは人的ミスということなのだろう。正直なところ、多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが。
まさにこの部分に尽きると思うの。
データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の２倍程度の負荷で済むはず。それで落ちるってことは、普段から「想定される最大負荷の５０％以上」で運用してたってことになるわよね。新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの？
電車が「止まる」だけなら人命に直接は関係しないからいいけど、安全対策とかの部分も「結構ぎりぎり」なのだとしたら怖いわよねぇ。そんなことは無い、と思いたいけど。
今回の事案を纏めると、24件の列車運用を変更したら、自動的に修正されたダイヤが表示限界の600件を超えて表示が消えたと云う物。
表示限界の600件だが、正直言って、一度に600件のデータを人間が目視で確認して対応するのは不可能だから、例え表示出来ても無意味な件数として設定されたのだと思う。件数が半端なのは、多分、現場が頑張れば、500件なら対応出来ると見たんだろうと推測。
ダイヤ変更自体が「普通じゃ無い事」だから、それを関係各位に通達するとなると、500件でも人間側の作業は大忙しになる事が予見出来る。「表示」が必要なのは、人間が対応するからで、対応不要なら、初めから表示する必要が無い。
では、24件の設定変更が拙いかと言うと、表示限界600件から考えると、無茶な数では無い筈。
根本問題は、自動変更に任せた、24件が600件以上に膨れ上がる、過密連携ダイヤ編成自体に在る。それが避けられない場合は、運用で、連鎖しない様に注意して変更する必要が有る。が、人間が作業する以上は、運用だけでは回避出来ない。それが実際に起きたのが今回の事例。「停止しないシステム」としては、通常ダイヤ編成時点で、実は破綻していたと云う事だね。
今後は、「連鎖しないダイヤ生成アルゴリズム」が仕様に入るのだろう。
>根本問題は、自動変更に任せた、24件が600件以上に膨れ上がる、過密連携ダイヤ編成自体に在る。
JR東日本の新幹線運行ダイヤグラムが過密なのは、ひとえに東京大宮間の線路容量に拘束されているからで、さっさと新宿大宮間の上越新幹線筋を建設するのが本質的な解決策ですね。ということで旧浦和市域と戸田市の反対住民の説得をお願いします。
#ぶっちゃけJR東の新幹線は東京大宮間のシャトル便と大宮以北の遠距離便で運行を完全分断すりゃいいと思うよ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
ぎりぎり運用やっちゃいけない分野 (スコア:1)
まさにこの部分に尽きると思うの。
データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の２倍程度の負荷で済むはず。
それで落ちるってことは、普段から「想定される最大負荷の５０％以上」で運用してたってことになるわよね。
新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの？
電車が「止まる」だけなら人命に直接は関係しないからいいけど、安全対策とかの部分も「結構ぎりぎり」なのだとしたら怖いわよねぇ。そんなことは無い、と思いたいけど。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:4, 参考になる)
今回の事案を纏めると、24件の列車運用を変更したら、自動的に修正されたダイヤが表示限界の600件を超えて表示が消えたと云う物。
表示限界の600件だが、正直言って、一度に600件のデータを人間が目視で確認して対応するのは不可能だから、例え表示出来ても無意味な件数として設定されたのだと思う。
件数が半端なのは、多分、現場が頑張れば、500件なら対応出来ると見たんだろうと推測。
ダイヤ変更自体が「普通じゃ無い事」だから、それを関係各位に通達するとなると、500件でも人間側の作業は大忙しになる事が予見出来る。
「表示」が必要なのは、人間が対応するからで、対応不要なら、初めから表示する必要が無い。
では、24件の設定変更が拙いかと言うと、表示限界600件から考えると、無茶な数では無い筈。
根本問題は、自動変更に任せた、24件が600件以上に膨れ上がる、過密連携ダイヤ編成自体に在る。
それが避けられない場合は、運用で、連鎖しない様に注意して変更する必要が有る。
が、人間が作業する以上は、運用だけでは回避出来ない。
それが実際に起きたのが今回の事例。
「停止しないシステム」としては、通常ダイヤ編成時点で、実は破綻していたと云う事だね。
今後は、「連鎖しないダイヤ生成アルゴリズム」が仕様に入るのだろう。
-- Buy It When You Found It --
Re: (スコア:0)
「遅れても乗り換えの接続は取りません」
「遅れても回復運転は致しません」
「運休になったらあきらめて下さい」
という運用が最上と言うことですね:-p
Re: (スコア:0)
>根本問題は、自動変更に任せた、24件が600件以上に膨れ上がる、過密連携ダイヤ編成自体に在る。
JR東日本の新幹線運行ダイヤグラムが過密なのは、ひとえに東京大宮間の線路容量に拘束されているからで、
さっさと新宿大宮間の上越新幹線筋を建設するのが本質的な解決策ですね。
ということで旧浦和市域と戸田市の反対住民の説得をお願いします。
#ぶっちゃけJR東の新幹線は東京大宮間のシャトル便と大宮以北の遠距離便で運行を完全分断すりゃいいと思うよ
Re: (スコア:0)
さらに地方の方にとっては、新幹線に乗る目的は東京へ行くことであって、新宿など眼中に無いとのことですから、これもまた営業的に厳しいものがあるのかもしれません．
いっそのこと、混雑分散のために、新宿駅地下の専用スペースにはリニア中央新幹線の補助施設を設置してしまうのがよいかもしれませんね．