2015年10月15日 (木)

ForeAthlete 15Jを飛行機で使ってみたら、、、

飛行機に乗るチャンスがあって、しかも時計としてGPSスポーツウォッチのForeAthlete 15Jを身につけてた。以前、Foretrex301Jで実験したけど、ちょうど良いやとForeAthlete 15Jでも飛行機でのテストを実施。

15Jはジョギング用のウォッチで、一応カタログスペックでは稼働時間はGPS使用時約8時間とのことだが、自分としては数時間程度との認識。まっフルマラソンのレースでは使用できるといった感じ。

最近は、フィット感も良いので、改まった時でない場合の日常で使うことが少なくない。

飛行機の1週間ほど前の往路での席は窓際。今では離陸の時もGPSオンにしても問題なかったが、一応離陸してしばらくして(水平飛行に近い状態)からオン。すぐにというほどでもなかったが、GPSを捕捉してスピードなどが表示された。ところが、スピードが「235.9」。単位をkm/hにしているはずなので、新幹線並み。一瞬「えっ、どうしたんだろう」と思ったけど、飛行機自体は普段と同じような飛行。次に単位設定をどっかで変更してしまったかと思って確認したけど、km/h。

どうやらスピードの最大を、235.9km/hにしている感じ。まっ、人が走るのの計測と考えれば理解できなくもなかった。ちなみに、ラップ表示での平均スピードなどでは、飛行速度に近かったと思った。また、着陸時にはスピードは段々減じてゼロになった。


なお今日の帰路時(復路)の席は通路側。隣の席が空いていたので、少し手を伸ばして、GPS捕捉できるかやってみたけど駄目だった。GPS感度が向上してるかもと思ったけど、画期的に向上というほどでも無さそうだ。

なんで、235.9なのか推測しようとしたけど、すぐには思いつかない。どこかの値がオーバーフローしてるんだろうけど。いずれにしろ知ってたから得するほどでもないけど、ある意味当然だけどGPSウォッチもソフトで出来てるんだ~と改めて認識した。


Amazonでのガーミン

10月 15, 2015 スポーツ技術テクノロジー | | コメント (0) | トラックバック (0)

2013年9月13日 (金)

いよいよ明日は イプシロンロケット再発射

8月27日に発射しようとして発射中止になったイプシロンロケットは、トラブル対策して、いよいよ明日に再発射の予定だ。

それにしてもイプシロンロケットは、昨年11月に職員の端末1台がコンピュータウイルスに感染し、外部に情報が漏洩した可能性があった。そして本来22日に発射予定だったけど、回路の配線ミスが発覚して27日に発射延期となった。新ロケットなので、その分トラブルが多いだろうけど、多少不運続きだ。(こうのとり4号機の大気圏突入での撮影装置機能せずも、ちょっとネガティブなニュースだ。) 金曜日にせずに土曜日にしたのは、対策確認作業や見学への配慮もあろうが、13日・金曜日は避けたかったというのもあるかもしれない。

ちなみに27日の発射中止は大きなニュースになり、ネットでの記事では「大丈夫か日本の技術」みたいなのまであって、流石にそのようなタイトルにはうんざりした。ちょっとした中止を元に、これ幸いと他の技術系の失敗例などで記事を膨らませている。自分たちのことを棚に上げたり、日本を萎縮させようとしているように思えてならなかった。


さて、27日の発射中止で色々原因を考えたけど、最初に目に着いたのは以下。

http://togetter.com/li/555075

最後の方の「ロールがプラスマイナス1度の範囲で閾値設定をしていたが、もう1度くらい回ってしまったような値が来てしまった」を、359などが返ってきたのだと考えた。-1なのに359みたいなこと。後々、ここでの”1度くらい回って”は、1度くらい傾いてみたいな意味と判明した。ほんとは傾いてるんじゃなくて、回転なので”回って”。それを1周りの360度と、つい考えてしまった。ある意味、ありそうなバグなので。

その後、遅延が理由と発表された。ただ、ここでも、しきい値±1度みたいな言い方がされた。2度に対してしきい値±1度と言う表現。多少、その表現で混乱した。本来は、許容範囲±1度として、しきい値は1度~3度と言うべきだ。JAXAの発表でも、2度に対してしきい値±1度みたいに書かれてて、それがネット記事などになったように思う。

ちなみに、なぜ0度から2度に変更したかがはっきりせず、個人的には色々思いをめぐらせた。最初は、追跡用アンテナが違ったのかもと思ったけど、2度は微々たるもの。ありえるのは、内之浦内のアンテナで変更したかなくらいだった。あるいは、イプシロンロケットは固定燃料だけど垂直発射なので、何か計算間違いが判明したのかもと考えた。ただ、今は、ランチャーの回転が180度であるべきなのに、182度あるいは178度しか回ってないのかもしれない。1度レベルの精度出せないのかもしれない。素人考えだけど、そう高い精度が必要な箇所でもないだろうから、それ自体は構わないように思える。

また、そもそも起動した後に起動して、タイマー(時刻)が0.07秒違ったままというのも少し違和感があるが、そこの部分の対策は難しいというか手を入れられないのだろう。そのためもあって、監視側のロケットからのタイマー(時刻)監視をずらす対策とのこと。

ちなみに、直近で対策方法が参考になると思ったのは以下。ロケットの搭載計算機(OBC)からの情報が、タイマーも含めて分かるように図示してある。

http://news.mynavi.jp/articles/2013/09/13/epsilon_measure/index.html


再発射、うまく行くと良いな。

9月 13, 2013 品質テクノロジー | | コメント (0) | トラックバック (0)

2013年7月23日 (火)

情報処理学会「デジタルプラクティス」 ”ヘルスケアの現場を支えるIT”

今度の情報処理学会「デジタルプラクティス」の特集は、”ヘルスケアの現場を支えるIT”。さらっと読んだけど、面白い。実践分野の話しがほとんどだし、(デジタルプラクティスでも時々ある)論文のための理論こねくり回しが少ないように思う。

デジタルプラクティス単体でも、Amazonで購入できるそうだ。


実務を踏まえての論文が多いので、分かりやすい。苦労話や今後の課題と感じることも具体的に書かれている論文が多く、(他の分野でも)参考になるだろう。思い付くのは、カルテの閲覧への要望が多くて対応したが、対応したら対応したで分かりにくいとか医者の記載が横柄に思えるとの苦情があったそうだ。ある意味仕方ないと言えるが、その対策として、カルテ部分に内部用の欄を設けたとのこと。海外や地方への展開の際の、法律とか医師会への配慮のことなども書かれていた。

システムの構築と共に事業運営との問題や、虚偽データの扱いなど、結構本質的な問題にも触れている箇所があって考えさせられた。

また知らなかったシステムの紹介もあって、自分の健康維持などに役立ちそうなものがあった。具体的には、全国の血圧の上昇度合いが分かる”にっぽん血圧マップ”。時々アクセスして、自分の血圧データと比較してみたいと思う。(”にっぽん血圧マップ”への要望/切望としては、過去データを見ることができればと思う。せめて1月前程度はクリックか何かで見ることができればありがたい。)


興味あれば、購入して読むのも良いかもしれない。なお、価格が情報処理学会誌と同じような価格で、多少躊躇するかもしれない。今回の号はある程度見合ってるとは思うが、デジタルプラクティスの趣旨などを考えると、もう少し安価にするなども考えて良さそうに思う。

7月 23, 2013 書籍・雑誌技術ソフトウェアテクノロジー | | コメント (1) | トラックバック (0)

2013年7月11日 (木)

真っ直ぐレーンの回転寿司 渋谷・魚べい

今日は知り合いのつぶやきに触発されて、「魚べい 渋谷道玄坂店」へ。回転寿司のお店だけど、レーンがUターンなどをせず、真っ直ぐになっているお店。

動画がアップされているので、そちらを見るとイメージしやすいと思う。

レーンの一般的な名前は?だけど、「リニアレール」と言った製品なのかもしれない。

TVでは見て知っていたけど、知り合いのつぶやきをきっかけにして、どんな仕組みになっているかのが気になった。特にソフトウェアの視点。

そもそも各自に配膳(?)されるレーンのトレイには、3皿までしか乗らない。そのためと思うけど、1度に注文できるのは、最大3種類かつ最大3皿。最初の注文時には皿数が3まで出るけど、例えば2皿頼んだ後の注文では1皿部分しかタッチできないようになってる。あっ、注文のタッチパネルはアンドロイドで制御しているとのこと。

注文した後で皿が来て、自分の前で停止して、小さなブザー音が鳴る。ボタン部分が光って、皿を取って、その後ボタンを押すと、バックヤードの方にトレイが戻っていく。レーンが3つあり、一番下にボタンとブザーが1セット。真ん中にはなくて、一番上のところに、中段と一番上の2セットが配置されている。(どちらなのかはシールの類があったか??)

ネタというか皿はこの3つのレーンのみで、各自の注文した皿のみが行き来する。(普通の回転寿司店のように、お店の方で予想したネタが回っていることは、無い。)

食べ終わったら、会計確認のボタンを押して、席番号のバインダーを会計のところへ持って行って精算。皿数などは数えない。なお、会計確認や注文履歴もそうだったと思うけど、ワサビ抜きかどうかの識別のために、”ワサビアリ 0円”のような品目が書かれている(いたと思う)。

なかなか近未来的なシステムと感じた。なお、バックヤードでトレイに行き先を設定するはずと目を凝らしていたけど、分からなかった。ちなみに、各皿の下の方にはマグネットの類は無かったので、皿での管理制御は行っていないように思う。


