アカウント名:
パスワード:
日立製作所などと行った調査でシステム自体には問題がないことを確認され、人的ミスでソフトが不具合を起こしたことが判明したと書かれているのだが、おそらくシステム容量という仕様を超える入力をしたのは人的ミスということなのだろう。正直なところ、多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが。
まさにこの部分に尽きると思うの。
データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の２倍程度の負荷で済むはず。それで落ちるってことは、普段から「想定される最大負荷の５０％以上」で運用してたってことになるわよね。新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの？
電車が「止まる」だけなら人命に直接は関係しないからいいけど、安全対策とかの部分も「結構ぎりぎり」なのだとしたら怖いわよねぇ。そんなことは無い、と思いたいけど。
> それで落ちるってことは、普段から「想定される最大負荷の５０％以上」で運用してたってことになるわよね。> 新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの？
オンラインデータ処理の認識が甘いと思います。1カ所でポイント切り替え故障しただけならともかく、同時多発的に発生した場合は2倍程度では済まないです。リアルタイムで新幹線の位置が変わる中で筋切り替え、筋戻しをそれぞれのポイント/新幹線車両ごとに調整しながらやっていくわけですから。しかも新幹線は時速270km とかで 3から 5 分間隔で走っています。
システム設計は別として全系止めたのは危機対処としては (なかなか出来ない) すばらしい判断だと思います。
皮肉にもなってないな。他社がなかなかできない(しない)のは事故回避よりも運行維持に天秤を傾けているだけだろう。羽越本線で列車がひっくり返って以降、JRは事故回避の側に倒すようになったが、それが悪いとは思わないけどな。人死にが出るよりはなんぼかマシだよ。
＞他社がなかなか出来ないすばらしい判断
同感です。確かにこんな複雑な高密度運行が要求されるシステムは世界でそうはないでしょうから、大半の他社はシステム開発と線路の敷設から始めなければなりませんね。なかなかできないですよね。
> 縮退運転するくらいなら全面停止してしまえという発想ですよね。
今回の件で言うと縮退運転すら出来ない状況になっています。
在来線の速度・密度ならば運転手の目視による運行というのは十分あり得ますが、新幹線の場合にはコンピュータの補助無しには実質運行できないですから。
1. 運行状況が画面に正常に表示できなくなった2. 原因を切り分けるためには止めるしかない状況になった3. 停止した
これだけ早く検出して、復帰しているところを見ると完全にマニュアル化されていたのだと思います。
今回の事案を纏めると、24件の列車運用を変更したら、自動的に修正されたダイヤが表示限界の600件を超えて表示が消えたと云う物。
表示限界の600件だが、正直言って、一度に600件のデータを人間が目視で確認して対応するのは不可能だから、例え表示出来ても無意味な件数として設定されたのだと思う。件数が半端なのは、多分、現場が頑張れば、500件なら対応出来ると見たんだろうと推測。
ダイヤ変更自体が「普通じゃ無い事」だから、それを関係各位に通達するとなると、500件でも人間側の作業は大忙しになる事が予見出来る。「表示」が必要なのは、人間が対応するからで、対応不要なら、初めから表示する必要が無い。
では、24件の設定変更が拙いかと言うと、表示限界600件から考えると、無茶な数では無い筈。
根本問題は、自動変更に任せた、24件が600件以上に膨れ上がる、過密連携ダイヤ編成自体に在る。それが避けられない場合は、運用で、連鎖しない様に注意して変更する必要が有る。が、人間が作業する以上は、運用だけでは回避出来ない。それが実際に起きたのが今回の事例。「停止しないシステム」としては、通常ダイヤ編成時点で、実は破綻していたと云う事だね。
今後は、「連鎖しないダイヤ生成アルゴリズム」が仕様に入るのだろう。
プロコンでオーバーロードになるとレスポンスが遅くなるというのはよくある話で、制御系システムではこれを如何に潰すかが腕の見せ所であるわけですが、それで画面の応答がが遅くなって、表示されないように見えたということだろうと思います。
件数が大きくなって巡回セールスマンを解くのに 1/60 秒を超えてしまったのですねあれ？なんか既視感が……気にしないことにしよう。
昔の１６ビットコンピューターでも、３２７６８件ぐらいは、平気なはずです
処理内容を把握せずに「平気なはず」って……。３２７６８都市の巡回セールスマン問題も「平気なはず」ですか？
どんだけ新幹線走らせるつもりなんだ？
>昔の１６ビットコンピューターでも、>３２７６８件ぐらいは、平気なはずです。
なにこの恥ずかしいコメント
昔の１６ビットコンピューターでも、 ３２７６８件ぐらいは、平気なはずです。
神経が切れているとしか思えない…
さすがに低脳過ぎるだろ・・・びっくりするわ釣りだろ？
16bitなら６５５３６件って突っ込めば良いのか？
みんな16bitまではそらんじてるよね1,2,4,8,16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,6553624bitがフルカラー1270万色なのは知ってるけど確かな数字が言えない誰か32bitまで暗記してる人いますか？
> 負荷の増大に耐えるようにすればいいわけですが、それは予算との兼ね合いがあるわけです。> かといって、オーバーロードだから入力の受け付けはやりませんという分けにもいかないのです。設備を十分に強化したからオーバーロードは「想定外」ってのも危険な気がするけど。
誤動作もしてないしダウンもしてないし、
平成７年のコスモスの運用開始時に比べ、新幹線の輸送量が約４割増加していることなどが背景となったようだ。ＪＲ東では「これまでトラブルはなく、６００件という上限を変更する必要は感じていなかった」（ＪＲ東）という。http://sankei.jp.msn.com/affairs/news/110118/dst11011821360040-n1.htm [msn.com]
といった背景は無視ですか？
鉄道はエラー時のフェイルセーフが重要視される分野だけど、画面表示がおかしくなることで異常が確認されたってのはまずいんじゃないかな。もし、内部的なエラーが発生しているにもかかわらずエラー表示や異常終了がおこらず、「画面表示」以外の、人間がみえないところでこっそりとエラーをおこしていたら、人が異常に気付かずに重大事故につながった危険性もあるよね。
「本製品は、医療機器、原子力発電など人命に関わる設備や機器、高度な信頼性を必要云々には使っちゃだめだよ」契約ならまだしも、こういうお値段の桁が一つ以上違う契約でエラー検出がしっかりされていないなんて...
正確には、オーバーロードになっていることを、エラーと定義しなかったので、エラーが出ないのは正常、ということですよね。
で、大事なのは、これを教訓に、オーバーロードについてもエラーなり警告なりが出るように発注仕様に入れておかなければならない、ということをちゃんと知見として蓄えることでしょう。もちろん、それを組み込むことでコストがどれくらいはね上がるか、という検討も含めて。
600件でだめだってさしばらくは運用でカバーしますので許してくださいだそうです
>正直なところ、多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが。
だとか
>データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の２倍程度の負荷で済むはず。
slashdotも2ちゃんねるかそれ以下のレベルに落ちてしまったのだなあ、とこういう投稿を見るとつくづく思う。どういう根拠でこういう考え方になるのかまったく理解できない。あ、もしかして事情に詳しい中の人なのかな？
今の運行管理システムは昔みたいに事故発生等に伴う応急ダイヤ変更時に筋屋さんが新たに手書きでダイアグラムを書く（線を引っ張る）代わりに，適当なパラメータを入力するともろもろの条件を考慮してコンピュータが自動的に処理をするようになってます． もろもろの条件とは車両や乗務員のやりくり、在来線との接続、その他運行管理上の制限事項等です． JR東のCOSMOSはかなり進んだシステムらしいですよ． というわけで，定期的なダイヤ変更時のデータ入力と事故処理等のための応急処置とは話が違います．
＃こういうシステムがなければ，筋屋と司令員込みで新幹線輸出しなけりゃいけなくなる
COSMOSの優秀さはおっしゃるとおりですが、ツッコミどころはそこではなく『たかだか通常運用の２倍程度の負荷で済むはず』とか『普段から「想定される最大負荷の５０％以上」で運用してた』とかどんな根拠で言ってるのよ、ということです。
＞そういう人間があれこれ考えないといけないのって結構 NP なんとか問題だよねー。
必ずしも最適解を求める必要はないので、何らかのヒューリスティックでチャチャッと片付ければいいんじゃないか、と思います。
行ってたかどうかなんてわからないでしょ、JR側からの要求仕様の範囲内かもしれないし。
線路に近づくような類の作業は終電から始発の間までにしか出来ません。当然保線車両なんか出そうものなら軌道回路が短絡するから停止信号出て列車は止まります。
鉄道じゃないですけど最近入っちゃいけないコースへ入っちゃった [sponichi.co.jp]のが有りましたねえ#これも人為ミス
線路脇ではなく、作業準備用の安全なスペースでの作業として・明るいうちに予め物資搬入・そういった場所の定期的な巡回・目視で確認できる範囲の設備の確認くらいは想像つきますけど？
もしかしてEast-i（926形)とかドクターイエロー(923形）のことを言ってるの？通常の新幹線車両だからダイヤの隙は縫ってるけどあくまで信号には従うし、アレは普通に走行しながらデータを取得するものだし。
在来線と違って、さすがに新幹線の営業運転中の昼間に保守作業はやらんだろ？
ダウンする前に警告を出して欲しいですね
勘違いしている人がいるみたいだが、ダウンはしていないんだよね。データ配信は正常に行えていて、表示が間に合わなくなったわけ。
正常に表示できない状態でどうやって警告を表示するか知りたいが。
最初に「運転中の２４本の列車を最寄りの駅に止めるダイヤの変更情報」を入力したとのことで、結果的に上限の600件を超えたそうだ。
影響しあって600件を超えたのであって、入力時に判定するのは難しいだろう。
メインフレームのECS(ログ)の画面で高輝度メッセージが大量に出て、reply応答が画面の外に出てしまって気がつかないというネタを思い出しました:-)
けど2008年年末のトラブルも仕様を理解していなかったという所だから、仕様を守る運用に課題があるのかもしれません。
そこまで単純じゃないですよ。運転ダイヤの変更は配車の兼ね合いもあって以降の便にまで影響が及びます。一件の入力で数十本の修正が発生する世界で“多数の変更入力があった”という状況の方がむしろ異常ではないでしょうか？
今回の件はシステムの冗長性の問題というよりも、いちいち変更要請を行った“現場の運用ミス”という気がしますがどうでしょう？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
ぎりぎり運用やっちゃいけない分野 (スコア:1)
まさにこの部分に尽きると思うの。
データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の２倍程度の負荷で済むはず。
それで落ちるってことは、普段から「想定される最大負荷の５０％以上」で運用してたってことになるわよね。
新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの？
電車が「止まる」だけなら人命に直接は関係しないからいいけど、安全対策とかの部分も「結構ぎりぎり」なのだとしたら怖いわよねぇ。そんなことは無い、と思いたいけど。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:5, すばらしい洞察)
> それで落ちるってことは、普段から「想定される最大負荷の５０％以上」で運用してたってことになるわよね。
> 新幹線なんてかなりミッションクリティカルな分野なんだから、その時点でかなり駄目じゃないの？
オンラインデータ処理の認識が甘いと思います。
1カ所でポイント切り替え故障しただけならともかく、同時多発的に発生した場合は
2倍程度では済まないです。リアルタイムで新幹線の位置が変わる中で
筋切り替え、筋戻しをそれぞれのポイント/新幹線車両ごとに調整しながらやっていくわけですから。
しかも新幹線は時速270km とかで 3から 5 分間隔で走っています。
システム設計は別として
全系止めたのは危機対処としては (なかなか出来ない) すばらしい判断だと思います。
Re: (スコア:0)
他社がなかなか出来ないすばらしい判断をしょっちゅうできるというのも大変なことですよね。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:3, すばらしい洞察)
皮肉にもなってないな。
他社がなかなかできない(しない)のは事故回避よりも運行維持に
天秤を傾けているだけだろう。羽越本線で列車がひっくり返って
以降、JRは事故回避の側に倒すようになったが、それが悪いとは
思わないけどな。人死にが出るよりはなんぼかマシだよ。
Re: (スコア:0)
＞他社がなかなか出来ないすばらしい判断
同感です。
確かにこんな複雑な高密度運行が要求されるシステムは世界でそうはないでしょうから、
大半の他社はシステム開発と線路の敷設から始めなければなりませんね。
なかなかできないですよね。
Re: (スコア:0)
トータル的にみれば運用側の傷が最も浅く済むのでしょう、その発想に立つ事により冗長系の切り詰めも可能になりますからね。
鉄道の運行という面からは、私なんぞかなり違和感のある考え方なのですが、それは多分私が古い人間だからなのでしょう。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:2)
> 縮退運転するくらいなら全面停止してしまえという発想ですよね。
今回の件で言うと縮退運転すら出来ない状況になっています。
在来線の速度・密度ならば運転手の目視による運行というのは十分あり得ますが、
新幹線の場合にはコンピュータの補助無しには実質運行できないですから。
1. 運行状況が画面に正常に表示できなくなった
2. 原因を切り分けるためには止めるしかない状況になった
3. 停止した
これだけ早く検出して、復帰しているところを見ると完全にマニュアル化されていたのだと思います。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:4, 参考になる)
今回の事案を纏めると、24件の列車運用を変更したら、自動的に修正されたダイヤが表示限界の600件を超えて表示が消えたと云う物。
表示限界の600件だが、正直言って、一度に600件のデータを人間が目視で確認して対応するのは不可能だから、例え表示出来ても無意味な件数として設定されたのだと思う。
件数が半端なのは、多分、現場が頑張れば、500件なら対応出来ると見たんだろうと推測。
ダイヤ変更自体が「普通じゃ無い事」だから、それを関係各位に通達するとなると、500件でも人間側の作業は大忙しになる事が予見出来る。
「表示」が必要なのは、人間が対応するからで、対応不要なら、初めから表示する必要が無い。
では、24件の設定変更が拙いかと言うと、表示限界600件から考えると、無茶な数では無い筈。
根本問題は、自動変更に任せた、24件が600件以上に膨れ上がる、過密連携ダイヤ編成自体に在る。
それが避けられない場合は、運用で、連鎖しない様に注意して変更する必要が有る。
が、人間が作業する以上は、運用だけでは回避出来ない。
それが実際に起きたのが今回の事例。
「停止しないシステム」としては、通常ダイヤ編成時点で、実は破綻していたと云う事だね。
今後は、「連鎖しないダイヤ生成アルゴリズム」が仕様に入るのだろう。
-- Buy It When You Found It --
Re:それはチョット違うよな (スコア:3, 参考になる)
読売 [yomiuri.co.jp]だと
＞同社によると、新幹線の運行を管理するシステム「ＣＯＳＭＯＳ（コスモス）」は、トラブルなどで運行本部の係員がダイヤ変更を行うと、
＞その後に運行される列車のダイヤについて自動計算で変更か所を表示する。表示は６００件が上限という設定だった。
＞トラブルのあった１７日朝、雪の影響で新白河、福島駅でポイントが切り替わらなくなり、運行本部は列車２４本のダイヤを変更。
＞その際、自動計算で変更されたダイヤが６００件を超えてしまい、画面が消えるトラブルが発生したという。
プロコンでオーバーロードになるとレスポンスが遅くなるというのはよくある話で、制御系システムではこれを如何に潰すかが
腕の見せ所であるわけですが、それで画面の応答がが遅くなって、表示されないように見えたということだろうと思います。
負荷の増大に耐えるようにすればいいわけですが、それは予算との兼ね合いがあるわけです。
かといって、オーバーロードだから入力の受け付けはやりませんという分けにもいかないのです。
オーバーロードでおかしくなったのは、新幹線で以前もあったと思うし、最近では消防庁で119番がつながらないという
トラブルも起きたばかりですね。
Re:それはチョット違うよな (スコア:2)
プロコンでオーバーロードになるとレスポンスが遅くなるというのはよくある話で、制御系システムではこれを如何に潰すかが腕の見せ所であるわけですが、それで画面の応答がが遅くなって、表示されないように見えたということだろうと思います。
件数が大きくなって巡回セールスマンを解くのに 1/60 秒を超えてしまったのですね
あれ？なんか既視感が……気にしないことにしよう。
これが参考になる意見かな？ (スコア:0, フレームのもと)
偉そうな事を言うのは、神経が切れているとしか思えません。
昔の１６ビットコンピューターでも、
３２７６８件ぐらいは、平気なはずです。
どう考えても、どこかの図書館の検索システムの問題と同類の不具合ですね。
ちなみに、119番の場合は、「ループ」だったので、
処理能力が∞に必要になる状態で、全く参考にはなりません。
Re:これが参考になる意見かな？ (スコア:1, すばらしい洞察)
処理内容を把握せずに「平気なはず」って……。
３２７６８都市の巡回セールスマン問題も「平気なはず」ですか？
Re: (スコア:0)
どんだけ新幹線走らせるつもりなんだ？
Re: (スコア:0)
>昔の１６ビットコンピューターでも、
>３２７６８件ぐらいは、平気なはずです。
なにこの恥ずかしいコメント
Re: (スコア:0)
昔の１６ビットコンピューターでも、
３２７６８件ぐらいは、平気なはずです。
神経が切れているとしか思えない…
Re: (スコア:0)
>昔の１６ビットコンピューターでも、
>３２７６８件ぐらいは、平気なはずです。
さすがに低脳過ぎるだろ・・・びっくりするわ
釣りだろ？
Re: (スコア:0)
16bitなら６５５３６件って突っ込めば良いのか？
Re:これが参考になる意見かな？ (スコア:1)
みんな16bitまではそらんじてるよね
1,2,4,8,16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536
24bitがフルカラー1270万色なのは知ってるけど確かな数字が言えない
誰か32bitまで暗記してる人いますか？
Re: (スコア:0)
> 負荷の増大に耐えるようにすればいいわけですが、それは予算との兼ね合いがあるわけです。
> かといって、オーバーロードだから入力の受け付けはやりませんという分けにもいかないのです。
設備を十分に強化したからオーバーロードは「想定外」ってのも危険な気がするけど。
Re:それはチョット違うよな (スコア:2, 興味深い)
誤動作もしてないしダウンもしてないし、
といった背景は無視ですか？
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1, すばらしい洞察)
鉄道はエラー時のフェイルセーフが重要視される分野だけど、画面表示がおかしくなることで異常が確認されたってのはまずいんじゃないかな。
もし、内部的なエラーが発生しているにもかかわらずエラー表示や異常終了がおこらず、「画面表示」以外の、人間がみえないところでこっそりとエラーをおこしていたら、人が異常に気付かずに重大事故につながった危険性もあるよね。
「本製品は、医療機器、原子力発電など人命に関わる設備や機器、高度な信頼性を必要云々には使っちゃだめだよ」契約ならまだしも、こういうお値段の桁が一つ以上違う契約でエラー検出がしっかりされていないなんて...
Re: (スコア:0)
Re:ぎりぎり運用やっちゃいけない分野 (スコア:2, 興味深い)
正確には、オーバーロードになっていることを、エラーと定義しなかったので、エラーが出ないのは正常、ということですよね。
で、大事なのは、これを教訓に、オーバーロードについてもエラーなり警告なりが出るように発注仕様に入れておかなければならない、ということをちゃんと知見として蓄えることでしょう。
もちろん、それを組み込むことでコストがどれくらいはね上がるか、という検討も含めて。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1, すばらしい洞察)
Re: (スコア:0)
600件でだめだってさ
しばらくは運用でカバーしますので許してくださいだそうです
Re: (スコア:0)
>正直なところ、多数のダイヤ変更に対応できないシステムのほうがおかしい気がしないのでもないのだが。
だとか
>データの入れ替えで「全部の」ダイヤを変更したとしても、たかだか通常運用の２倍程度の負荷で済むはず。
slashdotも2ちゃんねるかそれ以下のレベルに落ちてしまったのだなあ、とこういう投稿を見るとつくづく思う。
どういう根拠でこういう考え方になるのかまったく理解できない。
あ、もしかして事情に詳しい中の人なのかな？
Re:ぎりぎり運用やっちゃいけない分野 (スコア:3, 興味深い)
今の運行管理システムは昔みたいに事故発生等に伴う応急ダイヤ変更時に筋屋さんが新たに手書きでダイアグラムを書く（線を引っ張る）代わりに，適当なパラメータを入力するともろもろの条件を考慮してコンピュータが自動的に処理をするようになってます． もろもろの条件とは車両や乗務員のやりくり、在来線との接続、その他運行管理上の制限事項等です． JR東のCOSMOSはかなり進んだシステムらしいですよ．
というわけで，定期的なダイヤ変更時のデータ入力と事故処理等のための応急処置とは話が違います．
＃こういうシステムがなければ，筋屋と司令員込みで新幹線輸出しなけりゃいけなくなる
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1, すばらしい洞察)
COSMOSの優秀さはおっしゃるとおりですが、ツッコミどころはそこではなく
『たかだか通常運用の２倍程度の負荷で済むはず』とか『普段から「想定
される最大負荷の５０％以上」で運用してた』とかどんな根拠で言ってるのよ、
ということです。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1)
...
>コンピュータが自動的に処理を
そういう人間があれこれ考えないといけないのって結構 NP なんとか問題だよねー。
そういうのが解けるということは、なかなかすごいシステムなんだなー。
件数がちょっとふえると大変そうだ。
まあ、事故がなくてなにより。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:2, 興味深い)
＞そういう人間があれこれ考えないといけないのって結構 NP なんとか問題だよねー。
必ずしも最適解を求める必要はないので、何らかのヒューリスティックで
チャチャッと片付ければいいんじゃないか、と思います。
Re: (スコア:0)
Re: (スコア:0)
行ってたかどうかなんてわからないでしょ、JR側からの要求仕様の範囲内かもしれないし。
Re: (スコア:0)
「ダイヤ管理」についてまでミッションクリティカルだと言うのは、恣意的な拡大解釈ではないですか？
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1)
場合によっては、走行制御よりも被害者が出る危険性が増えますよ。
如何なる内容であろうとACでの書き込みは一切無視します。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1, 参考になる)
線路に近づくような類の作業は終電から始発の間までにしか出来ません。
当然保線車両なんか出そうものなら軌道回路が短絡するから停止信号出て列車は止まります。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:2)
鉄道じゃないですけど
最近入っちゃいけないコースへ入っちゃった [sponichi.co.jp]のが有りましたねえ
#これも人為ミス
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1)
カギを開けて上っていくJRと書かれた車両を時たま見るんですが、あれはなんなのでしょう？
作業員が上に行って線路にまで入り込んで作業されてるかは確認してませんが…
如何なる内容であろうとACでの書き込みは一切無視します。
Re: (スコア:0)
線路脇ではなく、作業準備用の安全なスペースでの作業として
・明るいうちに予め物資搬入
・そういった場所の定期的な巡回
・目視で確認できる範囲の設備の確認
くらいは想像つきますけど？
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1)
もしかしてEast-i（926形)とかドクターイエロー(923形）のことを言ってるの？
通常の新幹線車両だからダイヤの隙は縫ってるけどあくまで信号には従うし、アレは普通に走行しながらデータを取得するものだし。
Re: (スコア:0)
在来線と違って、さすがに新幹線の営業運転中の昼間に保守作業はやらんだろ？
Re: (スコア:0)
ダウンする前に警告を出して欲しいですね
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1, 参考になる)
勘違いしている人がいるみたいだが、ダウンはしていないんだよね。
データ配信は正常に行えていて、表示が間に合わなくなったわけ。
正常に表示できない状態でどうやって警告を表示するか知りたいが。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:2, おもしろおかしい)
「時間がかかる可能性があります」といったメッセージのように、
「システムの想定範囲を越えたデータ数です。異常動作を引き起こす可能性がありますが、続行しますか。」
みたいなメッセージがあらかじめ表示されると親切だったかもしれない。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:2)
最初に「運転中の２４本の列車を最寄りの駅に止めるダイヤの変更情報」を入力したとの
ことで、結果的に上限の600件を超えたそうだ。
影響しあって600件を超えたのであって、入力時に判定するのは難しいだろう。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:2)
メインフレームのECS(ログ)の画面で高輝度メッセージが大量に出て、reply応答が画面の外に出てしまって気がつかないというネタを思い出しました:-)
けど2008年年末のトラブルも仕様を理解していなかったという所だから、
仕様を守る運用に課題があるのかもしれません。
Re:ぎりぎり運用やっちゃいけない分野 (スコア:1)
>のは難しいだろう。
実更新に行く前に同一条件での影響検索で件数だけはじき出し
事前チェックすることも作りによっては可能かも。
# 制御系で許容されないほどレスポンス低下しそうだけど
まぁ、レコード変更をトリガで拾って影響レコードを更新、
なんて作りだったり、入力以外にセンサ等の情報から自動更新
とかだったりすると事前検知できないですね。
---- 何ぃ！ザシャー
Re:ぎりぎり運用やっちゃいけない分野 (スコア:2)
Re: (スコア:0)
組み合わせは指数的に増大するってw
Re: (スコア:0)
そこまで単純じゃないですよ。
運転ダイヤの変更は配車の兼ね合いもあって以降の便にまで影響が及びます。
一件の入力で数十本の修正が発生する世界で“多数の変更入力があった”という状況の方がむしろ異常ではないでしょうか？
今回の件はシステムの冗長性の問題というよりも、いちいち変更要請を行った“現場の運用ミス”という気がしますがどうでしょう？
Re: (スコア:0)
変更せずに、ダイヤとは違う運転ができるシステムなの? 新幹線は。