【ARTSAT API】 衛星API

ARTSAT Projectでは、来たるべき芸術衛星INVADERの打上げに向けて、INVADERのシミュレーションデータを用いたARTSAT APIの試験公開を始めました。
リクエストは、HTTPプロトコルのGETメソッドによって行われ、パラメータはURLエンコードして送ります。レスポンスの形式は、JSON、JSONP、XMLの3種類から選択できます。
取得できるデータは以下の通りです。
/invader/getAvailableTime
・データを取得可能な時刻 (UNIX時刻)
/invader/getSensorData
・緯度[deg]、経度[deg]、高度[km]
・角速度[rad/s] (X軸、Y軸、Z軸)
・姿勢角[rad] (X軸、Y軸、Z軸)
・磁気[T] (X軸、Y軸、Z軸)
・温度[°C] (+X面、-X面、+Y面、-Y面、+Z面、-Z面、内部)
・発電量[W] (+X面、-X面、+Y面、-Y面、+Z面、-Z面)
具体的なリクエストの方法については、ARTSAT API Previewページ(http://api.artsat.jp)をご覧ください。
なお、シミュレーションの基点(t=0[s])は、UNIX時刻の1343746800(2012/8/1 00:00)とし、そこから10[s]間隔で20000ステップ(55時間33分20秒、約34周)の計算を行っています。20000ステップ(t=200000[s])経過した後は、再び初期値(t=0[s])からデータをループさせています。
注)
APIが提供する全てのデータは、非商用の目的でのみ利用できます。
APIの利用回数に関する制限は設けていませんが、状況に応じて事前の告知なしに制限をかける可能性があります。
APIおよびシミュレーションデータは事前の告知なしにアップデートする可能性があります。

 
システム仕様
「ARTSAT API」とは衛星から得られる各種センサデータやステータスデータをエンドユーザが利用するアプリケーションに配信したり、衛星を操作する各種コマンドを受け付けてそれを地上局に受け渡すためのゲートウェイとして動作するソフトウェア群のことです。

このような一連の動作を行なうためには、サーバ側ソフトウェアとクライアント側ソフトウェアを開発し、それらが連携して動作する設計とします。ARTSAT API は INVADER 衛星に限らずに、既存の PRISM 衛星のデータや将来打ち上げられる衛星のデータにも適応できるように抽象的な設計とし、衛星データ配信システムのデファクトとなりうる設計を目指しています。

 
基本コンセプト
ARTSAT APIはサーバ側ソフトウェアとクライアント側ソフトウェアに別けて考えることができます。サーバ側ソフトウェアの設計思想としては INVADER 衛星のデータ型に対応することを基本とし、他の衛星のデータ型にも柔軟に対応できることが求められます。また、クライアント側がさまざまなプログラミング言語を用いてサーバと通信できるようにします。

サーバ側は中央に1つだけデータを集中的に管理するシステムとし、データの P2P 的な分散は行いません。ただし、簡易ソフトウェア受信局(自作八木アンテナと ARTSAT 簡易受信局ソフトウェアを用いてアマチュアの人に受信に参加してもらうことが可能なシステム)などの準サーバ側ソフトウェアの場合、P2Pも将来的には考慮できるかもしれません。

クライアント側ソフトウェアの設計思想も同様に、INVADER 衛星やさまざまな衛星のデータ型にも柔軟に対応し、抽象的なインターフェースを提供することを目指しています。プログラミングにあまり詳しくない人でもクライアント側アプリケーションを簡単に記述できるように、クライアント側ソフトウェアは openFrameworks や Processing のライブラリとして提供します。
データベースがサーバ側、ソフトウェア側何処に存在するかや実際にデータを取得して処理する部分などソフトウェア的に複雑になる部分はなるべくライブラリ内に隠蔽して、アプリケーション開発者にはできるだけシンプルなインターフェースを提示するようにします。
以上をまとめると、ARTSAT APIは、
1. 可能な限り抽象的なデータ管理システム
2. プロトコルは XML ベースの一般的なものを採用し、さまざまな記述言語からのアクセスを許す
3. 複雑なアルゴリズムはなるべくライブラリ内に隠蔽してシンプルなインターフェースを提供する
ものとします。
 
