X



信号・標識・保安設備について語るスレ27
■ このスレッドは過去ログ倉庫に格納されています
0001旭=1008 (ワッチョイWW b3eb-uXJK)
垢版 |
2017/11/11(土) 01:26:23.62ID:DKfpNTqj0
信通屋さん、信号屋さん、信号・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
0876名無しでGO! (ワッチョイ 972d-Z9Wx)
垢版 |
2018/07/23(月) 02:31:50.70ID:DB7KmzMz0
システムをシンプル化してエラー混入を最小限に抑止し、運用の汎用性を持たせるための原則
として強調されることは
1).システムのことはシステムに聞け
2).関連群はそのグループ毎に分けて、相互乗り入れさせず管理せよ
ってことで、信号ATS/ATCシステムに即して言えば
2)−1.車両由来のデータは車両側で持ち
2)−2.地上由来のデータは地上側で持って、
信号現示に即したコマンドとして地上側から車上に送れば、
車両に路線依存性がなくなり、何処にでも自由に持って行ける。
安全性に問題のあるシステムだがATS-Sxは、この車上−地上分離は行われていて、
建前として全国のJR相互に自由に乗り入れることが出来た
(細かにはATC専用/ATS-P専用区間は総てそうか?とかの実務的疑問は残るが、「方式」として完全分離)

鉄道総研提唱で、何処も採用しなかった悲劇のATS−SP方式のキモは、
1).車上演算方式の採用(=車上データは車上に持つ)
2).Sx地上子データベースによる絶対位置照合
3).S地上子で停止コマンドを車上へ送出
4).信号電流転極による現示アップ検知
(続1)
0877名無しでGO! (ワッチョイ 972d-Z9Wx)
垢版 |
2018/07/23(月) 02:33:22.14ID:DB7KmzMz0
(承前1)
 車上演算方式1).はATS-P以降の全方式に採用される優れた方式で、
全データベース方式2).は地上に手を加えず1).を実現できる手っ取り早い方式だが、
路線毎に固有のデータであるに留まらず、駅の番線毎にデータを選ぶ必要があるなど、
データベース方式2).の管理に不安が感じられたことと、
転極を現示アップ検知に使う4).、新方式導入への不安などからJR各社とも不採用の幻のATSとなった。

そのデータベース方式の事実上の実証実験となったのが、制御式振り子へのS地上子データベース方式導入。
こればら誤動作して乗り心地悪化が起こっても危険はなく、その良好な制御特性でDB方式の鉄道市民権を確立。
D-ATC、DS-ATC、ATC−NSなどにこのDB方式が採用されて、ATS-SPでのDB方式提唱を引き継いだ。

>>835
> >>830
> 最近は車上に持たせられるものは極力車上に持たせるというのがトレンドだよねぇ
> 地上設備の更新(夜間作業が必要)と車上DBの更新(日中作業で済む)ではどちらが簡便なのかは明らか
というのは、現段階の実態の話で、車両を自由に他線に入線できない基本的理由が、
線路固有のデータを車上に持っている、というデータ搭載場所の交錯があるため。
(続2)
0878名無しでGO! (ワッチョイ 972d-Z9Wx)
垢版 |
2018/07/23(月) 02:34:35.06ID:DB7KmzMz0
(承前2)
車上データと地上データの厳密な仕分けが出来ると、車両は何処へでも行けるし、
地上の設定管理も一本化できる。ATS-Pの優れてる点は、地上データは地上で受け持つことが基本であること。
問題は、各地上データを、どこかのセンターで集約管理できるシステムを構築できるのかどうか。
通信線だの疑似LANだので、簡易に、確実に地上設備をセンターに繋げれば、一元管理に出来る。
車両制御ではE993、E331等で、個々の機器制御の通信線化、LAN制御化が既に開発されて、E233等に採用済。
その結合手段としては、ローカル線用として携帯電話回線まで動員したシステムが検討されている。
中央管理なら、個々の地上機器ごとの設定値のダンプリストカードを作って、貼りに行って確認を求めるとか、
検測車データとの突き合わせで確認するとか、一対一対応を実現でき、
分岐制限誤設定155km/hを12年間も放置してしまうようなポカミスは発生頻度を大幅に下げられたはず。

> 東武のT-DATCや小田急のD-ATS-Pなども車上DBを持たない方式だけど、
> 地下鉄直通車に関しては地下鉄線内のATO運転に必要なので結局車上DBを持つことになっているという
独立の別システム。車上DBは共通には使われないから無関係の指摘。

メモリーが余っても、そこに存在すべきではないデータを安易に載せては、
スパゲティー・システム化して、汎用性を無くし、メンテ困難度を極端に大きくしてしまうではないか。
メモリーが超高価だったATS-P開発1980年代の感覚ではいけない。
(了)
0879名無しでGO! (ワッチョイ 972d-Z9Wx)
垢版 |
2018/07/23(月) 02:38:19.69ID:DB7KmzMz0
>>866,872
ATC減速度設定の降雪モード否定論は何処に行ってしまった??

物理的データからは、衝突防止に必然。事故調報告書に触れてないことが不足。
しかし激しい否定に見舞われ続けたあとで、
「そんなものD-ATCの時代から既実施」「重要ノーハウは明かせない」と、
降雪モード否定論の方が吹き飛ばされた結果になっている。

・・・・・・・・のだが、
どこにもその謬論の撤回がなく>>866,872とは、まともな論議ではない。
十分な冷却期間もあって、論理整理はきっと出来ているだろう。

東横線元住吉駅追突事故調報告には、
一段制動方式ATC(/ATS)への降雪モード減速度採用の勧告を加えることが必要だ。
当然、閉塞区間毎独立のシステムでは、保障できる減速度の減少に伴い、最高速度を落とした運行が求められる。
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況