JP6546832B2 - 動作環境再構築プログラム、動作環境再構築システム、動作環境再構築方法 - Google Patents

Description

本明細書は、動作環境再構築プログラム、動作環境再構築システム、動作環境再構築方法に関する。

近年、コンピュータなどの情報・通信機器だけでなく、それ以外の物にも通信機能を持たせて、インターネットに接続したり、相互に通信したりするＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）が実現されている。

このような背景の下において、Ｒａｓｐｂｅｒｒｙ Ｐｉなどハードウェアリソースの限られた小型のコンピュータ（ＰＣ）が提供されている。

特許５４４５７２２号公報 特開２０１４−２２９３２１号公報 特開２０１２−１４５９９５号公報 特開２００１−３４４５８号公報 国際公開第２０１０／１００７３５号 国際公開第２０１３／０１８２０４号 国際公開第２０１４／０４５６９９号

メモリ容量が少ない等のハードウェアリソースに制限のある小型ＰＣにおいて、複数の種類のセンサを用いたアプリケーションプログラム（以下、「アプリケーション」と称する）を随時切り替えて試作したり、動作確認を繰り返すことがある。

ところが、利用するセンサや連携先サーバによって、ドライバや関連ツールなどが異なるので、上記センサの交換によるアプリケーションの切り替えの度に、小型ＰＣのシステム環境を再構築する必要があり、その準備に時間がかかる。

また、システム環境を、デバイスドライバやサービス、設定まで含めて元に戻したり、再現するのは容易ではない。

本発明は、一側面として、センサを搭載可能な情報通信デバイスにおける、センサに対応する動作環境を容易に再構築する技術を提供する。

本発明の一側面に係る環境再構築プログラムは、検知対象を検知する検知部を搭載可能な情報通信デバイスに含まれるコンピュータに、以下の処理を実行させる。コンピュータは、搭載された検知部の種類を特定する。コンピュータは、特定した検知部の種類と、検知部により生成される検知データを収集するサーバ装置における検知データの収集方法とに対応する情報であって情報通信デバイスの動作環境を再構築する情報を示す再構築情報を取得する。コンピュータは、ブート処理を実行し、再構築情報に基づいて検知部に対応する動作環境を再構築する。なお、収集方法は、サーバ装置からの問い合わせに応じて情報通信デバイスから送信される検知データを収集する収集方法を含む。

本明細書に記載の技術によれば、センサを搭載可能な情報通信デバイスにおける、センサに対応する動作環境を容易に再構築することができる。

本実施形態における動作環境再構築システムの一例を示す。 本実施形態における小型ＰＣ管理システムの一例を示す。 本実施形態におけるセンサデータ要求モデルの一例を示す。 本実施形態におけるセンサ・ブートイメージ関係情報の一例を示す。 本実施形態における小型ＰＣ管理システムの全体の処理フローを示す。 本実施形態におけるブートイメージを利用したブート処理（Ｓ１）の詳細を示す。 本実施形態におけるloopbackスクリプトの一例を示す。 本実施形態におけるブートイメージ特定処理（Ｓ３）の処理の一例を示す。 本実施形態におけるセンサデータの収集方法の決定処理（Ｓ３−２）のフローを示す。 本実施形態における送信スクリプトを説明するための図である。 本実施形態におけるサーバにおいて生成されるブートイメージ定義３１の例を示す。 本実施形態におけるデバイスにおいて、ダウンロードしたブートイメージ定義に基づいて書き換えられたブートローダ用定義を示す。 図５のＳ４〜Ｓ７の詳細を示す。 本実施形態におけるブートイメージファイルの作成の際に用いるコマンドの例である。 本実施形態におけるブートイメージファイルの作成手順を示す。 本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。

仮想マシン、Ｌｉｎｕｘ（登録商標）コンテナなどの仮想技術などでは、ゲストのオペレーティングシステム（ＯＳ）側からホストＯＳへのアクセスは制限されるため、接続されたセンサへのアクセスが困難である。

Ｃｈｅｆなどの環境構築自動化ツールでは、システム環境を元に戻すのが一般的に困難である。

