|
防災研究のために観測情報を（内部）統一フォーマットで収集と蓄積をして、研究の目的に応じて変換+統合提供をする無償サービス。数理設計が自己研究のために作成し無償で一般提供する。 |
別URL
|
- （いつ、どこで、どんな）の３要素が基本となるがもっと正確には
- （いつ、どこで、どんな、誰が測定）の４要素が検証性確保のために必要
アメダスや気象情報はわりに固定した情報源だが、それでもかなりの変動があるのでレコードサイズがどんどん変化するタイプのＤＢ構成はあつかいづらい。
いくつかの整理構造を持たせて、ありとあらゆる内容に対応すべきだろう。逆に言えばデータを押し込む側から考察するのではなく、取り出すときの便利さから構造を考えるべきだ。
- 取り出すときにユーザはどうするか？ 第一選択について考えれば
- 特定期間に着目 おおいにある
- 特定地域に着目 おおいにある
- 特定の値に着目 地震や極値を求めることはありそう
- 特定の情報源に着目 信頼性選択が好まれることもある
- たとえばの例
- 電波雑音と地震相関の評価 → （特定サイト＋装置指定）＋（＞震度＋特定地域）
- 降雨量と水位 → （地域＋雨量）＋（水位＋観測サイト）
- 困難
- 地震情報は困難が多い 時刻＋Ｍ＋緯度経度 がペアになる
- 時刻情報のコンパクト化と簡素性が相反する
データ量の推定
- AMeDAS
- １３００地点の気温、湿度、気圧、風向、風速、日照など８データを１０分記録すると
- 時間当たり １３００×８×６＝６２４００項目
- 項目２バイトとすると＝１２４．８ｋバイト
- １日＝３M １年＝１G
- 電波情報、行徳などのサイトあたりの１０秒観測情報
- ４＋１方位 ＋なにかで８データとすると
- 毎分 ８×２バイト（１データ）×６ ＝９６
- 毎時＝５．７６ｋ、 １日＝１３８ｋ １年＝５０M
- これらのサイトが１００箇所あると１年で５G
- たいしたことはない
|
- RDB形式は項目追加や変更、観測値の中止など柔軟性にか欠ける
- 階層構造を持つシーケンシャル型
- 蓄積ＤＢ 時刻＋値の２項タイプ、時刻＋多項目対応のＮ項タイプの２本立て
|
システムの構成
- WANのIP割付 ８個あるが６個だけ割り付けられる、外からは３装置が見える
- ルータ
- DNS Mail WWW 公開の研究開発用 120GB
- WWW2 非公開の研究開発用 関係会社の研究開発情報 相手先IPによるセキュリティ
120GB
- 千葉とクロスバックアップ 相手先IPによるセキュリティ 250GB
- ＬＡＮ内システム
- DBサーバ SQLインターフェース 250GB
- MPI-4CPU 8GB-RAM P4-2GHz 20GB
無停電電力は１２時間の保持能力
- 全部だと平均１００W ８台→８００W 12時間→10kWH
- １２Vバッテリー勘定では ８３３AH → １ｋAH → ３０Aバッテリが３０個 ！ ちょい無理
- 最低限装置なら2台 平均１００W で２／８となり １２Vバッテリ８個 、これなら問題ない。
B-FLETSの無停電性能
- NTT全体は１２時間ほど、途中が光なので局舎までの電源は要らない
- こちらの端末装置へ電力を与えれば動く
- プロバイダは自家発電あり（群馬インターネット、高崎ノード）
- プロバイダから東京までTAOのギガビットイーサネット、途中で分岐している？
|