感想めいた事項は、、、、。11時50分くらいにお店に入ったけど、結構空いてた。食べ終わる頃に少し混んできたけど両脇とも1人分空けてくれた。これは自分の列は皆さんそう。係の人の格好が、カラオケ店のようにちょっと近代的と思えた。ワサビの小袋の隣に余り見かけない小袋があって、(目が悪いこともあり)じっと見ていたら、係の人が穴子のタレと教えてくれた。

個人的に少し変わったメニューと思ったのは、ハンバーグすし、パイナップルかな。まっ他のお店でもやってるところがあるかもしれないけど。

なお場所は、渋谷の109の裏の方の狭い路地といえば分かる気がする。


以下のサイトなど、結構触れているページとかあるので、興味あればどうぞ。

http://matome.naver.jp/odai/2136612182583873901

7月 11, 2013 テクノロジー | | コメント (0) | トラックバック (0)

2013年7月10日 (水)

「生字幕放送でお送りしています」

半月ほど前に病院に行った際に、待合室のテレビが音量微少になって字幕がオンになってた。以前は、それなりの音量。病院のテレビをしばらく眺めていたこともあって、それ以降、自宅のテレビでも字幕オンにしていることが多い。

病院でなかなか面白いと思ったのは、普通の番組からCMになる時。CMには字幕がないせいか、内容が分からない。もちろんCM上の文字とかで訴求するものもあるけど、多くは伝わってこない。病院などでは字幕オンのところも少なくないだろうから、薬やヘルスケアなどは字幕付きのCMにしても良いような気さえした。

結構自宅で視聴するCS放送での時代劇チャンネルなどは、全部字幕の付いた番組になってる。また驚いたのは、バラエティ番組でのリアル字幕放送があること。今回のタイトルの「生字幕放送でお送りしています」は、NHKの朝の番組”あさイチ”の冒頭で出てくる表現である。

その直前が朝の連続ドラマ(朝ドラ)で、そちらも字幕付きだけど、朝ドラは脚本などを元に事前に字幕を作成しているもの。その直後の”あさイチ”は生放送のため、リアルタイム入力して、多少音声に対して字幕が遅れる。とは言っても、しゃべったほとんどが字幕に出てくるし、”あさイチ”で時々駄洒落などが飛び出すがそれへの対応もたいしたものだ。


入力がやたらと早いな~とか、テレビ局間で結構似た表示のさせ方だな~と思っていたら、どうも処理しているのは(特に生字幕は)1社のようだ。

http://www.nhk.or.jp/seikatsu-blog/800/111911.html

NHKのブログだけど、入力方法が特殊だし、キーボードの写真などもある。

しかも字幕作成の会社は、直接NHKで作業するのではなくて、一般の人達と同じように会社でTV受信して字幕データをNHKに送るようにしているとのこと。意外だった。

1社なので、主人公とかが黄色表示とか、テロップとの関係で字幕に矢印が出たりするのが、似ているのはそのためと思う。

なお、字幕を注意したらしたで、色々気になることも出て来た。時々半角文字が表示されるが、全角と半角の使い道の違いが今ひとつ分からない。例えば、朝ドラ「あまちゃん」で”ウニがゴロゴロ”という台詞があり、”ウニ”は全角なのに”ゴロゴロ”は半角だった。また、多くの人がしゃべると文字列を自由配置したり、同一人の台詞でも改行後に字下げしたりしなかったりしている。

字幕オンのままにしていると、番組や放送局での多少の違いも判明して面白い。特に生字幕というかリアルタイムでの字幕化。テレビ朝日のニュースでは、冒頭に”当番組は同時入力の為、誤字脱字が発生する場合があります”の字幕が出るものがあった。逆に、人気のある番組で字幕のないものもあって、なんか勿体ない気もした。

なお自分の使用している機器の操作が良く分かってないのか、録画再生での字幕扱いは気になっている。イメージ的には、再生時に字幕のOn/Off切り替えが可能と思えるんだが、どうも字幕付きで録画できてるケースとそうでないケースがある。録画モードに依存するかと思ったけど、どうも直前でのテレビでの字幕On/Offの設定が関係するように思える。自分の操作の勘違いかもしれないけど、障害の人の利便性などを考えると、そんなことも技術的には要検討なような気がする。


ちなみにウィキペディアには、「リアルタイム字幕放送」での記載がある。

http://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%A2%E3%83%AB%E3%82%BF%E3%82%A4%E3%83%A0%E5%AD%97%E5%B9%95%E6%94%BE%E9%80%81


字幕のお陰で、特に時代劇とかでの用語の漢字(しかも結構ルビ付きが多い)が分かったりして勉強になることが多い。試しに字幕オンしてみてはいかが?

追記:生字幕放送に関する参考になるネット記事があったので紹介。

http://www.tv-asahi-create.co.jp/jimaku/jimaku-rt.html

分割作業や辞書のことなどが書かれている。

http://wakuteka.ascii.ne.jp/2009/03/18/%E7%94%9F%E5%AD%97%E5%B9%95%E3%81%AE%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E8%81%B7%E4%BA%BA%E3%80%813%E3%81%A4%E3%81%AE%E9%A9%9A%E3%81%8D/

実際の作業の様子。修正担当の話しもあって、結構驚く。ちなみにシリーズ物なので、他でも参考になることが多い。

http://blog.goo.ne.jp/hearingrabbit/e/6a89d9c0b1ea46bc7e6144c89fa80f46

個人ブログ。音声認識利用に関するもの。

7月 10, 2013 映画・テレビ技術テクノロジー | | コメント (0) | トラックバック (0)

2013年3月25日 (月)

「プリンタ」と「プリンター」どっち?

ここ数日悩んでるのが、とある用語集で記載を「プリンタ」と「プリンター」のどっちにしようかということ。いわゆる”長音”の扱いで、erなどで終わる用語のカタカナ表記で”ー”を使うか/使わないか。後述するが、「プリンタ」/「プリンター」以外にいっぱいある。

昔は”プリンタ”で納得してたし、ドキュメントレビューなどでも”プリンタ”に修正することは良く行われていた。設計ドキュメントで厳密に統一する必要はないのだろうけど、後々のマニュアルとか表示関係の実装での間違いを防ぐ意図(意識)もあって、修正したのだろう。このブログでも、結構「プリンタ」とか「レーザ」のように、長音符号無しで表現していた。

で、今回のとある用語集での統一性のために色々検討して、(案の定というとおかしいけど)長音符合の件は議論になった/なっている。


まずは、長音符号のいきさつ。ちなみにここでの大きな問題は、言葉が 3音以上の場合にで英語の語末が‐er, ‐or, ‐arなどに当たるものカタカナ表記に、長音符号を付けるか付けないかである。(2音以下の場合には、語尾に長音符号を付けるで合意。)

1)http://ci.nii.ac.jp/naid/110002440034「電子管式アナログ・コンピュータ : 自動制御への応用」電気系の論文1953年とかで、音引き省略の用例が見つかるそうだ。

カタカナ語語尾長音(音引き)省略に関する話題 http://kozawa.jugem.cc/?eid=477 より)

2)個人的なイメージ的には、1970年代でも結構音引き省略/長音符号省略の用例が広がっていたと思う。

3)1991年6月28日の内閣告示第二号で、長音を付けるべしと告示。

個人的には、工業界は知らんぷりというか、移行した所は皆無だったと思われる。

4)JIS Z 8301:1996において、長音符を付けないと規格化された。

5)JIS Z8301(2000年版)で上記長音無しルールが一度削除された。(上記サイト)

JISが1991年の内閣告示へ賛成する格好になったようだけど、これも普及しなかった(長音符号省略が継続)ように感じる。

6)JIS Z8301(2008年版)では、決めるのが難しいとの表現に変わった。

Z8301規格では「専門分野の用語の表記」の項での表現は、”長音符号を付けるか,付けないかについて厳格に一定にすることは困難であると認め,各用語集の表記をそれぞれの専門分野の標準とするが,長音符号は,用いても略しても誤りでないことにしている。”との表現になった。また、長音符号を省く場合の原則(8301:1996とほぼ同じ?)が列挙された。

7)ポツリポツリと企業等で長音符号を付けるようになったり、その旨を明言したりするようになった。逆に、旧来の長音符号を付けないままとする旨を、明言するところもあった。

長音符号を付けることを明言した端的なところは、(日本)マイクロソフト。

http://www.microsoft.com/japan/presspass/detail.aspx?newsid=3491

以前なら、日本語スタイルガイドにも辿れたようだが、スタイルガイドの方はもう無いようだ。

逆に、長音符号を付けないことを明言した端的なところは、情報処理学会。

http://www.ipsj.or.jp/magazine/topics/katakana.html


じゃ、プリンターメーカーはどうなのか調べたら、、、、。

<<「プリンター」派>>
富士ゼロックス
http://www.fujixerox.co.jp/product/printer/

エプソン
http://www.epson.jp/products/colorio/printer/

キヤノン
http://cweb.canon.jp/product/printer/

(日本)HP
http://h50146.www5.hp.com/products/printers/inkjet/

ブラザー
http://www.brother.co.jp/product/printer/

リコー
http://www.ricoh.co.jp/printer/

コニカミノルタ
http://www.konicaminolta.jp/business/products/printers/

パナソニック
http://panasonic.jp/dc/printer/


<<「プリンタ」派>>
富士通
http://jp.fujitsu.com/platform/document/

NEC
http://www.nec.co.jp/products/peripheral/printer.html

デル
http://accessories.apj.dell.com/sna/category.aspx?c=jp&category_id=4014&cs=jpdhs1&l=ja&s=dhs
(デル自身のプリンタが無い?ので、多少は矛盾。また「レーザープリンタ」との表記で、長音符号を付けない原則なら「レーザプリンタ」だろうにとか、逆に「スキャナー」と長音符号ありの用語を使っていたり、「モニタ」と「モニター」との記載のページが混在している。)