Ｗｉｎｄｏｗｓ（登録商標）などのドライバの自動インストールでは、ＯＳ自体を入れ替えるなどシステム環境を大きく入れ替えることは想定していない。しかし、特定のセンサは、特定のＯＳやバージョン用のドライバしか存在しないものもあるので、その場合には、特定のＯＳに入れ替える必要がある。また、環境構築同様、ＯＳの環境を元に戻すのが一般的に困難である。

また、ライブＯＳなどによる固定環境の利用においては、動作環境が固定化されるため、センサに応じた環境の切り替えやアプリケーションなどのカスタマイズが難しい。

そこで、本実施形態では、予め格納している小型ＰＣの起動に用いるデータやアプリケーション等を一まとめにしたブートイメージから、接続されたセンサとセンサデータの要求モデルの組み合わせに対応するブートイメージを特定する。小型ＰＣ上のエージェントがその合成されたブートイメージを取得し、ブートローダのオプションを書き換えてデバイスをリブートする。そして、圧縮したブートイメージを読み込み専用でループバックマウント（ストレージ内にあるストレージファイルをマウント）する。これにより、小型ＰＣのシステム環境を容易に元に戻すことができる。

図１は、本実施形態における動作環境再構築システムの一例を示す。環境再構築システム１は、検知対象を検知する検知部を搭載可能な情報通信デバイスと、該情報通信デバイスと通信するサーバ装置とを含む。

デバイス環境再構築システム１は、特定部２、取得部３、再構築部４を含む。
特定部２は、情報通信デバイスに搭載された検知部の種類を特定する。特定部２の一例として、後述する接続センサ検知部１３が挙げられる。

取得部３は、サーバ装置から、特定した検知部の種類に対応する情報であって情報通信デバイスの動作環境を再構築する情報を示す再構築情報を取得する。取得部３の一例として、後述するブート制御エージェント１５が挙げられる。

再構築部４は、情報通信デバイスのブート処理を実行し、再構築情報に基づいて検知部に対応する動作環境を再構築する。再構築部４の一例として、後述するブート制御エージェント１５が挙げられる。

このように構成することにより、情報通信デバイスにおける、センサを利用する動作環境を容易に再構築することができる。

環境再構築システム１は、さらに、検知データ送信部５を含む。検知データ送信部５は、再構築された動作環境において、送信方法情報に基づいて、検知データを送信する。

このように構成することにより、再構築された動作環境において、検知データを送信することができる。

環境再構築システム１は、さらに、提供部６を含む。まず、取得部３は、検知部の種類を特定する種類特定情報と、検知部により生成される検知データの取得条件とに基づいて設定された該検知データの送信方法を示す送信方法情報を取得する。提供部６は、種類特定情報と取得条件とに基づいて検知データの送信方法を特定する。提供部６は、関係情報から、種類特定情報と送信方法との組み合わせに対応する再構築情報と送信スクリプトを、情報通信デバイスに提供する。ここで、関係情報は、再構築情報と、種類特定情報と、送信方法と、送信方法に対応する送信スクリプトとを関係付けた情報である。提供部６の一例として、後述するブートイメージ特定部２４が挙げられる。

このように構成することにより、情報通信デバイスに、センサとセンサデータ要求モデルに応じて、検知データの送信方法を特定することができる。さらに、センサと、その送信方法に基づいて、ブートイメージと、送信スクリプトを特定することができる。

図２は、本実施形態における小型ＰＣ管理システムの一例を示す。小型ＰＣ管理システム１０は、小型ＰＣ（以下、「デバイス」と称する）１１、サーバ２１を含む。デバイス１１とサーバ２１は、インターネット、ローカルエリアネットワーク（ＬＡＮ）等のネットワークを介して接続されている。

デバイス１１は、制御装置１２、記憶装置１７、センサ１９を含む。センサ１９は、外部の事象や状況を検知したり、周辺にある無線通信機器を検出したり装置であって、交換可能である。センサ１９としては、例えば、温度センサ、圧力センサ、音センサ、Bluetooth（登録商標）通信により周辺にあるBluetooth対応機器を検知するセンサ、光センサ等、様々なセンサを用いることができ、限定されない。

