JP2019049905A - デバイス連携サーバおよびデバイス連携プログラム - Google Patents

Abstract

【課題】ＩｏＴデバイスを動的に発見し利用するサービスを、継続してリーズナブルに提供する。【解決手段】デバイス連携サーバ１は、サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、デバイスレイヤに属する各デバイスの利用履歴を収集する利用履歴収集部と、収集された利用履歴を参照し、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層の一つないし複数を、サービスに関する機能の配置先として決定する機能配置先決定部と、サービスに関する機能を、決定した３層の一つないし複数のレイヤに配信する機能配信部と、を備える。【選択図】図１

Description

本発明は、ネットワークに多種多様なＩｏＴ（Internet of Things）デバイスが繋がる環境における、デバイス連携サーバおよびデバイス連携プログラムに関する。

近年のＩｏＴ技術の進展により、数多くのセンサやアクチュエータ、ロボット等のＩｏＴ機器がネットワークに繋がるようになってきている。ＩｏＴは、物体に通信機能を持たせ、ネットワークに接続しデータを解析することにより、サービスの提供を行う。ＩｏＴの適用範囲は多岐にわたり、ドイツのインダストリー4.0（Industrie 4.0 ）で検討されている製造、流通、メンテナンスだけでなく、健康管理、医療、農業、エネルギ等も適用先として期待されている。

しかしながら、現状のＩｏＴの適用は、特定のターゲットに合わせた垂直統合的なワンオフソリューションになりがちである。つまり、センサの選定や、分析、表示、アクション等を一括で行い、システム化して提供するＳＩ（System Integration）ビジネスで用いられることが多い。この結果、個々のＩｏＴサービスのコストが高くなり、多彩なサービスが十分出ていないという現状がある。

多彩なＩｏＴサービスを、コストを抑えて開発、運用するためには、センサやアクチュエータ等のデバイスとサービスとを分離し、水平分離的にデバイスとサービスを相互に利用可能とすることが必要となる。このような考え方はオープンＩｏＴと呼ばれ、今後のＩｏＴサービスを活性化するために重視されている。

このようなオープンＩｏＴにむけて、サービスからデバイスを自由に利用するための仕組みとしてTacit Computing技術が提案されている（非特許文献１参照）。Tacit Computingは、デバイスがその時点で保持するライブデータに基づき、ユーザが必要なデータを保持するデバイスをオンデマンドに発見し、利用することを可能にする技術である。

図７は、Tacit Computingの概要を説明するための図である。
Tacit Computingでは、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層の中から、ユーザへのサービスに適切なリソースを発見し連携することにより、そのユーザのリクエストに応えサービスを継続する（図７の符号ａ）。また、３層の構成のうち、時々刻々変化する状況に対応するため、データが発生する現場に近いデバイスレイヤにおいてできるだけ処理を行うようにする（図７の符号ｂ）。より低いレイヤで処理を行うことにより、ネットワークトラフィックの削減や（図７の符号ｃ）、プライバシー性の高いデータの流出を抑えることができる（図７の符号ｄ）。

このTacit Computingでは、その要素技術として、ライブデータ検索技術とデバイス仮想化技術を用いる。
ライブデータ検索技術は、ユーザにとって必要なデータを提供するデバイスを検索するための技術である。ＩｏＴサービスの例として、橋等の施設にセンサを複数設置し、劣化状況等をモニタリングするサービスがある。この場合、劣化状況が急激に進むとは考えられないため、数時間等の周期で複数点でのセンサデータをクラウドに上げ、劣化状況の変化を統計ソフトや機械学習により分析すればよい。これに対し、定点のカメラに映った人物に対して、情報案内や警告アラート等を行うサービスの例では、数秒程度しかカメラに人物は映らないし、また、その人物が写ったカメラの映像しかその人物には意味のないデータといえる。このように、デバイスレイヤで発生し、時々刻々変化するようなデータをライブデータと呼ぶ。

ユーザにとって必要なこのライブデータを検索するため、Tacit Computingでは、クラウドレイヤにデータが上がってくるのを待つのではなく、下位レイヤに分析する機能を配置し、その下位レイヤにおいてライブデータを検索させる。
例えば、駅伝予選会に友人が参加しており、その友人が写ったカメラの映像を自動で繋いで欲しいとする。この場合、例えば友人のゼッケン番号を検索キーとしてリクエストすると、Tacit Computingでは、カメラを収容するゲートウェイやネットワークエッジに、OpenCV等の画像分析機能を配置する。そして、カメラに近い場所で映像を分析することにより、友人のゼッケン番号が画像分析により抽出され、友人が映っているカメラを特定することができる。このようにして、Tacit Computingにおいてライブデータ検索技術が用いられる。

次に、利用したいデバイスがライブデータ検索技術により特定された場合に、そのデバイスを実際に利用する必要がある。ＩｏＴデバイスは、多数のメーカーが開発しており、利用時のプロトコルやインタフェース、アドレス等がデバイス毎に異なる。そこで、デバイス仮想化技術によって、個々のデバイスにおけるインタフェースの違いを吸収する。
例えば、上記した例であれば、カメラ映像の取得のような共通のリクエストを元に、カメラを収容するゲートウェイ等で、デバイス毎のアダプタを設けておきプロトコル等の変換を行った上で、個々のカメラに応じたリクエストを行う。このようなデバイス仮想化技術を用いることにより、ユーザはデバイス個々の違いを意識せず、そのデバイスの利用が可能となる。

佐々木潤子、他５名、「Tacit Computing：オープンＩｏＴ・偏在リソース時代にむけたネットワークサービス」、株式会社ビジネスコミュニケーション社、ビジネスコミュニケーション、Vol.54、No.5、pp.24-25、May 2017

上記したTacit Computing技術により、ユーザが必要なライブデータを持つデバイスを発見し、デバイス仮想化の仕組みを用いて、個々のデバイスのインタフェース等を隠蔽することにより、ユーザがデバイスのアドホックな利用が可能となる。しかしながら、Tacit Computingを用いて、その時点の状況に合わせてデバイスを発見し利用するだけでは、ユーザのニーズに対し一時しか対応できないケースが考えられる。以下、具体的に説明する。