レックスマーク
http://www1.lexmark.com/ja_JP/products/printers-multifunctions.shtml
(こちらも「カラーレーザー」との表記で、長音符号を付けない原則の統一感には乏しい。)


上記ではプリンター派が多いが、いくつかはマイクロソフトの長音使用に対する賛同企業として名を連ねている。またマイクロソフトの長音使用に前後して、テクニカルコミュニケーター協会から、「外来語(カタカナ)表記ガイドライン(第2版)」が出された。(上でのマイクロソフトのページにあるように、テクニカルコミュニケーター協会の会長が、マイクロソフトの呼びかけに賛同している。)

http://www.jtca.org/ai_collaboration/katakana_wg/index.html


ちなみに上記マイクロソフトのページなどで長音符号を付けるようになった用語の主なものは以下。

アダプター、インストーラー、エクスプローラー、コントローラー、スキャナー、ドライバー、バッファー、パラメーター、ブラウザー、プリンター、ユーザー、コンピュータ-。

なお、内閣告示第二号での「外来語の表記」 では、語末*y も原則として長音とし長音符号「ー」を用いて書き表すとしている。アクセサリー(accessory)、エネルギー(energy)、メモリー(memory)など。ただし、マイクロソフトのサイトなどでも、これらについては長音符号を使わないケースになっている。例えば、セキュリティーとせずに、セキュリティ。(さらにただし。「エネルギー」に関しては、マイクロソフトを含めて長音符号を付けている場合がほとんどである。)


今回の調べで、自分の頭の中で、「プリンタ」→「プリンター」など長音利用の方向に頭を切り換えることができそうなのは有意義だった。さらには、語末*yでの長音符号など、用語表記に関するルールで混乱している部分がまだまだ少なくないことを改めて知ったことは大きかった。

自分なりに、長音を含めた用語表記ルールを意識しておくことは大事だろう。例えば情報処理学会などへの投稿の際には長音符号削除にすべきだが、自分なりに統一していれば削除のための作業は楽といえる。また、自分の属する会社や団体での長音扱いがどうなっているか、今のうちに調べてみるのも悪くないと考える。

3月 25, 2013 パソコン・インターネット技術テクノロジー | | コメント (0) | トラックバック (0)

2013年2月15日 (金)

ETロボコンの部門追加 今までの総括も欲しい

昨日・今日のネットニュースで目を引いたのは、ETロボコンのコンテストが2部門制になるというもの。創造性の高いロボットなり、ロボットの動作が見られそうで、楽しみが増えた感じではある。

ただし、個人的には良い機会なので、ETロボコンにおける「組込みでのモデリングって何だったんだろうか」を総括して欲しい気がする。ETロボコンの発祥は、ご存じのように2002年の「UMLロボットコンテスト」。2002年の最初はUML”のみ”がモデリングの規定だったか分からないが、長く走行時間とモデリング能力の2つがコンテスト対象となった。

組込み屋視点では始めの頃から、以下のような項目は気になった事項。

・モデリング(ツール)を利用して、走行スピードが確保できるか
・処理の全てをモデリングするのか、あるいはモデリングする割合はどれくらいか
・どの程度モデリングツールによるコード生成をするものか
・モデルとして採用されるのは何が多いか
  :

以前は走行スピードの上位入賞者とモデリングの上位入賞者が不一致だったが、最近は両方とも上位にランクされるチームが増えてきた。ただ、そのこととモデリングで高速処理が出来ることを示しているかは別。つまり、同じチームに、モデリングを考えるグループと(モデルは参考にせず)走行スピード検討のグループを設ける作戦もある。それは趣旨に反するだろうけど、少なくとも走行スピードと発表されたモデル(の該当部分)との関連が示されたことは無いように思う。

ただ、モデル(の部分)と走行スピードとの関連を示すのは難しい。ETロボコンでのパネルセッションのモデルを眺めたことがあるが、以前はユースケースの掲示が少なくなかったが、最近はシーケンス図である動作部分のロジックを示す展示が増えたように感じる。パネルでのモデルは、ロジックを示すために利用されていると考えて良いだろう。

モデルのその部分は自動コード生成している/していないはあるかもしれないが、実際の組込み開発でも良く目にする事項だ。つまり、走行スピードに関するソースコードの全部分とモデルの全部分が無いと2つの関連を示すことが出来ないが、モデルで100%コード生成してるとは限らないしモデリング100%が唯一無二でもない。

個人的には上で書いたような必要部分のみをモデリングしているのが実際的だろうけど、せっかくロボコンとして大会を開いているのなら、モデリングの割合などの統計を取っても良いと考える。あるいは、モデリングと走行の相関性を掘り下げたり、モデル→ソースや実際の走行状況の追跡を行っても良いと考える。

後の方に書いたのは結構労力が必要かと思われるので、実現は難しいだろう。しかし、せっかくの節目なので、今までのETロボコンを総括するような語論はあって良い。


追記:オージス総研のETロボコンレポートで、関連しそうなことが書かれていたので紹介。

http://www.ogis-ri.co.jp/otc/hiroba/Report/ETRobocon2012/ChampionshipWorkshopReport/index.html

2013年に向けて「キレイなモデルを評価するのはおしまい、手垢にまみれたモデルを期待」とある。

2012年は、完走率が悪かった。原因を照明とする意見が多い。また組込みならそれへの対応は当然だろうとの意見すらある。ただ後者に関しては、モデリングとのバランスで致し方なかったかも、というのが個人的な感想でもある。後追いでは誰でも言える。また、後になっての要求事項追加のように思えてしまう。

蛇足だが完走率が悪かった原因が照明であれば、それに早期に気が付かなかった大会関係者や、その対応が出来なかったことは反省として述べるべきだ。オリンピックなどだと、風速によって”追い風参考”の記録となるが、あんな感覚が欲しい。今まで大会会場では、マイクで何度も、フラッシュや赤外線の距離計測カメラは使うなと述べている。意識はあったはずだ。今後は、大会向けの”標準”マシンでコースや状況の確認を行う検討などに結びつけて欲しい。(その上で、リスク発生度を大会規定に明示されるのがよい。)

本レポートに書かれている審査委員長の弁は、完走率の低下などに絡めたものだが、今まで再試行とか方法の変更など組込みらしいモデルというか対応説明のパネルもあったように思う。その意味では、委員長の弁は一歩踏み込んだ方向性を示していて良いことだと思う。個人的に、さらに今回書いたようなコード自動生成との絡みやモデル利用率などにも、言及/総括して欲しかったというのが感想である。

2月 15, 2013 ソフトウェアテクノロジーETロボコン | | コメント (0) | トラックバック (0)

2013年1月15日 (火)

日本最古のレール(高尾駅) 見つけた

以前「日本最古のレール 高尾駅」で日本最古の国内製造のレール探しの事を書いたけど、今日見つけた。偶然、登山でのバス発車まで時間があって、本件を思い出した。

P1011691P1011692P1011693レールの色が他の所と違ってて、すぐに判明した。やはり、前に聞いた(と思った)柱番号と1つ違って24。以前も一応その時も周りを見たんだけど、、、。以前は、日本最古の掲示がなかったのか?? 

それはともかく、探し物の時はもっと回りを注意すべきなんだなとか、今日は幸先良いぞとか思った。


ちなみに、JRの改札口からほぼ正面で、そちらからもレールというか柱の色が違うのが分かる。

1月 15, 2013 技術電車テクノロジー | | コメント (0) | トラックバック (0)

2012年11月27日 (火)

駅での地図が立体的になってた

今日、都営地下鉄の駅だったと思うけど、改札出てからの地図にちょっと感激。ビルがそれなりの高さで表示されてて、東京ドームでのテント屋根の様子もそれなりに分かる。公園も池の様子が詳しくなったように感じた。平面地図ではなくて、ちょっと立体的。「へー、ここまで分かりやすくなったんだ~」と感心したけど、別の駅では従来の平面的な地図で、順次変えたりお客から問い合わせの多いところを対策しているのかも。(他も同様だろうと撮影せず。機会あったら、撮影したものを補足で追加したい。)

で、以前からこれらの地図は立体的な方が分かりやすいとは思っていて、”坂”が表現できれば良いのに~は気にしていたこと。等高線で示すと坂は分かるんだけど、それは分かりにくいというか専門的。土地が高くなっていることをシンプルに分からす表現方法があるか、、、、。目的地に行くのに、いくつかあって、近いと思ったけど上り坂だったということは何度か経験している。これが車いすの人だと、行き着けないとか怪我の発生の可能性などもある。

今日見かけた地図の影響もあって、少し本格的に調査。すると以下のページを発見。

「地図で、坂道だと分かる表記はあるのですか?どこが坂道部分と分かるにはどうしたらいいでしょう?」
http://oshiete.goo.ne.jp/qa/6074917.html

ミシュランの地図ということでホームページに行ってみた。
http://www.viamichelin.com/web/Maps

Photo_2青色の”>”が坂を示しているようだ。

ほんとは、日本だと地形が分かるから良いな~と思ったけど、細部の日本地図には行き着かないみたいだ。

前述のoshieteだと、勾配に3種類あるように書いてあるけど、他の種類はすぐに見つからなかった。>の間隔で、勾配が分かるのかも知れない。

なお、以下のような特許申請もあるのを考えると、坂の表現は工夫しつつあるのかも知れない。
http://www.patentjp.com/06/R/R100083/DA10063.html

ただし、”→”の利用は、一方通行と重複しそうで、地図表示では利用は難しそうだ。(既にGoogleマップでは、一方通行で→は表示される。ちなみに、Googleマップでも高いビルはほんの少し立体的に見えるようにしてある。)

駅近くの地図があったら、立体的なそれになってるか、坂表示があるか注意しておこうと思う。坂表示はずっと先というか、今後も実現されない可能性が大だけど。