制御装置１２は、デバイス１１の全体の動作を制御する。制御装置１１は、接続センサ検知部１３、ブートローダ１４、ブート制御エージェント１５、センサデータ送信部１６として機能する。接続センサ検知部１３、ブートローダ１４、ブート制御エージェント１５、センサデータ送信部１６については、後述する。

記憶装置１７は、データを格納するものであり、フラッシュメモリ等の小型の記憶装置だけでなく、フラッシュメモリカード（例えば、ＳＤカード）等の可搬型記録媒体でもよい。本実施形態では、記憶装置１７の一例として、ＳＤカードを用いることとする。ＳＤカード１７は、サーバよりダウンロードしたブートイメージ３０’、送信スクリプト３２’等を格納する。また、ＳＤカード１７は、ＯＳ、アプリケーション、後述する種々のファイルやスクリプト、データを格納する。ここで、本実施形態では、サーバからダウンロードした情報に「’」を付する。

サーバ２１は、制御装置２２、記憶装置２６を含む。
制御装置２２は、サーバ２１の全体の動作を制御する。制御装置２２は、受信部２３、ブートイメージ特定部２４、センサデータ受信部２５として機能する。受信部２３、ブートイメージ特定部２４、センサデータ受信部２５については、後述する。

記憶装置２６は、センサデータ要求モデル２７、センサ・ブートイメージ関係情報２８、ブートイメージ３０、ブートイメージ定義３１、送信スクリプト３２、センサデータ３３を格納する。

図３は、本実施形態におけるセンサデータ要求モデルの一例を示す。センサデータ要求モデル２７は、「モデル名」２７−１、「データの取得頻度」２７−２、「固定／移動」２７−３、「信頼性」２７−４のデータ項目を含む。

「モデル名」２７−１には、センサデータ要求モデルの名称が設定される。「データの取得頻度」２７−２には、センサデータの取得頻度（リアルタイム／１時間以内／１日以内／１週間以内）が設定される。「固定／移動」２７−３には、位置が固定されるセンサか、移動するセンサであるかが設定される。「信頼性」２７−４には、センサデータに信頼性が必要（例えば、センサデータの欠落があってはいけない場合）であるか必要ないか（例えば、センサデータの欠落があってもよい場合）が設定される。

図４は、本実施形態におけるセンサ・ブートイメージ関係情報の一例を示す。センサ・ブートイメージ関係情報２８は、接続されているセンサ１９とセンサデータの収集方法とから、利用ブートイメージリストと送信スクリプトを特定するための情報である。

センサ・ブートイメージ関係情報２８は、「センサタイプ」２８−１、「収集方法」２８−２、「利用ブートイメージリスト」２８−３、「送信スクリプト」２８−４のデータ項目を含む。

「センサタイプ」２８−１には、センサのタイプが格納される。例えば、“温度”は、温度センサを示す。“Bluetooth”は、Bluetooth通信により周辺にあるBluetooth対応機器を検知するセンサを示す。

「収集方法」２８−２には、サーバがセンサデータを収集する方法が格納される。「利用ブートイメージリスト」２８−３には、ブートに必要な１以上のブートイメージファイルの名称がリスト化されて格納される。「送信スクリプト」２８−４には、センサ１９から値（センサデータ）を取得する取得処理スクリプトと、取得したセンサデータをサーバに送信する送信処理スクリプトとが合成されたスクリプト名が格納される。

図５は、本実施形態における小型ＰＣ管理システムの全体の処理フローを示す。図５では、デバイス１１のブートから新しいブートイメージでアプリケーションが動作するまでのフローを示す。

デバイス１１側では、ブート処理が実行される（Ｓ１）。ブート後、接続センサ検知部１３は、デバイス１１に接続されているセンサ１９を検知してその種類を特定し、その特定した結果を示すセンサ特定情報をサーバ２１に送信する（Ｓ２）。

サーバ２１側では、受信部２３は、デバイス１１からセンサ特定情報を受信する。すると、ブートイメージ特定部２４は、記憶装置２６に格納された１以上のブートイメージから、センサ特定情報と、予め登録されたセンサデータ要求モデル２７とに対応するブートイメージを特定する（Ｓ３）。

