コメント: あのときは馬鹿にしてすみませんでした (スコア 4, 参考になる) 30
10数年前、何かのオーディオ誌に「iPodに曲を入れるときは同じファイルを上書き保存してなじませる」
と書いてあって思わず鼻で笑ってしまったんですが、これを予見してたんですね。流石です。
アナウンス:スラドは 2024 年 1 月 31 日で終了します。データ保存はお早めに。
10数年前、何かのオーディオ誌に「iPodに曲を入れるときは同じファイルを上書き保存してなじませる」
と書いてあって思わず鼻で笑ってしまったんですが、これを予見してたんですね。流石です。
まだ詳細は判明していないので外野の推測ですが、軌道回路短絡不良があって、
復位に失敗したのではないか、という話です。
貨物列車も含めてすべての列車位置が把握されているのは正しいです。
一部の保線機械は別ですが、今回の先行は列車として扱われるものなので、
運行管理システムで管理されています。
この位置検知は、軌道回路といって、両側のレールの間が車輪と車軸で短絡されることを
検知する仕組みでやっています。
しかし、レールが錆びているなどで両レール間の抵抗が十分に下がらないと、
検知に失敗することがあり、これを軌道回路短絡不良と言っています。
今回の問題になった貨物線への渡り線は、かつては定期旅客列車が使っていたことも
あるという話ですが、今は資材運搬などの列車がたまに通るだけで、
レールが錆びやすい条件でした。(列車が通ると錆びが落ちるので)
そのため、軌道回路短絡不良が起きていて、運行管理システムが
渡り線を通る先行列車のために進路を切り替えたが、
渡り線を通っている状態を検知できず、渡り線の手前にまだ在線しているものと
判断していた可能性があります。
なので、問題の東海道線の旅客列車に対して誤って貨物線への進路を
出してしまったのではなく、先行列車への進路が誤認で残ったままだったのでは、
という推定です。
これは稀に起きるので、運行指令が手作業で運行管理システムの列車位置認識を
修正できる機能がありますが、今回は指令が注意してなかったのでしょうね。
断続的に発症というのが不思議です。初期化してない変数を参照したようなことかな?
Qiita
アプリケーションを Large Address Aware 対応にしたいのであれば、Integer によるポインタ操作をしていない事が条件です。ポインタを Integer でキャストしている場合には正常動作しない可能性があります
ってな記述をみると、CopyFile()にポインタをIntegerにしている箇所があって、たまたま上位アドレスが0なアドレスの範囲なら動くけど、それを越えたらダメとか?
「この手の新技術」にそもそも興味ないから叩くし、
実用化されてても当然知らんから調べず掘り返して叩く。
ここで教わっても興味ないから忘れてまたいずれ叩く。
>現地での検証を検討しましたが、ご本人が頑なに辞退をされた為検証ができなくなりました
嘘つきはほっといて、介護施設に取材確認したら検証完了ですね
なんでそうしないんだろう
それはネトウヨ・パヨク関係ない気がする(笑)
少なくとも都市部は貨物列車含め列車位置が把握されていて、ああいうポイント切り替えは完全自動化されていて、目つぶっていても運転できるんだと思っていたんだけど、違うの?
店員の制服を再現を期待してるのではない
制服を着てる可愛いグラマーな女の子の再現を期待してるのだ
にわかな奴ほど語りたがる -- あるハッカー