11月 27, 2012 電車テクノロジー | | コメント (0) | トラックバック (0)

2012年10月17日 (水)

趣味の世界の技術革新

技術系会合の後の情報交換会・懇親会で、話題となるのが趣味の世界での”情報”などの技術の浸透。”情報”分野だとIT技術といっても良いだろうけど、ITと言うとエンタープライズ系とも捉えられちょっと違う。

案外というと変だけど、素材関係の進歩もすごい。防寒や防水、軽量化のための素材が進化している。ゴアテックスは結構昔から有名だけど、軽量化や発汗への作用などきめ細かくなっている。登山向けのシューズの紐で使われてるサロモンのQuicklaceもある。Quicklaceは非常に頑丈な糸(?)でペンチとかでないとちぎれない。ストッパーを使って結び位置を調整する。軽量化の最たるものは、カーボン。自転車のフレームなど色んな所で使われている。

ちなみに、技術記事としてネット記事とかの登場が少ないのは、同じ趣味でないと興味をそそられなくて読者数が少ないとの読みかと思う。また、書き手がその趣味でないと書き辛いし、仕事と趣味は別との考えが普通なので仕事に趣味の話を持ってくる抵抗感はあるのかもしれない。さらには、学校の先生などの教える立場となると、さらに扱うのに気が咎める事もありそうに感じる。これは、情報分野もそうだし、素材などもそうだと考える。

さて、情報分野の趣味分野での利用の筆頭は、GPSやランナーチップの利用だろう。

ランナーチップは、マラソン大会などでランナーが靴に装着してレースを行う。特定の箇所にマットを含めた計測装置を置いて、そこでの通過時間を各ランナーごとに測定する。関門での通過チェックや、(号砲からでなくて)スタート位置からゴールまでの実時間(ネットタイム)を計測して、参考として結果に記載することも行われている。計測作業の効率化に繋がっているし、大人数の大会開催にも役立っている。

ランナーチップは、マラソン大会以外でもトライアスロンやオープンウォーターの水泳大会でも利用されている。以下で、ランナーチップの形状や機能などが一覧で表示されている。

http://runnet.jp/runtes/chip/

で、GPS利用の件。以下のNike+は、有名。スマフォなどを一緒に持ち歩いて、走ったコースなどを公開できる。


http://nikeplus.nike.com/plus/products/gps_app/#get_the_software_section

知り合いなどからその人のコースなどを教えてもらって見ることは多いけど、ここで書こうとサンプル的なものを探したけど、すぐに見つからず。身近な人へ公開とのケースが多いからだろう。とりあえず以下辺りを参考のこと。

http://www.yuznak.jp/yodan/blog/2012/07/29/nike-run-club%E3%80%80%EF%BC%94%E5%9B%9E%E7%9B%AE/

他のGPS利用のソフトなりサービスでも同様だけど、コースや高低差、スピードなどを表示してくれる。

Nike+のシューズに付けてiPodやiPhoneで情報を蓄積するもの。

Nike以外の靴でも可能かと思われたが、Nike+の靴は、このチップの取り付け用のくぼみがあるそうだ。他のメーカーにはないし、サードパーティから他のメーカー用のための(靴のベロなどに付ける)グッズも出ているようだがやはり誤差があるようだ。(Nike+の靴でも誤差は多分発生するだろうけど。)

Nikeにあるなら日本のメーカーにもあるかもと調べたら、アシックスのサイトに以下があった。


http://www.asics.co.jp/running/myasics/

こちらもiPhone向けのアプリなどを用意してある。

さらに、アディダスの動向を調べたら、”miCoach”なるものがあり、心拍数や距離などを計測するようだ。

http://adidas.jp/mi/micoach/product/aboutmicoach/

サッカースパイクへの応用が、以下や日経エレクトロニクス 2011年11月14号に書かれている。

http://www.dgfreak.com/blog/2011/10/20111025adizero-f50.html

”miCoach”をユニフォームに付けて、公式試合で利用することになってるという記事が以下。

http://pc.nikkeibp.co.jp/article/news/20120416/1046167/

どんどん進化しているといった感じ。ただし、選手の位置なども分かるのかと思ったが、(勘違いかも知れないが)それは無理みたい。また、そこでのデータが一般に公開されていないのかと調べてみたが見つからなかった。一般の人達でのmiCoach利用のログも同様。一般の人達の利用ログはあっても良さそうだが、そちらも見つからない。位置情報と比較すると、見栄えなどが無いことや相対的に普及していないのかも知れない。


旧来の教科書や情報家電などでの情報分野の利用からは、なかなか発想しづらい分野なのだろう。特に日本人としては。スマートフォンなどで”遊ぶ”みたいな発想がないと、これら趣味での情報化の製品やサービスの提供を思い付かないと言える。何となく、そんな発想の貧弱さが、これらの分野での情報化に立ち遅れた理由かもと思うこの頃だ。

10月 17, 2012 スポーツソフトウェアテクノロジー | | コメント (0) | トラックバック (0)

2012年6月29日 (金)

JAXA見学

今日は、技術士会情報工学部門部会でのJAXA(宇宙航空研究開発機構)見学。相模原キャンパス。「はやぶさ」帰還後の公開時に自転車で門の所まで行った所で、場所的には馴染みにあるところ。

P6290414今回は自転車というわけには行かず。相模大野などからのバスにするか淵野辺駅からのバスや徒歩にするか悩んだけど、電車の接続が良かったこともあって結局淵野辺駅からの徒歩にした。

淵野辺駅の改札出ると、結構大きめのはやぶさの掲示。

P6290415P6290416JAXAまでの道なりに、衛星の写真など。そんなに数は多くなかったけど、道標になった。

P6290423P6290424棟のエントランスの左右。映画のポスターが飾ってあった。

部屋に集まった後は、2つに分かれて見学コース。係の人が説明してくれた。(当初予定されてた燃焼実験棟の見学は取りやめに。)

P6290418P6290421P6290425P6290427P6290428見学時の写真。

P6290430P6290431P6290432P6290433見学時の写真、その2。結構昔のロケットや設備の展示もあって、当時の苦労などが偲ばれた。熱気球などロケット以外の展示もあった。

写真での右端は、見学の少し前から個人的に興味を持った「あけぼの」。もう20年以上飛んでいる衛星。

見学の後に、講演もしてもらえた。計算工学センターの人。JEDI(ジェダイ)と聞こえた。

シミュレーションやスパコンの話が出て幅広いと感じた。逆に、話を聞きながら、ロケットのプロジェクトとの関わり合いがずっと気になっていた。つまり、組織的には燃焼とか色んな部門があって研究開発してる。ロケットのプロジェクトは、ある意味それらの組み合わせ。Q&Aの時間に聞いたら、(自分の理解では)ロケット側のプロジェクトマネージャーの依頼でシミュレーションやソフトウェア品質保証(改善)を行っているようだ。

Q&Aでは、他にもいくつかやり取りがあった。今回講演もアテンドできて良かったと思う。やっぱ現場の人の説明やQ&Aが出来たことは貴重。

帰りしなにちょっとしたグッズを頂戴した。衛星「あかつき」のシールなど。幹事さんと馴染みの方の計らいのようだ。


その後、淵野辺駅から少し離れたところで情報交換会。というか宴会。他部門の方とかいて、貴重な話も聞けて有意義だった。日本のノーベル受賞者2,3人の方のちょっとしたエピソードなどが聞けたのは、面白かった。なお、その後は有志で淵野辺駅近くで2次会。

jAXA見学、情報交換会と充実した半日だった。


補足:後で調べたら、2,3年前のクリテイカルソフトウェアワークショッフ(WOCS2009)でのJAXA講演の中の一人もJEDIの人だった。


6月 29, 2012 科学技術テクノロジー技術士 | | コメント (0) | トラックバック (0)

2012年6月 7日 (木)

東京スカイツリーの成長曲線

東京スカイツリーが営業開始して、しばらく経ったが、自分の属するコミュニティで東京スカイツリーの耐震や建築確認申請の変更などが話題となった。特に工事中の610mから634mへの変更。

で、その関連で調べていたら、公式とも言って良いページに日付とツリーの高さが記載されていた。大林組のページ。

http://www.skytree-obayashi.com/pointview/index.php?point=1

ビルの高さも、ある意味では”成長曲線”。普段ソフトウェアの世界での信頼性曲線のことは気にかけているので、それとの対比してみようと考えた。日付と高さを表形式にしてグラフ化したのが以下。

https://docs.google.com/spreadsheet/ccc?key=0At5_RJyc2TPhdEZlUXB5R21TRE8yMFpsOHQtVzJmVUE

多少意見あるだろうけど、一次曲線に近い。心柱作りや上部のアンテナ鉄塔引き上げでも、高さが急成長していないように思える。高精度が要求され、当初からの想定だったのかもしれない。

また、2010年の6・7月では高さ成長がストップている。これは(多分)、第1展望台に関する工事とさらに上の工事のためのジャッキなどに関する工事が関係したのだろう。


以前、本ブログでバグカーブ 対数曲線や二次曲線での近似のお勧めを書いたけど、高さや信頼性をコンスタントに成長させる意識の方が考え方として適しているような気がする。成長曲線になったりするのは、あくまで結果との割り切りの方がよいだろう。ふとそう思った。

6月 7, 2012 日記・コラム・つぶやきソフトウェアテクノロジー | | コメント (0) | トラックバック (0)

2012年4月21日 (土)

コンビニでA3スキャン

自炊/他炊で少し悩んでいるものはいくつかあるが、A3サイズのスキャンもその一つ。本とかなら他炊でのサービスを行うところも少ないものの存在するが、プリントしたりのシートタイプの扱いが悩みのタネ。手ごろな価格では、自宅のがそうだし、一般的な家庭用向けではA4サイズが最大。なのでスキャンできずに残ってた。折りたたんでスキャンした後に接合する機能があったりするけど、その後の文字認識精度などで使うことは限定的になってる。