デバイス１１側では、ブート制御エージェント１５は、サーバ２１にアクセスして、新しいブートイメージがあるかを確認する（Ｓ４）。ここでは、ブート制御エージェント１５は、サーバ２１からブートイメージ定義３１をダウンロードし、前回ダウンロードしたブートイメージ定義と今回ダウンロードしたブートイメージ定義とを比較する。例えば、比較したブートイメージ定義のタイムスタンプに相違がある場合、ブート制御エージェント１５は、サーバ２１に新しいブートイメージ定義３１が存在すると判定する。

サーバ２１の記憶装置２６に新しいブートイメージ定義３１が存在すると判定した場合、ブート制御エージェント１５は、ダウンロードしたブートイメージ定義３１を用いて、サーバ２１からブートイメージ３０と送信スクリプト３２をダウンロードする。ブート制御エージェント１５は、ダウンロードしたブートイメージ３０’を用いて、デバイス１１を再ブートし（Ｓ５）、アプリケーションを起動させる（Ｓ６）。

デバイス１１において、センサデータ送信部１６は、ダウンロードした送信スクリプト３２’を用いて、センサ１９からセンサデータを収集し、サーバ２１へ送信する。

サーバ２１は、デバイス２１から送信されたセンサデータを収集する（Ｓ７）。
図６は、本実施形態におけるブートイメージを利用したブート処理（Ｓ１）の詳細を示す。ＳＤカード１７は、start.elfファイル４１、カーネル４２、config.txtファイル４３、cmdline.txtファイル４４、initrdイメージファイル４５、initファイル４６、loopbackスクリプト４７、base.sfsファイル４９、app.sfsファイル５０、diff.ext４ファイル５１を含む。root４８は、外部記憶装置であるＳＤカード１７を示す。

start.elfファイル４１は、ブート後、カーネルをロードするファイルである。カーネル４２は、Linux等のＯＳの主要部を形成するモジュールである。config.txtファイル４３は、デバイス１１をブートするためのパラメータを管理するファイルである。cmdline.txtファイル４４は、カーネルに与えるためのパラメータを管理するファイルである。initrdイメージファイル４５は、カーネル４２が起動する前に一時的に使用されるファイルであり、initスクリプト４６及びloopbackスクリプト４７を含む。
initスクリプト４６は、ブート用のスクリプトである。loopbackスクリプト４７は、initrdイメージファイル上で独立して動作するスクリプトである、ＳＤカード１７内に格納されている所定のファイルをマウントするスクリプトである。

base.sfsファイルは、ＯＳ等を含むベースイメージである。app.sfsファイルは、アプリケーションやデバイスドライバについてのイメージを含み、さらに、ブート制御エージェント１５を示すエージェントスクリプトも含む。diff.ext４ファイル５１は、ある基準となるデバイス１１の状態からの差分の状態を保持するワークファイルである。

デバイス１１のブートが開始すると、start.elfファイル４１が起動することで、カーネル４２がロードされる（Ｓ１−１）。start.elfファイル４１により、config.txtファイル４３と、cmdline.txtファイル４４がロードされる（Ｓ１−２、Ｓ１−３）。start.elfファイル４１により、initrdファイル４５がロードされる（Ｓ１−４）。すると、start.elfファイル４１により、カーネル４２が起動される（Ｓ１−５）。

カーネル４２は、initファイル４６を起動させる（Ｓ１−６）。initファイル４６は、loopbackスクリプト４７を起動させる（Ｓ１−７）。

loopbackスクリプト４７は、ＳＤカード内のファイル（rootファイル４８、base.sfsファイル４９、app.sfsファイル５０、diff.ext４ファイル５１）をマウントする（Ｓ１−８〜Ｓ１−１１）。

図７は、本実施形態におけるloopbackスクリプトの一例を示す。図７は、具体的には、Archlinux用にブートイメージをマウントするhookの例である。

loopbackスクリプト４７は、init４６より起動させられると、所定のパラメータを取得する。loopbackスクリプト４７は、取得したパラメータを用いて、ＳＤカード１７のマウント、ブートイメージ（base.sfsファイル、app.sfsファイル）のマウント、差分ファイル（diff.ext４ファイル５１）のマウントをし、ブートイメージと差分とを１つのファイルにまとめる。これにより、起動パラメータに指定されたブートイメージをマウントしてまとめることができる。

