[過去ログ] JR東日本 山手線の新型電車 7編成目©2ch.net (1002レス)
上下前次1-新
抽出解除 レス栞 あぼーん
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
108(1): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/02(土)00:00 ID:qOChkdUsM(1) AAS
>>100
素人でもわかるウソつくなあ。
> TCP/UDPはコネクション確立不要だよ。
外部リンク:qiita.com
TCP:コネクション型
UDP:コネクションレス型
省7
110(1): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/02(土)04:57 ID:SqxznI59M(1) AAS
>>109
CAMプロトコルは、CSMA/CA方式を採用して、時分割に近い制御をしとるように見える。
ちゃうかったら指摘して。
外部リンク[html]:monoist.atmarkit.co.jp
> 時分割は、リアルタイム性を犠牲にして、
> 通信速度の安定性を高める方式。
イメージ論で語るなよ。
省2
135(1): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/03(日)21:52 ID:2TNftveRM(1/3) AAS
久しぶりに、日本のそこらじゅうにあるエアセクション問題について書いた文章を。
京浜東北線事故で、”エアセクション”のところで電車が停車してしまったのが問題、エアセクションで停車しないような装置もあった、とされていますが、実をいえば”エアセクション”で2つのき電線が短絡しないように、き電線を若干分離していれば済む話です。
交流なんて、”異相区分セクション”としてき電線は完全に分離しているのですから、直流だって同じ方式がやれないはずがありません。
仮にその部分で電車が止まってしまったとしても、通勤路線ではパンタは複数個あるため、生きているパンタで力行して、セクションを通過すればいいだけです。
それでアークが発生するから問題、というならば、たとえばそこにトランスポンダを使用して、本当にその部分だけモータが停止するように作るべきです。
新しいシステムってそうやって考えつくべきものです。
省2
136(1): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/03(日)21:53 ID:2TNftveRM(2/3) AAS
>>135 つづき
そう思って調べたら、こんな装置があるそうです。
−−−−−−−−−−−
外部リンク:ja.wikipedia.org
またN700系ではデジタルATCと連動させて、切替セクションに差し掛かる前に自動的にノッチオフ・ブレーキ解除、通過後にノッチオン・ブレーキ作動する機構を搭載する。
−−−−−−−−−−−
交直流や特高圧引きとおし、饋電区分切替セクションなどの細かい違いはありますが、同じデジタルATCなのだから、山手線や京浜東北線でもほぼ同じ装置を搭載すれば、運転士がエアセクションを認識する必要はないはずです。
省1
139(2): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/03(日)22:19 ID:2TNftveRM(3/3) AAS
>>126
CANに関する論文
外部リンク[pdf]:ir.nul.nagoya-u.ac.jp
UDPに関する資料
外部リンク:pc.nikkeibp.co.jp
省5
217(1): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/04(月)04:48 ID:0PDj/Co+M(1/3) AAS
>>204
コレを読むに、”RTT”には、私が問題と言うとる、ノイズは考慮されてないっぽいなあ。
−−−−−−−−−−−−
外部リンク:thinkit.co.jp
RTTが100msでウィンドウサイズが64キロバイトの場合には、この式に当てはめると、ネットワーク通信帯域がどんなにあったとしも、TCP通信では5Mbps以上のスループットは出ないことになります。
TCP通信のスループットを劣化させるもう1つの原因がパケットロスです。通信が集中してしまう輻輳が発生し中継器でパケットが溢れてしまう、通信ノイズの影響でパケット内の情報が壊れてしまう場合などにパケットロスが発生します。
パケットロスが発生すると送信側にはACKが帰ってきませんので、TCP通信では一定時間後に同じパケットを再送信します。ACKが帰ってくるまで何度でも同じパケットを送らなければいけませんので、TCP通信のスループットの低下につながります。
−−−−−−−−−−−−
省1
218(3): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/04(月)04:52 ID:0PDj/Co+M(2/3) AAS
そして、私が見た限り、下記の通りなのが真実や。
山手線E235系INTEROSは、ブレーキ時にモータが発するノイズが原因で、イーサネットのIP通信により伝送遅延が発生するのですが、それを回避するために、敢えて空気ブレーキの比率を上げ、回生性能を落としています。
鉄道会社が自ら主張している”省エネ”とは逆行しているし、最終的には使用電力増によるコストアップに繋がるのですから、山手線E235系INTEROSは、いくらJR東日本が強行採用しようが、他線に持っていけるシロモノではありません。
まあ、強行採用したかったら採用したら?というのが私の考え。
219: おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/04(月)04:55 ID:0PDj/Co+M(3/3) AAS
ついでに、データ収集技術も怪しいもんや。
私がかつてJR東日本の研究発表会に、日進の研究所に行って、さまざまな部品に測定装置をつけ、データを収集できるようになりました!と発表している人に対して、
「じゃあ、全ての部品に測定装置をつけたら、便利ですよね」
と聞いたら、その研究者は、
「あまり装置を取り付けると、測定装置自身が故障することがあるので、装置が出すデータが正しいか正しくないかわからなくなり、狼少年になってしまい現実的ではない」
省4
245(4): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/04(月)23:10 ID:uIUwLnNHM(1) AAS
>>241
じゃあTCP通信でリアルタイム制御した事例があれば教えてよ。
そんな論文あるか?
日立製作所の、リアルタイム制御の一歩手前の”制御系LAN”でさえ、UDP通信で速度確保しとるんやけど。
258(4): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/05(火)04:51 ID:vngXacuzM(1) AAS
>>257
ハナシをめっちゃズラしとるよなあ。
運行管理システムはUDPで通信しとるよ。
けど、その下で信号システムとか、ガチのリアルタイム制御はUDPなんか使ってない。
運行管理システムが”制御系LAN”なんて言葉を使うから、一般人は騙されてまう。
本当のリアルタイム制御は、同期通信やねん。
285(3): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/06(水)05:08 ID:8YS5trMoM(1) AAS
>>267
> >>258
>
> すみません、これはどういう意味ですか???
>
> >本当のリアルタイム制御は、同期通信やねん。
TIMSでもATACSでも、受け手が送り手とタイミングを同期して、受け手がどのタイミングで自分宛の情報が来ているかチェックしとるやろ?
と言うとるんやけど。
291(5): おーにっちゃん ◆yoCsKijoxhpN (ワイマゲー MMaf-E08h) 2016/04/06(水)22:43 ID:fqEuJ37nM(1) AAS
>>289
だからなんべんも書いているように、それ”リアルタイム制御”ちゃうやろ。
ならばなんでTIMSでは、トークンバス方式のARCNETを採用してん?
外部リンク:ja.wikipedia.org
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.036s