Tacit Computingの利用例として追跡カメラを考える。追跡カメラによるサービスは、小学生等の子供の学内や登下校中の映像を、子供近傍のカメラから取得し、親の携帯端末等で見るというものである。このサービスは、追跡カメラで親が子供の安全を映像で確認することによりその時点でも親にニーズを満たすことができる。しかしながら、このサービスを１回毎の料金設定により課金した場合には、その都度ライブデータの検索のため、画像処理機能を、カメラを収容するゲートウェイやネットワークエッジ等に配置する必要があり、コストがかかってしまう。むしろ、子供近傍のカメラから映像を取得し続けるが、親は携帯端末等で見たい時には子供の映像を見られるとともに、見ていない時にも機械学習等により子供を見守り、登下校中に不審者が近づいた等の異常時には親にアラートを送る等の継続的なサービスの提供が求められると考える。

追跡カメラの処理としては、Tacit Computingで子供が映っているカメラを発見し、親のリクエスト時はそのカメラの映像を親の携帯端末等に配信するとともに、見守りのため、カメラを収容するゲートウェイまたはネットワークエッジのＳＳＥ（Subscriber Service Edge）等に画像処理する機能（例えば、OpenCVライブラリ等）を配置し、子供が映っているカメラの映像から画像の切り出し分析を行う。そして、画像分析した結果は、特徴ベクトルにサマライズされた後集約され、クラウドレイヤにおいて、不審者が近づいている等の異常値分析を機械学習の手法（Local Outlier Factor等）を用いて解析し、異常がある場合には親の携帯端末等にアラートを送信する。

追跡カメラ自体は、Tacit Computingの技術を用いなくても、カメラと機械学習等を使ったＳＩサービスとして実現することはできる。しかしながら、Tacit Computing等の従来技術を使用した場合であっても、利用可能なデバイスを発見し、そのデバイスを継続的に利用するサービスをリーズナブルに、つまりコストを抑えて提供することは実現されていない。

このような点に鑑みて本発明がなされたのであり、ＩｏＴデバイスを動的に発見し利用するサービスを、継続してリーズナブルに提供することができる、デバイス連携サーバおよびデバイス連携プログラムを提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、前記サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、前記デバイスレイヤに属する各デバイスの前記サービスに関する利用履歴を収集する利用履歴収集部と、収集された前記利用履歴を参照し、前記クラウドレイヤ、前記ネットワークレイヤ、前記デバイスレイヤの３層の一つないし複数を、前記サービスに関する機能の配置先として決定する機能配置先決定部と、前記サービスに関する機能を、前記決定した３層の一つないし複数のレイヤに配信する機能配信部と、を備えることを特徴とするデバイス連携サーバとした。

このように、デバイス連携サーバは、最適化期間に収集したデバイスの利用履歴に基づき、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層のうちのいずれかを、サービスに関する機能の配置先として決定することができる。これにより、サービスで実際に利用されるデバイスに関連するレイヤのリソースに機能配置することができるため、当該サービスを継続してリーズナブルに提供することができる。

請求項２に記載の発明は、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、前記サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、前記デバイスレイヤに属する各デバイスの前記サービスに関する利用履歴を収集する利用履歴収集部と、収集された前記利用履歴を参照し、前記最適化期間中に利用されたデバイスが属するエリアのゲートウェイを、前記サービスに関する機能の配置先として決定する機能配置先決定部と、前記サービスに関する機能を、決定した当該ゲートウェイに配信する機能配信部と、を備えることを特徴とするデバイス連携サーバとした。

このように、デバイス連携サーバは、最適化期間に収集したデバイスの利用履歴に基づき、サービス提供に使用するデバイスを収容するゲートウェイに、そのサービスを実現するための機能を配置することができる。よって、分析機能が不要なエリアのゲートウェイに対し機能配置する必要がなく、サーバコストや通信コストを削減することができる。これにより、サービスを継続してリーズナブルに提供することが可能となる。

請求項３に記載の発明は、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、前記サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、前記デバイスレイヤに属する各デバイスの前記サービスに関する利用履歴を収集する利用履歴収集部と、収集された前記利用履歴を参照し、前記最適化期間中に利用されたデバイスが属するエリアのゲートウェイに接続される前記ネットワークレイヤのネットワークエッジを、前記サービスに関する機能の配置先として決定する機能配置先決定部と、前記サービスに関する機能を、決定した当該ネットワークエッジに配信する機能配信部と、を備えることを特徴とするデバイス連携サーバとした。

このように、デバイス連携サーバは、最適化期間に収集したデバイスの利用履歴に基づき、サービス提供に使用するデバイスを収容するゲートウェイに接続されるネットワークエッジに、そのサービスを実現するための機能を配置することができる。よって、分析機能が不要な他のネットワークエッジ等に対し機能配置する必要がなく、サーバコストや通信コストを削減することができる。これにより、デバイスレイヤのゲートウェイに機能配置できない場合であっても、サービスを継続してリーズナブルに提供することが可能となる。

請求項４に記載の発明は、前記決定したネットワークエッジが属するネットワークにおいて、前記サービスの提供に関する帯域確保および優先制御を含むネットワーク設定を実行させるネットワーク設定部を、さらに備えることを特徴とする請求項３に記載のデバイス連携サーバとした。

このようにすることで、デバイス連携サーバは、最適化期間に収集したデバイスの利用履歴に基づき機能配置先として決定されたネットワークエッジが属するネットワークについて、ネットワーク設定を行うことが可能となる。

請求項５に記載の発明は、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、前記サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、前記デバイスレイヤに属する各デバイスの前記サービスに関する利用履歴を収集する利用履歴収集部と、収集された前記利用履歴を参照し、前記最適化期間中に利用されたデバイスが属するエリアのゲートウェイ、または、当該ゲートウェイに接続される前記ネットワークレイヤのネットワークエッジを、前記サービスに関する機能の配置先として決定する機能配置先決定部と、前記サービスに関する機能を、当該決定したゲートウェイまたはネットワークエッジに配信する機能配信部と、収集された前記利用履歴を参照し、前記最適化期間中に利用頻度が最も多いデバイスを収容するネットワークエッジを抽出し、前記抽出したネットワークエッジとの間の遅延が最も少ないクラウドのクラウドサーバの処理機能をデプロイし、当該処理機能に必要なリソースサイズを確保するリソース確保処理部と、を備えることを特徴とするデバイス連携サーバとした。