図８は、本実施形態におけるブートイメージ特定処理（Ｓ３）の処理の一例を示す。サーバ２１において、受信部２３は、デバイス１１から、接続されたセンサ１９の種類を特定するセンサ特定情報を取得する（Ｓ３−１）。

すると、ブートイメージ特定部２４は、記憶装置２６に格納されたセンサデータ要求モデル２７と、取得したセンサ１９の種類を特定する情報とに基づいて、センサデータの収集方法、すなわちデバイス１１からのセンサデータの送信方法を決定する（Ｓ３−２）。Ｓ３−２については、図９で詳述する。このとき、ブートイメージ特定部２４は、サーバ２１側の受信方法もあわせて設定する。

ブートイメージ特定部２４は、取得したセンサの種類と、決定したセンサデータの収集方法をキーとして、センサ・ブートイメージ関係情報２８から、利用するブートイメージリストと送信スクリプトとを決定する（Ｓ３−３、Ｓ３−４）。

ブートイメージ特定部２４は、決定したブートイメージリストに含まれるブートイメージの格納場所を、図１１に示すように、ブートイメージ定義３１としてデバイス用の定義ファイルに出力し、記憶装置２６に格納する（Ｓ３−５）。

図９は、本実施形態におけるセンサデータの収集方法の決定処理（Ｓ３−２）のフローを示す。ブートイメージ特定部２４は、記憶装置２６からセンサデータ要求モデル２７を取得する。

ブートイメージ特定部２４は、センサデータ要求モデル２７の「固定／移動」２７−３を参照し、センサデータ要求モデルで示されるセンサモデルが位置が固定されるセンサであるか、移動するセンサであるかを判定する（Ｓ３−２−１）。

「固定／移動」２７−３が“移動”を示す場合、ブートイメージ特定部２４は、センサデータの収集方法を“Push送信”に決定する（Ｓ３−２−４）。“Push送信”は、サーバ２１がデバイス１１へ問い合わせを行うことなしに、デバイス１１からセンサデータが送信される方式である。

「固定／移動」２７−３が“位置固定”を示す場合、ブートイメージ特定部２４は、「データの取得頻度」２７−２を参照し、データの取得頻度が、例えば、リアルタイムか、１時間以内か、１日以内のいずれであるかを判定する（Ｓ３−２−２）。

「データの取得頻度」２７−２が“１日以上”を示す場合、ブートイメージ特定部２４は、センサデータの収集方法を“アーカイブPull”に決定する（Ｓ３−２−６）。“アーカイブPull”は、サーバ２１がセンサへ問い合わせを行って、センサから所定期間分蓄積されたセンサデータを取得する方式である。

「データの取得頻度」２７−２が“１時間以内”を示す場合、ブートイメージ特定部２４は、センサデータの収集方法を“Pull”に決定する（Ｓ３−２−５）。“Pull”は、サーバ２１がデバイス１１へ問い合わせを行って、デバイス１１から前回収集以降に蓄積されたセンサデータを取得する方式である。

「データの取得頻度」２７−２が“リアルタイム”を示す場合、ブートイメージ特定部２４は、センサデータの収集方法の「信頼性」２７−４を判別する（Ｓ３−２−３）。

「信頼性」２７−４が“必要”を示す場合、ブートイメージ特定部２４は、センサデータの収集方法を“Pull”に決定する（Ｓ３−２−５）。「信頼性」２７−４が“不要”を示す場合、ブートイメージ特定部２４は、センサデータの収集方法を“Push送信”に決定する（Ｓ３−２−４）。

図１０は、本実施形態における送信スクリプトを説明するための図である。送信スクリプトは、センサデータの取得処理スクリプトと送信処理スクリプトとを、パイプ（＋）で組み合わせて合成したスクリプトである。以下では、送信スクリプトを形成するシェルスクリプトであって、パイプ（＋）で接続対象となる各シェルスクリプトを説明する。

図１０（Ａ）は、センサデータの取得処理のうち温度データ取得の一例としてシェルスクリプト“digital-read.sh”の例を示す。図１０（Ａ）に示すように、デバイス１１側でdigital-read.shが実行されると、センサ１９により検知された値が読み取られ、その値が数値へ変換され、変換処理により得られた数値データにタイムスタンプが付与される。

