信号・標識・保安設備について語るスレ27
■ このスレッドは過去ログ倉庫に格納されています
信通屋さん、信号屋さん、信号・ATSマニアの方など、引き続きカキコおねがいします。
なるべくマターリ進行で行きましょう。
前スレ
信号・標識・保安設備について語るスレ26
http://mevius.5ch.net/test/read.cgi/train/1471584705/
次スレ立てる時は一行目に
!extend:default:vvvvv:1000:512
を入れて名前欄は「旭=1008」を入れること
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>636
宇都宮にそっぽを向かれた組織だったか？ >>645
むしろ２１世紀の今まで遺ってたのが驚異的 工務スレにはヤフーニュースソースで書いたが神奈川新聞サイトでは原因が更新されてた
ttp://www.kanaloco.jp/sp/article/326544
連動装置の保守点検作業中に配線を誤ってつないだ、とな。
連動装置の保守点検で配線つなぎ替えなんてするんかい、なんて無垢な突っ込みは置いといて。 >>648
どこか繋いじゃいけない所を繋いじゃったから事故になったんだろ（適当 ちょいと質問
SMETとMTDってどこがどう違うのでしょうか？
よろしければ教えてください
あとSMETの読み方も教えて欲しいです。
MTD(エムテイデー)は読めるのですが。 >>653
前回の更新から20年ちょっとでもう更新か。流石に金持ちだな。 閉塞がめちゃくちゃ細かくて地上設備がやたら多いシステムだから
嫌になったんじゃないの？ >>654-656
田園都市線のケーブル火災などのトラブルの対策で設備更新を計画して、
どうせ設備更新するなら地上設備が削減できる新システムにしてしまおう
みたいな感じになったのではないかと >>656
ズバリ元住吉事故（2014/2/14 24時）対応で、現状「地上演算一段制動ATC」の、
降雪時制限40km/hでは使い物にならず、
それに替われる方法としてATC全換装を内定した
という話が漏れ伝わったのが1年前。
今回公式発表となっている。
降雪モードのパターンについては認識している。（40km/h制限はその反映だろう）
東急の安全対策はかなり徹底していて、横浜駅脱線を機に、
ガードレール厳重設置、輪重比10%管理実施など、充分金を使っている。
この基準が日比谷線中目黒事故（2000/3/8）で運輸省から全鉄道事業者に採用勧告されている。
営団事故現場両側の東横線にはガードレールが設置され、
中2本の営団線には無設置の写真が当日の読売新聞夕刊に載ってた。 ATACSのような無線方式はまだ途上の技術だから見送り？
JR東は普及させたいようだから採用したいと言えば使わせてくれそうだけど
あるいは東武のATCと互換性を持たせて車両側の更新コストを抑えるとか >>659
埼京線や常磐緩行線を越える過密路線を実験台として提供する度胸はなかろう。 >>659
まだ様子見してるんだろう
東京メトロは採用に踏み切ったが、こちらもまずは走行試験で
問題がないか確認してから本格導入という流れだしな
>>661
丸ノ内線もなかなかの過密路線だと思うがなぁ >>662
CBTCは、地下鉄やAPM（新交通システム）なら世界中で実績があるからね。
ちなみに、丸ノ内線のCBTCは三菱電機。
でも、踏切あり緩急接続ありで過密ダイヤの郊外電車となると、おそらく世界初。
ATACSだって、実用化されているのは
踏切なしで緩急接続ありの埼京線と、踏切ありで緩急接続なしの仙石線だけ。
少なくとも中央快速で使い物にならなきゃ大手民鉄には入れられないかと。 >>663
赤羽〜池袋間は踏切があります。
まもなくATACSで踏切制御も始まります。 >>664
そうでしたね。でも、その区間は平行ダイヤですね。 デジタルATCやATS-P、ATACSの「車上演算方式」の共通原理は、
開通距離（許容進入距離）に函するデータを車上に与えて、走行距離分を減じ、
車上では個々の列車の想定減速度特性から限界速度を求めて速度照査すること。（勾配補正あり）。
ATS-Pなら直に距離データだが、DS-ATCで送信される「開通閉塞数」はデータベースに照らして、
速度演算に必要な許容進入距離データに転換される。
そのコマンド情報の伝え方の相違の問題。
点伝送であるATS-Pでも常に進入限界距離を与えていて、オープンにはならない訳で、
伝送のステータスをシステムが常に把握しているATACSやCBTCの方が、
正常動作かどうかシステム自身には分からない軌道回路方式より、理屈の上では信頼性が高い
という判断でATACS等が採用箇所を広げている。
その稼働実績が良ければ、旧来の実績・経験を乗り越えて転換速度が早まるってことだ。
ただ、実績を見るのに、理論的・原理的優位を押さえたうえでないと、判断が大幅に遅れる。
ここが消化不良を起こして「俺の目の黒いうちは軌道回路方式」と頑張られてるとこもあるとか。
相互乗り入れや、メンテ、要員・教育等を考えて、「最先端」に拘らず、適応しやすいものを選ぶのはアリだ。
ATS-SPでの車上データベース方式は、何処も採用しなかったが、制御振り子での実用化を経て、
ATS-Pの車上演算方式と併せて、D-ATC、DS-ATC開発、さらに無線によるATACSと段階を経て広がっているのだから。 東急のデジタルATCの仕様がわからないけど
JRみたいにDB積むのかな？
東武（T-DATC）や小田急（D-ATS-P）が
トラポンから地理情報を取得しているのは車上DBを嫌ったためで
東急やメトロのCS-ATCもそういう考え方だったはず。
5社直通で、数年後には相鉄も加わる。
車上DB方式だとしたらメンテが大変な気がする。 車上DB方式だとDB更新の度に他社線の車両まで面倒見ないといけないからな。
東武や小田急みたいに乗り入れが多ければ多いほど、￥がかかる。 >>665
緩急ありなしは、連動上の機能なんで、ATACSで何か変わるものでもないと思うけど。
時隔を詰められるという差はあるにせよ、ATPにとって緩急で性能差にならんと。 >>667
車両由来データは車上データベースへ、
地上由来データは地上データベースへ、
という合理的振り分けが追及されてきていて、
ATS-SP〜D-ATCなど当初のような全部を車上データベースに、というのは止められる方向。
地上、車上それぞれのデータベースを独立にメンテする。 東急のことだから京三製なんだろうな
京王の二の舞になるのが… >>667-668
従来の車両だとその通りだが、最新の車両では保安装置の車上DBの書き換えは
WiMAXやLTE経由で人手を介さず場所も選ばず可能となっているから
（JRのE235系、東急の2020系・6020系、相鉄20000系などが既に対応）、
今回の東急D-ATCは地上主体だったとしても、今後は車上DB方式が
主流になっていくのではないかな 東武や小田急みたいに3閉塞先までしか情報持たないとなると
新幹線のナビ、定速制御、車体傾斜のような高度な先読みがやりにくいはず。
素人考えだけど、会社境界駅や車両基地でミリ波（5G？）等を使って1路線分の地理情報を丸ごと取得できないのかな？
東横線なら、渋谷に地上子を置いて上りはDBデータ削除、下りはデータ挿入。
元住吉でも同様に入庫時に削除、出庫時に挿入。
これができれば、将来的に機能拡張の余地が生まれるはず。 境界駅での「信号機トラブル」が頻発しそう。
3閉塞先までの情報と全線の情報じゃ量が桁違いでしょ。 >>674
N700Sはミリ波でテラバイトクラスの車両データ（バイナリ）を伝送するみたいだし
それに比べたらテキスト主体のDBデータなんて軽いもんでしょ。 >>673
車上装置のメモリ容量を充分確保しておけばそこまでする必要はない
例えばATS-DNでは車上DBに北海道内の全線のATS地上子・曲線・分岐器の
位置データが収録されているわけで >>676
境界駅で一日何回も車上データ入替するよりも、
地上設備変更の時だけ車上データ更新する方が、逆に手間が掛からないないということか。 車両に流し込む路線データのバイナリフォーマットって各社同じなの？
そこの変換コストが結構重そう。
>>675
テラバイトは全車両の1日合計じゃない？ >>676-677
差分更新だとバージョン管理に手間かからない？
東横線の例だと、休日しか乗り入れない西武40000系にも
予めDBデータを登録しておく必要がある。
電留線整備工事で元町・中華街の進入速度が仮に35km/hになった場合
5社の乗り入れ可能な全車両の車上DBを漏れなく更新しないと
事故につながる恐れがある。
東横線内に入線したときに最新の線路情報を都度取得した方が安全な気がするけど
バージョン管理の上手いやり方があるのかな？ >>679
DS-ATCだとそこら辺
うまーくやってて特許かなんかになってたような
テクニカルプレビューとか見てみ 一時的な物だけ、臨時規制情報を適宜地上から投げれば >>677
車上DBに予め設備変更後のデータも記憶しておいて、地上からの指令で切り替える、ってことで良いかと。
あと、臨時速度制限機能は残すでしょうね。
まぁ、会社側の正式発表じゃないし、刷新と書いてるけど既設のTASC/ORPの応用止りかもしれないし、中の人は一連のレス見て笑ってそうな気もするし。 おまいら詳しいなあ。ｦﾀ？メーカーの中の人が多い？事業者の中の人もいる？
>>666
パターンを生成するのに、ATS-Pのように全て？の情報を地上子から拾わず、わざわざ車上DBを（併用？）使うのは
地上子などの地上設備を設置するコストを抑えるため？
車上DBのメンテの方がメンドクサそうだし、更新失敗orし忘れでリスクがありそうに見えるんだけど…
（車両系統との調整とか） あと、車上DB登録済みだけど線路切替とかが列車遅れ等で中止になったときとか。 車上DB式の場合、通常2バージョンのDBを持ってて、
地上側で使うバージョンを指定するんじゃなかったかな。 >>685
2バージョンのDBデータをどこで登録するの？
JRのように他社線乗り入れが少なければ
自社の車両基地で一括登録・更新とかできそうだけど
東横線の線路情報を登録するのに、森林公園や小手指まで中の人が出張するとか
逆に車両を元住吉まで回送するとしたら、かなり手間がかかりそう。
データの持ち出しは、セキュリティ的にもあまり良くないし。
>>682
>刷新と書いてるけど既設のTASC/ORPの応用止りかもしれない
TXみたいに伝送系をデジタル化するだけだったりして。 運転時隔の短小化も
目的の一つなら
最低でもCS-DATCか
京王、東武、JRのどれかに
当てはまる方式を採用するんじゃないか
さてはどこが製造するんだろうね(Kなんだろうけど) >>686
2バージョンを登録できる仕様が普通って話でしょ。でないと線路改良の度に徹夜しなきゃならなくなる。
何日間かに分けて全車両の車上DBを更新し、新旧同居させた状態で変更当日を迎えるから
悪天候などで延期になっても困らない、という話かと。
少なくともDBのために乗入れする他社の車両基地に入庫させたって話は聞かないから、
普通に記録媒体を運んで各社の車両基地で入れているんだと思うけど。
鉄道の維持管理はもっと手間とお金がかかる事ばかりだろ。
東横のATCは、ある意味で究極のアナログATCというか進化の袋小路というか、
よっぽど使いにくい代物なのだろうか。
例の1967年通達以降で2回目の保安装置全面更新をするのは東急が初めてだよね。 >>687
特に東武は京三アレルギーがあるのでは？
てなくらい京三がないから、車上DB更新で京三サービスマンを自社車両基地に入れるのすら嫌がったりして 運転間隔に関してはクソ細かい閉塞割りのお陰で
デジタルATCに遜色ない運転が出来てると思ってたけど
さらに詰められるの？
実際前の駅に先行が停車中でも駅手前まで普通の速度で走行→
減速→駅のギリギリ直前にて停車して開通待ちとかやってるけど >>690
デジタルATCだと閉塞割がクソ細かい個所（現状では駅構内等のみ）以外でも
そういう運転ができるようになるので、ダイヤが乱れて団子運転になった時などに効果が出る 思ったんだけど、車上DBのデータを運転士が携行する方式にしたらどうだろう？
ブレーキハンドルや行路表みたいに。
乗務所で懐中時計の時刻合わせと一緒に
毎回、地理情報の入ったメモリカードを専用端末で最新化して
自分が乗務する車両にメモリカードを読み込ませる。
（車上DBはメモリカードのデータを参照する形）
車両にメモリカードを挿入する際にPWや生体認証したり
営業線の要所要所で地理情報のバージョンチェックを行うとしても
地上側からデータを送る必要もなくなるし
乗り入れの多い線区でも工事の度に他社で更新作業する手間が省ける。 >>692
車上DBを更新しなきゃいけない機会って、そもそも年何回くらいあるんだろう。
鉄道各社がそこまで避けたいと考える作業なのだろうか。
車両基地で用意周到に技術者立ち会いの下でやるのに比べ、
境界駅でのわずかな引き継ぎ時間に読み込みする方法を
エラーとかで即運休のリスクを負ってまで採用するとも思えないけど。
データの持ち歩きはセキュリティ的にマズいんじゃなかった？
※一部外者の個人的感想です。 >>692
そこまでするくらいなら、車上DBの変更発生時に相手方会社の車両基地に
メモリーカードを持ち込む方式で充分と思うがなぁ
>>672でも書いたように今後はその持ち込みすら不要となる方向なわけだし 取り敢えず規格の乱立だけはやめてくれよ
2012年12月9日に綱島で7113Fが朝を直撃した重故障はボタンの押し間違いが原因だった
会社に怒られた人は少ないだろうけど定期客の転出は多かっただろうね
電車なのにB747のコックピット並みとか草も生えない 2018年度 鉄道事業設備投資計画
http://www.keikyu.co.jp/company/news/2018/20180509HP_18031EW.html
京急の事業計画だけど、
一部の駅で運行管理支援システムを
導入とあるね。羽田国内と蒲田はPTCに
してたと思うけど次は何処にするのかな？ >>690
列車間隔については接近し過ぎて止まってしまうより、止まらないように速度を落として走り続ける方が結果として間隔を詰められるそうだ。
なおATS時代の京王線はホーム手前にORSを付けて後続がギリギリまで接近していた。
今のATCでは駅間でも先行に近づけますね。仕様上は最短25mまで可能らしいですが、実際のところは何mなのかは測ってみたいところ。 明大前では実際に25mくらいまで近づいてるように見えるけど 京王は立体化（地下にしたい派と高架にしたい派で揉めてる）で烏山と明大前構内の上りが2線化するらしいけど、基本桜上水のような運用をして退避には使用しないのだろうか？
立体化が何十年先になるかわからないけど、その頃にはIT-ATPなどで技術的にさらに近づけることができても実際の運用ではそれが起きるかわからなくなるな >>703
25mが本当ならほぼ1車長だから、軌道回路だろうが無線だろうが
それ以上詰めたら危険だと思うが･･･・
むしろ、現状のK製デジタルATCが意外と優秀だという話では？
まあ、最初のgdgdぶりはおいといて･･･・ 空気読めないで書けば、どこまで接近できるかは、軌道回路を閉そく方式で使っているのであれば
ATCやATSの防護点の設定次第なような。
極論言えば糞田舎で長大な閉塞長の路線でも、
ATSの直下を踏まなければ軌道回路境界ギリギリまで詰めれるし
内方の列車が軌道回路境界近くにケツが残っている形で止まってたら相当接近する形になるだろうし。 >>705
確かに。
地下鉄の地上信号機の場合、R現示を2閉塞重ねる「全重複式」として
そういう事態が起こらないようにしていたけど。
地下鉄以外では1号型ATS時代の京成は
ケツ抜け感知を信号機の内方140mで行う「半重複式」だったので
無閉塞運転をしない限り140mより接近することはなかった。
どちらも列車が団子になりやすい稠密ダイヤを前提としたシステム。 >>699
文庫・八景をまとめてPTC化して省力化するんじゃない？
将来的には運輸区ごとに信号扱いを束ねていく気がする。 >>697
昨年か一昨年には発表してたと思うけど。
ちなみに都交も同じことやってる。 >>706
半重複式の信号制御なｗ
150ｍから125mだよ >>703
立体化は下り線が先。
明大前は交互発着でライナー以外は追い抜きはしないだろうが、その先は烏山が増えて一駅置きに追い抜きができるので、急行系はスピードアップになるはず。
後は、抜かれた方が即座に発車できるようになるといい。現状では進路が取れないと発車ベルが鳴らないが、通過時刻を推定して発車の案内を始め、ベル、戸閉、ホーム柵閉(非連動かよ)、安全確認にたっぷり時間を取って出発進行。
勿論、新宿みたいに同時発車までできれば、もう複々線なんて要らねぇ、って事になるんだが。 >>701
赤信号を見つけたら止まらずに手前から速度を落としてチンタラ走るバスを思い出した >>712
長距離トラックなども普通にやっているよ。
交差点の間隔が短くて後ろが詰まっている時には単なる迷惑だが･･･
どんな乗り物でも停車時とゼロ発進時には乗り心地が悪くなるし
エネルギーも浪費するからね。鉄道は特にそうなので
地上信号機にこだわる会社があったり
車上信号機に予告機能を持たせたりするんでしょ。 >>713
今、前に詰める事を話しているが、次は後続との間隔も考えることになるかも。
後続が迫っているときはできるだけ前に詰めるけど、そうでなかったら、ゆっくり走る。
現在は駅での延発や抑止は中央の指示だけど、各列車が自分で判断して走るようにする。時刻表を守るべき高速鉄道では受け入れられないだろうけど、随時運行の、例えば空港内の新交通なんかでは採用できそう。 D-TASって結局ATS-DNの亜種ってことでOK？ >>715
ATS部分の機能はATS-Dxの車上主体版そのまま（ATS-DNと同じ）なので、
亜種というよりも追加機能てんこ盛り版と考えたほうがよさそうだが、
おおざっぱにはその解釈でよいかと >>711
出発進路を構成する前から扉扱いっていろいろ難しいんだろうか。
各停が頻繁に待避するような会社だと多少は効果がありそうなものだが。 >>712
京三製作所がある市のナンバーはそんな運転するクルマが多いな
かなり遠くから減速して後方ギリギリまでゆっくり近づいてくるまさに京王京三ATCと同じようなパターンを描いてる >>718
ATC化前の東武東上線池袋駅は出発信号機が進行現示前に発車メロディーが鳴り始め、
進行に変わったらメロディーが鳴り止んでいた。
あとは、丸ノ内線池袋駅で朝ラッシュ時に出発進路を構成する前から扉扱いしてるね。
（反対側ホームに列車が到着する前に扉扱いし、列車到着後に発車） もう25年以上も前の話だが、富山地鉄の途中駅で、対向列車が進入、停車し切らぬうちに対向列車待ちをしていた列車が既に発車していた事に当時は驚いた。
いちいち電動転轍機で進路を開通させる必要のないスプリングポイントだから成せる技なのかもしれないが、
列車有効長がカツカツの離合駅、そんな場面で当時の色灯式信号機がどんな挙動をしてそれを可能にしていたのかは知らない。
当時ATSがあったかどうかも知らないし、進行現示前でも見切り発車上等ということだったのかな… >>722
対向列車のケツが車両接触限界を抜けていれば物理的な問題はないかと。
信号機もそれに合わせて出発進行になる仕様なのでは？
いくら何でも絶対信号機である出発信号機の冒進はそれだけで「事故」だから。
とはいえ、関東大手私鉄の単線区間では、対向列車が停車してから
出発進行を確認して発車するのが普通だとは思う。 >>718
別に運転保安としては
出発信号の現示と戸閉めは関係なくてよいかと。
現示でる前の出発信号機内方に列車が進入しなければよいのだから。
（あと運転取り扱い的には出発時刻前に車輪が動き出さなければよい？）
戸閉めランプ着く前にノッチ入れてたアホ運転士はつい最近の山手線で見たがw >>724
酷電時代の国電ではそれが普通だった。戸閉め連動解除で即発車ww
発車前のブザ合図をしていた営団では逆にフライング開扉が常態化していたし。
ドアの前に立ってて開いてすぐ降りるとホームが少し動いていたww >>720
俺は黄色信号を見るとアクセル踏む派だけどな >>692
> 思ったんだけど、車上DBのデータを運転士が携行する方式にしたらどうだろう？
データエラー回避には「一対一対応」が原則なんで、
車上に特有の特性データは車上に持ち、
地上に特有のデータは地上で1対1対応として、常に点検できることが必要。
この車上・地上分離の点で、ATS-Pは優れていて、
地上データまで固定車載する方式のD-ATCには問題があり、
今後、自動更新や集中管理のシステムが検討されている。
最も簡易のCBTCでは、地上データを地上一箇所に集めて全体制御まで考えられてるから、
その場合の「1対1対応」は、ダンプリストとカードで、
各現場にカードを貼り付けて比較対照する等の手立てが考えられる。
車両由来のデータを、簡単に車両と切り離して持ち歩いてはイカンてことで、>>692は原則に反して不採用。 >>727
種別と停車駅の情報に限ってそれを実施するD-TASの場合、
ダイヤが乱れても種別変更が不可能。 >>727
またまたデタラメばっかり。
D-ATCでデータベースの検討なんてされていない。
よくもまぁウソを書けるもんだ。
恥を知れ。 >>727
ＩＣカードの容量に車上ＤＢデータが入るかが問題だけど。 >>725
シーケンス制御の常識として、ON信号入れっぱなしでインターロック解除して即座に装置が動き出したらマジで死人が出るので、絶対にありえないんですけどね(ロック解除状態でのOFF→ONのエッジしか受付ない)。
フライング開扉は 有りましたねぇ。
他社ですが、オーバーランでバックしている途中で開けてしまったことがありました(先頭は未だホームから外れている)。今時だと写真撮られてネットに拡散されて大炎上だろうなぁ。 >>732
昭和時代の趣味者向けの本には裏話としてよく載っていた話です。
終戦直後の混乱期の話だったのでしょうか。
そこまで遡ると自動ドアの不具合が頻発していて
戸閉め連動そのものを開放しているケースが多かった気もする。
アナログ時代でも101系や103系などの新性能電車には
逆順の操作をブロックする論理が組まれていたんですか？
流石に旧型国電にはなかったんじゃないかと思いますけれど。 >>730
D-ATCなど、車上データベースに地上データを載せてるのは弱点だが、今、それを修正する計画はない。
確かに誤解を生ずる表現だった。
今後のシステムとして、検討されている内容。
極端には携帯回線まで動員したりして、地上は地上のデータベース、車上は車上のDBという
合理的整理の方向。
車上には、開通距離・制限点距離と、そこでの到達速度、補助的に勾配を与えて車上演算させるだけで良いはず、
地上は究極1箇所に集約という考え方で、構造・メンテの単純化が考えられている。
現状はまだ過渡的なモノが多く含まれている。
ATS-Pに追加導入された「路線の最高速度」なんてのは地上由来のモノだから、
本来なら地上に降ろす方向がすっきり。
「許容不足カント別制限」の方は、今は地上から＋値を4種送ってるが、
元々車上データだから＋部は車上演算に任せられないか？とか、境界領域の検討はされてる。 >>732
工学の基本としてはごもっともだけど、
E電の実態として、運転士が自分の目で後方確認など殆どせず
戸締め表示灯を盲目的に信頼して発車しているわけで、
フライングでノッチを入れたから即、死人が出るほど危険とは思えない。
ブザ合図で発車している路線だから引きずり事故が皆無という訳でもないし。 >>736
車掌がブザ合図をフライングで出してしまったのを見た事があります。
パイロットランプが点いてないので、
即座に運転士がインターホンで車掌に連絡、車掌が謝ってました。 東さんの首都圏の運転士は基本動作が壊滅的だが（その分高度な保安装置やらに助けられてる）
組合の情勢が一気に変わったんで、そこなへんもかわるかな、と。少しは期待してみる。
ま、事故らなきゃいいんですけどね、どちらにせよ、個人的には。 >>738
西日本の私鉄はベルの所もありますな。
中間の運転台でいきなり「チンチン」と鳴って関東住みの私は驚きました。
都電ワンマンの「チンチン」は飾りですが、こんな大型のチンチン電車が健在なのかと。 >>740
東武だったかな。何か戸挟み事故を起こしてからブザー合図を始めた所があったな。 東武の場合は、レチが体調不良で倒れていたのにもかかわらず、ウテシは知らせ灯しか見ないで運転を続けて、途中駅で知らせ灯が滅灯しない（開扉しない）ことに気が付いて様子を見に行ったら、倒れていた、というのが大きなきっかけではなかったっけ？
戸挟み事故は、都営か京王だったと思う。 >>742
関東大手では東武が最後でしたっけ、ブザー合図の導入。世紀末でしたよね。
でも、ブザーが鳴ったと思い込んで車掌置き去り事故を数年前にやってるみたい。
今世紀に入ってからはJR海とJR西がブザー合図を始めていて、
知らせ灯式は全国でもJR東の電車と伊予鉄くらいとか。
伊予鉄は「待ちノッチ」（知らせ灯点灯前のノッチオン）も健在という
目撃談がありますね。 >>743
都営地下鉄の戸挟み事故は、異物検知が甘い昔の京成車のギロチンドア
が原因で何度か起きているが、その頃にはすでにブザー合図はしていたかと。 ■ このスレッドは過去ログ倉庫に格納されています
