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

東海道新幹線の新型ATS装置に不具合 49

ストーリー by mhatta
ある意味DoS 部門より

Nekomimi-Maid曰く、"朝日新聞読売新聞産経新聞の記事によると、JR東海が今年3月のダイヤ改正で導入した新型自動列車制御装置(ATC)に不具合があり、車輌側ATC装置が異常と判断して非常ブレーキを作動させるなどのトラブルが19件起こったとのことです。

読売新聞では不具合の原因を、「デジタルATCの車両側コンピューターには一気に大量の情報を処理する想定のプログラム設定がなされておらず、処理能力が追いつかずに列車を非常停止させてしまうケースがあることが判明した。」と説明しており、また他紙においても不具合の原因は車輌側ATC装置にあるということが読み取れるのですが、読売・産経では「ATC装置のプログラムミス」、朝日は「ATCのプログラムに不具合」と微妙に表現が異なっています。

「一気に大量の情報を処理する想定のプログラム設定がなされておらず」という表現から、車輌側ATC装置のソフトウェア開発時の仕様策定における問題とも思えるのですが、それを「プログラムミス」と解説してしまって良いものかどうか…一般的に説明するには「プログラムミス」の方が通りが良いのでしょうか。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Sanjuro (7894) on 2006年04月13日 14時22分 (#920679) 日記
    日経コンピュータから。 [nikkeibp.co.jp]
    プログラムにより改善とはあるけど、プログラムミスではなさそうですな。
    むしろテストケース洩れか?
    • by Anonymous Coward on 2006年04月13日 20時43分 (#920938)
      そこから推察すると、恐らく前方予告信号の処理に問題があるのではないかと思われます。
      新型ATCでは自車走行区間の一つ先の閉塞区間の速度信号を受信し速度制御に活用しています。
      現在210信号区間を走行し次に160信号区間に進入した場合、在来型ATCではATC常用ブレーキが最大で作用し160キロまで減速しますが、ブレーキの作用と緩開時に軽い衝動を感じることもあり乗り心地が低下する原因になっていました。
      そこで前方の速度信号を併せて受信し車上装置で最適なランカーブを演算処理しブレーキ制御を行なわせることによスムーズな走行を実現させようというのが新型ATCのセールスポイントの一つです。
      ここで問題になるのは前方信号は変化する、ということです。
      例えば先行列車が急減速すると予告160信号を受信していても突然110信号や70信号に変化する場合があります。
      逆に通過駅に近づくと先行列車が退避し進路構成が本線側に完了すると160信号が210信号に切り替わることも有り得ます。
      このように車上装置への入力条件が変化した場合、演算処理以前であれば旧データを破棄すか上書きすれば良いのでしょうが、既に演算処理が実行されブレーキ制御が開始されているような状況で処理条件が変化した場合の追加処理が間に合わないか不可能であったため処理停止、非常制動動作に至ったものではないでしょうか。
      10分程度の遅れとなるとリセットしてすぐに正常動作に戻るようなのでさほど重大なトラブルではなさそうです。
      となるとやはりソフト的な問題よりもプロセッサーやメモりーの処理能力不足な気がします。
      これを設計ミスと言って良いのか分りませんが、仕様策定に問題が無かったか検証する必要があるでしょうね。
      以上、あくまでも推測ですが。
      親コメント
    • ですね。
      でも、こういうのってかなり厳しいテストをする
      イメージだったんですが・・・。
      --

      --- (´-`)。oO(平和な日常は私を鈍くする) ---
      親コメント
      • by Another_View (29838) on 2006年04月13日 15時59分 (#920752) ホームページ 日記
        ま、この手のグリッチ的バグは実際に動かしてみないと発露しないことが多いからね。

        モノが新幹線だけに、なかなか試験もしにくいだろうし。
        親コメント
        • by Anonymous Coward
          >モノが新幹線だけに、なかなか試験もしにくいだろうし。

          一夜にしてアナログ式ATCからデジタル方式に切替える必要があったから、という理由かもしれない。
          アナログとデジタルを併設できれば、長期にわたって動作の予行をできたのかもしれないけど。

          こういう車上装置は多重化できないものだろうか?
          入出力の仕様が同じで、それを実現するロジックは別々のチームに実装させるとか。

          • by ktxg7 (21705) on 2006年04月14日 0時37分 (#921134)
            一般のコンピューターシステムなどと異なり、問題が起きた時、安全側(≒停止側)の動作をさせることになるので、どちらかが止まると新幹線が停止。
            2倍の確率で止まったりするんじゃないですか?

            親コメント
    • by Anonymous Coward
      やっぱりわからない。
      クリティカルな処理の処理時間の見積の誤り?
      タスクのプライオリティ付けの失敗?
      そもそもRTOSを使ってなかった?
      ---
      よく分からないのでAC
      • by Anonymous Coward
        > やっぱりわからない。

        全くもって門外漢ですが、
        トラブルは大きく二つの要因で発生している。一つめが各新幹線に搭載したATC用コンピュータのメモリ不足。先行している新幹線の速度が相対的に速いと、自列車のATCの取得する相手位置の情報が増える。

        自列車から見た先行列車の位置が、前回の位置より遠い場合は、先々行列車と判断して、別途メモリを確保する、というような感じかもしれません。
        もう一つがATC用コンピュータの処理能力の問題。0.1秒以内に、先行列車と自列車の位置情報を同時に受け取ると、コンピュータが処理しきれずに異常と判断するという。

        受信→割り込み→処理(0.1秒かかる)→待機
        という流れで、処理の途中で割り込みが入ると、処理が途中で打ち切られる、という問題かもしれません。
    • by Anonymous Coward
      できあがったプログラムに問題があったということは事実。仕様策定もテストもプログラムの作成過程の一つ。
      そういう意味では、プログラムミスというのも全くの誤りとは言えないと思う。
      タレコミやいくつかのコメントを見ると、プログラム作成=コーディングという見方が主流のようですな。
      要するに、用語の定義があっちとこっちでずれているのが問題なのではないかと。
      • by power (11625) on 2006年04月13日 17時20分 (#920832) 日記
        どこにつけようか迷ったけどここに。

        >仕様策定もテストもプログラムの作成過程の一つ。

        それは事実でしょうね。作成過程と捉えるならば。
        ただ私も含め、単に『プログラム』となると、どうしても実際に作業してコーディングしているイメージがあるんじゃないでしょうか?
        ハードウェアにしたって、開発という言葉と設計という言葉では受け取るイメージが違うと思います。
        開発と捉えれば、仕様策定も過程の一部として認識できますが、これを設計と捉えると回路を組んでいたりコーディングしていたり、というイメージが出てきます。
        単にプログラムという言葉に、どこまでをイメージするのが一番妥当か?という問題のように思います。
        親コメント
      • by Anonymous Coward
        >仕様策定もテストもプログラムの作成過程の一つ。

        後者はともかく前者はちげーよ。
  • by llm (11066) on 2006年04月13日 13時39分 (#920633) 日記
    読み手の不安をあおりたい場合は、直接的な表現の「ミス」を使用し、
    そうでない場合は「不具合」を使っているってのはどう?

    #なにが?(^^;;
    --
    人事を半分尽くして天命を待つ
  •  想定外のデータが入力されると異常が発生する場合でも、想定外データでは動作保証ができないことが仕様として規定されていて、それをクライアントに告知していればソフトウェア側のミスじゃあないでしょ。
     アップデートコスト(もしくは検討そのもの)をケチった運用ミスだったりはしないんですかね。

    #限界性能について記述がなくて、見切り発車でやってみたらダメだった、でも普通は管理責任が先に来るよね。
    #一次原因はともかく、真の原因はチェック漏れってオチのような気がするなぁ

    --
    しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
  • 理系弾圧 (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2006年04月13日 14時03分 (#920656)
    つまり、「仕様書を作成して、作らせた側は悪くない。 プログラムを作ったプログラマーが悪い。」と言いたいわけだ。

    これにはプログラマーという得体の知れない奴を悪者にしておけば良いという会社側の作為を感じる。

    大きく見れば、技術など理解できないのに大きな顔で会社を支配している文系が自分の理解できない事をやっている理系を不当に弾圧しているとも言える。

    立て万国の理系諸君!!
    弾圧し搾取する文系にいまこそ反旗を翻すのだ!!
    文系の奴等の収入の原点は我々理系技術者の汗であり、彼らの生活を支えているのは名もなき理系技術者の涙である。
    立て万国の理系諸君!!
    立て万国の同士諸君!!

    #ジークジオン!!(あれ?)
    • Re:理系弾圧 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2006年04月13日 16時21分 (#920769)
      > つまり、「仕様書を作成して、作らせた側は悪くない。プログラムを作ったプログラマーが悪い。」と言いたいわけだ。
      > これにはプログラマーという得体の知れない奴を悪者にしておけば良いという会社側の作為を感じる。

      #920730で言われているように設計ミスを含めた表現としてのプログラムミスでしょうね。
      プログラミング(コーディング)ミスと言う話ではなさそうですし、
      畑違いの人にその様な誤解を受ける表現とも思わない。

      ただ、設計前の発注ミスの可能性も残ってますね。
      その場合にはプログラムミスと言う表現は不適切と言えるでしょう。

      # とネタに無粋レス。
      親コメント
    • by akio_pisces (19456) on 2006年04月15日 0時24分 (#921887) 日記
      えーと、仕様書を書く理系の人間がプログラマになった理系の人間を虐待している、と。
      親コメント
    • by Anonymous Coward
      仕様書やテスト項目を修正しても不具合は直らない。プログラムを修正すれば不具合は解決する。
      なので、 「プログラムを修正すれば直る」→「プログラムが悪い」→「プログラムを作った奴が悪い」というのが世間一般での理解。

      本来プログラムにバグがあるのは当り前でそれを各種設計書レビュー、テスト項目レビュー、テストにて検出できなかったことが問題なんですがね。
  • by Anonymous Coward on 2006年04月13日 14時05分 (#920659)
    ハードウェアの処理能力を超えているってことですか?
    だとすれば、ソフトウェアだけでどうにかできるレベルを超えていることになるわけで…
    どうやら読売の記事が一番詳しそうですが、それによれば「0・1秒以内に複数の情報を受信するなどすると処理能力を超えてしまうという」とあるので、これを読む限りではイレギュラーな状態に対するチェックが甘かった、ってことかも知れません。

    以前関わった装置で、CPUの持ってる機能を使う前提で設計したが、実際に使って動かしてみるとCPU使用率100%状態になってハングする状態となり、結果的にCPUのその機能殺して別にコントローラ追加した、なんてものを見たことがあるのでAC(^_^;)
    • Re:もしかして… (スコア:2, すばらしい洞察)

      by mocchino (13752) on 2006年04月13日 14時42分 (#920696)
      CPUの処理能力が満たされていてもプログラム事態に処理優先順位とか、処理コストの考慮がされていないと問題が起きる場合があります

      処理能力自体は足りてるのにメッセージバッファー溢れたりとか.....

      #詳しく書こうとしたらうまくかけなくて挫折しました(苦笑
      親コメント
    • by Anonymous Coward
      単にロックしそこねて排他制御になってなかったってだけでも、ブンヤが書くとそういう表現になったりしない?
      ま、チェックが甘かったのは確か。
    • by Anonymous Coward
      > ハードウェアの処理能力を超えているってことですか?

      そこでマグネットコーティングですよ。
    • 昔、近鉄がVVVF車の量産始めた頃に、制御基板にZ80系CPU(確か64180)を使ったら試運転では問題が出なかったのに、営業運転では処理が追いつかなくなってトラブルが頻発し、以後懲りて68000系にプロセッサを変更した話を思い出しました。 ま、こう書けばどこが制御器製作を担当した車で起きたトラブルかはバレバレなんですが・・・。 あと、京阪800系で初期にトラブルが発生したときは制御系のマイコンを「リセット」してその場を取り繕っていたそうで・・・。 やっぱり鉄道系は営業運転に出さないと判らない問題(満員乗車で雨天時とか)が多いっぽいです。
  • by Anonymous Coward on 2006年04月13日 13時43分 (#920636)
    何が違うんでしょうか?
    • Re:ATSとATCって (スコア:3, 参考になる)

      by ultra_hawk_1 (13626) on 2006年04月13日 14時10分 (#920666) 日記
      この記事で言及されているのは「ATC」の方ですね。見出しが間違っています。

      ATS(自動列車停止装置)は、列車が、信号の指示する速度(赤信号なら速度0)を越えて信号を通過した場合に列車を停止させる装置です。

      ATC(自動列車制御装置)は、信号の指示する速度に従い、列車にブレーキをかけ減速させる仕組みです。もちろん、赤信号に相当する速度0の信号が出ている場合は列車を止めます。新幹線など、高速で走行する車両の場合は、車内信号を併用します。

      加速の方まで自動化した場合はATO(自動列車運転装置)といいます。最近のワンマン化された地下鉄などで使われていますね。

      Cf. 自動列車停止装置 [wikipedia.org]
      自動列車制御装置 [wikipedia.org]
      自動列車運転装置 [wikipedia.org]
      あたらしいATC・ATSのはなし [plala.or.jp]
      親コメント
      • とりあえず (スコア:2, 参考になる)

        by Anonymous Coward on 2006年04月13日 14時47分 (#920701)
        ATCの場合は基本的には全て社内信号ですよ

        新幹線の場合非常ブレーキになる場合はいくつかあって
        ・前に列車がいる区間に進入した場合
        ・転てつ機の状態で進路が開いていない区間に進入した場合
        ・停止から走りはじめて一定時間内に地上装置を捕捉できない場合
        ・速度照査用の地上装置を検出して一定時間内に次のトラポンを捕捉できない場合

        処理能力云々って言ってるから最後の速照の場合じゃないかと思うのですが
        ハード性能もありえるけど、ソフト的なミスも無いわけじゃないと思いますよ。
        どっちにしても試験の抜けだろうな

        親コメント
        • Re:とりあえず (スコア:1, 参考になる)

          by Anonymous Coward on 2006年04月13日 16時23分 (#920771)
          のんのん、東京地下鉄の一部の線なんかではまだ地上信号式のATCが使われています。
          親コメント
          • by kazuno (16214) on 2006年04月13日 18時05分 (#920858)
            東京地下鉄では東西線にのみ使用されてますね。
            あと相互乗入れ先である東葉高速鉄道でも使用されています。
            かつては日比谷線でも採用されていましたが、2003年に全線、一段ブレーキ対応のCS-ATCに置き換えられています。

            東西線も車両更新が終わり次第、日比谷線同様のCS-ATCに置き換わるようです。
            これで東京地下鉄の地上信号式ATCは全廃となります。
            東葉高速鉄道の方はそのままWS-ATCを使い続けるようですが。
            親コメント
            • by kazuno (16214) on 2006年04月13日 18時11分 (#920861)
              あ、東西線の新しいATCは日比谷線と異なりデジタル化されるようですね。
              自己訂正しておきます。

              ×東西線も車両更新が終わり次第、日比谷線同様のCS-ATCに置き換わるようです。
              ○東西線も車両更新が終わり次第、デジタル方式のCS-ATCに置き換わるようです。
              親コメント
        • by njt (4968) on 2006年04月14日 10時13分 (#921342) 日記
          トランスポンダか。地上子とは別の用語で表現したということは、違う範囲の概念なのかしらん。
          --
          s/社内/車内/
          親コメント
          • by Anonymous Coward
            ATS-Pの速照でもトランスポンダと呼ぶのだけど、地上子そのものですよね。
            速照に使うときは2つペアになるわけですが。

            他にCTC用に列車位置情報を補足するのに使うのもトラポンと呼んでます。
            ATS,ATCの地上子は軌道間の進行方向左よりありますが、CTC用は軌道間の中央に置かれて、形状も違ってます。
      • by Anonymous Coward
        #920636の者ですが、東海道新幹線にはATSはなくATCである
        という理解でOKですか?

        「ぐぐれ」と言われましたが鉄道関係はWikipedia見る
        ことにします。ハイ。
    • Re:ATSとATCって (スコア:1, 参考になる)

      by Anonymous Coward on 2006年04月13日 14時10分 (#920665)
      せめてぐぐれ。といいたいとこだが速度照査型ATSなんてものがあってわかりにくいのかな。
      ATS
      Automatic Train Stop (自動列車停止装置)
      停止させるだけ
      ATC
      Automatic Train Control (自動列車制御装置)
      複数の制限速度に応じて減速
      です。加速制御まで行うものは ATO といいます。
      親コメント
    • by Anonymous Coward
      >何が違うんでしょうか?
      無い頭使ってググレばいんじゃね?
  • by Anonymous Coward on 2006年04月13日 13時50分 (#920645)
    このへん [srad.jp]を参考に、ソフトウェア以外もきちんと勉強を。
    • by gedo (7079) on 2006年04月13日 14時27分 (#920682) 日記
      おそらく、今回のケースは組込み関連系の知識や技術(特にリアルタイム性とか、処理時間などに対する制約関連とか)が不足していて、パソコンとかと同じ感覚で作ってしまったと言うパターンではないでしょうか?

      最近は、ハード離れの傾向が良く見かけられ、そういう方向に明るい人が確保しにくくなっている傾向があるので、止むを得ずパソコン系な人を組込みのチームに入れる際には、その辺をよく注意(とコードのチェック)することにしています。(実際組込み系の目から見ると信じられないコードを作るし)

      あと、リソースや使用目的が許せば組込み用Windowsを採用と言うのも、こういう情勢に対する現実解と捕らえる向きもあるようです。
      親コメント
      • 組込み系に限らず, 世の中のシステムのほとんどがベストエフォート型になっちゃったので, 性能保証型のシステムを扱える人材が全般的に少なくなっちゃたんでしょうね.

        まあ性能保証型のシステムは全体的に高コストではあるんですが, それに文句を言うのであれば夏のビッグサイトで携帯が継らないのにも文句を言っちゃダメな分けで.

        親コメント
    • 旧型ATCって、6800とか6809が入っていた箱のことかなー。
  • by Anonymous Coward on 2006年04月14日 0時14分 (#921110)
    台湾新幹線は入札が二転三転の大逆転してしまったので、
    単線並列になっちゃいましたけど、もしもATC-NSやKS互換だったら
    実運用に近い状態でバグ出しできたんだろうなぁ

    #台湾版デジタルATCの方がよほど地雷だという話もありますが
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...