このように、デバイス連携サーバは、最適化期間に収集したデバイスの利用履歴に基づき、利用頻度が最も多いデバイスを収容するネットワークエッジを抽出し、その抽出したネットワークエッジとの遅延が最も少ないクラウドサーバの処理機能をデプロイし、リソースサイズを確保することができる。よって、通信コストを削減できるとともに、処理機能が必要なクラウドサーバのみについてリソースサイズを確保するため、サービスを継続してリーズナブルに提供することが可能となる。

請求項６に記載の発明は、前記クラウドレイヤは、ＧＰＵとＣＰＵのヘテロデバイスを備えるヘテロクラウドにより構成されており、前記クラウドサーバにデプロイする処理機能の一部である特定処理を前記ＧＰＵにオフロードするオフロード設定部をさらに備え、前記オフロード設定部は、遺伝的アルゴリズムに基づき、前記デプロイする処理機能を実現するアプリケーションのソースコードを分析し、前記ＧＰＵの並列可否を試行する繰り返し処理の文の数から遺伝子長を定めて、所定の個体数の遺伝子を作成し、前記繰り返し処理の文について、前記ＧＰＵで並列処理するか、または、前記ＧＰＵで並列処理しないかを、遺伝子値として前記遺伝子に該当する前記ソースコードに割り当て、検証用クラウドサーバにデプロイすることにより性能測定を行い、前記性能測定の結果に基づき、各遺伝子の適合度を設定し、設定した適合度の値が高い遺伝子を所定の個体数選択し、所定の交叉率で、選択された個体間において一部の遺伝子である一点で交換し、子の個体を作成し、所定の突然変異率で、当該作成した個体の遺伝子の各遺伝子値を変更し、前記遺伝的アルゴリズムの処理を、所定の世代数繰り返し、最高適合度に該当するソースコードを解として算出し、前記クラウドサーバにデプロイさせることを特徴とする請求項５に記載のデバイス連携サーバとした。

このようにすることで、デバイス連携サーバは、遺伝的アルゴリズムを用いて、ＧＰＵへオフロードする処理を特定することができるため、処理を高速化することが可能となる。

請求項７に記載の発明は、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、前記サービスを提供する処理を前記３層のレイヤそれぞれで行う際の、サーバコストおよびネットワークコストを含むコストと、スループットおよび遅延を含む性能と、を各サービスの処理毎にパラメータとして保持し、前記サービスの処理機能をどこに配置し、どのリソースを確保するかを、コストが所定値以下になるような制約条件で性能を大きくすること、性能が所定値以上になるような制約条件でコストを小さくすること、を目的として組合せ最適化問題を解くことにより、機能確保およびリソース確保を行うことを特徴とするデバイス連携サーバ。

このようにすることで、デバイス連携サーバは、デバイスレイヤ、ネットワークレイヤ、クラウドレイヤの全てを考慮した上で、最適なレイヤに機能配置を行い、リソース確保することができる。よって、ユーザが所望するサービスを、継続してリーズナブルに提供することが可能となる。

請求項８に記載の発明は、コンピュータを、請求項１乃至請求項７のいずれか１項に記載のデバイス連携サーバとして機能させるためのデバイス連携プログラムとした。

このようにすることにより、一般的なコンピュータを用いて、請求項１乃至請求項７のいずれか１項に記載のデバイス連携サーバの各機能を実現させることができる。

本発明によれば、ＩｏＴデバイスを動的に発見し利用するサービスを、継続してリーズナブルに提供する、デバイス連携サーバおよびデバイス連携プログラムを提供することができる。

本実施形態に係るデバイス連携サーバを含むTacit Computingシステムを示す図である。 本発明の第１実施形態に係るデバイス連携サーバの構成例を示す機能ブロック図である。 本発明の第２実施形態に係るデバイス連携サーバの構成例を示す機能ブロック図である。 本発明の第２実施形態の変形例に係るデバイス連携サーバの構成例を示す機能ブロック図である。 本発明の第３実施形態に係るデバイス連携サーバの構成例を示す機能ブロック図である。 本発明の第３実施形態の変形例に係るデバイス連携サーバの構成例を示す機能ブロック図である。 Tacit Computingの概要を説明するための図である。

次に、本発明を実施するための形態（以下、「本実施形態」と称する。）における、デバイス連携サーバ１等について説明する。
図１は、本実施形態に係るデバイス連携サーバ１を含むTacit Computingシステムを示す図である。
本実施形態に係るTacit Computingシステムは、図７に示した従来のTacit Computingの構成に加え、デバイス連携サーバ１を含むことを特徴とする。デバイス連携サーバ１は、クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層に位置する各装置と通信可能に接続され、ユーザが所望するサービスを実現するための各種機能の配置や処理オフロードの最適化を行う装置である。

図７に示すような従来のTacit Computingによるシステムでは、デバイスをアドホックに発見し利用する際に、まずサービスを提供できることが前提となるため、コストや性能は考慮されない。しかしながら、サービスを継続的にかつリーズナブルに提供するためには、性能向上等を行うことによる運用コストの低減が必要となる。

そこで、本実施形態に係るデバイス連携サーバ１を含むTacit Computingシステムでは、デバイスレイヤ、ネットワークレイヤ、クラウドレイヤのそれぞれのレイヤにおいて、機能配置や処理オフロードを適切に行うことによる最適化を実行する。この最適化は、最初のアドホックなデバイス利用期間中（以下に示す「最適化期間中）」）に行う。例えば、追跡カメラのサービスであれば、初日を試し利用期間（所定の試用期間）として最適化期間を設定し、追跡対象となる子供近傍のカメラ映像を親の携帯端末で確認できるようにする。この最適化期間における、デバイス、ネットワーク、クラウドの利用履歴の情報を収集することにより、デバイス連携サーバ１が最適な機能配置を、デバイスレイヤ、ネットワークレイヤ、クラウドレイヤのいずれか（一つないし複数）に決定する。これにより、例えば、その初日の試し利用期間（最適化期間）の日以降は、リーズナブルな価格での追跡カメラのサービスを提供できるようにする。

以下、本実施形態に係るデバイス連携サーバ１が、Tacit Computingシステムにおけるデバイス利用を継続的にかつリーズナブルなサービスとして提供する際の構成例について、第１実施形態から第３実施形態として説明する。