ハードウェア
ARTSAT APIでのハードウェアは、サーバ側ソフトウェアやクライアント側ソフトウェアが動作する環境のことをさします。これらのソフトウェアが適切に動作するハードウェアであれば特に種類は問いませんが、開発段階としては次の環境を想定して開発しています。
サーバ:さくらのVPS Ubuntu 10.04 LTS 64bits http://vps.sakura.ad.jp/
クライアント側 (デスクトップ / ノート):Macintosh MacOS X 10.6 以降 http://www.apple.com/mac
クライアント側(モバイル):iPhone iOS 4.3 以降 http://www.apple.com/iphone/
 
ソフトウェア
ARTSAT APIのソフトウェアとはサーバ側ソフトウェアやクライアント側ソフトウェアを記述するときに用いる言語や開発環境、データベースシステムなどの種類をさします。サーバ・クライアント間で決められたプロトコルを扱えれば良いので、本質的にソフトウェアの種類は問われませんが、開発段階としては次の環境を想定して開発しています。
サーバ側 ARTSAT サーバ(予定):
Rails + apache http://rubyonrails.org/ Java Servlet + apache http://www.oracle.com/technetwork/java/index-jsp-135475.html C based original daemon
サーバ側 データベース:
MySQL5 http://dev.mysql.com/
クライアント側ライブラリ:
openFrameworks OSX http://www.openframeworks.cc/ openFrameworks iPhone http://www.openframeworks.cc/ Processing Mac OSX http://processing.org/
クライアント側 データベース:
SQLite3 http://www.sqlite.org/
 
プロトコル

ARTSAT APIのサーバ・クライアント間、サーバ・準サーバ間は REST ベースのプロトコルを用いて通信を行うことを想定しています。Web アプリケーション開発で広く使われている技術を採用することで、さまざまな環境上で互換性を保ち、予期しない問題を回避することが可能となります。

 
システム構成
ARTSAT APIでは次のようないくつかの構成をとることができます。
開発の初期段階としてはクライアント側のみで動くライブラリを試作し、次第に機能をサーバ側に委譲してゆくことで最終的なサーバ・クライアント構成になるように開発していきます。
サーバなし、クライアント側ライブラリ + クライアント側データベース:
サーバを持たず、クライアント側ライブラリが外部のウェブサイトなどからデータのクロールとローカルのデータベースへのデータの格納を全ておこなう構成
メリット1:完全にクライアント側アプリケーションだけでシステムが完成するのでサーバが停止しているときや障害発生時にアプリケーションが停止することがない
メリット2:取得したデータはローカルのデータベースに格納されているのでネットワークが使えない状況かでも既に取得したデータを参照することができる
デメリット1:クライアントで全ての処理を行なうので動作が重くなりがちである
デメリット2:多数のクライアントが存在したときに、各々が同じデータをクロールするのでクロールされる側の外部サイトに負荷がかかる恐れがある
サーバ側クローラー、クライアント側ライブラリ+クライアント側データベース:
外部のウェブサイトや地上局などからのデータをサーバ側でクロールし、データを最適化したのちクライアント側に受け渡す。クライアント側がデータをローカルのデータベースに格納する。
メリット:前項目に比べてサーバ側でデータをクロールするので、クライアント側の処理が軽減される
デメリット:よって、サーバ側に障害が発生すると全てのクライアントで通信障害がおきることになる
サーバ側クローラー+サーバ側データベース、クライアント側ライブラリ:
外部のウェブサイトや地上局からのデータをサーバ側でクロールし、データベースに格納する。クライアント側ライブラリはリモートのデータベースにデータを取得しに行く。
メリット1:サーバ側でデータをクロールしてデータベースに格納するため、クライアント側の処理が軽減される
メリット2:さらに、データのクロールは1回で済むのでクライアントの数が多くなっても外部サイトに迷惑をかけることが無い
デメリット1:サーバ側に障害が発生すると全てのクライアントで通信障害が起きることになる
サーバ側クローラー+サーバ側データベース+シミュレータ、クライアント側ライブラリ:
外部のウェブサイトや地上局からのデータをサーバ側でクロールし、データベースに格納する。さらに実際のデータが存在しない部分をシミュレートしデータの密度を増やす。クライアント側ライブラリはリモートのデータベースにデータを取得しに行くが、実際に衛星から取得されたデータかシミュレート結果なのかは透過的に扱うことができる。
メリット:前項目に比べて利用できるデータの密度が向上する
デメリット:シミュレーションはたくさんの CPU リソースを消費するのでサーバに負荷をかけ動作が遅くなるかもしれない。