図１０（Ｂ）は、センサデータの取得処理のうちBluetoothスキャンの一例としてシェルスクリプト“Bluetooth-detect.sh”の例を示す。図１０（Ｂ）に示すように、デバイス１１側でBluetooth-detect.shが実行されると、Bluetoothにより通信を行う近隣の機器から機器情報が検知され、その機器情報にタイムスタンプが付与される。

図１０（Ｃ）は、送信処理のうちPush送信の一例としてシェルスクリプト“send-push.sh”の例を示す。図１０（C）に示すように、デバイス１１側でsend-push.shが実行されると、サーバ２１へデータ送信する処理が行われる。

図１１は、本実施形態におけるサーバにおいて生成されるブートイメージ定義３１の例を示す。ブートイメージ定義３１は、サーバ２１において、ブートイメージが格納されている場所を示す。

図１２は、本実施形態におけるデバイスにおいて、ダウンロードしたブートイメージ定義に基づいて書き換えられたブートローダ用定義を示す。ブートローダ用定義は、図１３にて後述する。

図１３は、図５のＳ４〜Ｓ７の詳細を示す。ブートローダ１４は、ブート制御エージェント１５を起動させる（Ｓ４−１）。ブート制御エージェント１５は、サーバ２１にアクセスし、新しく登録されたブートイメージ定義３１が存在するかを確認する（Ｓ４−２）。ここでは、ブート制御エージェント１５は、サーバ２１からブートイメージ定義３１をダウンロードし、前回ダウンロードしたブートイメージ定義と今回ダウンロードしたブートイメージ定義とを比較する。例えば、比較したブートイメージ定義のタイムスタンプに相違がある場合、ブート制御エージェント１５は、サーバ２１に新しいブートイメージ定義が存在すると判定する。

新しく登録されたブートイメージ定義３１が存在する場合、ブート制御エージェント１５は、そのブートイメージ定義３１を取得する。ブート制御エージェント１５は、取得したブートイメージ定義３１で示された格納場所から１以上のブートイメージをダウンロードすると共に、そのブートイメージに対応する送信スクリプト３２をダウンロードする（Ｓ４−３）。

ブート制御エージェント１５は、ダウンロードしたブートイメージ３０’と送信スクリプト３２’を、ＳＤカード１７に格納する（Ｓ４−４、Ｓ４−５）。

ブート制御エージェント１５は、取得したブートイメージ定義３１に基づいて、cmdline.txtに含まれるブートローダ用定義を、図１２に示すように、書き換える（Ｓ５−１）。

ブート制御エージェント１５は、ブートローダ１４にリブート指示を行う（Ｓ５−２）。ブートローダ１４は、リブート指示を受けると、ブートローダ用定義（cmdline.txt）に基づいて、ブートイメージ３０をマウントする（Ｓ５−３）。Ｓ５−２及びＳ５−３の処理は、図６で説明した処理と同様である。

ブートローダ１４は、ブート制御エージェント１５を起動させる（Ｓ７−１）。ブート制御エージェント１５は、送信スクリプト３２’ をセンサデータ送信部１６として起動させる（Ｓ７−２）。すると、センサデータ送信部１６は、センサ１９から、センサデータを収集する。

すると、センサデータ送信部１６は、送信スクリプト３２’で規定された送信方法でセンサデータをサーバ２１に送信する（Ｓ７−３）。サーバ２１側では、センサデータ受信部２５は、デバイス１１から送信されたセンサデータを受信する。

次に、ブートイメージファイルの作成について説明する。
図１４は、本実施形態におけるブートイメージファイルの作成の際に用いるコマンドの例である。これについては、図１５にて説明する。

図１５は、本実施形態におけるブートイメージファイルの作成手順を示す。ユーザは、デバイス１１に対して、図１５（Ａ）に示す差分ファイル作成コマンドを実行することにより、差分ファイルのフォーマットを行い、初期化された差分ファイル（diff.ext4）を作成する（Ｓ１１）。ユーザは、差分ファイル（diff.ext4）を用いて、デバイス１１をブートする（Ｓ１２）。