ちょっと都内ならスキャンサービス店があるようだけど、近くの横浜のFedなどではやってないようだ。昔みなとみらいのTSUTAYAでやり出したニュースを目にしたけど、最近は案内から無くなっているようだ。また、印刷を意図したサービス店もあるようだけど、ネットも含めて遠い所がほとんどだしそもそも価格がべらぼうに高い。

ドキュメントの整理でA3でスキャンすべきものが溜まってきて、そろそろとの意識で再調査。すると、コンビニでスキャンできるところがあると出てた。サイトによってはファミマでもやってるとの記載も。ちらっとセブンイレブンでのサービス方法を見て、今朝早朝に散歩がてら出向いた。(早朝でなくてても良かったんだけど、最初の利用で操作に手間取ったりしたら悪いと思ってのこと。)

近くのファミマでは、スキャンがメニューに出てない。稀にコピーで利用してメニューで見かけたこと無かったので、案の定との思い。少し離れたファミマでも同様。で、その先にセブンイレブンがあったので、そちらへ。メニューに出ていて、ラッキーとの思いだった。ちなみに、セブンイレブンでの、スキャンサービスに関するページは以下。(「詳しい操作」を事前に読んどけば良かったと後になって感じた。)

http://www.sej.co.jp/services/scan.html

最初どこにUSBを差すのか分からなかったけど、マルチコピー機の隣上にPCのようなのがあり、DVDやUSBの差し込み口群にプラスチックカバー。開始して確認などを操作すると、そのカバーが動いてUSBなどを差せるようになってる。後は画面に従って操作するだけ。最後に縮小的なイメージで画像を確認できるのも良い。完了でコイン投入して、USBを抜いたらまたカバーが動いて差し込み口群に被さった。

ちなみにPDFにしたけど300dpi固定だったと思うし、OCR機能は処理されてなかった。画質とかはまっそんなもんだろうといった感じかな。(自分の今回のは、A3の16ページで27MB。) むしろ個人的には、A3での折り目を元に戻すようにしたり少し厚めの紙などと一緒に押さえとけば良かったかなと反省。

他に思ったことは、、、。
・ADFじゃないので、ちょっと手間。まっ、こればかりは仕方ないかな。

・1ページ読み取った後の画面操作で、読みとりOKで「これで設定」ボタンが表示されて、その次に継続しようとすると同じ位置に同じような色で「これで設定 終了」といったボタンが表示される。連続してスキャンする時に、つい終了をタッチしそう。後者でのボタンの位置などは工夫が欲しいかな。

・画像を確認したら、定位置に霞んだような何かが。ガラスが綺麗になってなかったようだ。USBなどの媒体と一緒に拭くためのものを持って行った方が良いかなと思った。ひどくはなかったけど、その後でのOCRなどの修正の手間などに影響する。


いずれにしろ、A3スキャンは目処が立って一安心。

4月 21, 2012 技術ソフトウェアテクノロジー電子ブック | | コメント (0) | トラックバック (0)

2011年9月 4日 (日)

がっちりマンデー! 模倣防止のためのダミー

今日のTV番組「がっちりマンデー!」は、(技能工での)すごい人がすごい人を教えるシリーズの葛飾編。その中での2番目か3番目に出た人は、ゴム作りの人。

ゴム作成の過程で、練り機(?)の中に白っぽい板のようなものを入れていた。職人の杉野さん(社長)が”ダミー”と言っていたが、模倣されるのを防ぐ目的で入れているとのこと。

で以前から、分析装置が進歩しているので、成分分析などが容易に行われる時代になったな~とは感じていた。しかし今日のTVのシーンを見て、最終的な成分の分析は行えても、触媒や製造過程での中間生成物は分からない/分かりにくいと改めて思った。つまり、ここでの“ダミー”を入れるのは有効と。しかも、この”ダミー”は、模倣を攪乱するために工夫も行っているのだろう。やはり、すごい。

なお、このような”ダミー”の考えを、ソフトウェアの耐タンパー性の向上に利用できないかと、ふと思った。特に製造過程での細工のようなこと。でも、思うに化学反応とは異なり、ソフトの場合は変化しないから難しそうに思える。やはり、プログラムの上書きとか、実際は動作しない部分も入れておくなどの従来型の方法程度で良いのかもしれない。(逆にあまりに工夫しすぎて、実際の動作が不安定になると本末転倒だ。あるいは、特許や著作権による保護などと一緒の検討が良いのかもしれない。)


補足:番組内容の概要を、以下で見ることが出来る。

http://www.tbs.co.jp/gacchiri/archives/20110904/2.html

9月 4, 2011 映画・テレビテクノロジー | | コメント (0) | トラックバック (0)

2011年8月11日 (木)

iPadでの音声認識ソフト

一昨日、iPadにお試し的に音声認識ソフトをインストールしてみた。ひどくないというか、そこそこ使えそう。自分のデスクトップPCだと、音声認識のためにはヘッドセットを取り出して接続が必要で、ちょっと面倒。しかも最近は、閲覧のPDFファイルやメールをiPadで見ることが多いので、メモ的なものはiPad操作の際に多くが発生する。メモを音声認識で残せれば便利と考えて、お試し的にインストール。もう少し早めに気がつけば良かったのだが。

ただし一昨日試したのは、クリックで一挙に変換結果が表示されるタイプ。逐次表示のものとかが自分には合ってそうとのことで、今朝物色。良さそうなのが見つかり、さっきダウンロード。「音声認識メールST(3GS以上専用)」。

http://itunes.apple.com/jp/app/id347250830?mt=8

ソフトウェアのタイトルだとiPad向けに思えないが、条件などに記載してあるようにiPadでも大丈夫。また、以前は115円していたようだが、今は85円。(「音声認識メール クラウド」の方が機能が充実してるようだが、オフラインでの利用もあるし何日かでの利用更新も気になったので、ST版にした。)

音声認識の機能は、思ったよりも素晴らしい。もっぱら連続入力のモードで利用すると思う。文の区切りで認識結果が出るので、それを多少確認しながら次の文を入れるやり方だ。多少、そのための効率落ちるけど、その都度の修正とかができるので自分には合ってる。

また、Evernoteとの連携が可能なのもメリット。デフォルトのノートブックに、認識結果のテキストを置ける。他のアプリもデフォルトノートブックへ置くので、ちょっとEvernoteのデフォルトノートブック名を変更した。 他にTwitterへの投稿なども可能だ。

8月 11, 2011 パソコン・インターネットソフトウェアテクノロジー | | コメント (0) | トラックバック (0)

2011年6月23日 (木)

IBM100周年ビデオでの「ブルックス」

先週だったか、日本IBMに行った際のロビーで目に付いたのが、ブルックス。IBMのシステム360システムの開発マネージャであるが、「ソフトウェア開発の神話」「人月の神話」の著者との方が馴染みがあるかもしれない。(「人月の神話」は、「ソフトウェア開発の神話」の改訂版。)

その際にちらっと見たのは、上司になるボブ・エバンスが、意見の対立した彼をメンバーに含めるくだり。

今日、もしかしたらYouTubeにアップされてないかと調べたら発見。まださらっとしか見てないが、360システムの次には、飛行機の予約システムSABREに関するインタビューもあるので、いくつかのシステムが取り上げられているのだろう。

プロモーション的なIBM100周年のビデオも見たが、技術屋さんにはこちらの方が面白いような気もする。土日に、じっくりと見てみようと思う。

6月 23, 2011 ソフトウェアテクノロジー | | コメント (0) | トラックバック (0)

2011年6月14日 (火)

テレビ データ放送での水位

この所、雨の強い日があったりするので、ちょっと気になってテレビのデータ放送で水位を確認しようとしてみた。

と言うのも、先々週から鹿児島に帰省して、その際に何気に操作したら、データ放送で河川の水位が表示されたため。てっきり関東のデータ放送でも見ることができると思ったら、メニューに見当たらない。鹿児島では、多分NHKG。念のために、関東の民放とかも見てみたけど無かった。

なお鹿児島でのデータ放送で結構以外だったのは、河川の水位を定常との変化量で表示しているところと、標高というか高さそのもので表示しているところがあった点。30なんメートルと出たので、結構驚いた次第。しかも1つの河川で混在している。個人的には、定常との変化量で統一すべきかと思うんだけど。ちなみに知り合いに聞いたら、気象庁管轄と土木事務所管轄が混在してるのが理由かもしれないと言ってた。ただし、知り合いも的確に知ってる風でもなかったけど。

放送局なり地方で、データ放送での細部になると色々違ってるんだと改めて認識した。また、それぞれの局でシステム化等を行う必要もあり、負担になってるんだろうな~とも思ってしまった。

6月 14, 2011 映画・テレビテクノロジー安心・安全 | | コメント (0) | トラックバック (0)

2011年5月19日 (木)

注意報や警報の情報

今回の震災に関連して色々調べて、利用してはじめたサービスに「横浜市注意報警報情報」がある。横浜市では、同報系防災無線の設置が見送られているのも理由。

最初は、近くの川が気になって水位の警報程度のみを受信するようにしていた。ところが、雷などを含む注意報も受信しようと設定を変更。最近ほとんどの注意報/警報を受信するようにした。結構便利なんだけど、できれば、あと何時間くらいで発生するかとか警報に変わる可能性があるとかが判ると良いな~というのが感想だった。少し調べたので、メモのつもりで書いとく。

まず、今日10時での横浜市からの注意報のメール文。他に情報のURLなどがある。

■気象警報注意報情報 2011年05月19日 10時08分発表 横浜市:  強風注意報(発表)


