信号・標識・保安設備について語るスレ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 >>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 >>810
ATCからフィールド機器まで全てをKで揃えてる京王、ATC更新の時期か、今やってる立体化が完成したらIT-ATPになるかもね
で直通する都営線は京王に合わせる気がないし、KにこだわってないからATACSかSPARCSになったら車上に2種類の受信装置が付くわけか >>812
改称するならJ-ATPとかどう？
>>804
国内メーカーなら日本の鉄道会社の事情はよくわかっているはずだから
移動閉塞だけ単体で売ってくれないのかな？ >>814
それならJ-RBTPかな
敢えてcommunicationをradioに
controlをprotectionに変えるという姑息さw 保安装置に「アタックす」はいかんと誰も言わなかったのか >>813
現在も車上装置は2つだよ
ATC違うから 軌道回路使ってないのだからLaneless ATCで良いのでは
LANの頭文字でもあるし >>817
ATSから列車無線まで統一している都営浅草線乗り入れ各社がレアケースでしょ。
それですら北総線（連動駅構内を除く）と芝山は旧ATSが残っているから厳密には2種類混在。 アタックスは総研ベース、スパークスはＧＥベースってまじ? >>814
NSあたりの国内信号メーカーならその辺進んで受けてくれそう。
ただ、移動閉塞は供給元によって微妙な違いこそあれど、ほぼ
連動〜ATP地上〜無線〜ATP車上
が揃ってはじめて実現するんで、実質運行管理以外はほぼ丸々取替や新設になると思われ。 >>822
あ、連動は軌道回路ベースじゃなく車上の位置情報ベースで連動処理する専用のやつね。
メーカー同じならソフトの大規模改修で対応できるようなケースもあるかもしれないけど。 JREはあまり好きじゃないけど、鉄道と電気技術のATACS切り替えの記事は面白かったな。
ってか早く板橋十条高架化シル！ 板橋に電留線作ったから高架化はしばらく無いんじゃない？ ATACSは技術的にはだいぶ確立してきたな
落ち着いたら通信をLTE-Rに変えるのかな？ LTE-R化実現したらまず管理が面倒な車上データベース方式やめようや
地上から数キロ先までの線路データを車上に送りつければいいだけだべ 車上データベースって
例えばそのデータベース内容を書き換える必要のある夜間施工(線形改良とか防護点の変更に絡む奴とか)が列車乱れや天候等々でトケになったとき
どう対応してるの？気になって昼も眠れねぇや >>829
車上装置にはあらかじめ事前作業で新旧双方のバージョンの車上DBが記録してある
新旧どちらのバージョンの車上DBを使用するかは軌道回路や現在位置補正用地上子等を経由して地上側から指定する仕組みとなっていて、
作業中止になるとバージョン切り替えに必要な地上作業も中止となるので新バージョンに移行されない >>830
なるほど。
バージョンを指定する軌道回路もしくは地上子は車両基地の出区線もしくは始発が出る駅のホームトラックとかに仕掛けてあるのかな？
あと気になるのが、そのデータベースの粒度(といっていいのかな)だな。
そのデータベースのバージョンが、線区ごと(もしくは会社まるごと)みたいに粒度が荒ければ保守性は高くミスも起きづらいだろうけど、
先の事情(施工中止のリスク)を考慮すれば、データベースの変更が生じるような工事はそこの単位で１日１施工とかに限定する必要がでてくると思われるが
線区の更に区間を分けるように細かくわけちゃうとそれはそれはミスを誘発しかねない悪寒。
ちなみに切り替え作業をするのはどこの系統なんだろう。一見車両系統な気がするが(車上DBなんだし)、
うちの車両系統なら工務の都合なんだからと絶対拒否りそうだなw >>832
とりあえず、ATS-Dxだと連動駅の構内を出るところに現在位置確定用地上子を設置して
そこで車上DBのバージョンの照合をおこなってる
車上DBの書き換えは、同じくATS-Dxだと車上装置に差さっているCFカードを交換するだけの作業なので
（CFカード交換済み車両＝車上DB更新済み車両となる）、拒否するしないと騒ぐようなものでもないと思う 中間の踏切の制御方式って、大手民鉄は大部分が軌道回路＋AFOなのに対してJR各社は電化区間でも制御子使った点制御式らしいですが、何か理由があるのでしょうか？
制御論理の単純さ、短絡不良対策や続行対策、停電対策、故障からの復旧作業時の安全性等々を考えると、多少のコスト差を考慮しても連続閉電路式が圧倒的に有利な気がしますが。 福知山線丹波大山〜下滝間に蛍光色地黒文字の「曲」標識 >>834
確か、
民鉄は設備の保全とか信用ならないから踏切は連続制御が基本な！
国鉄？うち(国鉄)はうちできちんとやっから点制御でえんだよ！な！(そんなに金ねぇしな！)
という理由にならない理由だったと思う。 １．踏切数が多すぎて金が掛かり過ぎる
２．踏切閉まりっぱの苦情が来ても気にしない。私鉄さんはローカルだから沿線住民からの苦情を放っておくと議員が出てきたり面倒
こんなとこかな >>842
復活させると何が良いの？
何か解決するの？ 踏切のパターン式防御動作の略図をしまします。
踏切発光警告灯を見たら即座にブレーキを扱わないと、立ち往生トラックに衝撃することが判ります。
600m〜500m先の状況を目視判断できる状況にはありません。
制動中に踏切支障が解消されたらブレーキを緩めて良いってことです。
http://jtqsw192.nobody.jp/DOC/diary/dry0440.htm#C3
http://jtqsw192.nobody.jp/DOC/diary/dry0440.htm#2
物事の判断を「朝日新聞の『受け売り』」方式で、他人に委ねて、ただ多数論を借りてきて主張するのか、
自分で納得の出来る解析検討を重ねて、納得のいく結論を求めるのか、そして、
当面少数派なのは判っても、妥当な主張をして多数を目指すのかって問題で、
論議が万一転けるとドンキホーテ化するリスクはあるんですが、
スレの話題の流れの切れ目でもあり
言うべきことは言っておきませんと･･････････。
ミクロじゃ情報ゲットが連続か、特定点かってのは安定動作の保証に重要なんだけど、
マクロでみれば、どんな条件で動作させれば、交通量を維持して、安全を確保できるかが重要でしょうが。
現状の設備を前提に実施を図れば、点制御が簡便なのか、連続制御が可能なのか、
それぞれの事業者で判断が別れるでしょう。 >>753
このスレの大前提として、鉄道を運営する上で必要な「信号・標識・保安設備について語るスレ」
だから、鉄道無用論は全くのスレ違い。まずは鉄道の無用論・有用論スレを建てられるべし。ナンセンス！
＆道路交通の弱点は、荒天、降雪、渋滞に大きく影響されることと、表定速度が遅いこと。
それが有るんで国土を人が住めるよう維持するインフラとして道路も国営鉄道も港湾も空港も建設されるんで、
西欧を含めて単純な独立採算の話じゃ無い。何処でも公的資金で路線が維持される所以だ。
日本でだけ「鉄道の独立採算」が強調されるのは、日本の労働運動破壊の謀略政策としてのデマ宣伝の一環で、
日本でだけ大都市周辺の私鉄が、都市開発を含んで独立採算経営に成功している特殊状況を梃子に、
労働者派遣法制定とセットで国鉄分割民営化が強行されて、90%が正社員だった社会を、
首切り自由の非正規・派遣労働中心に切り替えて、青年層の過半数を非正規派遣にして、
家庭を維持できない結婚できない低賃金に貶めて、急激な人口減少問題＝高齢化問題を起こしている。
守銭奴経団連・財界・多国籍企業・その傀儡政府は、国民生活が食い荒らされて立ち行かなくなる
政策を35年以上継続して、亡国へ導いているが、その被害を直接・間接に受けている
肝心の国民の多数派がまだそれに気付いてないのは大変残念。 >>845
＞労働運動破壊
∠○の方ですか？
令和の世になっても未だに革命ゴッコとかやってる人達ってやっぱり頭おかしいんですね。 >>843
かつての竹ノ塚みたいに通行人の集団圧力により温情で無理やり半開させて
その無茶横断者を轢殺の刑に処してあげられる自由度が増しますな。 あれ、これ随分前に発表されてたような？
気のせいか >>848
地上時代の京成船橋はプロ旅客と警手の絶妙な連係プレイで見事なものだった。 やはり特発見通し600mで時速120km運転は無謀だとしか。
旧国鉄なとこでは基本800m、なはずだ。
機械的な担保が無い限りは無理、ということが今回の事故でわかったんでは？ 自動ブレーキ無しの場合は300m制限にしたほうが良いな >>854
自己レス、800mは線区最高120km以上なとこね。
100kmに満たないローカル線はもっと短かったりする。
>>531さんによると東さんは一律800mらしいがな >>847
？不当な非正規低賃金労働に抵抗できない労働組合運動にしたというのは、明確な労組破壊の結果。
英米仏独伊など先進資本主義国では到底考えられない暴挙で、国の経済が廻らないほど疲弊してしまった。
そういう事実把握が「∠○」「革命運動」に見えるってのは、いくら何でも不勉強に過ぎる。
欧米だったらとっくにゼネストになって、政府がいくつも潰れてるよ。
資本主義経済体制であっても経済民主主義が全く貫徹されていない、一種独裁国家になっている。
肝心の、踏切の動作図は理解出来たと思うが、
少なくとも、警報ランプが見えたら、判断する前にブレーキ操作をしないと間に合わず衝突することは一目瞭然。
踏切に接近して危険回避できたことが判ったら、ブレーキ緩解、加速するって運転方式が必要。
運転士に、ブレーキを掛けるかどうかをまず判断させる京急方式じゃ絶対にダメ！まずブレーキだ。 踏切動作図‥？
＿__ ━┓
／ ―＼ ┏┛
／ノ (●)＼ ・
. ｜ (●) ⌒）＼
. ｜ （__ノ￣ |
＼ /
＼ _ノ
/´ ｀＼
| |
| | 踏切動作図というものは知らないが
当該踏切の制御図表は見てみたいものだね。
あと当該踏切のジャーナル、当該車両の動作ログ、神奈川新町駅の連動装置ジャーナル、ぐらいか。
勿論事故調と警察は全部召し上げるんだろうが。 物理的な限界図を描いて、そこに飛び込まないで済む様々の方式を開発するもの>>858,859
実構成に当たり、ATS-Sxのような点照査にすると、大きな余裕を採らないと危険域に入ってしまう。
たとえば地点で60km/h照査があって、そこに最高100km/hで進入する場合は、照査点の後ろ側に
100km/hで止まれるだけの制動距離を保証して物理限界に達するように設置する。
一種、安全のために必要とされる「無駄」であり、
P方式（パターン照査方式）はそれが必要ないからD-ATC、DS-ATC、各種無線閉塞に急速に広く普及したのだ。
福知山線で事故後にP/S併用の拠点Pにしたが、過速度速照がSwばかり先に働いて、
Ｐ速照は全く動作しなかった理由は、このATS-Sw点照査のための減速距離を採って設置するから、
目標点・停止点めがけたパターン照査で良いATS-Pより先にSwが当たってしまうというお粗末。
ちゃんと双方の動作図を書いていたら、点照査Sw特有の減速距離に気付いて、
最初からその手前にP速照パターン設定しただろう。
いまはそういう調整をしてP搭載車はP速照が先に働くよう設定し直した。
基本動作図を馬鹿にしてはいけないのだ。 ■ このスレッドは過去ログ倉庫に格納されています