デバイス１１のブート後、ユーザは、センサ１９に対応するアプリケーション等の必要なパッケージをデバイス１１にインストールする（Ｓ１３）。

ユーザは、デバイス１１に対して、図１５（Ａ）に示す差分ファイル作成コマンドを実行することにより、差分ファイル（diff.ext4a）を作成する。ここで、差分ファイル（diff.ext4a）は、上記パッケージのインストール前後のデバイスの環境の差分を含む。ユーザは、Ｓ１１で作成した差分ファイル（diff.ext4）を、インストール処理後に得られた差分ファイル（diff.ext4a）と入れ替える（Ｓ１４）。

ユーザは、差分ファイル（diff.ext4a）を用いて、デバイス１１を再ブートする（Ｓ１５）。ユーザは、デバイス１１に対して、差分ファイル（diff.ext4）を用いて、図１５（Ｂ）に示すイメージファイル作成コマンドを実行することにより、ブートイメージファイルを作成する（Ｓ１６）。

ユーザは、生成されたブートイメージを予めサーバ２１の記憶装置２６に登録する（Ｓ１７）。また、ユーザは、センサ・ブートイメージ関係情報２８へ、サーバ２１に登録したブートイメージに対応するレコードを登録する（Ｓ１８）。

図１６は、本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ６０は、デバイス１１またはサーバ２１として機能する。コンピュータ６０は、ＣＰＵ６２、ＲＯＭ６３、ＲＡＭ６６、通信Ｉ／Ｆ６４、記憶装置６７、出力Ｉ／Ｆ６１、入力Ｉ／Ｆ６５、読取装置６８、バス６９、出力装置７１、入力装置７２によって構成されている。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インタフェースを示す。バス６９には、ＣＰＵ６２、ＲＯＭ６３、ＲＡＭ６６、通信Ｉ／Ｆ６４、記憶装置６７、出力Ｉ／Ｆ６１、入力Ｉ／Ｆ６５、及び読取装置６８が接続されている。読取装置６８は、可搬型記録媒体を読み出す装置である。出力装置７１は、出力Ｉ／Ｆ６１に接続されている。入力装置７２は、入力Ｉ／Ｆ６５に接続されている。

記憶装置６７としては、ハードディスク、フラッシュメモリカードなど様々な形式の記憶装置を使用することができる。コンピュータ６０がデバイス１１である場合には、記憶装置６７またはＲＯＭ６３には、ＣＰＵ６２を特定部２、取得部３、再構築部４、検知データ送信部５として機能させる本実施形態に係るプログラムが格納されている。コンピュータがサーバ２１である場合には、記憶装置６７またはＲＯＭ６３には、提供部６として機能させる本実施形態に係るプログラムが格納されている。

ＣＰＵ６２は、記憶装置６７またはＲＯＭ６３から本実施形態に係るプログラムを読み出し、当該プログラムを実行する。

通信Ｉ／Ｆ６４は、ネットワークと接続して他の装置と通信するためのポート等のインタフェースである。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク７０、および通信Ｉ／Ｆ６４を介して、例えば記憶装置６７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読取装置６８にセットされて、ＣＰＵ６２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置、半導体メモリカードなど様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読取装置６８によって読み取られる。

入力装置７２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレット、タッチパネルなどを用いることが可能である。また、出力装置７１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。

ネットワーク７０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。

本実施形態によれば、メモリ容量等のハードウェア資源が制限されたデバイス１１において、複数の種類のセンサを用いたアプリケーションを随時切り替えて試作したり、動作確認を繰り返す場合に、デバイス１１のシステム環境の再構築を容易に行うことができる。

なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 環境再構築システム
２ 特定部
３ 取得部
４ 再構築部
５ 検知データ送信部
６ 提供部
１０ 小型ＰＣ管理システム
１１ デバイス
１２ 制御装置
１３ 接続センサ検知部
１４ ブートローダ
１５ ブート制御エージェント
１６ センサデータ送信部
１７ ＳＤカード
１９ センサ
２１ サーバ
２２ 制御装置
２３ 受信部
２４ ブートイメージ特定部
２５ センサデータ受信部
２６ 記憶装置
２７ センサデータ要求モデル
２８ センサ・ブートイメージ関係情報
３０，３０’ ブートイメージ
３１ ブートイメージ定義
３２，３２’ 送信スクリプト
３３ センサデータ