＜第１実施形態＞
第１実施形態は、最適化をデバイスレイヤにおいて実行する例である。
第１実施形態に係るデバイス連携サーバ１Ａ（図２参照）を含むTacit Computingシステムでは、最適化期間中に収集した利用履歴に基づき、デバイスレイヤにおいてサービス提供のために使用するデバイスを特定するとともに、その特定したデバイスが属するエリアのゲートウェイ１０（図１参照）に、そのサービスを実現するための機能を配置する（機能配置する）ことを特徴とする。

デバイスレイヤでは、ユーザが所望するサービスを実現するためにデバイスの切替を随時行う場合が想定される。例えば、追跡カメラのサービスであれば、子供が存在する場所に応じてその子供の映像が映っているカメラ（デバイス）を選択してゆくことが必要となる。このとき、ネットワークに繋がる全カメラ（デバイス）において画像解析をし、対象とする子供が映っているカメラの映像だけを使うのであれば、非常にコスト（処理コスト、通信コスト）が高くなってしまう。よって、最適化期間において、子供の位置情報を所定の手法により取得し、カメラのメタデータで示されるそのカメラの設置場所等の情報に基づき、その子供の近傍に存在するカメラを選択する処理を行う。

また、デバイスレイヤでは、デバイスを収容するゲートウェイ１０群の中から、どのゲートウェイ１０に分析のための機能配置を行うかが、コスト（処理コスト、通信コスト）に大きく影響する。追跡カメラであれば、例えばOpenCV等の画像分析機能を使うが、子供が通るエリアのゲートウェイ１０を最適化期間において特定し、その特定したゲートウェイ１０に対し画像分析機能を配置して処理を行う。

図２は、本発明の第１実施形態に係るデバイス連携サーバ１Ａの構成例を示す機能ブロック図である。デバイス連携サーバ１Ａは、サービスを提供するための機能配置の最適化をデバイスレイヤにおいて実行する装置である。
このデバイス連携サーバ１Ａは、図２に示すように、制御部１１と、入出力部１２と、記憶部１３とを含んで構成される。

入出力部１２は、クラウドレイヤ、ネットワークレイヤおよびデバイスレイヤに属する各デバイス等との間で情報の送受信を行うための通信インタフェースと、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースとから構成される。

記憶部１３は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等により構成される。
この記憶部１３には、デバイス情報ＤＢ１３１および配信機能情報ＤＢ１３２が記憶されるとともに、制御部１１の各機能を実行させるためのプログラム（デバイス連携プログラム）や、制御部１１の処理に必要な情報（例えば、デバイスの利用履歴）が一時的に記憶される。

ここで、デバイス情報ＤＢ１３１には、デバイスレイヤに存在する各デバイスのメタデータが格納される。このデバイスのメタデータには、少なくとも、デバイスの識別情報、デバイスの種別（カメラ等のデバイスの機能等を示す情報）、デバイスの位置情報が格納される。
また、配信機能情報ＤＢ１３２には、デバイス連携サーバ１Ａが、利用するデバイスを収容するゲートウェイ１０に配置する機能（処理プログラム）が格納される。例えば、追跡カメラのサービスであれば、OpenCV等の画像分析機能を実現する処理プログラムが格納される。

制御部１１は、デバイス連携サーバ１Ａ全体の制御を司り、位置情報取得部１１１と、デバイス選択部１１２と、利用履歴収集部１１３と、機能配置先決定部１１４と、機能配信部１１５とを備える。
また、この制御部１１は、例えば、記憶部１３に格納されたプログラム（デバイス連携プログラム）を不図示のＣＰＵ（Central Processing Unit）が、ＲＡＭに展開し実行することにより実現される。

位置情報取得部１１１は、所定の手法により、サービスの対象物（追跡カメラのサービスであれば追跡対象の子供）の位置情報を取得する。所定の手法としては、サービスの対象物に付された位置検出機能のより得られた位置情報を受信する。例えば、子供に携帯端末を保持させてＧＰＳによる位置情報を検出させ、その位置情報を位置情報取得部１１１が受信する。また、ＩｏＴのデバイスには、非ＩＰ（例えば、ＮＦＣ（Near Field Communication）のBluetooth等）が用いられる場合もあり、非ＩＰの機器を含めて、ＩｏＴデバイスの通信パターンを解析し、位置情報を取得するようにしてもよい。
また、位置情報取得部１１１は、最適化期間中において、位置情報取得部１１１が取得した位置情報を、デバイス選択部１１２に出力する。

デバイス選択部１１２は、位置情報取得部１１１が取得した位置情報に基づき、記憶部１３内のデバイス情報ＤＢ１３１を検索し、ユーザが所望するサービスを実現するためのデバイスであり、取得した位置情報で示される位置の近傍に位置するデバイスを選択する。

利用履歴収集部１１３は、最適化期間において、ユーザ所望のサービスで利用したデバイスの利用状況を示す情報（利用履歴）を取得する。この利用履歴は、例えば、追跡カメラのサービスであれば、追跡対象の子供が最適化期間において映っていたか否かを示す情報が、そのカメラ（デバイス）の識別情報とともに収集される。

機能配置先決定部１１４は、利用履歴収集部１１３が収集した利用履歴を参照し、最適化期間中に利用されたデバイスの履歴に基づき、分析機能を配置するエリアのゲートウェイ１０を決定する。

機能配信部１１５は、機能配置先決定部１１４が決定した機能の配置対象となるゲートウェイ１０に対し、記憶部１３内の配信機能情報ＤＢ１３２に格納された機能（処理プログラム）を抽出して配信する。機能配信部１１５は、例えば、追跡カメラのサービスであれば、OpenCV等の画像分析機能を実現する処理プログラムを、機能配置先決定部１１４が配置先に決定したゲートウェイ１０に対し配信する。
なお、機能配信部１１５は、最適化期間中において、デバイス選択部１１２が選択したデバイスを収容するゲートウェイ１０に対し、配信機能情報ＤＢ１３２に格納された機能（処理プログラム）を抽出して配信するようにし、当該ゲートウェイ１０のうち、機能配置先決定部１１４において、分析機能を配置するエリアのゲートウェイ１０として決定されなかったゲートウェイ１０の分析機能を削除するようにしてもよい。

