信号・標識・保安設備について語るスレ29
■ このスレッドは過去ログ倉庫に格納されています
!extend:default:vvvvv:1000:512
信通屋さん、信号屋さん、信号・ATSマニアの方など、引き続きカキコおねがいします。
なるべくマターリ進行で行きましょう。
前スレ
信号・標識・保安設備について語るスレ28
https://mevius.5ch.net/test/read.cgi/train/1533578820/
次スレを立てる時は一行目に
!extend:default:vvvvv:1000:512
を入れて名前欄は「旭=1008」を入れること
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>711
東武って地上子で踏切防護してるの？
確かにTSPとM式は速照地上子まるけだよな >>709
一昔前のSS無線
通信規格についてはアップデートの余地がありそうやね >>706
もちろん車上側も金かかる（線区を走行する車輛全てに車上装置、無線装置を積むための改修費、などなど）と思うが、
それ以上に地上側かなあ。
全線が無線のカバーエリアに入るように基地局建てなきゃいかんのは当然として、軌道回路なくなるから連動装置も全部ATACS専用のに取り替え、踏切制御装置も同様。
やっぱり既存のATSやATCを閉塞割り変えずに改良するのとはかかる金が桁一つ変わってくるのは当然かと。
まあ、軌道回路レス諦めるとか、踏切だけ現行のままにするとかで安くはできるけど、それだとATACSいれる意味半減だしね。 >>696
貨物は運転士が広域で乗務して線路を覚えきれないと困るので
機関車にデータベースを積んで表示していなかった？ >>715
なるほど。勉強になります。
軌道回路前提のシステムからの移行に費用がかかるわけか。
ということは、新規路線や既存路線の延伸区間ならATCよりATACSの方が安く済んだりするのかな？
（たとえばブルーラインをあざみ野から新百合ヶ丘まで延伸したとして、その区間だけCBTC導入するとか） そもそもATACSってコスト削減も売りの一つなんだが 過去スレでも議論されたことがあったはずだが、深夜帯作業で地上子交換したり現地でデータ書き換え作業したりするよりも
車上DBの作成や更新に金がかかるということはないと思うのだがなぁ
そもそもATS-Pでは地上側に持たせている情報をD-ATCやATACSでは車上側に持たせたというだけなので
DBに関してのみ考えるなら作成や管理の労力はそれほど変わらないわけで
>>686 >>689
JR東日本のD-ATCでは閉塞境界標は地上信号機の閉塞信号機にする箇所には設置されてない
>>702 >>715
導入後は地上設備の保守費用が年間ン億減るので充分回収できるという触れ込みだったはず 車上DBのネックは直接的な設備費用よりは全車への更新データデプロイの手間よね、相互直通の場合とか
将来的には随時無線で配布かしら 一人、ATCよりATACSのほうが桁一つ高いなんてデタラメ吹き込んでいるやつがいるな。
キか？ どうせ後で出来たシステムだから省コスト設計なんて…とでも思ったんだろ
にわかめ 結局、ATACSは高いの安いの、どっちなの？
安くて、データ更新も無線で楽々というなら
なぜ大手民鉄で採用されない？
東横線なんかCBTC化の絶好のチャンスだっただろうに。 >>725
高密度運転かつ他線とつながっている路線では海外でもあまり例がないんでは？
中国の高速鉄道も日本の新幹線ほどの頻繁運転はしていないだろうし。
東京メトロは丸ノ内線でCBTCを導入する一方で銀座線はATCで更新するというのは保健を掛けているのかな？
JR東は仙石線と埼京線でATACSが問題なく使えているので今後は一気に広げるんだよね。 >>722
踏切のパターン防護を既設の保安装置の改良で済ます場合とATACS導入する場合の比較の話をしたんだけどね。
>>715の書き方が悪かったのならすまんが。。
>>717
新線ならともかく既存路線の延伸でCBTCはあまり現実的では・・・
運行管理システムから運転保安装置まで全部パッケージになってるので。車上に2種類の保安装置積む羽目になるばかりか運行管理まで分断されてしまう。 JR東が一通りの路線に入れて不具合出し切るまでは様子見じゃないかな
編成長均一で分割併合のない路線にしかまだ入ってないでしょ >>727
そういや銀座線の車両を中野工場に回送する時はどうするんだろう >>725
ATACSと同等の機能を備えたシステムが世界の何処にも存在しないので定量的に高い安いの比較をしようがないな。
・・・と言ったら終わってしまうので。超大雑把だけど、
埼京線は大宮までの25kmで100億円（？？）くらい→kmあたり4億くらいか
小田急D-ATS-Pは120kmで280億、たぶん踏切防護も込み→kmあたり2.3億
両方とも車上改修工事費込み、ATACSは連動機能も込み
小田急は投資額公表してるけど埼京の方は正確な数字わからん
高密度運転（というより、遅延発生時の遅延回復ポテンシャル）、地べたの設備がなくなるが故の省メンテ化と設備故障による輸送障害の発生頻度の減、踏切完全パターン防護と警報時間の適正化、といったプライスレスなメリットをどれだけ評価するかだな。
感覚的な話をすれば「お得」だとは思う。 今回みたいな停車と通過が混在する駅横踏切の制御はぐっとやりやすくなるよな >>730
> 地べたの設備がなくなるが故の省メンテ化
これはプライスレスではなく普通にコスト削減になるわな
（深夜帯作業が減少することによる人件費削減とか） 逆に転換不良は軌道回路で検知できなくなるので別の検知装置が要るんだろうな >>729
銀座線にもCBTC入るまで赤坂見附〜中野車両基地はCS-ATCと軌道回路を残置？
それか夜間に保守用車扱いで回送か・・・
>>725
ATACSはCBTCではないし、無線で車上DB更新なんて現時点で実用化されてない
まあLTE-Rとか使えば難しくはないと思うけど。 地上設備のデータベースは地上側に集中して置いて、
車上関連のデータベースは各車両に置き、
進入許容区間と、その地点の必要データを地上から車上に送って、
あとは車上演算に任せるって方向に集約されていて、
当初の全地上データを車上のデータベースに持たせる方式は今後はやめる方向。
通信技術と設備の発達で、地上データを集約管理出来るようになったから。
超ローカルの方式としてはG5回線を割り当てることがほぼ決まっている。 >>733
軌道回路なくなって困るのはレール破断検知。
ポイントの転換不良は転てつ器自身で検知できる。 >>735
それ実用化したらまじで日本版ETCSで全国統一も見えてくるね。 >>734
ATACSとCBTCって何が違うの？
ATACSはCBTCの一部（iPhoneとスマホみたいな関係）で
国際入札などに配慮してCBTCという言葉を使っているという理解なんだけど、間違ってる？
>>735
小田急や東武東上に近いイメージだと思うけど
地上から送信するデータの範囲はどうやって決めるの？
軌道回路なら3閉塞先までとかできるだろうけど、移動閉塞だと、そういう区切りがないよね？ 主要駅で路線データを車輌にダウンロードって近未来的だなー >>729 >>734
銀座線の1000系にもCBTCの車上装置搭載かと
非CBTC線区との接続は不可能ではないし
（海外だとイギリスのロンドンに来年開業するエリザベス線（CBTC採用）で非CBTCの路線との直通運転を実施予定）
>>735
停車パターン発生に必要な情報のうち、編成長や加減速度など各列車ごとの固有の情報だけ車上に残して
それ以外の情報は運転指令所等に設置のサーバーに置く方向になるという理解でいいのかな？
5G通信の技術が枯れるのが前提だろうから実用化はまだしばらく先だろうけど >>738
CBTCは上位の運行管理から地べたの保安装置までまるごと統合したシステムで、要件がIEEE1474で規格化されている（オプションではあるけどホームドア制御とか旅客案内装置まで規定がある）。
言い方を変えればこの規格満たしていないものはCBTCの範疇に入らない。
たとえばCBTCの構成要素になっていてATACSに含まれないのは運行管理システムとかATO車上装置とか。
もちろんどっちが優れているとかではなくて、単に定義に当てはまらないというだけ。 >>694
結局はルールなのよね
北陸トンネルを含めて >>743
リードソロモン符号とかハッシュコードみたいな強力な誤り検出や訂正手段があって、危険側のエラーが発生する確率は限りなくゼロに近づけられるから、今どきそういうのはほとんど問題にならない >>741
CBTCが導入されているのが地下鉄やAPMや高速新線など「閉じた」路線が殆どなのはそういうことなのね。
日本の実情に合わせるならATS/ATCみたいな日本独自の無線制御に対する総称が要りそう。 >>741
＞CBTCの構成要素になっていてATACSに含まれないのは運行管理システムとかATO車上装置とか
ということは、日比谷線はATO積んでワンマン運転するのが確定しているってこと？ >>713
ATS時代の東武東上線だと、障検のある踏切の400m位手前に踏切用の地上子があったな。
端子箱には「UXP」か「DXP」の文字が。 ATOに代表される鉄道の自動運転なんて所詮、エレベーターと同じですよね。
障害物が一切無い前提
山手線に導入するべく開発してるのは違うんだろうけど。JRQのはどうなんだろう？ >>748
山手線も同じだよ
踏切一箇所しかないからそこにいろいろ対策して、ホームドアつけ終わったら障害物が入ってこないという前提。
だけどそうはうまく行くかな
運転士がぼーっとしてて気付かずに轢き殺してそのまま放置とかやりそう
大阪環状線も踏み切りなくなったからホームドアつけたら条件的には変わらない >>746
当然そうなると思う。
推測になるがワンマン化による人件費削減分で投資回収が見込めるからこそ、メトロがATO化やホームドア設置に積極的なのだろう。 >>749
そうなの？ 車みたいに光学カメラやレーザー検知つけて
能動的にやらないのかな？ 多くのローカル私鉄が独立採算経営としては存亡の危機にあって、
軌道回路方式だとリレー一基10万円とか非常に高価な列車制御法設備の
コストダウンが喫緊の課題となっていて、無線閉塞が広がってきているが、
現在、「本質制御」と名付けた安全性を落とさない簡略化が提唱されている。>>737
従前は、駅毎とかCTCごとの複数箇所からの操作で矛盾設定が起こらないように
各種排他制御として連動と鎖錠が両側から厳重に行われて複雑化、高価化していた訳であるが、
独立路線にコマンドを発する箇所を1箇所に集約することで、
各駅間にバラまかれていた排他制御が無用になり、制御装置内部論理だけの措置にまとまって、
あとは各地上装置の動作ステータスを返して貰って照合するだけという方式が現在実用化しつつある。
中央制御装置内の論理だけで済めば、10万円リレー群に比べたらタダみたいなもので、
超ローカル経営の継続に大いに資するのではないか。
ATACSはまだまだ高価に過ぎる暫定方式ではある様だ。
踏切停止パターンを遮断完了＆支障検出無しで撤回する方式は、
この「本質制御」開発者たちの成果で、実用的で安価に踏切の安全が実現できる。
鉄道各社毎のATPの相違で、どういうハードでその機能を実現させるかという問題。
私鉄ATS機能通達1967/01のような、行政指導の強い勧告というのは充分あり得る。 もう全部BRTにしちゃえばいいじゃん。痴呆なんて。
ちゃんとバス自体に近接安全装置＆運転手状態確認装置つけてさ。 >>750
有楽町線は全線ホームドア設置完了から何年も経つけど、小竹向原以南はいまだにツーマン運転。
てっきり青山一丁目の事故で国交省から指導が入ってワンマン化は中止になったと思ってたけど
まだ諦めていないのかな？ >>753
バスドライバーの高齢化の方がヤバい。
支援装置付けて専用道路に限り普通免許でも可にするなら別だが >>752
中村教授の本質制御なんかに感化されてるようじゃ、底が知れるな。
定義付けしているだけで、実務に何にも役立っていない。
実際、日本信号のCBTCもJREのATACSにも関与していない。
総研時代のcombatぐらいだね、開発したのは。 >>748
JR九州のは今のところは地下鉄線内で使用している既存のATOを筑肥線内でも使用するようにするというだけの模様
>>749
山手線に残っていた踏切は最後の1箇所も既に何年か前に閉鎖済み
山手線のATOは運転士不在での運転（車掌のみ乗務のワンマン運転）が最終目標
今のところは障害物対策は各駅のホームに>>751みたいなのを整備してATCで停める方向のようだが、
実用化段階では>>751が書いているように車上からも監視するようになるのではないかと予想してみる 都営地下鉄大江戸線の列車を無線で制御…日本信号がシステムを一括受注
https://response.jp/article/2019/09/13/326477.html
日本信号は9月12日、東京都交通局から都営地下鉄大江戸線（都庁前〜光が丘）向けの
無線式列車制御システム（CBTC）を一括受注したことを明らかにした。同線の信号保安システム更新に合わせて
導入される。
CBTCとは「Communications Based Train Control」の略で、地上設備と列車との間で無線通信を行ない、
列車の制御や防護を行なうシステム。 >>755
間違えた、九段下だった...
申し訳ない
>>758
山手線の駒込〜田端の第二中里踏切はまだ残ってるよ
廃止に向け協議中
何年か前に閉鎖されたのって池袋の踏切のこと？
西武線の跨線橋架け替えに合わせて廃止したやつ
もう10年以上前のことだと思うけど 自動運転って踏切がなく全線立体交差である京葉の方がやりやすいと思うんだけど、山手線でやるってことはインパクトが大きいから？ >>761
言うまでもなく山手線の方がインパクト(投資効果)が大きい >>759
SPARCSか
メトロの無人運転ならCBTCの王道だな 運行管理から運転保安装置まで全部ひっくるめて、メーカー1社に丸投げできることそれ自体がCBTCの最大の強みかな？
どこの事業者とは言わないが車上はこっちのメーカー、無線装置はあっちのメーカー、みたいに装置とかサブシステム単位でバラバラに発注するとインターフェース部分の擦り合わせに有形無形のバカにならないコスト発生するんだよね。
結合テストや機能テストも事業者主体でやる羽目になるけど、テスト項目がザルだと致命的なバグが最後の方まで気づかれなかったりするし。 それ既存の機器だとできないこと？
むしろ一社にロックインされるのはリスクだと思うけど 去年のソフトバンクの通信障害でも問題になったけど
インフラ系はマルチベンダーが基本じゃないの？ >>766
1社集中は逆にコスト高。ぼられる。
ATOSの日立で懲りた。 >>769
＞マルチベンダーが基本
それが現実的に可能なのは、ETCS/ERTMSみたいに、システムを構成する各コンポーネントの仕様が具体的に決められているような場合だけな。
（というかETCSは最初からそれを前提に規格体系が作られている）
CBTCの規格は各コンポーネントへの要求事項が抽象的定性的にしか定められてないので、それを満たす範囲内でメーカーが好きに仕様を決められる、当然装置間のインターフェースなんて非公開。
なので事業者が仕切ってマルチベンダでシステムを組み上げるのはよほどの技術管理能力がないとほぼ不可能。 >>771
ATOSみたいなそれこそマルチベンダ化不可能なシステムの典型例挙げても仕方ない タレスCBTCがご破算になったのもATOSと両立出来なかったからだしよな。
まぁあれは「非関税障壁」じゃないよというポーズだった気もするけど。 >>773
いや、駅装置、ネットワーク、中央装置と実際分かれているし、日立も担当工場が異なる。
あれ？日立の関係者？ >>775
一社集中と言っておきながら装置ごとに別れてるとか、支離滅裂なんだけどどっちなの？
御社とHいずれの関係者でもないので分からんが、ある程度マルチベンダになってるならATOSのコスト高の要因は別のところにあるってことだよね？ あとシングルベンダ＝コスト高は一般論としてはその通りだが、CBTC自体は世界中でかなりの数のメーカーが作ってる上に線区単位で完結するシステムだから、メーカー間の競争原理をある程度働かせる余地があるだろ。
メトロみたいに閉じた線区を多数抱えてて、今後も線区単位のシステム更新案件がいくつも控えてて、それ自体が対メーカーの交渉カードになるような所は特に。
その点ATOSみたいな唯一無二で代替効かない超大規模特殊システムとは事情が全く異なると思う。 CBTCって、既存のATC/ATSのように
運行管理システムと保安装置を分離できないの？
たとえば、既存のATO線区の保安装置だけ
CS-ATCから移動閉塞に更新したとして
ATOもPTCもメーカーバラバラで独立していた場合
CBTCと名乗ることはできないの？
てっきり大江戸線も丸ノ内線も保安装置だけの更新だと思ってたけど、PTCもATOも丸ごと更新するの？ >>779
束がまさにそれやろうとして常磐緩行で失敗したばかりじゃんかw
仮にやろうとしても、すでにパッケージとして開発済みのシステムを部分部分で改修することになるからコストと時間が余計に要求されることになる
まあ>>774の言うように最初から分かった上でわざとのアリバイ作りかも知れないけど。 >>778
東京の地下鉄で厳密に「閉じたシステム」は大江戸線だけだけど。
今回CBTC化される丸ノ内線でさえ銀座線車両の車両基地への回送がある。 >>780
ということは、ATO、PTC、保安装置がそれぞれ独立していてもCBTCの要件を満たすわけだね？
あとは、ATACSのような保安装置単体の製品があれば、導入しやすくなるね。
デジタルATCの路線なら信号伝送を軌道回路から無線に置き換えるだけだし。
（言うほど簡単な話じゃないだろうけど） 切り替え自体は有線LANを無線LANに変えるようなものだし簡単だろうけどな >>777
へ？
日立の1社集中で担当工場が勝田、水戸、大甕と分かれいる。
どこが支離滅裂？
理解出来ていないだけでしょ。 >>784
じゃ、結局全部日立依存なわけで、現実は>>773のとおりマルチベンダ化できてないんでしょ？
何が言いたいのか分からない。
もしかしてマルチベンダの意味理解してない？ 小特は通行可能らしいがエンストしたらおしまいだな。
非常停止ボタン無いし
https://i.imgur.com/qLSoKLD.jpg >>785
やっぱり分かってないみたいだね。
工場も異なり、1社集中させなくても出来るけどやっていない一例として挙げただけ。
知らないのに、刺々しく食ってかかってくるやつに説明するの面倒だから、これ以上レスしなくていいよ。 >>787のアホは工場違えば同じ会社だろうと価格競争や仕事の奪い合いしてくれるとでも思ってるのかw >>779
なんか勘違いしてる人がいるみたいだけど、運管とＣＢＴＣは別で全く問題ないですね。
さらに言えば連動も別でＯＫ（原則既設そのままでも） >>788
そんな話誰もしてねーよ。
日本語読めねーなら消えろよ >>791
消えろと言われたのでもうお前にレスするのこれで最後にするけど、勘違いバカがどちらであるか客観的に示すために以下、まとめとくわ。
ID:zWMlrUQ2d の主張
・ATOSは日立一社集中だが、装置ごとに担当工場が違うから「マルチベンダー」である。
・ATOSでは日立一社依存であるがゆえにコスト高であり、これまで（束が）ぼられてきた。
・ところが「一社集中やめようと思えばできる」らしい。「けどやっていない」。
→おたくの会社幹部はHから賄賂でも貰っているのか？w
正直、誰が読んでも矛盾だらけ、俺の貧弱な語彙では「支離滅裂」以外の言葉で形容しようがない。
以上 >>790
自身の無知を晒して恥をかくのはお前の勝手だが、ミスリードやめろな。
CBTCの定義から勉強し直しな。 >>779
上で知ったかぶりが短絡的にデタラメな回答つけてるので訂正させてもらう。
CBTCは各サブシステムが備えるべき「機能」を定義しているだけなので、
質問のように、運行管理システムと保安装置をハードウェアとして別々に造って、それらを組み合わせても全く問題ない。
ただし、個々の機器や装置の「仕様」を規定しているわけではないので、マルチベンダでシステム全体を組み上げたり、
既存の設備を一部流用し残りの部分を取り替えるようなツギハギ方式で、CBTCの要件を満たすものを作り上げるのは、事業者の高度なPMワークが要求され、かなりハードルが高い。
なので、どうしてもシステム全体を一社丸投げになってしまう事例が多い、と言うだけの話。 どうでもいいけどごく一部の関係者しか知り得なさそうな情報をよく平気で書き込めるな、見ていて危なっかしい
意外と狭い業界だから下手すると身元特定されるぞ >>771
マルチベンダ化したらしたらで、みずほ銀行みたいになる予感。 >>769
むしろ逆。
自社の事業の基幹システムをマルチベンダーで開発とか、まともな経営判断できる会社ならまずやらないから。
大規模な障害起きれば会社の経営傾くようなシステムだからこそ、開発やメンテの責任の所在を明確にして、不具合発生時の原因究明とか対策に迅速さが要求される。
これがベンダー複数社だったらどうなるかって言うまでもないだろ。
不具合出てもすぐに責任のなすり合いになって、インターフェース部分に原因があっても、うちは仕様通り作ってます、○○さんの側を直すのが筋です、とか、
要求仕様に書いてないのでうちのミスじゃないです、追加仕様するなら対応はしますけどお金下さいね、とかとか。
>>798が例に挙げてるみずほのシステムが何度も障害起こして、新システムも何度も開発遅延おこしてる原因なんか、まさに典型的な失敗例。
みずほは3行の対等合併だったが故に、旧3行出身者のシステム屋同士がそれぞれのメインベンダーだった3社（F、H、IBM）まで巻き込んで社内抗争、結局政治的判断で新システムの開発を異例の3社のマルチベンダ体制にした結果大炎上。
マルチベンダ化で多少の開発費用浮かしても代償としてとんでもないリスクを負うわけで、一社丸投げが多少高くつこうが、リスク減らすための保険料だと割りきるべし。少なくとも基幹システムに関しては。 システム部が技術力牽引力あってしっかりしてるところはマルチベンダでもちゃんとやってる
丸投げだから駄目なの >>795
＞高度なPMワークが要求され、かなりハードルが高い。
今までPTCもATS/ATCもバラバラで独立したシステムだったのに
移動閉塞化した途端にハードルが上がるのはなぜ？
CBTCの要件に、移動閉塞と運行管理システムの連携とかあるの？ >>802
KのIT-ATPが固定閉塞も選べる仕様なのはその辺の考慮みたいね >>802
技術的というよりは契約上のハードルかな？
CBTC供給しているメーカーはどこも運管から保安装置までパッケージでの提供を前提に開発している。
そこを例えば、どこかの事業者が「おたくの供給してるシステムをベースにCBTCを入れたい。
でも車上装置だけ他所に造らせたいから仕様とか技術情報開示してもいいよね」などと要求したとして、そんな虫の良すぎる話に素直にはい分かりましたと言うメーカーはまずないと思われる。
1から事業者側主体で開発したシステムでない限りそういう采配は難しいでしょ。でもJREのATACS以外にそんな例あるのかな？ K3のカタログにも書いてあるね。
ttps://www.kyosan.co.jp/product/pdf/P28-29.pdf
IT-ATP（CBTC)
・IT-ATP地上装置は、既設の電子連動装置や運行管理装置と接続可能 まだいたのw
ツギハギが不可能だなんて誰も書いてないと思うけど何に噛みついてるんだいキミは
それはおいといて、軌道回路相当の条件に読み替えて既設の連動に渡すだけじゃ、移動閉塞のメリットは放棄すると割りきる前提かな？ 運用者のワガママって事で良いじゃん
マルチベンダーもシングルベンダーも結局は選ぶのは会社さんの意思な訳だし 日本の場合、JRは独自の運行管理システムを構築しているし
大手民鉄も重要な分岐点の平面交差など自社線の弱点を盛り込んだ運行管理を既に行なっている。
さらに複雑な相互乗り入れを行なっている路線も多い。
保安装置と運行管理とセットじゃなきゃダメという欧州製CBTCは入り込む余地がないね。 >>807
団子運転が日常化している路線でなければ移動閉塞の必要性は小さいかと。
地上設備メンテの大幅な省力化だけでもメリットは大きいんでない？ 勝手なイメージだけど欧州メーカーって「すげーシステム売ってやるんだからオペレーションの方をそれに合わせろ」みたいな傲慢さ融通の効かなさがありそう
ユーザーからしてみりゃCBTCというステータスが欲しい訳じゃなく、あくまで移動閉そくとか地上設備削減とかの果実さえ享受できさえすれば結果的に「擬き」になろうが別にいいわけで。
だったら自社の要求に合わせて細かいカスタマイズに応じてくれる協力的な日本メーカー集めた方がいいわな。 ATACSって規格として売り込むにはちと名前がなー
Advancedじゃ何をやらせてるか分かんないよなw ■ このスレッドは過去ログ倉庫に格納されています