で、気象庁の方はどうなってるかというと、以下のページにあって、結構詳しい情報が掲載されている。(以下のページは、注意報などの発生や解除で更新される。)

http://www.jma.go.jp/jp/warn/1410000.html

平成23年 5月19日10時08分 横浜地方気象台発表

神奈川県の注意警戒事項
 神奈川県では、19日昼過ぎから20日明け方まで強風に注意して下さい。東部では、19日夕方から20日明け方まで高波に注意して下さい。


===================================
横浜市 [発表]強風注意報 
 風 注意期間 19日昼過ぎから 19日夜遅くまで
   南の風
   海上 最大風速 12メートル

特に、いつくらいからがあるのが、ありがたい。(一昨日だったかの雷注意報には、いつからとはなかったように思うので、気象の種類によるのかもしれない。)

これらの情報は、週間の予報や当日とか明日の予報を知って使うのが良いのだろう。注意報が警報の前触れかは、そのような知識が役立つ。


なお、気象庁のページを見て、それぞれの注意報や警報の判断基準などを読んでみたら、自治体などで異なるなど相当複雑。花粉の情報なども、(当然)予測には気象データや気象モデルなども利用している。単に“気象データ”とか”予測”って言うけど、この辺りのコンピュータによる(有限要素法などを利用した)処理が複雑なり多量データなのはご存じのとおり。精度を高めるにはデータのメッシュを細かくする必要があるし、それは計算負荷に結びつく。

注意報の発令をちょっと考えてみたけど、予測を10分後、20分後、、、、等で行い、各自治体毎の基準に照らして判断することになる。項目も風力だったり水位だったりする。各メッシュでのポイントがどこの自治体に属するか判断して基準との比較を行うのだろう。ただし、単純に全メッシュ毎に全予測を行い、全項目の基準との比較を行うと、無駄な処理が増える気がする。多分アルゴリズムなどは工夫しているのだろう。

今まではTVでの天気予報とか花粉情報を目にしたり気にかける程度だったけど、注意報や警報の発令を調べたり市の注意報警報情報サービスを利用してみると、奥が深いな~という感想。紫外線とか人々の予報への要望への対応?もあるし、逆に桜の開花予報のように止めた対応もある。計算の複雑さやその回避に関しては、懇親会などの何かの折りに、詳しい人がいたら聞いてみるつもり。

5月 19, 2011 ソフトウェアテクノロジー安心・安全 | | コメント (0) | トラックバック (0)

2011年5月 7日 (土)

災害におけるIT ~ゼロからの視点~ 3(救助や復興)

災害に対する予報や警報を発したとして、次の課題は、能動的に避難してもらうことだろう。

ただし、結果的に避難が遅れたことの指摘は容易でも、避難する/しないの徹底には大きな課題がある。行政的には”避難勧告”は避難所への強制的な避難命令であるが、地震などは命令の発行やその徹底には時間的な余裕がない。雷や竜巻などは、注意報のような予報は可能でも、避難を命令するまでの時間や避難自体が効果的かとの疑問も発生するだろう。

ちなみに、避難勧告以外に、”避難準備”、”避難指示”もある。前者は老人などの災害弱者の避難実施であり、後者は勧告よりも強制的で罰則もある。

避難勧告等は原則市町村によるもので、防災無線やサイレンや広報車による呼びかけ、そして町内会組織や消防団を利用した口頭伝達などによる。従って、予報や注意報と異なり、情報伝達地域が狭いことになる。(多少極論だが)イメージ的には、予報が全国放送でTVなどにテロップが出るのに、避難勧告などはその市町村でのサイレンや広報車で知ることになる。

ちなみに、以下の放送研究と調査2010年10月号の「避難情報と放送メディア」は、避難に関する放送方法として参考になると思われる。

http://www.nhk.or.jp/bunken/resarch/title/month/2010/2010_10/index.html

ここに書かれているようなデータ放送等の利用や、地域FM放送、あるいは市町村レベルの避難情報の伝達サービスなどは重要である。平成の市町村合併を考えると、合併前より広域の避難情報伝達が必要となっている。避難に関する情報伝達は、防災での最も弱い部分のように思える。システム化も含め今後大きな検討課題であろう。(なお最近は、ちょっとした注意報や避難情報が、テレビでのテロップで出るようになったような気がする。改善されたのかもしれない。ただし、細部までは確認してはいないが、避難準備時点でのテロップまでだすかは? 予測的な情報としてメリットあることもあれば、その後に避難勧告にまで至らないこともあるので避難準備を広く流すことは一長一短ではある。これらの言葉の違いを知っておけば問題は少ないだろうが。)