Claims (7)

1. 検知対象を検知する検知部を搭載可能な情報通信デバイスに含まれるコンピュータに、
   搭載された前記検知部の種類を特定し、
   特定した前記検知部の種類と、前記検知部により生成される検知データを収集するサーバ装置における前記検知データの収集方法とに対応する情報であって前記情報通信デバイスの動作環境を再構築する情報を示す再構築情報を取得し、
   ブート処理を実行し、前記再構築情報に基づいて前記検知部に対応する動作環境を再構築する
   処理を実行させ、
   前記収集方法は、前記サーバ装置からの問い合わせに応じて前記情報通信デバイスから送信される前記検知データを収集する収集方法を含む
   ことを特徴とする動作環境再構築プログラム。
2. 前記再構築情報の取得において、
   前記検知データの取得条件に基づいて決定された前記収集方法と、前記検知部の種類を特定する種類特定情報とに基づいて設定された前記検知データの前記情報通信デバイスからの送信方法を示す送信方法情報を取得し、
   再構築された前記動作環境において、前記送信方法情報に基づいて、前記検知データを送信する
   ことを特徴とする請求項１に記載の動作環境再構築プログラム。
3. 前記取得条件は、前記検知データの欠落を許容するか否かを示す情報を含むことを特徴とする請求項２に記載の動作環境再構築プログラム。
4. 検知対象を検知する検知部を搭載可能な情報通信デバイスと、該情報通信デバイスと通信するサーバ装置とを含むデバイス環境再構築システムであって、
   前記情報通信デバイスが、
   前記情報通信デバイスに搭載された前記検知部の種類を特定する特定部と、
   前記検知部により生成される検知データを収集する前記サーバ装置から、特定した前記検知部の種類と、前記サーバ装置における前記検知データの収集方法とに対応する情報であって前記情報通信デバイスの動作環境を再構築する情報を示す再構築情報を取得する取得部と、
   前記情報通信デバイスのブート処理を実行し、前記再構築情報に基づいて前記検知部に対応する動作環境を再構築する再構築部と、
   を備え、
   前記収集方法は、前記サーバ装置からの問い合わせに応じて前記情報通信デバイスから送信される前記検知データを収集する収集方法を含む
   ことを特徴とする動作環境再構築システム。
5. 前記取得部は、前記検知データの取得条件に基づいて決定された前記収集方法と、前記検知部の種類を特定する種類特定情報とに基づいて設定された前記検知データの前記情報通信デバイスからの送信方法を示す送信方法情報を取得し、
   前記情報通信デバイスが、さらに、
   再構築された前記動作環境において、前記送信方法情報に基づいて、前記検知データを送信する検知データ送信部
   を備えることを特徴とする請求項４に記載の動作環境再構築システム。
6. 前記サーバ装置が、
   前記種類特定情報と前記取得条件とに基づいて前記検知データの前記収集方法を特定し、前記再構築情報と、前記種類特定情報と、前記収集方法と、前記送信方法情報である送信スクリプトとを関係付けた関係情報から、前記種類特定情報と前記収集方法との組み合わせに対応する前記再構築情報と前記送信スクリプトを、前記情報通信デバイスに提供する提供部
   を備えることを特徴とする請求項５に記載の動作環境再構築システム。
7. 検知対象を検知する検知部を搭載可能な情報通信デバイスに含まれるコンピュータが、
   搭載された前記検知部の種類を特定し、
   特定した前記検知部の種類と、前記検知部により生成される検知データを収集するサーバ装置における前記検知データの収集方法とに対応する情報であって前記情報通信デバイスの動作環境を再構築する情報を示す再構築情報を取得し、
   前記情報通信デバイスのブート処理を実行し、前記再構築情報に基づいて前記検知部に対応する動作環境を再構築し、
   前記収集方法は、前記サーバ装置からの問い合わせに応じて前記情報通信デバイスから送信される前記検知データを収集する収集方法を含む
   ことを特徴とする動作環境再構築方法。

Images