パスワードを忘れた? アカウント作成
291201 story
交通

JR東の新幹線運行トラブル、管理システムの仕様を超えるダイヤ変更が原因 154

ストーリー by hylom
容量オーバー 部門より

cvmonto 曰く、

JR東日本が1月17日朝に発生した運行システムトラブルの件について、新幹線管理全体を担うシステム「COSMOS」にて異常が発生したことが原因だと発表した(日本経済新聞)。

このトラブルは東北、上越など5つの新幹線、計139本が運休・遅延するという比較的大規模なものだったのだが、COSMOSにおいてシステムの容量を超える数のダイヤ変更が入力されたことが発端となったという。これにより東京の運行本部にあるPC22台すべてで「各駅の到着時刻や引き込む路線を示すデータがついたり消えたりする異常」が発生したため運行を中断したそうだ。

そもそもの「COSMOSへのシステム容量を超えるダイヤ変更の入力」については、直前にJR東管内の2つの駅で「降雪によりポイントが切り替わらない」という問題が発生、一時的に大量のダイヤ変更処理が必要になったことで入力されたとのことである。

朝日新聞では、JRと共同開発した日立製作所などと行った調査でシステム自体には問題がないことを確認され、人的ミスでソフトが不具合を起こしたことが判明したと書かれているのだが、おそらくシステム容量という仕様を超える入力をしたのは人的ミスということなのだろう。正直なところ、多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2011年01月18日 19時24分 (#1889896)
    JR東のプレスリリースが割と詳しいので
    ダイヤ変更に対応で来ていないとか指摘してる人たちは是非ご一読を
    これを機に未来の運行予測をしている事とか知っていただけるとありがたいです

    タレコミにも追記してくれると良いんだけど…

    中の人なのでAC
    • > JR東のプレスリリースが割と詳しい

      これですね(注:pdf) [jreast.co.jp]。
      確かに詳しいです。新聞記事のあやふやな記述を元に議論するのではなく、まずこっちを見るべきでしょう。

      この問題のポイントは

      • 2008 年 5 月に COSMOS を現在のバージョンにリニューアルした。旧システムでは予想ダイヤの範囲が 4時間先までであったものを、終日できるようにした。
      • システムは、1 分毎にデータ修正が必要な箇所をチェックしており、その数は 600件が限度で、限度を超えると予想ダイヤを表示することができない仕組みとなっていた。

      ってところでしょうね。

      PDFに挙げられてるような原因で発生する「データ修正が必要な箇所」の数は、大雑把に言えばチェックする時間範囲に比例しますから、
      4時間先までのチェックなら600件で実用上問題なかったけど、終日チェックするようにしたのに件数上限を増やさなかったのが敗因、って感じですかね。

      親コメント
      • pdf読んで「障害報告文書として考えると良い例だな。周りにも読まそう」なんて思ってしまった。
        いや、普段赤字添削すると泣きたくなるような障害報告書が多すぎて鬱になりそうとか思ってたりしないんだからねっ
        --
        fj.jokes出身:
        親コメント
      • >その数は 600件が限度で
        600件ってどういう根拠から来てるんでしょうかね?

        まさか、
        1分ごとに画面を消去

        修正が必要な個所を洗い出し

        ダイヤ画面を再描画

        って流れで処理してて、人間の目でみてチカチカしない範囲で
        処理が完了するのが600件って話なのかな?
        親コメント
      • で、どの時間範囲で何件までの入力が許容範囲なのかな。
        一分間毎に以前の変更箇所を処理済みっていう保証も無いみたいだし、なんだかなーって感じが。

        親コメント
  • なんというか (スコア:4, すばらしい洞察)

    by Anonymous Coward on 2011年01月18日 20時44分 (#1889976)

    こういう連中に仕様作らせたらやばいな、というコメントが多いな…

    • Re:なんというか (スコア:3, すばらしい洞察)

      by Anonymous Coward on 2011年01月19日 9時01分 (#1890220)
      > こういう連中に仕様作らせたらやばいな、というコメントが多いな…

      こういう連中がクライアントだったりしても同様にやばいよね。
      親コメント
  • by Anonymous Coward on 2011年01月18日 23時25分 (#1890089)
    ダイヤが乱れた際に必要な変更作業を行うことを「運転整理」といいますが、
    現段階ではまだ運転整理の問題を計算機で一般的・自動的に解くことはできていません。
    既にコメントしている方の中にはかなりそのあたりを勘違いしている方もいらっしゃるようですけど。
    COSMOSが自動でやっているのは、今の計画をそのまま実行したときに発生する
    支障や条件違反をチェックして警告するという処理で、それへの対処は人間が考えなければなりません。

    運転整理の自動化については、JR東日本は割と研究が進んでいる方なんですが、
    まだまだとても実用ではないです。

    この問題、本当に計算機に自動で解かせることができるのか、絶対無理じゃないか、という意見もあったのですけど、
    研究者が頑張ってきたことに加えて、計算機の性能向上と数理計画問題の解法の急速な進歩もあって、
    このまま研究を続けていけば実用化が見えてくるかなと思える程度には進歩してきました。
    鉄道関連の論文とか読んでいると、ここまで進歩してきたか、凄いなぁと思うものが結構あります。
  • by Anonymous Coward on 2011年01月19日 7時04分 (#1890199)

    朝日の記事http://www.asahi.com/national/update/0118/TKY201101180470.html [asahi.com](新幹線トラブル、運行担当者の誤解原因 JR東が謝罪)によると
    >JR東日本の五つの新幹線すべてが17日に一時運休したトラブルの原因は、運行担当部門がシステム表示の仕組みを知らされておらず、不具合発生と誤解したためだったと同社が18日、発表した。

    となっています。
    つまり、一部の表示が消えたのでシステムに不具合が発生したと誤解して全列車を止めてしまった、ということのようです。
    乱暴に言うと、普段と違う挙動をしたから壊れたと思った、です。

    これを受けてなのかは分かりませんが、各社ニュースでは「システムトラブル」ではなく「運行トラブル」とか「新幹線トラブル」等の表記となっています。

    海外への売り込みに絡んだ政治的な意味合いもあるのでしょうが。

  • おかしくない (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2011年01月18日 18時59分 (#1889873)

    >多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが。
    あらゆる例外に備えるのは、予算的にも無理。

    自分の乗った新幹線が遅れた人には気の毒だけど、仕方ないでしょう。

    誰か(こういう場合は大体開発会社)を悪者にしてやり過ごそうとしなかったJR東日本は立派だ。

    • by Anonymous Coward on 2011年01月18日 21時12分 (#1889995)

      しっかりした発注者は、自分たちが開発元で、ベンダは下請けだと考えているんですよね。
      だから、ベンダを教育するのも責任を取るのも自分たちなわけです。JR東日本以外にも、
      BTMUなんかがそうですね。

      まあ、下請けに責任を押し付ける開発元はろくなもんじゃないですな。

      親コメント
  • 多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが

    ある列車運行の変更を指定することによって、それ以外の列車の運行にも影響が波及しそうですし、それを洗い出す処理が大きい(大量に変更が入ると計算に必要なリソースが爆発的に増える)とか、そんな感じなんでしょうかね? 門外漢なので想像ですけど。

    • by akatsukin (40663) on 2011年01月18日 19時48分 (#1889923)
      線内最速の列車(東北ならはやて)AがB駅で10分遅れたとします

      B駅以降で列車Aに追い越される遅い列車Cに直接的な影響が出ます

      A列車からの乗り換え列車D(別路線)にも遅れが出ます
      当然ながら、列車Cに接続する列車Eも遅れます

      列車Aは終着駅に5分遅れて着きました。線路配線の都合上「同時に発車できない」
      制約があれば折り返し列車Fも遅れます

      以下延々とループ

      このとき、列車には余裕時分が設定してあるので(通常時、常にフルスピードで
      走っているわけではない)、この遅れの連鎖は徐々に収束して平常運転に戻ります。
      また、上記の例なら追い越される列車Cの追い越しの駅を先に変えて、遅れが
      最小限となるように調整します。
      また、列車には「車両」「運転士」「車掌」の3つが揃わないと運転できないため、
      このやりくりの作業も発生します。

      今回は駅間で止まらないようにダイヤを入力したためであるようなので、一気に
      計算が集中して処理落ちしたのかなあ、と思います。緊急時には一括抑止
      (その場で非常制動をかける)するはずなので、その為の試験はしていると
      思うのですが…。

      #何となく、1/15の不具合がなければ1/17の不具合も起きていなかった気が。
      親コメント
  • 日立製作所などと行った調査でシステム自体には問題がないことを確認され、人的ミスでソフトが不具合を起こしたことが判明したと書かれているのだが、おそらくシステム容量という仕様を超える入力をしたのは人的ミスということなのだろう。正直なところ、多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが。

    まさにこの部分に尽きると思うの。

    データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の2倍程度の負荷で済むはず。
    それで落ちるってことは、普段から「想定される最大負荷の50%以上」で運用してたってことになるわよね。
    新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの?

    電車が「止まる」だけなら人命に直接は関係しないからいいけど、安全対策とかの部分も「結構ぎりぎり」なのだとしたら怖いわよねぇ。そんなことは無い、と思いたいけど。

    • by tanichan (4498) on 2011年01月18日 19時07分 (#1889882)

      > それで落ちるってことは、普段から「想定される最大負荷の50%以上」で運用してたってことになるわよね。
      > 新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの?

      オンラインデータ処理の認識が甘いと思います。
      1カ所でポイント切り替え故障しただけならともかく、同時多発的に発生した場合は
      2倍程度では済まないです。リアルタイムで新幹線の位置が変わる中で
      筋切り替え、筋戻しをそれぞれのポイント/新幹線車両ごとに調整しながらやっていくわけですから。
      しかも新幹線は時速270km とかで 3から 5 分間隔で走っています。

      システム設計は別として
      全系止めたのは危機対処としては (なかなか出来ない) すばらしい判断だと思います。

      親コメント
    • by BIWYFI (11941) on 2011年01月18日 23時25分 (#1890090) 日記

      今回の事案を纏めると、24件の列車運用を変更したら、自動的に修正されたダイヤが表示限界の600件を超えて表示が消えたと云う物。

      表示限界の600件だが、正直言って、一度に600件のデータを人間が目視で確認して対応するのは不可能だから、例え表示出来ても無意味な件数として設定されたのだと思う。
      件数が半端なのは、多分、現場が頑張れば、500件なら対応出来ると見たんだろうと推測。

      ダイヤ変更自体が「普通じゃ無い事」だから、それを関係各位に通達するとなると、500件でも人間側の作業は大忙しになる事が予見出来る。
      「表示」が必要なのは、人間が対応するからで、対応不要なら、初めから表示する必要が無い。

      では、24件の設定変更が拙いかと言うと、表示限界600件から考えると、無茶な数では無い筈。

      根本問題は、自動変更に任せた、24件が600件以上に膨れ上がる、過密連携ダイヤ編成自体に在る。
      それが避けられない場合は、運用で、連鎖しない様に注意して変更する必要が有る。
      が、人間が作業する以上は、運用だけでは回避出来ない。
      それが実際に起きたのが今回の事例。
      「停止しないシステム」としては、通常ダイヤ編成時点で、実は破綻していたと云う事だね。

      今後は、「連鎖しないダイヤ生成アルゴリズム」が仕様に入るのだろう。

      --
      -- Buy It When You Found It --
      親コメント
    • by NOBAX (21937) on 2011年01月18日 19時05分 (#1889881)
      事実関係の認識に誤りがあるんじゃないですか?

      読売 [yomiuri.co.jp]だと
      >同社によると、新幹線の運行を管理するシステム「COSMOS(コスモス)」は、トラブルなどで運行本部の係員がダイヤ変更を行うと、
      >その後に運行される列車のダイヤについて自動計算で変更か所を表示する。表示は600件が上限という設定だった。
      >トラブルのあった17日朝、雪の影響で新白河、福島駅でポイントが切り替わらなくなり、運行本部は列車24本のダイヤを変更。
      >その際、自動計算で変更されたダイヤが600件を超えてしまい、画面が消えるトラブルが発生したという。

      プロコンでオーバーロードになるとレスポンスが遅くなるというのはよくある話で、制御系システムではこれを如何に潰すかが
      腕の見せ所であるわけですが、それで画面の応答がが遅くなって、表示されないように見えたということだろうと思います。
      負荷の増大に耐えるようにすればいいわけですが、それは予算との兼ね合いがあるわけです。
      かといって、オーバーロードだから入力の受け付けはやりませんという分けにもいかないのです。

      オーバーロードでおかしくなったのは、新幹線で以前もあったと思うし、最近では消防庁で119番がつながらないという
      トラブルも起きたばかりですね。
      親コメント
      • プロコンでオーバーロードになるとレスポンスが遅くなるというのはよくある話で、制御系システムではこれを如何に潰すかが腕の見せ所であるわけですが、それで画面の応答がが遅くなって、表示されないように見えたということだろうと思います。

        件数が大きくなって巡回セールスマンを解くのに 1/60 秒を超えてしまったのですね
        あれ?なんか既視感が……気にしないことにしよう。

        親コメント
    • by Anonymous Coward on 2011年01月18日 19時09分 (#1889883)

      鉄道はエラー時のフェイルセーフが重要視される分野だけど、画面表示がおかしくなることで異常が確認されたってのはまずいんじゃないかな。
      もし、内部的なエラーが発生しているにもかかわらずエラー表示や異常終了がおこらず、「画面表示」以外の、人間がみえないところでこっそりとエラーをおこしていたら、人が異常に気付かずに重大事故につながった危険性もあるよね。

      「本製品は、医療機器、原子力発電など人命に関わる設備や機器、高度な信頼性を必要云々には使っちゃだめだよ」契約ならまだしも、こういうお値段の桁が一つ以上違う契約でエラー検出がしっかりされていないなんて...

      親コメント
  • by Anonymous Coward on 2011年01月18日 19時24分 (#1889900)
    たまにはいいじゃないか。 人が死んだわけじゃないし。
    • by ct (41607) on 2011年01月18日 21時05分 (#1889990)

      寛大だよね、誰もJRを叩くとかではないからね。
      むしろ、「もう、同じことにならないためにはどうしたらいいかねぇ?」といった話になっていると思うんだな。

      >たまにはいいじゃないか。

      これが繰り替えされると、「たまにはいいじゃないか」とか言ってられないと思うよ。

      親コメント
typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...