このように、第１の実施形態に係るデバイス連携サーバ１Ａによれば、最適化期間中に収集した利用履歴に基づき、デバイスレイヤにおいてサービス提供するために使用するデバイスを特定するとともに、その特定したデバイスを収容するゲートウェイ１０に、そのサービスを実現するための機能を配置することができる。
よって、分析機能が不必要なエリアのゲートウェイ１０に対し機能配置する必要がない。これにより、不必要なトラフィックの増大を防ぎ、通信コストを削減することができる。また、利用されないデバイスのみを収容するゲートウェイ１０については、不必要な処理に伴うサーバコストを削減することができる。これにより、第１の実施形態に係るデバイス連携サーバ１Ａによれば、ＩｏＴデバイスを動的に発見し利用するサービスを、継続してリーズナブルに提供することが可能となる。

＜第２実施形態＞
第２実施形態は、最適化をネットワークレイヤにおいて実行する例である。
第２実施形態に係るデバイス連携サーバ１Ｂ（図３参照）を含むTacit Computingシステムでは、最適化期間中に収集した利用履歴に基づき、デバイスレイヤにおいてサービス提供のために使用するデバイスを特定するとともに、その特定したデバイスが属するエリアのゲートウェイ１０と接続されるネットワークレイヤに属するネットワークエッジ２０（図１参照）に、そのサービスを実現するための機能を配置する（機能配置する）ことを特徴とする。

Tacit Computingシステムでは、図７において説明したように、より低いレイヤで処理を行うのが原則となる。よって、できるだけ各デバイスが属するエリアのゲートウェイ１０に機能配置することが望ましいが、ゲートウェイ１０の種類や性能によっては、そのサービスを実現する処理プログラムを動作させることができない場合もある。そのような場合に、第２の実施形態に係るデバイス連携サーバ１Ｂは、ネットワークレイヤのネットワークエッジ２０に機能配置を行う。
なお、ネットワークエッジ２０は、ＮＧＮ（Next Generation Network）であれば、アクセスネットワークとコアネットワークとを接続するエッジルータであり、例えば、ＳＳＥ（Subscriber Service Edge）等である。

図３は、本発明の第２実施形態に係るデバイス連携サーバ１Ｂの構成例を示す機能ブロック図である。デバイス連携サーバ１Ｂは、サービスを提供するための機能配置の最適化をネットワークレイヤにおいて実行する装置である。
図２において示したデバイス連携サーバ１Ａとの違いは、機能配置先決定部１１４、機能配信部１１５が、図３のデバイス連携サーバ１Ｂでは、機能配置先決定部１１４Ｂ、機能配信部１１５Ｂとなっている点である。なお、デバイス連携サーバ１Ａと同様の機能を備える構成については、同一の名称と符号を付し説明を省略する。

機能配置先決定部１１４Ｂは、利用履歴収集部１１３が収集した利用履歴を参照し、最適化期間中に利用されたデバイスの履歴に基づき、その利用されたデバイスの属するエリアのゲートウェイ１０と接続されるネットワークレイヤのネットワークエッジ２０を、分析機能を配置するネットワークエッジ２０として決定する。
なお、機能配置先決定部１１４Ｂは、情報指向ネットワーク（コンテンツ指向ネットワーク）の技術を用いて、利用されたデバイスの属するエリアのゲートウェイ１０に隣接するエッジルータを抽出し、分析機能を配置するネットワークエッジ２０として決定するようにしてもよい。なお、情報指向ネットワークについては、例えば、非特許文献２（朝枝 仁、「情報指向ネットワークがもたらす可能性と研究課題」、情報通信研究機構研究報告、Vol.61 No.2、2015）に詳しい。

機能配信部１１５Ｂは、機能配置先決定部１１４Ｂが決定した機能の配置先となるネットワークエッジ２０に対し、記憶部１３内の配信機能情報ＤＢ１３２に格納された機能（処理プログラム）を抽出して配信する。
なお、機能配信部１１５Ｂは、最適化期間中において、デバイス選択部１１２が選択したデバイスを収容するゲートウェイ１０に接続するネットワークエッジ２０に対し、配信機能情報ＤＢ１３２に格納された機能（処理プログラム）を抽出して配信するようにし、機能配置先決定部１１４Ｂにおいて、分析機能を配置するネットワークエッジ２０として決定されなかったネットワークエッジ２０の分析機能を削除するようにしてもよい。

このように、第２の実施形態に係るデバイス連携サーバ１Ｂによれば、最適化期間中に収集した利用履歴に基づき、デバイスレイヤにおいてサービス提供するために使用するデバイスを特定するとともに、その特定したデバイスを収容するゲートウェイ１０と接続するネットワークレイヤのネットワークエッジ２０に、そのサービスを実現するための機能を配置することができる。
よって、サービス提供するために使用するデバイスが属するエリアのゲートウェイ１０に機能配置できない場合であっても、当該ゲートウェイ１０に接続するネットワークエリアのネットワークエッジ２０に機能配置することができる。また、分析機能が不要な他のネットワークエッジ２０に対し機能配置する必要をなくすことができる。これにより、不必要なトラフィックの増大を防ぎ、通信コストを削減することができる。また、利用されないデバイスのみを収容するゲートウェイ１０に接続するネットワークエッジ２０については、不必要な処理に伴うサーバコストを削減することができる。これにより、第２の実施形態に係るデバイス連携サーバ１Ｂによれば、ＩｏＴデバイスを動的に発見し利用するサービスを、継続してリーズナブルに提供することが可能となる。

＜第２実施形態の変形例＞
第２実施形態の変形例として、サービスの特性に応じて、ネットワークレイヤにおいて、帯域確保や優先制御等のネットワーク設定を実行する機能を備えるようにしてもよい。例えば、図３で示したデバイス連携サーバ１Ｂの構成に、図４に示すように、ネットワーク設定部１１６を追加して備えさせ、デバイス連携サーバ１Ｃとして構成する。
このネットワーク設定部１１６が、サービスを提供するに際しての帯域確保や優先制御をネットワークレイヤにおいて設定する。例えば、ＮＧＮであれば、ＲＡＣＦ（Resource and Admission Control Function）により帯域確保の機能を実現する。
このようにすることにより、デバイス連携サーバ１Ｃは、最適化期間の利用履歴に基づき、サービスを提供するためのネットワーク設定も行うことが可能となる。

