アカウント名:
パスワード:
> 信号線の異常で進行方向の情報が無い場合に、直前の進行方向を継続する
これって絶対にやってはいけないことですね・・・。
情報がないなら何も動かないようにすべき。勝手な判断をして無理に動かすとろくなことにならない。
実際のところ、他の6社では「情報不一致の場合、走行しない」とされていたわけで、横浜(金沢)シーサイドラインだけ、そういう仕様にあえてしたというのなら設計者の根本的な安全思想が間違っているということ。
この他の処理系統についても全て見直したほうが良さげに思います。
今回のは(命に係わる)動作する物なので、その例は無意味。動作中であれば減速停止、緊急停止の2択、停止中であればロック(手動で解除可能だが微速限定)しか有り得ない。
情報がないなら何も動かないようにすべき。
に対するコメント
地下(或いはそれに準じたリニア中央新幹線などのチューブ内)の鉄道車両でないならばね。
# 減圧チューブ内で自動停止したハイパーループも怖いねぇ。
報告書がごちゃごちゃ書いてあるので判りにくいですが、問題のポイントは各車両にあるVVVF装置が進行方向を指示するF線・R線の情報を憶えてて、加速指令はそれらの情報とは別系でVVVF装置に加わるということです。今回はF線が断線して、進行方向が切り替わらないまま加速指令を受けたVVVF装置が終着駅で加速して結果として逆走が発生したわけです。VVVF装置が勝手に判断したのではなくて、直前の指示に忠実に従ったから逆走したのです。なお、「VVVF装置が進行方向の情報を憶える」という点について他の新交通システムがどういう実装になってるのかはリンク先の報告書ではわかりません。それで対策としては、もとの設計思想からすると、VVVF装置が進行方向をどちらと認識しているかと、運転指令を突き合わせて加速指令を出してよいか判断すべきですが、VVVF装置から情報を送る改修が大変なためか、VVVF装置に進行方向を憶えさせるのはやめて常に進行方向を指示するようにして、その進行方向の指示と運転指令を突き合わせるように改めているようです。もとの設計のミスは、情報伝達の信頼性を考慮せず下位の装置が常に指示通りに動くという前提で考えられていたことです。この点、伝送路がちっともtrustedじゃなくて、パケットロスやデータ化け、順序の入れ替わりなどの発生を普通に受け止めてるネットワーク屋さんのセンスがあれば事故は防げたかもしれませんね。そしてもしあえて下位装置からのフィードバックなしでシステムを組むならば、「方向」と「加速」の指示を別々にすべきではなく、「上り加速」「下り加速」という指示の仕方に改めるのも手でしょう。この場合断線で情報が伝わらなければ列車は動きませんので。
他社のVVVF装置はすべて、力行指令が来た時点でF線・R線のどちらかが加圧されていないと、力行指令自体を無視する設計だったそうです。つまりシーサイドラインのものだけ設計ミスです。最後の情報を覚えておく設計はありえません。F線・R線は、その時の方向設定を常時加圧しておく設計なので、どちらの線も加圧されていないのに力行指令が来るのはおかしいのです。なお断線した時期が具体的に特定されたのは、F線・R線の状態のログが残っていて、両方の線が無加圧に変化した時間がわかったからです。
最近の新しい電車だと制御伝送といって、ネットワークを列車に張り巡らせて、運転台の装置から制御器に電文を送って制御する仕組みになっていますが、シーサイドラインの車両を含め古い車両は、車内放送の音声のようなアナログ波形をそのまま伝送するもの以外は、1ビットの情報に1本の線を割り当てて、そこに電圧が印加されているかいないかだけで情報伝送しています。また加速の指示も、加速の程度を与える必要があって、普通は3ビットか4ビット割り当てています。「上り加速」「下り加速」という指示にしようとするとその倍になってしまいますから、やはり順当には方向指示2ビット、加速指示3/4ビットでしょう。常時方向指示を見る設計にすれば今回の問題は起きません。
なお過去に、指令線に鉄粉が突き刺さって電源線と指令線を短絡してしまい、フル加速指示とドア開制御が同時に働いて、ドアが開いたまま全力で走ってしまった、という事故が国鉄でありました。ブレーキも効かずに結局パンタグラフを下げて無理やり止めたとか。
難しい言い回ししてるけど、要するに方向切替指示がエッジトリガ(横浜シーサイドライン)かレベルトリガ(他社)かって話でしょ?未定義状態での動作がフェイルセーフでは無かったにせよ、ありえない設計とまでは言えないかと。常時方向指示を見る設計にしたところで、貴方が挙げたような方向支持線の短絡・断線が起これば想定方向と逆走することはありえますからね。
今どきのネットワーク屋さんもTCPに慣れ親しみすぎているせいか、「正しく届いて当たり前」な人たちがほとんどなので、「ネットワークを扱う組み込み屋さんのセンス」か、「ありとあらゆることを疑ってかかるセキュリティソフト屋さんのセンス」でしょうね。
通信部分はライブラリ/OSに任せれば、アプリ開発者は余計なこと考えなくていいってのが最大の進化でしょう
通信がパケットだったら、その仕様はわからなくもない仮にパケロス50%とかで、その時に止まると、ガクガクしちゃうでしょ
飛行機で安全側に倒すなら、飛行中に異常を検知したらエンジンシャットダウンして停止すればいいのかな?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
安全側に倒れてない (スコア:5, 興味深い)
> 信号線の異常で進行方向の情報が無い場合に、直前の進行方向を継続する
これって絶対にやってはいけないことですね・・・。
情報がないなら何も動かないようにすべき。
勝手な判断をして無理に動かすとろくなことにならない。
実際のところ、他の6社では「情報不一致の場合、走行しない」とされていたわけで、
横浜(金沢)シーサイドラインだけ、そういう仕様にあえてしたというのなら
設計者の根本的な安全思想が間違っているということ。
この他の処理系統についても全て見直したほうが良さげに思います。
Re:安全側に倒れてない (スコア:4, 興味深い)
ガス系などは直前の状態を維持するのが良いとされています。
Re:安全側に倒れてない (スコア:2)
今回のは(命に係わる)動作する物なので、その例は無意味。
動作中であれば減速停止、緊急停止の2択、停止中であればロック(手動で解除可能だが微速限定)しか有り得ない。
Re:安全側に倒れてない (スコア:2)
情報がないなら何も動かないようにすべき。
に対するコメント
Re: (スコア:0)
地下(或いはそれに準じたリニア中央新幹線などのチューブ内)の鉄道車両でないならばね。
# 減圧チューブ内で自動停止したハイパーループも怖いねぇ。
Re: Re:安全側に倒れてない (スコア:1)
// 設計時から
Re:安全側に倒れてない (スコア:2)
報告書がごちゃごちゃ書いてあるので判りにくいですが、問題のポイントは各車両にあるVVVF装置が進行方向を指示するF線・R線の情報を憶えてて、加速指令はそれらの情報とは別系でVVVF装置に加わるということです。今回はF線が断線して、進行方向が切り替わらないまま加速指令を受けたVVVF装置が終着駅で加速して結果として逆走が発生したわけです。VVVF装置が勝手に判断したのではなくて、直前の指示に忠実に従ったから逆走したのです。なお、「VVVF装置が進行方向の情報を憶える」という点について他の新交通システムがどういう実装になってるのかはリンク先の報告書ではわかりません。
それで対策としては、もとの設計思想からすると、VVVF装置が進行方向をどちらと認識しているかと、運転指令を突き合わせて加速指令を出してよいか判断すべきですが、VVVF装置から情報を送る改修が大変なためか、VVVF装置に進行方向を憶えさせるのはやめて常に進行方向を指示するようにして、その進行方向の指示と運転指令を突き合わせるように改めているようです。
もとの設計のミスは、情報伝達の信頼性を考慮せず下位の装置が常に指示通りに動くという前提で考えられていたことです。この点、伝送路がちっともtrustedじゃなくて、パケットロスやデータ化け、順序の入れ替わりなどの発生を普通に受け止めてるネットワーク屋さんのセンスがあれば事故は防げたかもしれませんね。
そしてもしあえて下位装置からのフィードバックなしでシステムを組むならば、「方向」と「加速」の指示を別々にすべきではなく、「上り加速」「下り加速」という指示の仕方に改めるのも手でしょう。この場合断線で情報が伝わらなければ列車は動きませんので。
Re:安全側に倒れてない (スコア:1)
他社のVVVF装置はすべて、力行指令が来た時点でF線・R線のどちらかが加圧されていないと、
力行指令自体を無視する設計だったそうです。
つまりシーサイドラインのものだけ設計ミスです。
最後の情報を覚えておく設計はありえません。
F線・R線は、その時の方向設定を常時加圧しておく設計なので、
どちらの線も加圧されていないのに力行指令が来るのはおかしいのです。
なお断線した時期が具体的に特定されたのは、F線・R線の状態のログが残っていて、
両方の線が無加圧に変化した時間がわかったからです。
最近の新しい電車だと制御伝送といって、ネットワークを列車に張り巡らせて、
運転台の装置から制御器に電文を送って制御する仕組みになっていますが、
シーサイドラインの車両を含め古い車両は、車内放送の音声のような
アナログ波形をそのまま伝送するもの以外は、1ビットの情報に1本の線を割り当てて、
そこに電圧が印加されているかいないかだけで情報伝送しています。
また加速の指示も、加速の程度を与える必要があって、普通は3ビットか4ビット
割り当てています。
「上り加速」「下り加速」という指示にしようとするとその倍になってしまいますから、
やはり順当には方向指示2ビット、加速指示3/4ビットでしょう。
常時方向指示を見る設計にすれば今回の問題は起きません。
なお過去に、指令線に鉄粉が突き刺さって電源線と指令線を短絡してしまい、
フル加速指示とドア開制御が同時に働いて、ドアが開いたまま全力で走ってしまった、
という事故が国鉄でありました。
ブレーキも効かずに結局パンタグラフを下げて無理やり止めたとか。
Re: (スコア:0)
難しい言い回ししてるけど、要するに方向切替指示がエッジトリガ(横浜シーサイドライン)かレベルトリガ(他社)かって話でしょ?
未定義状態での動作がフェイルセーフでは無かったにせよ、ありえない設計とまでは言えないかと。
常時方向指示を見る設計にしたところで、貴方が挙げたような方向支持線の短絡・断線が起これば想定方向と逆走することはありえますからね。
Re: (スコア:0)
今どきのネットワーク屋さんもTCPに慣れ親しみすぎているせいか、「正しく届いて当たり前」な人たちがほとんどなので、
「ネットワークを扱う組み込み屋さんのセンス」か、「ありとあらゆることを疑ってかかるセキュリティソフト屋さんのセンス」でしょうね。
Re: (スコア:0)
通信部分はライブラリ/OSに任せれば、アプリ開発者は余計なこと考えなくていい
ってのが最大の進化でしょう
Re: (スコア:0)
通信がパケットだったら、その仕様はわからなくもない
仮にパケロス50%とかで、その時に止まると、ガクガクしちゃうでしょ
Re: (スコア:0)
飛行機で安全側に倒すなら、飛行中に異常を検知したらエンジンシャットダウンして停止すればいいのかな?
Re:安全側に倒れてない (スコア:1)