京王線の列車案内装置に表示された「32768編成」の原因は？ 106
ストーリー by hylom
さあみんなで考えよう！ 部門より
さあみんなで考えよう！ 部門より
あるAnonymous Coward 曰く、
2月13日14:45頃、京王線飛田給駅～武蔵野台駅間で作業員の電車接触による死亡事故が発生し、その影響でダイヤが大幅に乱れることになったのだが、このとき駅ホームの列車案内装置に「32768両編成」という異常な表示が見られたという。
これがTwitterで話題になり、編成長の計算をする人やバグの原因を想像する人が現れている（NAVERまとめ）。
タレコミ人は鉄道のシステムに詳しくないのですが、鉄道運行の業務や組み込みシステム特有の事情もあるのではないかと思っています。/.Jerの皆様はどのようにお考えでしょうか。
列車案内装置の例 (スコア:5, 興味深い)
日本信号製
フルカラー表示器 [signal.co.jp]
三色LED表示器 [signal.co.jp]
表示制御器と表示装置本体との間の通信は、RS-232Cとか424が主流なんですね。
駅構内の配線いじりたくないとか耐候性とかの関係ですかね……。
Re:列車案内装置の例 (スコア:1)
3.5インチ固定ディスク（８５０Mバイト）
こっちの方が驚きですよ。ほんとに主流なんかい。。。
3.5インチフロッピーディスク（1ドライブ）
ここ最近、触れる機会がほんとになくなりましたね。
2の補数 (スコア:1)
2の補数と符号無しの表現がこんがらがって2の補数の-1が符号無しの32768に化けたとか？
Re:2の補数 (スコア:5, 参考になる)
言わんとする事はわかるけど、-1なら65535になってないとおかしいでしょう。
short型の最小値-32768をint型として評価すると32768になるから、そんなところじゃないかな。
Re:2の補数 (スコア:1)
> K-T境界
って何だろう。 「Keio－Teito境界」じゃないよね？
内部値が下駄履き表現なんじゃないか？ (スコア:3, 興味深い)
歴史的経緯で下駄履き（エクセス）表現が使われ続けているのかも。
データベース上では編成数の内部表現が16ビットのエクセス32767になっていて、
表示部にデータを渡す前に、32767を減算しておく実装だったり。
で、なぜか編成数に0xFFFFが入っていた。（特殊値かミスオペ）
ここから32767を減算すると0x8000 になる。
表示部はこれを16ビットでの2の補数として解釈したため、 -32768 になった。
そして5文字しか表示幅がない仕様だったので、先頭の - が消えた。
「32768」の出来上がり。
Re:内部値が下駄履き表現なんじゃないか？ (スコア:3, すばらしい洞察)
って、単にエクセス32767で0xFFFFを解釈するだけで32768だわ。
深く考えすぎた。
きっと、合わせ技一本みたいなバグばかり目にしてきたせいだ…
Re:2の補数 (スコア:1)
表示側は、
1000 0000 0000 0000
を単純に符号なし2バイトか4バイト以上の整数として判断した。
ってことでしょうけど。
どういう入力や処理の結果として、そのデータになったのかが気になる。
Re: (スコア:0)
自然数を返す関数のエラーを負数で表す悪習が原因ですかね
表示側に渡る前に消すなり回送に置き換えるなりするはずだったのがすり抜けたとか
Re:2の補数 (スコア:2)
しかも、マジックナンバーを使っている悪寒が。
Re:2の補数 (スコア:1)
お前は-1両編成を見たことがあるのか？
Re:2の補数 (スコア:4, おもしろおかしい)
Re: (スコア:0)
いつもより短い11両編成なら見たことあります。
Re: (スコア:0)
この予想に賛成。ただ、この予想が当たってるなら、型関連のバグを心配しちゃう。
NAVERまとめにある写真からわかること (スコア:1)
・複数の駅の案内装置で確認されている
→データ配信側の問題?
・行先と到着時刻の異なる複数の列車で確認されている
→1本の列車に紐付けられた情報ではない
・10両編成は正しく表示されている
→京王線の場合あり得る編成は、2, 4, 6, 8, 10だったはずで、本線を走る列車は
ほとんど8両か10両ということを考えると、8両編成の表示に関わる処理orデータ入力がおかしい?
・事故後の運行で初めて確認された
→ダイヤ変更作業がトリガとなっている?
Re:NAVERまとめにある写真からわかること (スコア:1)
＞・複数の駅の案内装置で確認されている
3万両編成なら複数の駅にまたがるのは当たり前ですよ？
左詰め5桁 (スコア:1)
16ビット符号あり整数で、-32768を表示しようとして表示部は左詰め5桁だったので、先頭のマイナス記号は表示されなかった。
0x8000 (スコア:1)
BCD表現で「0008（両）」というデータだったのがエンディアン変換でおかしなことになって0x8000両編成に・・・ないか。
京王の案内表示といえば車内・駅LCDなど1画面の文字数が異なるデバイスで文章データを共用しているのか、
・・・駅係員、乗務員、 京王鉄道警備隊（ＡＬＳＯＫ）に・・・
といった具合に妙な空白が入った表示をたまに見かける。
本当は何両編成? (スコア:1)
本当は何両編成だったんだ?
8両編成なら (スコア:1)
4桁入力を慌てて1桁で入力してしまったんですね、「8」と。
桁数チェックなしの上詰めで「8000」となり「32768編成」に。
自動アナウンスは (スコア:1)
大原さやかさんの声で「この列車は32768両で云々」というアナウンスはあったのだろうか。
なぜ２バイト (スコア:0)
編成数なんて1バイト整数で十分なのになぜ2バイト確保した？
編成ごとに必要な量の2倍のメモリ空間を占めてんの？何それ馬鹿なの？
このプログラムを作ったのは誰だー！（C.V.海原雄山）
バイトプログラマーが作ったのかー
Re:なぜ２バイト (スコア:5, おもしろおかしい)
バイトプログラマー「先輩、それじゃだめっすよ。2バイトないと10両編成が困るじゃないですか」
Re:なぜ２バイト (スコア:2)
2バイト使うとあかんわ、にぶるで。
#難しい
Re:なぜ２バイト (スコア:3, 興味深い)
128両編成くらいだったら、その気になったらできちゃうからじゃね？
あと、大陸横断鉄道とかその手の列車だと、300両編成とかもありえるらしいし、
将来海外へ売り込みをする可能性を想定すると、1バイトじゃ不足だと言えるかもしれない。
Re:なぜ２バイト (スコア:1)
これに一票。
実際には、たとえば「世界最大で120両までです」みたいな事実があったとしても、
それを調べる労力がどうみても見合わん。
それにこの手の仕様は変化することもあるから、多めに見積もって2バイトというのは
そんなにおかしな判断じゃないと思われ。
＃まあネタにマジレスかな。
Re:なぜ２バイト (スコア:2, 参考になる)
貨物列車も使えるライブラリを使っているに決まっているだろ。旅客列車と貨物列車でライブラリを別に作るなんて、馬鹿なの？死ぬの？
Re:なぜ２バイト (スコア:1)
バイトプログラマー「文句なら、仕様書を書いた人に言って下さい！」
Re:なぜ２バイト (スコア:1)
> バイトプログラマーが作ったのかー
いえ、ワードプログラマーです。
# もしくはショートプログラマー
Re:なぜ２バイト (スコア:1)
（「ネタにマジレス」なのかもしれないけども）
バグが表示器のものなのか、ネットワークなのか、もっと上の運行管理のシステムで起きてるのか知らないけど、
制御用でも32ビット1ワードのプロセッサが普通にある昨今、
わざわざ1バイトのデータとか作っても効率よくアクセスできない。
Re:なぜ２バイト (スコア:1)
そこまでかつかつのシステム設計なら、上位11ビットに編成の構成情報のフラグ(扉の位置とか)を詰め込んで、下位5ビットが編成長、ぐらいまで頑張るだろう。
そしてそう推理すると、本来、マスクされるはずの上位バイトに記録されたフラグがマスクをすり抜けた結果、表示が乱れた、というこの件の原因の推測までセットで付いてくるのに。
Re:なぜ２バイト (スコア:1)
char [srad.jp]先生、出番ですぜ！
Re:なぜ２バイト (スコア:3)
/.Jよ、私は帰ってきた!
むぅ、何か違うな。
char *A;
モータースポーツ部 [slashdot.jp]
Re: (スコア:0)
そのぐらい気にする必要ないでしょ…
Re: (スコア:0)
安全率を考えると仕方ない。
「アメリカでは１００両以上の編成があるから、その倍…うーん、もうちょっと増えると…」
ってなると、１バイトでは危険。
昔のシステムからの使いまわしてワードの上位に運用条件なんかを入れていて、人身事故の発生を判る人にのみ伝えているって事は無い筈。きっと。
そういやどっかの工場のは４桁以上は数値で無くエラーコードだったな。
Re:なぜ２バイト (スコア:2)
Re:なぜ２バイト (スコア:1)
かつてMacがMC68000を使っていた頃, アドレスレジスタが32bit有るのに対して外に出ているアドレスバスが24bitしか無かったため, 上位8bitを別の目的で使うなんていうテクニックが有ったらしいです.
その後MC68020に移行した際に, 隠れていた8bitが表に出てきて動かなくなっちゃったとか.
Re:なぜ２バイト (スコア:1)
昔はアドレスデータにタグを埋め込んだりってのはよくやってました。
Lisp の処理系とか。
データ配置のアラインメントを意識して、下位数ビットを使うとかね。
Re: (スコア:0)
昔と違って今時バイト単位の違いを切り詰める必要はない。
寧ろ切り詰めたことにより、後々足りなくなった時の影響のほうが大きい。
某ゲームでも符号ありintでやってしまったため、約21億しか所持金が持てないというゲームがある。
開発当時はそんないくわけねえと思ってて、実際数年はそうだったが
どんどんインフレしてきて21億どころか42億でも到底足りない始末。
8バイト使わせろという事態になっている。
変数なんてちょっと余裕ありすぎね？というぐらいでもいい。
ファミコンとかの時代はそれこそバイトどころかビット単位で削ったものだが、それは過去の話。
Re:なぜ２バイト (スコア:1)
ただねぇ、こういう業界だと昔々のリレー制御由来のデータ形式が有ったりするのですよ。
1ビットが１リレーとなると、変数の余裕ってのは最終的には凄いコストや消費電力の差に成ったりします。
かといってエイヤっと全部を更新できるかって言うとそれも出来ないですし。
Re: (スコア:0)
Re:なぜ２バイト (スコア:1)
それは環境依存だぜ。
# ワードは環境依存だけど、エイトビットでバイトだから由来的に8ビットは確定だろ思ってたら違うと知ったときの衝撃。
Re: (スコア:0)
日本国内の旅客営業私鉄に限るのであれば、編成両数は4bit、列車種別(各停、急行等)は4bit、
行先(回送、試運転等も含む)は8bitあれば十分コード表現可能で、これらをまとめた16bit数をIDに
して、テーブルひいて表示データを読み出すなんて処理は可能ですけどね。
Re: (スコア:0)
そして列車番号で引けない
ダメぢゃん
Re:仕様といえば (スコア:3, 興味深い)
知人がレチやってたんですけど、査定がガンガン下がるって嘆いてました。確かに戸閉のタイミングなんか、難しそうだし。
死して屍、拾う者なし。
Re:仕様といえば (スコア:2, 参考になる)
京王線の小さい駅だと発車案内の掲示板が2列車分しかないのですが、
小さい駅だと特急と急行（1列車か2列車）が通過するため「通過」で埋め尽くされて
次の電車がいつくるかわからなかったりします。
それじゃ不便だということで改良されて複数の「通過」は一つにまとめるように
なったのですが、2列車目の案内部分は時おり「駆け込み乗車はおやめください」
といったメッセージの表示欄も兼用しているため、結局「通過」しか表示されない
時間がけっこうあったりします。
数十秒待てば表示が切り替わって次の電車の時間はわかるんだけど、ホームを
歩きながらの時間確認はできないという点で不親切。
Re:そもそもだな (スコア:1)
ふむ。
一両を10万円で換算すれば、32768両で約32.8億円。
新幹線の700系が一編成約36.4億円。
つまり、1割ほど減価償却しちゃった中古700系が来ます、って意味だったんだよ！
Re:そもそもだな (スコア:3, おもしろおかしい)
電車に乗ったときには既に目的地についている。
画期的な電車だな。
Re:そもそもだな (スコア:3, おもしろおかしい)
編成全体としてはそうだけど乗客は出発地のままじゃん。
波動みたいなものか。
あ、もしかして「波動輸送」ってそういう意味なの？
Re:どちかというと気になるのは (スコア:2)
大幅な電車遅延でこの症状が起こったことを考えると、BOFの可能性もありますよね。
確かに、表示だけの問題で済んで良かった。