＜第３実施形態＞
第３実施形態は、最適化をクラウドレイヤにおいて実行する例である。
第３実施形態に係るデバイス連携サーバ１Ｄ（図５参照）を含むTacit Computingシステムでは、最適化期間中に収集した利用履歴に基づき、デバイスレイヤにおいてサービス提供のために使用するデバイスを特定するとともに、その特定したデバイスが属するエリアのゲートウェイ１０またはそのゲートウェイ１０に接続されるネットワークレイヤに属するネットワークエッジ２０に、サービスを実現するための機能を配置する（機能配置する）。さらに、デバイス連携サーバ１Ｄは、利用頻度が多いデバイスを収容するネットワークエッジ２０との遅延が少ないＤＣ３０（図１参照）の選択し、そのＤＣ３０のクラウドサーバにおいて処理機能のリソースサイズを確保することを特徴とする。

例えば、追跡カメラのサービスであれば、ゲートウェイ１０またはネットワークエッジ２０において、配置された処理プログラムにより画像をサマライズして特徴ベクトルを抽出する。そして、その特徴ベクトルをＤＣ３０のクラウドサーバが取得し、機械学習等の手法で分析することにより不審者が近づいている等を解析してアラートを出力する。この場合において、デバイス連携サーバ１Ｄは、利用頻度の多いデバイスを収容するネットワークエッジ２０との遅延が少ないＤＣ３０を選択し、そのＤＣ３０のクラウドサーバに備わる、リアルタイムに発生するデータを処理する機能（例えば、Apache StormやApache Sparkのようなストリーム処理機能）をデプロイし、適切なリソースサイズを確保する。

図５は、本発明の第３実施形態に係るデバイス連携サーバ１Ｄの構成例を示す機能ブロック図である。デバイス連携サーバ１Ｄは、サービスを提供するための最適化をクラウドレイヤにおいて実行する装置である。
図２において示したデバイス連携サーバ１Ａとの違いは、機能配置先決定部１１４、機能配信部１１５が、図５のデバイス連携サーバ１Ｄでは、機能配置先決定部１１４Ｄ、機能配信部１１５Ｄとなっている点と、新たにリソース確保処理部１１７が備わる点である。なお、デバイス連携サーバ１Ａと同様の機能を備える構成については、同一の名称と符号を付し説明を省略する。

機能配置先決定部１１４Ｄは、利用履歴収集部１１３が収集した利用履歴を参照し、最適化期間中に利用されたデバイスの履歴に基づき、分析機能を配置するエリアのゲートウェイ１０、または、そのゲートウェイ１０と接続されるネットワークレイヤのネットワークエッジ２０を、分析機能の配置先として決定する。なお、機能配置先決定部１１４Ｄは、ゲートウェイ１０に分析機能を配置できる場合には、そのゲートウェイ１０を配置先として決定する。ただし、ゲートウェイ１０に処理プログラムが配置できない等により、そのゲートウェイ１０を配置先にできない場合には、当該ゲートウェイ１０に接続されるネットワークエッジ２０を、分析機能の配置先として決定する。

機能配信部１１５Ｄは、機能配置先決定部１１４Ｄが決定した分析機能の配置先となるゲートウェイ１０またはネットワークエッジ２０に対し、記憶部１３内の配信機能情報ＤＢ１３２に格納された機能（処理プログラム）を抽出して配信する。
なお、ここで機能配信部１１５Ｄが配信する処理プログラムは、例えば、追跡カメラのサービスであれば、追跡対象となる人物（子供）を画像認識（例えば、顔認識）する機能に加えて、画像認識して追跡対象となる人物（子供）が映っていると判定した映像をサマライズして特徴ベクトルを抽出する処理を実行する機能を備える。

リソース確保処理部１１７は、利用履歴収集部１１３が収集した利用履歴を参照し、最適化期間中に利用頻度が最も多いデバイスを収容するネットワークエッジ２０を抽出し、その抽出したネットワークエッジとの遅延が最も少ないＤＣ３０のクラウドにそのサービスに必要となる処理機能（例えば、特徴ベクトルから不審者が近づいている等を解析しアラートを出力する機能）をデプロイする。さらに、リソース確保処理部１１７は、当該処理を実行するために必要なリソースサイズを確保する。
リソース確保処理部１１７は、確保するリソースサイズについて、サービスに応じて予め設定しておいたリソースサイズを確保するようにしてもよいし、必要なリソースサイズとして初期値を定めておき、リソースの利用状況に応じて所定値を増加するように設定してもよい。

このようにすることで、第３実施形態に係るデバイス連携サーバ１Ｄによれば、最適化期間中に収集した利用履歴に基づき、デバイスレイヤにおいてサービス提供するために使用するデバイスを特定するとともに、ゲートウェイ１０またはネットワークエッジ２０に分析機能（処理プログラム）を配置することができる。また、デバイス連携サーバ１Ｄは、利用頻度が最も多いデバイスを収容するネットワークエッジ２０との遅延が最も少ないＤＣ３０のクラウドサーバに、サービスに必要な処理機能をデプロイし、リソースサイズを確保する。よって、全ＤＣ３０のクラウドの処理機能をデプロイし、リソースサイズを確保する場合に比べ、運用コストを削減することができる。これにより、第３実施形態に係るデバイス連携サーバ１Ｄによれば、ＩｏＴデバイスを動的に発見し利用するサービスを、継続してリーズナブルに提供することが可能となる。

＜第３実施形態の変形例＞
第３実施形態の変形例について説明する。
図６は、本発明の第３実施形態の変形例に係るデバイス連携サーバ１Ｅの構成例を示す機能ブロック図である。図５において示したデバイス連携サーバ１Ｄとの違いは、オフロード設定部１１８をさらに備えている点である。なお、デバイス連携サーバ１Ｄと同様の機能を備える構成については、同一の名称と符号を付し説明を省略する。

近年、クラウドでは、ＧＰＵ（Graphics Processing Unit）やＦＰＧＡ（Field Programmable Gate Array）等のヘトロジニアスなＨＷ（ハードウェア）（以下、「ヘトロデバイス」と称する。）を備えたサーバが増えてきている。例えば、Microsoft（登録商標）社のBing検索においても、ＦＰＧＡが利用されている。このように、へトロデバイスを活用し、例えば、行列計算等をＧＰＵにオフロードしたり、ＦＴＴ（Fast Fourier Transform）計算等の特定処理をＦＰＧＡにオフロードしたりすることで、高性能化を実現している。図６に示すデバイス連携サーバ１Ｅのオフロード設定部１１８は、特定処理についてオフロードする設定を、リソース確保処理部１１７がデプロイしたクラウドサーバに対して設定することを特徴とする。以下、オフロード設定部１１８が実行する２つの手法、（手法１）および（手法２）について説明する。

