アカウント名:
パスワード:
駅構内の発車時刻案内板はそもそも単純な垂れ流しのシリアル通信で送られてきたデータ(またはデータを変換したもの)を表示してるだけじゃないの?ならば発車時刻案内板に垂れ流しているデータをそのまま、あるいはデータ形式を変換してwebに垂れ流せば良いのではないかと思うのだが、そう簡単にはいかないシステム上の問題・大人の事情等があるのだろうか?
中の人情報なのでだいぶぼやかして書きますが
駅の発車時刻案内表示は旅客案内表示装置といいまして運行管理システムの一部分です。で、運行管理システムはPRCや連動装置や沿線防災、列車無線などを含む列車運行の安全を確保する重要な仕組みなわけで、たとえTCP/IPやLinux,Windowsを利用したオープンな仕組みとはいえ、基本的には公衆回線を通らない鉄道会社が設備として持つ回線を利用して通信しています。
そこまでクローズドな環境に後付けでインターネットをつなぐとなると、基本設計から見直したりCTC設備側にFWを入れたり、データ変換用サーバを入れたり、結構な追加投資をして物理的な施策を講じると同時に、社内のポリシーやら規定変更、関係各社・各箇所との調整やら何やら非常に面倒な手続きが待ち構えているわけです。
さて、これらを前提とした場合、あなたが担当者だとして、カメラと動画配信サーバくらいですむシステムの開発と運行管理システムの仕様変更とどちらを選択したいですか?
赤外線で回路絶縁するようなチップがあるけど、ああいうので、受信のみ可能な状態にしてパケットキャプチャすればOKなんじゃないの?
そこに流れるのが運行情報だけであれば問題ないでしょうが、実際には様々な機密情報(痴漢などの犯罪に関する警察情報や、いわゆる「特定旅客」の方々の動向の情報、社員情報など)が流れうるネットワークでもありますので、公開は難しいと思いますよ。
言い換えれば、「受信だけなら攻撃される心配がないんだから、社内LANを公開してみたら?」って言ってるようなもんでしょう。
うーん、「運行システムをのっとられる可能性が、もしかしたら・ひょっとすると・t検定・微レ存・υーσでも否定できない」危険性をわざわざシステムに直に組みこむことが、今回紹介されたシステムを凌駕するメリットは?
・リアルタイム性・耐障害性・低価格性・メンテナンス費・ソフト・ハード開発費用・情報の正確さ
どの面においても、今回のシステムが勝つと思うんだが
データを直接配信するのに比べてライブカメラが劣る点は、配信される情報の加工しやすさでしょ。例えば経路検索サービスで各鉄道会社の遅れを反映してより良い結果を提示するのに使いたい場合に、ライブカメラの映像ではすごく使いにくい。ライブカメラと OCR を組み合わせてもある程度はエミュレートできるだろうけれど、当面 OCR には誤認識の問題が付いて回るし、ライブカメラで配信するためには情報が出ているモニターがないといけないので、配信できる情報量も限られる。
データを直接配信する方がライブカメラより労力がずっと大きいのはその通りだと思う。でも、メリットが何もないかのような主張には賛成できないな。メリットが労力に見合うかどうかは、利用者が何を求めるかによる。
>利用者が何を求めるかによる。
文字情報でくれって、求められてるの?欲しいんなら、その人が提供されてる画像から読み取る仕組み作ればいいんじゃね?
メリットだけ着目するのはおかしい、というのが元コメの視点だけど。
>「運行システムをのっとられる可能性が、もしかしたら・ひょっとすると・t検定・微レ存・υーσでも否定できない」危険性を>わざわざシステムに直に組みこむこと
このリスクに対して「画像じゃなくて文字情報で提供する」ことの、運営者側のメリットって何?
フォトカプラ [srad.jp]だね。
愛環 [aikanrailway.co.jp]とかほくほく線 [hokuhokusen.jp]とか鉄道業界でやってる例が皆無ってわけじゃないけど、基本的にはシステム設計時点でそういう情報の二次活用を考慮してないと面倒でしょうね。(バスは身軽なのか、接近情報が見られる会社が割とある気がする)
あんまり関係ない話だけど、そういう外部との接点を一切絶ったシステムって時刻同期源で苦労するんだよなあ。GPS利用のNTPサーバアプライアンスは結構なお値段だし。
ネットワークのセキュリティ関係の再設計が一番面倒ですな。外部との接点が増えるほど、セキュリティ対策は面倒になりますから。
どうせならもう一歩踏み込んで、画像認識からテキストデータまで落とし込めばいいのにと思った。
> 同時接続数に限りがあり、アクセス集中時には映像が表示されない可能性もある。映像を表示するウィンドウは約1分で閉じるようになっているが、利用後はウィンドウを閉じることを求めている。
こんな問題があるなら、ね。
他で「OCR には誤認識の問題が付いて回る」と指摘している人もいますが,駅の案内表示なのでフォントも固定,表示される内容もフォーマットほぼ固定で使われる文字も限られているのだから,ほぼ確実に読める気がします.
「ほぼ」じゃダメってことでしょうクレーマーはどこにだって潜んでる
>カメラと動画配信サーバくらいですむシステムの開発nice hack.
つまり、これこそハックだったわけです。やり方はナニかもしれないけど、ちゃんと目的を果たして動く。
モニタとカメラを向かい合わせにして画像をOCRにかけて、結果をテキストでウェブに配信するという案は出なかったんですかね。
内部データを「外に出す仕組みをつくる」ことで、新機能追加以前の従来のシステムに不具合を起こす可能性があるでしょ?可能性があるとしたら事前対策しないといけなくなるでしょ?クラッキングの可能性を全く考慮しなくても、不具合の可能性なんていくらでもあるよ。 >大人の事情コストだね。
「スマートな仕組みを導入する」ことよりも、おおざっぱで古臭くて重複するような仕組みの方が人的・金額的、どちらのコストも同時に上回っているんでしょう。これを日本全国で同時にやる、とかなると事情も異なってくるかもしれないけどね。今回の事例は、地方組織の「コストをかけない知恵」でやりくりしたってレベルの話だよ。ゴミのポイ捨て禁止ポスターを手作りしたとかってそういうの。そういう努力は、面白いね、頑張ったねって褒めてやればいい。さすがにこれを全国規模でやられると、仮にコストで勝っていたとしてもアホっぽく見えるだろうけどね。
今回の事例では、低コストは言うまでもないことだけど、支社の担当部署の権限だけで実現できるのが重要なポイントな気がします。本社とかまきこんじゃうと途端に調整が面倒になりますしね。
#こうやって中央のシステム担当箇所が知らないシステムが増えていく…#良いのか、悪いのか…
途中・現場でいろいろあるかもしれない(でしょ?)ので、とにかく最終の結果を絶対間違いない形で提供しよう、というのはわかる気がすます
なんつーか、マスタを作るとき、一からビルドしましょう、小手先の調整は無しね、と似た感じ
あっ、なるほど!!
QRコード等の画面を作って、ライブカメラという2次元フォトカプラを経由してシリアルデータをweb制作会社に売ったら面白かろうと思った。
フォトカプラ…。言おうと思ったら、言われてしまった。もう少しコンピューターと電話に近いところでいえば「音響カプラ」もありますねっ。既存のシステムの枠内でシステムの通常使用という形を取りながら実際にはシステムを拡張的に(システムの当初の設計者の想定外の用途で)使用するものですねっ。 (;・∀・)
閉じたネットワークとインターネットを繋いでも一切リスクもコストも上がらないという主張でしょうか?
まぁまぁあたりちらすなよ。調べるといっても調べようがないのだし。たぶん大人の事情なんでしょ。
子供の場合はたいていお金も能力も親がなんとかしてくれるよね?何とかしてくれる誰かがいないが故にそれは大人の事情なんですよ。
ぐぅの音も出ない反論で感心した: +1# どうでもいいけど、能力が足りない、お金が足りないのを気合と根性でカバーしようとするのは旧軍から続く悪癖の一つだよな。
知恵でカバーしてるだけであって、気合いと根性ではないでしょうよ。
> データ形式を変換して
これが結構手間なのではないですかね。
さらに言えば何か変更があるたびにフォーマットも代わったりしてそれをフォローするのが面倒なんだよね画像ならそんなこと考えなくていい
たぶんモニタにはDVIかD-SUBで繋いでいるので、その映像データをキャプってWeb配信するようなハードがあるといいなぁ
でもそういうのが普及したら、著作物コンテンツを流して権利者団体がらクレームされる人が出そうですが…
配信先がUstreamかニコ生などでよければLiveShellという機械が既にある。http://static-shell.cerevo.com/ja/index.html [cerevo.com]DVIなら物理的にHDMIに変換すればいいし、DSubしかないなら何か適当なDSub-HDMIコンバータを噛ませば良かろう。他にも同様の機材は何社か出しているよ
ライブカメラなら、買ってきてつなぐだけで済むからでしょう。おっしゃるようなシステムを書くとなると、稟議やら仕様書やら作らなければなりませんから…
motion jpegなら、自宅サーバーから10分おきにwgetで取得してlibocrにかけて文字情報に落として、スマホのアプリ書いて、自宅サーバーのデータを見るとかするとアレゲですね。
たぶん、そこまでする予算をかけたくなかったんでしょうけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
なぜカメラを使うのか? (スコア:1)
駅構内の発車時刻案内板はそもそも単純な垂れ流しのシリアル通信で送られてきたデータ(またはデータを変換したもの)を表示してるだけじゃないの?
ならば発車時刻案内板に垂れ流しているデータをそのまま、あるいはデータ形式を変換してwebに垂れ流せば良いのではないかと思うのだが、そう簡単にはいかないシステム上の問題・大人の事情等があるのだろうか?
Re:なぜカメラを使うのか? (スコア:5, 興味深い)
中の人情報なのでだいぶぼやかして書きますが
駅の発車時刻案内表示は旅客案内表示装置といいまして運行管理システムの一部分です。
で、運行管理システムはPRCや連動装置や沿線防災、列車無線などを含む列車運行の安全を確保する重要な仕組みなわけで、
たとえTCP/IPやLinux,Windowsを利用したオープンな仕組みとはいえ、
基本的には公衆回線を通らない鉄道会社が設備として持つ回線を利用して通信しています。
そこまでクローズドな環境に後付けでインターネットをつなぐとなると、基本設計から見直したり
CTC設備側にFWを入れたり、データ変換用サーバを入れたり、結構な追加投資をして物理的な施策を講じると同時に、
社内のポリシーやら規定変更、関係各社・各箇所との調整やら何やら非常に面倒な手続きが待ち構えているわけです。
さて、これらを前提とした場合、
あなたが担当者だとして、カメラと動画配信サーバくらいですむシステムの開発と運行管理システムの仕様変更とどちらを選択したいですか?
繋ぐ必要ない気が (スコア:2)
赤外線で回路絶縁するようなチップがあるけど、ああいうので、受信のみ可能な状態にしてパケットキャプチャすればOKなんじゃないの?
uxi
Re:繋ぐ必要ない気が (スコア:2, すばらしい洞察)
そこに流れるのが運行情報だけであれば問題ないでしょうが、実際には様々な機密情報(痴漢などの犯罪に関する警察情報や、いわゆる「特定旅客」の方々の動向の情報、社員情報など)が流れうるネットワークでもありますので、公開は難しいと思いますよ。
言い換えれば、「受信だけなら攻撃される心配がないんだから、社内LANを公開してみたら?」って言ってるようなもんでしょう。
Re: (スコア:0)
うーん、「運行システムをのっとられる可能性が、もしかしたら・ひょっとすると・t検定・微レ存・υーσでも否定できない」危険性を
わざわざシステムに直に組みこむことが、今回紹介されたシステムを凌駕するメリットは?
・リアルタイム性
・耐障害性
・低価格性
・メンテナンス費
・ソフト・ハード開発費用
・情報の正確さ
どの面においても、今回のシステムが勝つと思うんだが
Re:繋ぐ必要ない気が (スコア:2)
データを直接配信するのに比べてライブカメラが劣る点は、配信される情報の加工しやすさでしょ。例えば経路検索サービスで各鉄道会社の遅れを反映してより良い結果を提示するのに使いたい場合に、ライブカメラの映像ではすごく使いにくい。ライブカメラと OCR を組み合わせてもある程度はエミュレートできるだろうけれど、当面 OCR には誤認識の問題が付いて回るし、ライブカメラで配信するためには情報が出ているモニターがないといけないので、配信できる情報量も限られる。
データを直接配信する方がライブカメラより労力がずっと大きいのはその通りだと思う。でも、メリットが何もないかのような主張には賛成できないな。メリットが労力に見合うかどうかは、利用者が何を求めるかによる。
Re: (スコア:0)
>利用者が何を求めるかによる。
文字情報でくれって、求められてるの?
欲しいんなら、その人が提供されてる画像から読み取る仕組み作ればいいんじゃね?
Re: (スコア:0)
メリットだけ着目するのはおかしい、というのが元コメの視点だけど。
>「運行システムをのっとられる可能性が、もしかしたら・ひょっとすると・t検定・微レ存・υーσでも否定できない」危険性を
>わざわざシステムに直に組みこむこと
このリスクに対して「画像じゃなくて文字情報で提供する」ことの、運営者側のメリットって何?
Re: (スコア:0)
フォトカプラ [srad.jp]だね。
Re:なぜカメラを使うのか? (スコア:1)
愛環 [aikanrailway.co.jp]とかほくほく線 [hokuhokusen.jp]とか鉄道業界でやってる例が皆無ってわけじゃないけど、
基本的にはシステム設計時点でそういう情報の二次活用を考慮してないと面倒でしょうね。(バスは身軽なのか、接近情報が見られる会社が割とある気がする)
あんまり関係ない話だけど、そういう外部との接点を一切絶ったシステムって時刻同期源で苦労するんだよなあ。
GPS利用のNTPサーバアプライアンスは結構なお値段だし。
Re: (スコア:0)
ネットワークのセキュリティ関係の再設計が一番面倒ですな。
外部との接点が増えるほど、セキュリティ対策は面倒になりますから。
Re: (スコア:0)
どうせならもう一歩踏み込んで、画像認識からテキストデータまで落とし込めばいいのにと思った。
> 同時接続数に限りがあり、アクセス集中時には映像が表示されない可能性もある。映像を表示するウィンドウは約1分で閉じるようになっているが、利用後はウィンドウを閉じることを求めている。
こんな問題があるなら、ね。
Re:なぜカメラを使うのか? (スコア:1)
他で「OCR には誤認識の問題が付いて回る」と指摘している人もいますが,
駅の案内表示なのでフォントも固定,表示される内容もフォーマットほぼ固定で使われる文字も限られているのだから,ほぼ確実に読める気がします.
Re: (スコア:0)
「ほぼ」じゃダメってことでしょう
クレーマーはどこにだって潜んでる
Re: (スコア:0)
>カメラと動画配信サーバくらいですむシステムの開発
nice hack.
Re: (スコア:0)
つまり、これこそハックだったわけです。やり方はナニかもしれないけど、ちゃんと目的を果たして動く。
Re: (スコア:0)
モニタとカメラを向かい合わせにして画像をOCRにかけて、結果をテキストでウェブに配信するという案は出なかったんですかね。
Re:なぜカメラを使うのか? (スコア:3, 興味深い)
内部データを「外に出す仕組みをつくる」ことで、
新機能追加以前の従来のシステムに不具合を起こす可能性があるでしょ?
可能性があるとしたら事前対策しないといけなくなるでしょ?
クラッキングの可能性を全く考慮しなくても、不具合の可能性なんていくらでもあるよ。
>大人の事情
コストだね。
「スマートな仕組みを導入する」ことよりも、おおざっぱで古臭くて重複するような仕組みの方が
人的・金額的、どちらのコストも同時に上回っているんでしょう。
これを日本全国で同時にやる、とかなると事情も異なってくるかもしれないけどね。
今回の事例は、地方組織の「コストをかけない知恵」でやりくりしたってレベルの話だよ。
ゴミのポイ捨て禁止ポスターを手作りしたとかってそういうの。
そういう努力は、面白いね、頑張ったねって褒めてやればいい。
さすがにこれを全国規模でやられると、仮にコストで勝っていたとしてもアホっぽく見えるだろうけどね。
Re:なぜカメラを使うのか? (スコア:2, すばらしい洞察)
今回の事例では、低コストは言うまでもないことだけど、
支社の担当部署の権限だけで実現できるのが重要なポイントな気がします。
本社とかまきこんじゃうと途端に調整が面倒になりますしね。
#こうやって中央のシステム担当箇所が知らないシステムが増えていく…
#良いのか、悪いのか…
Re:なぜカメラを使うのか? (スコア:1)
途中・現場でいろいろあるかもしれない(でしょ?)
ので、とにかく最終の結果を絶対間違いない形で提供しよう、
というのはわかる気がすます
なんつーか、マスタを作るとき、一からビルドしましょう、
小手先の調整は無しね、と似た感じ
Re:なぜカメラを使うのか? (スコア:1)
#アクセス集中時のデータ量をファミコン風に減らせないかなぁ
Re:なぜカメラを使うのか? (スコア:1)
あっ、なるほど!!
ちどりの「ち」きっての「き」…
Re:なぜカメラを使うのか? (スコア:1)
QRコード等の画面を作って、ライブカメラという2次元フォトカプラを経由して
シリアルデータをweb制作会社に売ったら面白かろうと思った。
Re: (スコア:0)
フォトカプラ…。言おうと思ったら、言われてしまった。もう少しコンピューターと電話に近いところでいえば「音響カプラ」もありますねっ。既存のシステムの枠内でシステムの通常使用という形を取りながら実際にはシステムを拡張的に(システムの当初の設計者の想定外の用途で)使用するものですねっ。 (;・∀・)
Re:なぜカメラを使うのか? (スコア:1)
Re: (スコア:0)
閉じたネットワークとインターネットを繋いでも一切リスクもコストも上がらないという主張でしょうか?
Re: (スコア:0)
>そう簡単にはいかないシステム上の問題・大人の事情等があるのだろうか?
と思うなら少しは調べてから言ったほうが言ってみてはどうか。
Re: (スコア:0)
Re: (スコア:0)
まぁまぁあたりちらすなよ。
調べるといっても調べようがないのだし。
たぶん大人の事情なんでしょ。
Re: (スコア:0)
Re:なぜカメラを使うのか? (スコア:5, すばらしい洞察)
子供の場合はたいていお金も能力も親がなんとかしてくれるよね?
何とかしてくれる誰かがいないが故にそれは大人の事情なんですよ。
Re: (スコア:0)
ぐぅの音も出ない反論で感心した: +1
# どうでもいいけど、能力が足りない、お金が足りないのを気合と根性でカバーしようとするのは旧軍から続く悪癖の一つだよな。
Re: (スコア:0)
知恵でカバーしてるだけであって、気合いと根性ではないでしょうよ。
Re: (スコア:0)
> データ形式を変換して
これが結構手間なのではないですかね。
Re: (スコア:0)
さらに言えば何か変更があるたびにフォーマットも代わったりしてそれをフォローするのが面倒なんだよね
画像ならそんなこと考えなくていい
Re: (スコア:0)
たぶんモニタにはDVIかD-SUBで繋いでいるので、その映像データをキャプってWeb配信するようなハードがあるといいなぁ
でもそういうのが普及したら、著作物コンテンツを流して権利者団体がらクレームされる人が出そうですが…
Re: (スコア:0)
配信先がUstreamかニコ生などでよければLiveShellという機械が既にある。
http://static-shell.cerevo.com/ja/index.html [cerevo.com]
DVIなら物理的にHDMIに変換すればいいし、
DSubしかないなら何か適当なDSub-HDMIコンバータを噛ませば良かろう。
他にも同様の機材は何社か出しているよ
Re: (スコア:0)
ライブカメラなら、買ってきてつなぐだけで済むからでしょう。
おっしゃるようなシステムを書くとなると、稟議やら仕様書やら作らなければなりませんから…
motion jpegなら、自宅サーバーから10分おきにwgetで取得してlibocrにかけて文字情報に落として、
スマホのアプリ書いて、自宅サーバーのデータを見るとかするとアレゲですね。
たぶん、そこまでする予算をかけたくなかったんでしょうけど。