ちなみに私事のようなものだが、今の住み家は横浜市の外れ。川を挟んでお隣の大和市の防災アナウンスが聞こえる。夕方の時報のようなものから、時々の行方不明者まで。洪水などの時に、果たして横浜市の警報は何処から聞こえることになるだろうと不安になるこの頃である。(なお調べたら、横浜市では以前防災無線に関して議論され、設置されないことになっているとのこと。ここに書かれた配信サービスに申し込んだ。 http://cgi.city.yokohama.lg.jp/shimin/kouchou/search/data/22001411.html )

原則市町村によることでの問題点も考えられる。行政的な僻地というか離れ地の問題である。これは避難時のみではなく、その後の救援活動、避難所生活にも同じような問題となる。

ここでの行政的な僻地は、飛び地のようなものもだが、例えば河川で昔の流れなどで川向こうに同じ行政地区があるようなケースもそうである。川の氾濫などを考えると、川向こうにまで広報車が回れなくなる事態が考えられる。さらには、今回のような震災の場合は、役場機能自体が移転することが考えられ、従来とは異なる避難や救済の方法の検討が必要となる。

また、個人的に少し厄介なことと感じているのは、町内会とか自治会への強制的加入との関連がある。強制加入は違法との判例もあるし、特に都市圏では加入を促すことが実質難しいであろう。その意味でも市町村レベルでの避難情報の伝達サービスは重要となる。(なお町内会や自治会への非加入者の件は、防災備品や救助での対応、一時的な避難時の食料などの利用を考えると、その後の避難所運営にも関連しかねない可能性がある。)

さらに言えば、数年前だったか消防用の半鐘の窃盗が相次いだことがあった。予防策も必要であろうが、防災用設備や防災備品に対する窃盗罪などは厳罰に処すなどのコンセンサスがあって良いと思う。


自主的な避難や避難勧告などによる避難の前後で重要なのが、救助依頼である。今回の震災では、避難所丸ごとでの救助依頼の発生や、電気や通信のインフラの被害、そして役場のような拠点の被害も発生した。救助依頼の情報伝達も、複数の手段を用意したり想定している拠点への連絡が行えない場合をも想定する必要性が増した格好になった。

救助依頼で重要な事は初動、しかも近所のような近くの人への伝達である。そのことを踏まえて、どんな情報伝達があるか、ゼロスタートで思いつくままにまとめてみた。以下では、不正確な情報や主観的なことも記載しているので注意。

https://spreadsheets.google.com/spreadsheet/pub?hl=ja&hl=ja&key=0At5_RJyc2TPhdG9HMldYX290N2xlTG5KMzZnQnR1OXc&output=html

なお、表には伝達手段のシート以外に、想定すべき状況も記載してみた。全ての状況へ対応できてコストも安く仕上がる手段には限界があるだろうが、例えば避難所の備品などの検討は必要と考える。(横浜市の避難所の備品に関するページでは、関連しそうなものとしては投光機がある程度である。ただし当然ながら、投光機の本来の目的は夜間作業の照明のため。これらは電話等での連絡が行える前提だから仕方ないが、今回の震災を教訓に一工夫すべきと考える。) 

これらの情報整理と今回の震災を考えるに、情報伝達手段として”音”と”光”は重要であると思える。物理的に2つは似てはいるが、収束性(集光性)との観点で音は制御しにくくて、光の方はレーザのように極端に集光するものは救助では短所にもなる。手に入りやすい事を踏まえると、自転車や登山用のランプ、防犯ブザーは有効に思えてきた。

GPSによる緊急通報位置通知に関しては、携帯電話への搭載や防災システムでの利用がTVに取り上げられたりしたが、今回の震災で有効に機能したニュースをあまり聞かない。そもそも携帯電話の通話やネット接続自体が困難だったのが大きな理由と思われる。

なお、今回の震災では、一般市民の水上バイクによる救助のことやアマチュア無線による連絡などもニュースになった。後者は地方によっては、”アマチュア無線非常通信協力会”という組織もあるようだ。アマチュア無線本来の意図との兼ね合いとの細部の調整が必要なケースもあろうが、防災での情報伝達では念頭に置いておくべきと言える。また、水上バイクの例にもあるように、趣味の世界が役立つことも少なくない。避難所での登山者のノウハウは役立ったと思われる。これらも上手く活用できるようにしたりできるようにする工夫も必要だろう。


その次のフェーズでは支援物資など、復旧や復興に向けた情報伝達が必要となる。今回の震災では、通信インフラの被害もあったり、自治体自体が避難したり場所が移ったりした。またニュースなどによると、物資が地域により足りている(余っている)所と足りてないところの差が激しかったことと、品目でのばらつきが大きく必要な品目は足りない状況もあったようだ。前者は、地域間もそうだが、県レベルでは届いているのに、市町村まで行き渡っていないなど。交通インフラの損傷もあろうが、支援物資情報の管理や伝達・運営方法の問題も大きくなかったと思われる。

・防災時のための品目コードとかがあると便利に思えた。あるんだろうか。また、実際に活動できるかは未知数だが、サービスなどもコード化した方が良いだろう。

食料品と言っても、非常に種類が多い。非常食でも固形的なものからご飯系などもある。品目をいくつかの階層に整理するだけでも、物資の欲しい所と集計するところの情報共有が行いやすい。また、食品に関しては、食物アレルギーの人への配慮も重要である。場合によっては、それらも明示的に品目コード化しても良いかと思われる。

サービスには散髪とか入浴などが考えられる。瓦礫撤去などもそう。行政自体での提供は難しくても、自衛隊とかボランティアへの依頼などを直接/間接的に行えるようにしておいた方がよいだろう。(阪神淡路大震災や中越地震の際の婦人警官による活動や今回の震災での女性自衛隊による”御用ミッション”などの話を聞けば、サービスや品目コードを明確にすることで頼みやすいなども起きてくると思われる。)

・要請情報の管理を行わないと、2,3週間後に(もう)不要になった品物が届くことも考えられる。言わば注文とキャンセルを、要求元と集計側で情報共有できる必要がある。手配中や継続検討とか却下の状態が識別できるべきだし、100個のうち50個は届けたなどの進捗なり達成率のような把握も必要になるだろう。

なお、要求元は避難所であったり自治体であったりするが、集計側は都道府県の場合が多いとしても、都道府県自治体以外の場合もあろう。医療品などのように、特定商品で無いと不都合なものや専門的な知識が必要なものもある。

・復旧や復興に関しては、多くの組織体が関係してくる。例えば、ボランティアの受け入れ窓口を、社会福祉事務所にするケース。協会とか委員会といった名前の組織体もあるだろう。

これらの組織体は各自治体毎に存在するケースが多く、他の自治体に属する団体との連携や情報共有が進んでいないケースが多い(と思われる)。市町村での情報を県単位でまとめるなどの情報共有も必要であろう。また、自治体との連絡や連携が、災害時に迅速に行われているかも疑問である。情報ネットワークという意味では、自治体とこれら事務所や協会との情報共有に関係する。定常時はメールなどで十分だろうが、災害時の担当者の死亡や行方不明まで考えると、MLやSNSのような手段を考えるべきではないだろうか。

・自治体自体が震災に遭遇した場合の、救援や復興のための情報通信のあり方は大きな課題となる。特に今回の震災では、いくつもの自治体で発生し、戸籍や住民台帳がデータとともに消失したとのこと。(調べると、どうやらバックアップのデータは無事だったらしい。)

それらの情報のリカバリや、そもそもの(暫定的な、最低限の)システム構築が必要となる。今回の震災では、いくつかのメーカーからクラウドサービスの無償提供などもあったようだ。これらの活用は今後増えていくかもしれない。また、通信インフラの損傷の場合での通信方法の確保や、場合によってはシステム運用の場所を別途確保するなども必要かもしれない。

避難所間の情報共有(特に行方不明者の検索)や、自治体間の情報共有のあり方も課題となろう。その際の大きなネックが、特に前者の個人情報との兼ね合い。番地まで含めた住所とフルネームの方が情報の信憑性なり確実性は増すが、悪用の懸念がある。今回の震災では町名とフルネームの組み合わせが、(広く情報を流す場合に)多く行われていたと思われる。

自治体間の情報共有のあり方は、行方不明者に関する情報共有もそうだし救援物資のとりまとめなども、個々の連絡よりも情報共有して進めるべきと考える。さらには、被災自治体への応援などを考えると、自治体間の掲示板のようなシステムも検討しても良いのかもしれない。姉妹都市間のような限定されたものから、多少全国的な自治体を網羅するようなシステムを踏まえたものまで様々であろうが、、、。個人的には、後者のようなものも検討の余地はあると考える。

ただし、大前提となるのは、情報共有は複数の媒体にして情報経路も複数確立しておくべきであるという点。今回の震災では、消息情報としてGoogleのPerson Finderが話題となった。NHKでの「安否情報ダイヤル」情報との連携や、人出による避難所での情報→文字化作業なども行われた。携帯各社の災害用伝言板や災害用伝言ダイヤル、安否情報の登録・確認も広く認識されたようだ。またコミュニティFM局(含む臨時災害放送局)の活躍もあった。(複数の媒体の視点でも、FM放送はラジオ形態なので、聴覚障害の人のことを考えても、TVやインターネットを含む視覚的な情報伝達も必要である。)

さらには、被災者のためのコンテンツ配信(特に著作権絡み)への配慮も必要になってくる。今回の場合は、NHK教育では子供番組の放送は早期に元どおりに行われた。心のケアに配慮してのことである。また、一部の子供番組はインターネットで閲覧できるようにした。著作権絡みでクリアすべき課題もあろうが、このような方法は今後行われていくだろう。


復旧/復興を情報通信の視点で考えれば、インフラの復旧やシステムの再起動になるだろう。言わば定常状態への復帰。思うに、複雑なシステムは社会自体の複雑化やニーズの多様化で必然的と言えるが、災害時の復元となると基本部分や基本機能の復帰が急がれる。その意味では、システム化の際に、必須項目事項だけを復旧できる構成などは考えておくべきかもしれない。必須項目のみの復旧とは、部分的な動作で消費電力を落とすとか、データは一時保存のみ行っておくとか、、、、、。今回の震災を期に、システムのロバスト性を高めたり、その思考を行っておくことは悪いことではない。


また、震災の教訓は活かすべきである。復興宣言などをプロジェクトやシステム開発での”振り返り”と考えれば、救助や復旧/復興のための活動のとりまとめなども必要であろう。政府としては、内閣府であり、白書としては「防災白書」が該当するかもしれないが。ただ、書籍やネット上の情報では、県とかの自治体の方の情報が分かりやすいとか具体的に思える。震災の教訓を、防災につなげるべきだろう。ちなみに、阪神淡路大震災関連として、兵庫県の”神出自然教育園”の震災学習棟には仮設住宅が保存されており教育などに役立てているという。


ここでは、東日本大震災を中心として、災害時のIT(情報技術)、情報通信について考えてみた。単なるバックアップや予備手段の視点より、原点に立ち返っての検討や原始的な情報通信の視点で災害時への対応を考えたつもりである。犠牲者の方々のご冥福をお祈りするとともに、自分の所属するコミュニティなどでの防災検討での一助になればと思う。

5月 7, 2011 日記・コラム・つぶやきテクノロジー | | コメント (0) | トラックバック (0)

災害におけるIT ~ゼロからの視点~ 2(災害種と予知)

今回の震災では地震・津波がクローズアップされているが、そもそも災害って何かと考えてみる。

http://ja.wikipedia.org/wiki/%E7%81%BD%E5%AE%B3

災害対策基本法第2条:暴風、豪雨、豪雪、洪水、高潮、地震、津波、噴火、その他の異常な自然現象又は大規模な火事若しくは爆発、その他その及ぼす被害の程度においてこれらに類する政令で定める原因により生ずる被害

国民保護法第2条第4号:武力攻撃により直接又は間接に生ずる人の死亡又は負傷、火事、爆発、放射性物質の放出その他の人的又は物的災害

と言ったところだろうか。関連する用語や想像できる用語としては、他に、台風、雷、ゲリラ豪雨、テロなどが思いつく。

これらの法律で、少し微妙なのが”感染症”(具体的にはインフルエンザ)。ネットにあるドキュメントや書き込みの類では、大流行すれば災害対策基本法が適用されるだろうとの意見/要望が多いと思う。逆に口蹄疫や鳥インフルエンザなどは、昨年の宮崎の例などでも災害対策基本法には該当しそうにない。(ちなみに、自衛隊の派遣依頼根拠は別法律。またインフルエンザ等は、”パンデミックBCP策定”などで企業にとっては馴染みになってきている。)

次に災害の規模を俯瞰してみる。20世紀以降の国内次元では、地震/津波での被害死者行方不明者は、関東大震災10万人を筆頭に東日本大震災、阪神淡路大震災、福井地震、1933年三陸地震津波と続く。(地震規模は、関東大震災がM7.9、東日本大震災がM9.0。ちなみに世界最大の地震規模は1960年5月発生のチリ南部地震でM9.5。)

http://homepage2.nifty.com/GmaGDW/grw/wdr/wdr007.html#002

発生時刻は、阪神淡路大震災が6時前の早朝、1933年三陸地震津波が深夜2時、三河地震が深夜3時などのように深夜や早朝もある。

なお、損保での保険金ベースの金額では、台風被害の方が大きい。

http://www.sonpo.or.jp/archive/statistics/disaster/

上記だと、阪神淡路大震災の783億円に対して、1991年の台風19号では5,679億円。あくまで損保の保険金ベースであるが、台風による被害も大きな事が分かる。

また、1918年のスペイン風邪では日本でも死者39万人近くが犠牲になっているが、犠牲者数としては関東大震災の4倍近いことは特筆に値する。他に1934年の伊勢湾台風、1945年の枕崎台風、 1959年の伊勢湾台風は、3千人、4千人弱、5千人といった死者行方不明者を出しているし、1963年豪雪での死者231人など地震以外の犠牲者も少なくない。

ちなみに、38豪雪(1963年豪雪の俗称)の国鉄による記録映画が、ニコニコ動画にアップされておりURLを紹介しとく。「豪雪とのたたかい」。ちなみにURLは、その前半。

http://www.nicovideo.jp/watch/sm5257212


これらを考えると、防災のためには各防災に対する予知能力を高めて、的確に国民に通知する必要がある。ただし、具現化するとなると結構難しいポイントも浮かび上がる。

・災害の種類が多彩。それぞれの予知方法の確率や予知能力や精度向上。

台風は2,3日前にはある程度の予報が出せるが、地震となると数秒程度前の警報発信がやっとである。竜巻やゲリラ豪雨のように、予報としてはまだまだ課題の多い分野もある。

・予知のロバストネス化。

今回の地震/震災で特徴的だったのは、地震観測地点すら被害に遭っていたこと。また、地震計の針が振り切れてしまい、震源地や規模の予想の手間取ってしまったようだ。それにより津波の予想も的確にできず、目視での情報をもとに津波の高さなどを補正したらしい。

(釈迦に説法だろうけど、震源地とかはいくつかの観測地での揺れのデータをもとに推定することになる。そもそも観測地での揺れデータが無かったり結果的に不正確な値なら、予想も狂ってしまう。ちなみに、海外からのデータなど参考にして予測値を補正する処理には時オーダーの時間がかかるらしい。また、11日の14時46分以降の30分間に震度5弱以上の地震が計8回起こっていたと4月に発表があった。それくらい解析には難しい面があったり、時間がかかるという認識は必要だろう。個人的には、コンピュータ能力も気になってしまった。)

今回の地震では、福島県の「おおたかどや山」標準電波送信所が被害にあって、電波時計など向けの電波の送信が停止している。福島原発の近くということもあって、すぐには復旧しそうにない。佐賀にも同様の電波送信所があるとか、最近の電波時計はどちらの電波でも受信できるタイプが多く、時計自身の自走もあるので、大きな問題にはなっていないようだ。(おおたかどや山の送信所は、一時復旧したが、4月下旬に落雷で停止したとのこと。)

また、福島原発の事故の際には、放射線量の測定時に針が振り切れてしまって慌てて引き返した事も発生した。さらには当初から放射線計測機器に被害が発生して、モニタリング自体が不能に近い状況になっていた。

これらのことを考えるに、そもそも(複数用意していたとしても)計測ポイントが欠落することや、それに応じたアナウンスなどの方法も検討が必要である。ざっくばらんな言い方をすれば、計測できないほど被害がひどいことを述べた方が避難等に有効になるかもしれない。(パニックに陥ることを避ける必要はあろうが。) ちなみに、今回の原発事故では離れた箇所での計測や海外での観測データが役立っていることを考えれば、放射能に限らず、洋上や大気中を含めた計測データ収集は今後必要性が高まるだろう。

また計測ポイントの複数化の見直しや、計測機器に対するエネルギーや通信手段の複数確保なども課題となるだろう。

・多岐な警報発信の必要性。

従来から、これら警報は、複数の媒体での提供が普通である。TVばかりでなく、自治体による防災警報や携帯電話などのような技術革新に応じての対応も必要となる。(昨今でのこの類のシステムでの代表は、J-ALERTと呼ばれる消防庁による全国瞬時警報システムかもしれない。ちなみに、J-ALERTの導入当初のトラブルに関しては、日経コンピュータ2010年4月14日号「動かないコンピュータ」のコーナーに詳しいので参考になろう。また今回の震災発生は3月で、J-ALERTを4月から導入する予定だった自治体も少なくなかった。さらには、震災後も自動転送にしていない自治体もあるようで、それらを含めての考察は必要と考える。)

今回の震災では、携帯電話が通じなかったり基地局や自治体ですら被害になっているケースもある。それらを考えると、さらに強固な連絡方法や多重の手段を講じておくべきである。

・多岐な警報受信。

視覚障害や聴覚障害の人たちへの手段も用意すべきだし、電波の届かない状況での対応も検討が必要である。一般的には電波が届かないケースは少ないと思われるだろうが、例えば劇場とか試験会場で携帯電話が電源Offになっているケースなどがあり得る。2011年地デジ移行ではTVの映らない家庭が一時的には増えるだろう。また、今回での電話基地局の被害を考えれば、TV電波中継局の(例えば落雷などによる)被害を想定しておくことは悪くないだろう。 (注意:4月20日に、震災3県の地デジ移行は先送りする方向になった。)

一方で、警報受信のために(更に)多くの機器が必要になることは、国民にとっては芳しくない。TVに地震や台風の情報が映るように、警報装置や携帯電話での通報サービス、いろんなタイプの警報が受信できるなどは検討すべきと考える。

5月 7, 2011 日記・コラム・つぶやきテクノロジー | | コメント (0) | トラックバック (1)

災害におけるIT ~ゼロからの視点~ 1(概要)

今回の東北地方太平洋沖地震の都内での実体験や、東日本大震災に関するニュースなどを目にして、災害時の情報伝達に関して考えさせられる事項が多かった。自分の参加しているコミュニティによっては、安心・安全や防災が話題となる頻度の高いものもあり、東日本大震災でのIT(情報技術)に関することを、ちょっとまとめておこうと思う。

阪神淡路大震災の際には、電話よりもインターネット利用の方が通じやすかったとの話もあったようだが、今回の自分自身の実体験やその後の計画停電での現象を考えると、インターネットも脆いという気がしている。さらには、今回の震災でのTwitterの有効性などが挙げられている。しかし一般的な話題なら理解できるが、Twitterの安定性も含めて考えないと防災レベルの議論としては不十分に感じていた。


なんでそんな感覚になるのかと考えていたら、少し判った気がしてきた。つまり従来の防災なりリスク管理だと、迂回策やバックアップ切替の話が主。ところが、今回の震災では、迂回手段などがばっさり断。そもそも電気が通じない。昔の電話なら電気が通じなくても通話できたが、最近の機種は電気利用タイプが多いし、そもそも電柱など倒れて電話線自体も断線。携帯電話も、基地局が流されたり、トラフィック急増での通話制限や停止措置が発生した。さらには、避難所や自治体の公舎すら被害にあったり、住民や患者の貴重なデータも無くなったこともあったようだ。そして、計画停電のように3時間も電気が途絶え、簡単な無停電電源装置では対応不可能な状況に陥った。

復旧や対応では、迂回策での対応を行うというよりも、一から構築するイメージに近いと感じた。ジクソーパズルだと、2,3個のパズルが欠けたのと、大部分が欠けてしまったのとの違いのような感覚。

警報通知・救援・避難・復興のための、ITなり情報通信のあり方を再考した方が良いかな~という気になった。しかも、従来のネットワークをベースにおいてのIT議論より、もっとプリミティブな方法から再検討した方が良いとの考えるようになってきた。

まとめ方として伝達媒体毎に括る方法もあるかと思うけど、当初、警報通知→復興のような時系列に近い方が分かりやすいかと考えた。もちろん、1つの方法がいくつもの状況に適応できることがあるので、大まかな流れでの分類といった感じ。また、これは(多少こじつけかもしれないが)マズローの要求5段階に、予知や待避を0番目にすることで、関連づけることも可能だろう。
  0. →予知情報入手や待避
1. 生理欲求→救助
2. 安全欲求→治療や避難生活
3. 社会欲求→協同的避難生活
4. 尊敬欲求→以前の日常生活やそれに近いもの
5. 自己実現欲求→以前の日常生活


当初は、災害での情報伝達手段として、救助や救援での情報伝達から考えてみた。しかしよくよく考えたら、警報通知のあり方も再検討が必要と思えてきた。そのために、上のように0を追加。

今回は、地震警報も津波警報も発せられた。東北地方の多くは、避難訓練なども行っている。地震速報については、時々テレビなどで警報に関する試験方法も行っている。それなのに膨大な数の被災者を生んでしまった。地震の規模が想定以上だったとの意見は判るが、再発防止という意味では、より良い警報システムの構築や、警報の受信やその対応での課題を調査する必要もあろう。(ただし、今回は予報のための観測での課題も発生しており、克服すべき課題は少なくない。)

さらに言えば、似たようなシステムとして「国民保護法」に基づくシステムがある。

http://www.kokuminhogo.go.jp/arekore/shudan.html

これらのシステムは、運用も含めて、有効に働くのかも非常に気になってきた。そもそも対策本部経由・内閣府からの情報発信(のみ)で良いのか。警報発信までの時間、その情報活用~国民への伝搬、そして国民の情報への対応までがスムーズに行きそうか。それらも含めて振り返りを行うのは、良いことだと考える。

5月 7, 2011 日記・コラム・つぶやきテクノロジー | | コメント (0) | トラックバック (0)

2011年4月29日 (金)

韓国の未来都市「ソンド」

録画再生して面白かったのが、CSディスカバリーチャネルの「奇跡の建造:韓国・未来都市ソンド」。5月6日にリピート放送がある。

http://japan.discovery.com/episode/index.php?eid1=876007&eid2=000000

空港で有名な仁川 ( インチョン )の市内で、位置的には仁川空港の対岸。埋め立て地で、仁川との橋も建築しようとしている。

旅行サイトでのページが以下。”松島”とも記載するようだ。

http://freepasskorea.web.infoseek.co.jp/songdo/songdo.htm

番組は、ソンドの都市計画、中心的なコンベンションセンターの設計や建築の様子、そして仁川との橋の建築の様子が紹介された。都市計画の設計は、アメリカの企業だったと思う。

個人的に面白かったのが、仁川との橋の建築。部材(というか結構大きな鉄筋コンクリートのユニット)を作って現場まで運ぶが、コンクリートの養生で“蒸す”やり方を実施。5日かかるところを16時間にしたそうだ。現場の人のヘルメットには、”サムスン”のマーク。また橋の建築現場は干潟のため、勤務形態は満潮/干潮の関係で、”月”をベースにしたものにしたそうだ。

また、コンベンションセンターは、柱が無くて梁で支えるタイプ。構造計算やその確認では、自動車の破壊シミュレーションを用いたとのこと。埋め立て地とのことで、梁の端は地下深くの鉄筋などで支えている。ただし、耐震はM7と言ったように思う。今回の震災との対比では少し気になった。


韓国の行政単位を知らないけど、仁川市内には空港があって、ソンド(松島)のような都市を作って空港との橋を架けるという。それらを1つの市で実施できる所もすごい。なんか韓国の躍動感を感じた。

4月 29, 2011 技術科学技術テクノロジー | | コメント (0) | トラックバック (0)