（オフロード設定部の手法１）
手法１においては、デバイス連携サーバ１Ｅの記憶部１３内に、行列計算等の特定処理のロジックを、ＧＰＵやＦＰＧＡ等のへトロデバイスにオフロードするパターンとして予め記憶しておく。そして、オフロード設定部１１８は、ユーザからのリクエストに特定処理が含まれていた場合、記憶部１３内に記憶したパターン（オフロードの処理記述、例えばOpenCL等）を抽出しクラウドサーバに対して設定を行う。

（オフロード設定部の手法２）
手法２は、特定処理における繰り返し文を、オフロード設定部１１８がＧＰＵ等のへトロデバイスにオフロードする最適化をその場で行う手法である。ＧＰＵ等による処理の高速化には、適切な領域の並列化が必要であり、自律的に適切な領域を抽出するため、例えば、遺伝的アルゴリズム（ＧＡ：Genetic Algorithm）等の手法が用いられる。遺伝的アルゴリズム（以下、「ＧＡ」と称する。）の手法により、特定処理の繰り返し文の並列可否を検証環境で試行反復し、抽出された最適並列領域を、ＰＧＩコンパイラ等（ＰＧＩは登録商標）により並列領域として指定する。これにより、オフロード設定部１１８は、コンパイラを用いてオフロード設定を行う。以下、ＧＰＵにオフロードする場合を例に、より詳細に説明する。

ＧＰＵは、レイテンシーを保証するものではないが、並列処理によりスループットを高めることができる。クラウドでユーザが動作させるアプリケーションを実行する、アプリケーションサーバやＤＢサーバでは繰り返し処理が多い。そこで、アプリケーションの繰り返し文をＧＰＵに自律的にオフロードすることで高速化する。
ただし、この高速化には適切な部分（アプリケーションの処理の一部）の並列化が必要であり、単純に繰り返しの部分を並列処理しただけでは性能がでない場合がある。この点に関し、ＰＧＩコンパイラを用いて、for文の並列可否を総当たりで最適化する試みがある。しかしながら、総当たりには多くの時間がかかり、クラウド事業では、ユーザの利用開始が遅くなってしまう問題があった。

そこで、本実施形態のデバイス連携サーバ１Ｅでは、自律的に適切なオフロード領域を抽出するため、オフロード設定部１１８が、ＧＡを用いた検証環境での性能試験の反復を行う。その際、トップとセカンドレベルのfor文のみをＧＡの組合せの対象とする。このオフロード設定部１１８の処理により、短時間で高性能となるオフロード領域を探索できるようにする。
このＧＡは、生物の進化過程を模倣した組合せ最適化手法の一つであり、初期化、評価、選択、交叉、突然変異、終了判定というフローで処理を進める。ここでは、Simple ＧＡの手法を用いる例で説明する。Simple ＧＡは、遺伝子を１，０のみとし、ルーレット選択、一点交叉、突然変異は１か所の遺伝子の値を逆にする等、単純化されたＧＡである。

初期化では、デプロイするアプリケーションのソースコードを分析し、最上段（トップレベル）と第二段（セカンドレベル）のfor文、while文を遺伝子配列にマッピングする。ここで、ＧＰＵ並列可否を試行する繰り返し処理の文の数から遺伝子長を定め、ＧＰＵで並列処理する場合は１、しない場合は０とする。遺伝子は所定の個体数Ｍが準備され、１つの遺伝子の値（遺伝子値）は全て１（全for文をＧＰＵオフロード）、１つの遺伝子は全て０（全ＣＰＵ処理）とし、残りをランダムに１，０を割り当てる。
評価では、遺伝子に該当するソースコードをビルドして検証用クラウドサーバにデプロイし、ベンチマーク性能測定を行う。そして、性能が良い遺伝子の適合度を高く設定する。
選択では、適合度に基づいて、高い適合度の遺伝子を所定の個体数選択する。ここでは、適合度に応じたルーレット選択および最高適合度遺伝子のエリート選択を行う。
交叉では、所定の交叉率Ｐｃで、選択された個体間において一部の遺伝子である一点で交換し、子の個体を作成する。
突然変異では、所定の突然変異率Ｐｍで、個体の遺伝子の各値を、０から１、または、１から０に変更する。
終了判定では、所定の世代数であるＴ回、繰り返し処理を行った後で終了し、最高適合度の遺伝子を解とする。
そして、オフロード設定部１１８は、最高適合度の遺伝子に該当する、最高性能のソースコードのパターンで、リソース確保処理部１１７が配置を決定したクラウドサーバにデプロイする。

このようにすることで、第３実施形態の変形例に係るデバイス連携サーバ１Ｅによれば、利用頻度が最も多いデバイスを収容するネットワークエッジ２０との遅延が最も少ないＤＣ３０のクラウドサーバに、サービスに必要な処理機能をデプロイし、リソースサイズを確保できるとともに、へトロデバイス（例えば、ＧＰＵ）にオフロード処理することにより、処理をさらに高速化することが可能となる。

以上説明したように、本実施形態に係るデバイス連携サーバ１Ａ〜１Ｅでは、デバイスレイヤ、ネットワークレイヤ、クラウドレイヤのそれぞれでの各種機能の最適配置や処理オフロードを実現することができる。ただし、サービスの利用形態によっては、例えば、どこに機能配置するのが適切かが変わってくる場合がある。そこで、デバイス連携サーバ１は、各処理を、各レイヤで実行する場合のコストと性能とをモデル化し、どこに配置するのが適切かを計算するようにしてもよい。ここでのコストは、例えば、リソース確保のためのサーバコスト、発生トラフィックに基づくネットワークコストである。また、性能は、例えば、スループットや遅延である。
デバイス連携サーバ１は、このコストと性能をパラメータとして保持し、処理機能をどこに配置し、どこのリソースを確保するのが適切かについて、「コストが所定値以下になるような制約条件で性能を大きくする」、「性能が所定値以上になるような制約条件でコストを小さくする」を目的として組合せ最適化問題を解くことにより、機能配置とリソース確保を行うようにする。
なお、この組合せ最適化問題を、限られた最適化期間中に解を発見できるようにするため、遺伝的アルゴリズム（ＧＡ）の手法を用いてもよい。

このようにすることにより、デバイス連携サーバ１は、３つのレイヤ（デバイスレイヤ、ネットワークレイヤ、クラウドレイヤ）の全てを考慮した上で、最適なレイヤに機能配置を行い、リソース確保することができる。これにより、ユーザが所望するサービスを、継続してリーズナブルに提供することができる。

１，１Ａ，１Ｂ，１Ｃ，１Ｄ，１Ｅ デバイス連携サーバ
１０ ゲートウェイ
１１ 制御部
１２ 入出力部
１３ 記憶部
２０ ネットワークエッジ
３０ ＤＣ（データセンタ）
１１１ 位置情報取得部
１１２ デバイス選択部
１１３ 利用履歴収集部
１１４，１１４Ｂ，１１４Ｄ 機能配置先決定部
１１５，１１５Ｂ，１１５Ｄ 機能配信部
１１６ ネットワーク設定部
１１７ リソース確保処理部
１１８ オフロード設定部
１３１ デバイス情報ＤＢ
１３２ 配信機能情報ＤＢ

Claims (8)

1. クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、
   前記サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、前記デバイスレイヤに属する各デバイスの前記サービスに関する利用履歴を収集する利用履歴収集部と、
   収集された前記利用履歴を参照し、前記クラウドレイヤ、前記ネットワークレイヤ、前記デバイスレイヤの３層の一つないし複数を、前記サービスに関する機能の配置先として決定する機能配置先決定部と、
   前記サービスに関する機能を、前記決定した３層の一つないし複数のレイヤに配信する機能配信部と、
   を備えることを特徴とするデバイス連携サーバ。
2. クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、
   前記サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、前記デバイスレイヤに属する各デバイスの前記サービスに関する利用履歴を収集する利用履歴収集部と、
   収集された前記利用履歴を参照し、前記最適化期間中に利用されたデバイスが属するエリアのゲートウェイを、前記サービスに関する機能の配置先として決定する機能配置先決定部と、
   前記サービスに関する機能を、決定した当該ゲートウェイに配信する機能配信部と、
   を備えることを特徴とするデバイス連携サーバ。
3. クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、
   前記サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、前記デバイスレイヤに属する各デバイスの前記サービスに関する利用履歴を収集する利用履歴収集部と、
   収集された前記利用履歴を参照し、前記最適化期間中に利用されたデバイスが属するエリアのゲートウェイに接続される前記ネットワークレイヤのネットワークエッジを、前記サービスに関する機能の配置先として決定する機能配置先決定部と、
   前記サービスに関する機能を、決定した当該ネットワークエッジに配信する機能配信部と、
   を備えることを特徴とするデバイス連携サーバ。
4. 前記決定したネットワークエッジが属するネットワークにおいて、前記サービスの提供に関する帯域確保および優先制御を含むネットワーク設定を実行させるネットワーク設定部を、
   さらに備えることを特徴とする請求項３に記載のデバイス連携サーバ。
5. クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、
   前記サービスの提供に際して、利用するリソースを決定するために設けられる所定の試用期間を示す最適化期間において、前記デバイスレイヤに属する各デバイスの前記サービスに関する利用履歴を収集する利用履歴収集部と、
   収集された前記利用履歴を参照し、前記最適化期間中に利用されたデバイスが属するエリアのゲートウェイ、または、当該ゲートウェイに接続される前記ネットワークレイヤのネットワークエッジを、前記サービスに関する機能の配置先として決定する機能配置先決定部と、
   前記サービスに関する機能を、当該決定したゲートウェイまたはネットワークエッジに配信する機能配信部と、
   収集された前記利用履歴を参照し、前記最適化期間中に利用頻度が最も多いデバイスを収容するネットワークエッジを抽出し、前記抽出したネットワークエッジとの間の遅延が最も少ないクラウドのクラウドサーバの処理機能をデプロイし、当該処理機能に必要なリソースサイズを確保するリソース確保処理部と、
   を備えることを特徴とするデバイス連携サーバ。
6. 前記クラウドレイヤは、ＧＰＵとＣＰＵのヘテロデバイスを備えるヘテロクラウドにより構成されており、
   前記クラウドサーバにデプロイする処理機能の一部である特定処理を前記ＧＰＵにオフロードするオフロード設定部をさらに備え、
   前記オフロード設定部は、遺伝的アルゴリズムに基づき、
   前記デプロイする処理機能を実現するアプリケーションのソースコードを分析し、前記ＧＰＵの並列可否を試行する繰り返し処理の文の数から遺伝子長を定めて、所定の個体数の遺伝子を作成し、
   前記繰り返し処理の文について、前記ＧＰＵで並列処理するか、または、前記ＧＰＵで並列処理しないかを、遺伝子値として前記遺伝子に該当する前記ソースコードに割り当て、検証用クラウドサーバにデプロイすることにより性能測定を行い、
   前記性能測定の結果に基づき、各遺伝子の適合度を設定し、
   設定した適合度の値が高い遺伝子を所定の個体数選択し、
   所定の交叉率で、選択された個体間において一部の遺伝子である一点で交換し、子の個体を作成し、
   所定の突然変異率で、当該作成した個体の遺伝子の各遺伝子値を変更し、
   前記遺伝的アルゴリズムの処理を、所定の世代数繰り返し、最高適合度に該当するソースコードを解として算出し、前記クラウドサーバにデプロイさせること
   を特徴とする請求項５に記載のデバイス連携サーバ。
7. クラウドレイヤ、ネットワークレイヤ、デバイスレイヤの３層から、リソースを選択してサービスを提供させるデバイス連携サーバであって、
   前記サービスを提供する処理を前記３層のレイヤそれぞれで行う際の、サーバコストおよびネットワークコストを含むコストと、スループットおよび遅延を含む性能と、を各サービスの処理毎にパラメータとして保持し、
   前記サービスの処理機能をどこに配置し、どのリソースを確保するかを、
   コストが所定値以下になるような制約条件で性能を大きくすること、
   性能が所定値以上になるような制約条件でコストを小さくすること、
   を目的として組合せ最適化問題を解くことにより、機能確保およびリソース確保を行うこと
   を特徴とするデバイス連携サーバ。
8. コンピュータを、請求項１乃至請求項７のいずれか１項に記載のデバイス連携サーバとして機能させるためのデバイス連携プログラム。

Images