JP7176295B2 - 判定装置、ゲートウェイ、判定方法及び判定プログラム - Google Patents

Description

本発明は、判定装置、ゲートウェイ、判定方法及び判定プログラムに関する。

従来、ＩｏＴ（Internet of things）デバイスの故障の判定は、死活監視のためのスクリプトや各デバイスからのアラームによる状態監視、及び動作の正常性を確認するコマンドの実行等により行われている（例えば、非特許文献１及び２を参照）。

日本ユニシス、「IoTデバイス管理機能」、[online]、[２０１８年８月３日検索]、インターネット（https://www.unisys.co.jp/solution/tec/iot/bp/bp02.html） 日立ソリューションズ、「ＩｏＴ／Ｍ２Ｍデータ収集・分析・活用基盤のご紹介」、[online]、[２０１８年８月３日検索]、インターネット（https://www.hitachi-solutions.co.jp/reports/dms2016/pdf/presentation06.pdf）

しかしながら、従来の故障の判定手法には、手順が複雑、かつ余分な通信コストが発生する場合があるという問題がある。

例えば、動作の正常性を確認するコマンドを実行する方法には、各デバイスの動作に合わせたコマンドを用意する必要があり、対応が複雑になるという問題がある。また、故障の判定の際に、上記のスクリプト、アラーム、コマンドのいずれを使う場合であっても、各データの分析のため、デバイスと管理用のクラウド等との間でのデータの通信のためのコストが発生する。通信コストとしては、例えば、キャリアネットワークにおける処理負荷、及びユーザの通信料金等が考えられる。

上述した課題を解決し、目的を達成するために、判定装置は、ネットワークに接続されたデバイスからデータが送信される際に生じるトラヒックの情報を収集する収集部と、前記収集部によって収集されたトラヒックの情報が、各デバイスのトラヒックのパターンを基にあらかじめ設定された判定条件を満たす場合、前記トラヒックを生じさせたデバイスに異常が生じていると判定する判定部と、を有することを特徴とする。

本発明によれば、容易かつ低コストでＩｏＴデバイスの故障の判定を行うことができる。

図１は、第１の実施形態に係る判定処理の一例を示す図である。 図２は、第１の実施形態に係る判定処理の一例を示す図である。 図３は、第１の実施形態に係る判定パターンについて説明するための図である。 図４は、第１の実施形態に係る判定パターンについて説明するための図である。 図５は、第１の実施形態に係る判定パターンについて説明するための図である。 図６は、第１の実施形態に係る判定パターンについて説明するための図である。 図７は、第１の実施形態に係る仮想ＣＰＥの構成の一例を示す図である。 図８は、第１の実施形態に係るＩｏＴゲートウェイの構成の一例を示す図である。 図９は、第１の実施形態に係る仮想ＣＰＥが記憶する情報の一例を示す図である。 図１０は、第１の実施形態に係るＩｏＴゲートウェイが記憶する情報の一例を示す図である。 図１１は、第１の実施形態に係る判定システムの処理の流れを示すシーケンス図である。 図１２は、判定プログラムを実行するコンピュータの一例を示す図である。

以下に、本願に係る判定装置、ゲートウェイ、判定方法及び判定プログラムの実施形態を図面に基づいて詳細に説明する。なお、本発明は、以下に説明する実施形態により限定されるものではない。なお、実施形態における仮想ＣＰＥは、判定装置の一例である。

［第１の実施形態］
まず、図１を用いて、判定装置を有する判定システムによって行われる判定処理ついて説明する。図１は、第１の実施形態に係る判定処理の一例を示す図である。図１に示すように、判定システム１は、クラウドサーバ１０、仮想ＣＰＥ（Customer Premises Equipment）２０、ＩｏＴゲートウェイ３０、運用者端末４０及びＩｏＴデバイス５０を有する。

クラウドサーバ１０は、クラウドネットワーク３に備えられている。また、仮想ＣＰＥ２０は、クラウドネットワーク３とキャリアネットワーク２との間に備えられている。また、ＩｏＴゲートウェイ３０は、キャリアネットワーク２に接続されている。また、運用者端末４０は、判定システム１の運用者によって操作される端末である。運用者端末４０は、仮想ＣＰＥ２０との間でデータの送受信を行うことができる。

ＩｏＴデバイス５０は、ＩｏＴゲートウェイ３０に収容される。例えば、ＩｏＴデバイス５０は、監視カメラ、自動車、ドローン、家電及び各種センサ等である。ＩｏＴデバイス５０は、トラヒックパターンに従って所定のデータをクラウドサーバ１０に送信する。ここで、例えば、トラヒックパターンには、常時通信、定期通信、不定期（ランダム）通信がある。

ＩｏＴデバイス５０がデータを常時送信し続ける場合、トラヒックパターンは常時通信である。また、ＩｏＴデバイス５０が所定の時間周期（例えば、１分に１回）でデータを送信する場合、トラヒックパターンは定期通信である。また、ＩｏＴデバイス５０が所定の処理が行われたタイミング又はランダムなタイミングでデータを送信する場合、トラヒックパターンは不定期通信である。

ここで、判定処理について説明する。まず、図１に示すように、ＩｏＴデバイス５０は、設置されると、ＩｏＴゲートウェイ３０、キャリアネットワーク２及び仮想ＣＰＥ２０を介して、クラウドサーバ１０にデータを送信する（ステップＳ１）。

ここで、ＩｏＴデバイス５０が設定されると、運用者端末４０は、運用者の操作により、ＩｏＴデバイス５０に関する情報を仮想ＣＰＥ２０に入力する（ステップＳ２）。そして、運用者端末４０は、運用者の操作により、仮想ＣＰＥ２０に対し、判定パターンに基づく判定条件を設定する（ステップＳ３）。仮想ＣＰＥ２０は、自動的に判定条件を生成し、設定してもよい。さらに、仮想ＣＰＥ２０は、ＩｏＴデバイス５０からクラウドサーバ１０へデータが送信される際に生じるトラヒックの情報の収集を開始する（ステップＳ４）。

図２を用いて、判定処理のうち、ステップＳ４に続く処理について説明する。図２は、第１の実施形態に係る判定処理の一例を示す図である。図２に示すように、ＩｏＴデバイス５０に故障が発生し、ＩｏＴデバイス５０からのデータ送信によって生じるトラヒックに異常が発生しているものと仮定する（ステップＳ５）。

このとき、仮想ＣＰＥ２０は、収集したトラヒックの情報を基にＩｏＴデバイス５０に異常が発生したと判定する。そして、仮想ＣＰＥ２０は、運用者端末４０にアラームを送信する（ステップＳ６）。さらに、仮想ＣＰＥ２０は、ＩｏＴデバイス５０を収容するＩｏＴゲートウェイ３０に対し、ＩｏＴデバイス５０から送信されるデータの転送を停止し、当該データを蓄積することを命令する（ステップＳ７）。

また、運用者は、運用者端末４０を用いてトラヒックの情報を確認し、人手による異常の有無の判断を行い、デバイスの交換等の対応を検討することができる（ステップＳ８）。また、運用者端末４０は、仮想ＣＰＥ２０からの命令に応じてＩｏＴゲートウェイ３０が蓄積しているデータを参照することができる（ステップＳ９）。

［判定条件］
ここで、図３から図６を用いて、判定パターンについて説明する。図３から図６は、第１の実施形態に係る判定パターンについて説明するための図である。判定パターンは、トラヒックパターン及び値パターンによって特定される。

図３に示すように、本実施形態のトラヒックパターンには、常時通信、定期通信、不定期（ランダム）通信がある。また、トラヒックパターンはデバイスごとの動作の特性に基づいて決定することができる。例えば、常に撮影した画像データを送信し続ける監視カメラのトラヒックパターンは、常時通信である。また、例えば、１分ごとに測定した温度を送信する温度センサのトラヒックパターンは、定期通信である。また、例えば、スイッチがＯＮ又はＯＦＦになった時にのみデータを送信する家電のトラヒックパターンは、不定期通信である。

また、本実施形態における値パターンには、固定値、上限値、下限値及びランダムがある。値パターンは、ＩｏＴデバイス５０が正常動作時に送信するデータの量に基づいて決定される。例えば、監視カメラが正常に動作しているときに送信する画像データのファイルサイズによって、当該監視カメラの値パターンが決定される。

例えば、監視カメラが正常動作時に送信する画像データのファイルサイズが常に一定である場合、当該監視カメラの値パターンは固定値である。また、例えば、監視カメラが正常動作時に送信する画像データのファイルサイズに上限又は下限がある場合、当該監視カメラの値パターンは上限値又は下限値である。また、例えば、監視カメラが正常動作時に送信する画像データのファイルサイズが一定でなく、上限及び下限もない場合、当該監視カメラの値パターンはランダムである。

図３に示すように、本実施形態では、トラヒックパターン及び値パターンの組み合わせにより、Ａ－１、Ａ－２、Ｂ－１、Ｂ－２、Ｃ－１及びＣ－２の判定パターンが決定される。

図４を用いて、常時通信の判定パターンＡ－ｘ（ｘは各判定パターンを識別する数字）について説明する。図４に示すように、判定パターンＡ－１は、トラヒックパターンが常時通信、かつ値パターンが固定値、上限値及び下限値のいずれかである場合に決定される。判定システム１は、判定パターンＡ－１が決定されたＩｏＴデバイス５０について、定義した期間内に通信がない、又はトラヒックの値が異常である場合に、異常があると判定する。

また、判定パターンＡ－２は、トラヒックパターンが常時通信、かつ値パターンがランダムである場合に決定される。判定システム１は、判定パターンＡ－２が決定されたＩｏＴデバイス５０について、定義した期間内に通信がない場合に異常があると判定する。

図５を用いて、定期通信の判定パターンＢ－ｘ（ｘは各判定パターンを識別する数字）について説明する。図５に示すように、判定パターンＢ－１は、トラヒックパターンが定期通信、かつ値パターンが固定値、上限値及び下限値のいずれかである場合に決定される。判定システム１は、判定パターンＢ－１が決定されたＩｏＴデバイス５０について、通信があるが定義した周期ではない、又はトラヒックの値が異常である場合に、異常があると判定する。

また、判定パターンＢ－２は、トラヒックパターンが定期通信、かつ値パターンがランダムである場合に決定される。判定システム１は、判定パターンＢ－２が決定されたＩｏＴデバイス５０について、通信はあるが定義した周期ではない場合に異常があると判定する。

図６に示すように、判定パターンＣ－１は、トラヒックパターンが不定期通信、かつ値パターンが固定値、上限値及び下限値のいずれかである場合に決定される。判定システム１は、判定パターンＣ－１が決定されたＩｏＴデバイス５０について、通信はランダムだが値が決まっている（例えば、常に下限値以下）場合に、異常があると判定する。

また、判定パターンＣ－２は、トラヒックパターンが不定期通信、かつ値パターンがランダムである場合に決定される。この場合、判定システム１は、運用者端末４０に、異常の判断を運用者に委ねる旨のメッセージを送信することができる。

［第１の実施形態の構成］
図７を用いて、仮想ＣＰＥ２０の構成について説明する。図７は、第１の実施形態に係る仮想ＣＰＥの構成の一例を示す図である。図７に示すように、仮想ＣＰＥ２０は、管理部２１、収集部２２、判定部２３及び命令部２４及び入出力部２５を有する。入出力部２５は、キャリアネットワーク２等を介してデータの入出力を行う。

管理部２１は、ＩｏＴデバイス５０の情報を管理する。管理部２１は、デバイス情報送受信部２１１、デバイス判定情報２１３及びデバイス情報２１２を有する。デバイス情報送受信部２１１は、デバイス情報２１２及びデバイス判定情報２１３の送受信を行う。

例えば、デバイス情報２１２は、図１のステップＳ２において、運用者端末４０から入力されるＩｏＴデバイス５０に関する情報である。また、例えば、デバイス判定情報２１３は、図１のステップＳ３において、運用者端末４０から設定される判定条件である。

収集部２２は、ネットワークに接続されたＩｏＴデバイス５０からデータが送信される際に生じるトラヒックの情報を収集する。収集部２２は、トラヒック情報収集部２２１、トラヒック情報計算部２２２及びトラヒック情報２２３を有する。トラヒック情報収集部２２１は、トラヒックの情報を示すデータの入力を受け付ける。トラヒック情報計算部２２２は、入力されたデータを基に所定の計算し、トラヒック情報２２３を得る。

判定部２３は、収集部２２によって収集されたトラヒックの情報が、各ＩｏＴデバイス５０のトラヒックのパターンを基にあらかじめ設定された判定条件を満たす場合、トラヒックを生じさせたＩｏＴデバイス５０に異常が生じていると判定する。

判定部２３は、判定情報送受信部２３１、判定処理実施部２３２及び判定処理情報２３３を有する。判定情報送受信部２３１は、判定条件、判定対象のトラヒックの情報及び判定結果の送受信を行う。判定処理情報２３３は、判定対象のトラヒックの情報である。判定処理実施部２３２は、判定条件及び判定対象のトラヒックの情報を用いて実際に判定を行う。

命令部２４は、判定部２３によってＩｏＴデバイス５０に異常が生じていると判定された場合、ＩｏＴデバイス５０を収容するＩｏＴゲートウェイ３０に、ＩｏＴデバイス５０から送信されるデータを蓄積することを命令する。命令部２４は、命令送受信部２４１、命令実施部２４２及びＣＰＥ命令情報２４３を有する。命令送受信部２４１は、命令の送受信を行う。命令実施部２４２は、判定部２３の判定結果を基に命令を生成し、命令送受信部２４１に受け渡す。また、ＣＰＥ命令情報２４３は、命令の対象のＩｏＴゲートウェイ３０及びＩｏＴデバイス５０の情報である。

図８を用いて、ＩｏＴゲートウェイ３０の構成について説明する。図８は、第１の実施形態に係るＩｏＴゲートウェイの構成の一例を示す図である。図８に示すように、ＩｏＴゲートウェイ３０は、命令管理部３１及び蓄積部３２及び入出力部３３を有する。入出力部２５は、キャリアネットワーク２等を介してデータの入出力を行う。

命令管理部３１は、仮想ＣＰＥ２０から受信した命令を管理する。命令管理部３１は、ＣＰＥ命令送受信部３１１、ＣＰＥ命令処理部３１２、ＣＰＥ情報３１３及びＣＰＥ状態３１４を有する。

ＣＰＥ命令送受信部３１１は、仮想ＣＰＥ２０からの命令を受信する。ＣＰＥ命令処理部３１２、受信した命令を実行する。つまり、ＣＰＥ命令処理部３１２は、命令部２４からの命令に応じて、指定されたＩｏＴ５０から送信されるデータの転送を停止し、蓄積するようにＩｏＴゲートウェイ３０の制御を行う。ＣＰＥ情報３１３は、ＩｏＴゲートウェイ３０が収容するＩｏＴデバイス５０の情報である。また、ＣＰＥ状態３１４は、ＩｏＴデバイス５０のそれぞれについての、データの蓄積を実施中であるか否かを示す情報及び蓄積中のデータ量である。

蓄積部３２は、通信データ送受信部３２１及び蓄積通信データ３２２を有する。通信データ送受信部３２１は、ＩｏＴデバイス５０によって送信されたデータを受信し、蓄積通信データ３２２として格納する。

図９を用いて、仮想ＣＰＥ２０が記憶する情報について説明する。図９は、第１の実施形態に係る仮想ＣＰＥが記憶する情報の一例を示す図である。図９に示すように、仮想ＣＰＥ２０は、デバイス情報２１２、デバイス判定情報２１３、トラヒック情報２２３及び判定処理情報２３３を記憶する。

デバイス情報２１２は、ＣＰＥ＿ＩＤ、デバイス種別、デバイスＩＤ、第１から第Ｎデバイス情報を含む。ＣＰＥ＿ＩＤは、ＩｏＴデバイス５０を収容するＩｏＴゲートウェイ３０を識別する情報である。デバイス種別は、ＩｏＴデバイス５０の種別である。デバイスＩＤは、ＩｏＴデバイス５０を識別する情報である。第１から第Ｎデバイス情報は、ＩｏＴデバイス５０に関する具体的な情報である。第１から第Ｎデバイス情報には、トラヒックパターン及び値パターンが含まれていてもよい。なお、ＣＰＥ＿ＩＤ及びデバイスＩＤは、ＩＰアドレスであってよい。

図９の例では、デバイス情報２１２は、ＣＰＥ＿ＩＤが「２００．０．０．１」であるＩｏＴゲートウェイ３０に収容されたデバイスＩＤが「１０．０．０．１」である監視カメラに、「４Ｋ」、「２００Ｍｂｐｓ」、「常時通信」といった情報が設定されたことを示している。

デバイス判定情報２１３は、デバイスＩＤ、トラヒックパターン、値パターン、判定トラヒック、判定パターン、第１判定条件及び第２判定条件を含む。ここで、判定部２３は、収集部２２によって収集されたトラヒックの情報が、各ＩｏＴデバイス５０のトラヒックのパターンごとに特定される判定パターンと、各ＩｏＴデバイス５０の想定されているトラヒック量と、を組み合わせた判定条件を満たす場合、トラヒックを生じさせたＩｏＴデバイス５０に異常が生じていると判定する。このとき、各ＩｏＴデバイス５０の想定されているトラヒック量の一例は、デバイス判定情報２１３の判定トラヒックである。

図９の例では、デバイス判定情報２１３は、デバイスＩＤが「１０．０．０．１」であるＩｏＴデバイス５０のトラヒックパターンが「Ａ」、値パターンが「固定値」、判定トラヒックが「２０Ｍｂｐｓ」、判定パターンが「Ａ－１」、第１判定条件が「無通信が１分以上」、第２判定条件が「２０Ｍｂｐｓ以下の通信が３０秒以上継続」であることを示している。この場合、第２判定条件は、判定パターンと判定トラヒックを組み合わせた判定条件である。

また、図９に示すように、トラヒック情報２２３は、デバイスＩＤ、トラヒック有無及び実トラヒックを含む。実トラヒックは、収集部２２が収集したトラヒックである、図９の例では、トラヒック情報２２３は、デバイスＩＤが「１０．０．０．１」であるＩｏＴデバイス５０のトラヒック有無が「有」、実トラヒックが「８Ｍｂｐｓ」であることを示している。

また、図９に示すように、判定処理情報２３３は、デバイスＩＤ、判定トラヒック、実トラヒック及びトラヒック有無を含む。図９の例では、判定処理情報２３３は、デバイスＩＤが「１０．０．０．１」であるＩｏＴデバイス５０の判定トラヒックが「２０Ｍｂｐｓ」、実トラヒックが「８Ｍｂｐｓ」、トラヒック有無が「有」であることを示している。

図１０を用いて、ＩｏＴゲートウェイ３０が記憶する情報について説明する。図１０は、第１の実施形態に係るＩｏＴゲートウェイが記憶する情報の一例を示す図である。図１０に示すように、ＩｏＴゲートウェイ３０は、ＣＰＥ情報３１３及びＣＰＥ状態３１４を記憶する。

図１０の例では、ＣＰＥ情報３１３は、ＣＰＥ＿ＩＤが「２００．０．０．１」であるＩｏＴゲートウェイ３０が、デバイスＩＤが「１０．０．０．１」であるＩｏＴデバイス５０を収容していることを示している。なお、ＣＰＥ情報３１３には、異常があると判定されたＩｏＴデバイス５０（故障被疑デバイス）の情報のみが含まれていてもよい。

また、図１０の例では、ＣＰＥ状態３１４は、デバイスＩＤが「１０．０．０．１」であるＩｏＴデバイス５０のデータ蓄積命令が実施中であり、「０．８ＧＢ」のデータが蓄積済みであることを示している。

［第１の実施形態の処理］
図１１を用いて、判定システム１の処理の流れを説明する。図１１は、第１の実施形態に係る判定システムの処理の流れを示すシーケンス図である。図１１に示すように、ＩｏＴデバイス５０が設置されると（ステップＳ１０１）、運用者端末４０は、運用者の操作に応じて、デバイス情報、判定パターン及び判定条件を仮想ＣＰＥ２０に設定する（ステップＳ１０２）。

仮想ＣＰＥ２０は、トラヒック情報の収集を開始する（ステップＳ１０３）。ＩｏＴデバイス５０は、仮想ＣＰＥ２０を介して、クラウドサーバ１０へのデータを送信する（Ｓ１０４、Ｓ１０５）。このとき、仮想ＣＰＥ２０は、収集したトラヒック情報が判定条件に合致するか否かを判定する。

ここで、ＩｏＴデバイス５０に異常が発生し（ステップＳ１０６）、トラヒックに異常が発生した場合（ステップＳ１０７）、仮想ＣＰＥ２０は、トラヒックの情報を基に異常を判定し、異常があった場合（ステップＳ１０８）は、運用者端末４０にアラームを送信する（ステップＳ１０８）。

さらに、仮想ＣＰＥ２０は、異常があったＩｏＴデバイス５０を収容しているＩｏＴゲートウェイ３０へ、当該ＩｏＴデバイス５０から送信されたデータを蓄積することを命令する（ステップＳ１０９）。そして、ＩｏＴゲートウェイ３０は、データの蓄積を開始する（ステップＳ１１０）。

その後も、ＩｏＴデバイス５０は、異常が発生した状態のままデータを送信し続ける（ステップＳ１１１）。ただし、送信されたデータは蓄積通信データ３２２として蓄積される。そして、運用者は、運用者端末４０を介して蓄積データを確認し、データに異常があれば、ＩｏＴデバイス５０の故障と判断することができる（ステップＳ１１２）。

［第１の実施形態の効果］
収集部２２は、ネットワークに接続されたＩｏＴデバイス５０からデータが送信される際に生じるトラヒックの情報を収集する。また、判定部２３は、収集部２２によって収集されたトラヒックの情報が、各ＩｏＴデバイス５０のトラヒックのパターンを基にあらかじめ設定された判定条件を満たす場合、トラヒックを生じさせたＩｏＴデバイス５０に異常が生じていると判定する。このように、仮想ＣＰＥ２０は、各ＩｏＴデバイス５０のトラヒックのパターンに基づく判定条件を用いて判定を行うため、ＩｏＴデバイス５０ごとのコマンドを用意する必要がない。また、仮想ＣＰＥ２０は、ＩｏＴデバイス５０の通常の動作で発生するトラヒックの情報を用いて判定を行うことができる。このため、本実施形態によれば、容易かつ低コストでＩｏＴデバイスの故障の判定を行うことができる。

命令部２４は、判定部２３によってＩｏＴデバイス５０に異常が生じていると判定された場合、ＩｏＴデバイス５０を収容するＩｏＴゲートウェイ３０に、ＩｏＴデバイス５０から送信されるデータを蓄積することを命令する。これにより、本実施形態によれば、異常があると判定された後に発生した通信データが失われないようにすることができる。なお、蓄積されたデータは、異常が取り除かれた後、又は異常がないことが判明した後に、クラウドサーバ１０に送信され、マージされてもよい。

判定部２３は、収集部２２によって収集されたトラヒックの情報が、各ＩｏＴデバイス５０のトラヒックのパターンごとに特定される判定パターンと、各ＩｏＴデバイス５０の想定されているトラヒック量と、を組み合わせた判定条件を満たす場合、トラヒックを生じさせたＩｏＴデバイス５０に異常が生じていると判定する。このように、本実施形態では、判定条件をパターン化しておくことができる。このため、運用者は、判定パターンに具体的な数値を設定するだけで容易に判定条件を作成することができる。

［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散及び統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散又は統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
一実施形態として、仮想ＣＰＥ２０又はＩｏＴゲートウェイ３０は、パッケージソフトウェアやオンラインソフトウェアとして上記の判定処理を実行する判定プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記の判定プログラムを情報処理装置に実行させることにより、情報処理装置を仮想ＣＰＥ２０として機能させることができる。ここで言う情報処理装置には、デスクトップ型又はノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）等の移動体通信端末、さらには、ＰＤＡ（Personal Digital Assistant）等のスレート端末等がその範疇に含まれる。

また、仮想ＣＰＥ２０は、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の判定処理に関するサービスを提供する判定サーバ装置として実装することもできる。例えば、判定サーバ装置は、トラヒックの情報を入力とし、判定結果を出力とする判定サービスを提供するサーバ装置として実装される。この場合、判定サーバ装置は、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の判定処理に関するサービスを提供するクラウドとして実装することとしてもかまわない。

図１２は、判定プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。

ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、仮想ＣＰＥ２０の各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、仮想ＣＰＥ２０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤにより代替されてもよい。

また、上述した実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０は、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した実施形態の処理を実行する。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１ 判定システム
２ キャリアネットワーク
３ クラウドネットワーク
１０ クラウドサーバ
２０ 仮想ＣＰＥ
２１ 管理部
２２ 収集部
２３ 判定部
２４ 命令部
２５ 入出力部
３０ ＩｏＴゲートウェイ
３１ 命令管理部
３２ 蓄積部
３３ 入出力部
４０ 運用者端末
５０ ＩｏＴデバイス
２１１ デバイス情報送受信部
２１２ デバイス情報
２１３ デバイス判定情報
２２１ トラヒック情報収集部
２２２ トラヒック情報計算部
２２３ トラヒック情報
２３１ 判定情報送受信部
２３２ 判定処理実施部
２３３ 判定処理情報
２４１ 命令送受信部
２４２ 命令実施部
２４３ ＣＰＥ命令情報
３１１ ＣＰＥ命令送受信部
３１２ ＣＰＥ命令処理部
３１３ ＣＰＥ情報
３１４ ＣＰＥ状態
３２１ 通信データ送受信部
３２２ 蓄積通信データ

Claims (5)

1. ネットワークに接続されたデバイスからデータが送信される際に生じるトラヒックの情報を収集する収集部と、
   前記収集部によって収集されたトラヒックの情報が、各デバイスがデータを常時送信し続けるか、所定の時間周期でデータを送信するか、所定の処理が行われたタイミング又はランダムなタイミングでデータを送信するか、に基づいて決定されるトラヒックパターンと、各デバイスが正常動作時に送信するデータのファイルサイズが固定であるか、前記ファイルサイズに上限又は下限があるか、前記ファイルサイズが固定でなくかつ前記ファイルサイズに上限及び下限のいずれもないか、に基づいて決定される値パターンと、を組み合わせた判定条件を満たす場合、前記トラヒックを生じさせたデバイスに異常が生じていると判定する判定部と、
   を有することを特徴とする判定装置。
2. 前記判定部によってデバイスに異常が生じていると判定された場合、前記デバイスを収容するゲートウェイに、前記デバイスから送信されるデータを蓄積することを命令する命令部をさらに有することを特徴とする請求項１に記載の判定装置。
3. デバイスを収容するゲートウェイであって、
   前記デバイスからデータが送信される際に生じるトラヒックの情報が、前記デバイスがデータを常時送信し続けるか、所定の時間周期でデータを送信するか、所定の処理が行われたタイミング又はランダムなタイミングでデータを送信するか、に基づいて決定されるトラヒックパターンと、各デバイスが正常動作時に送信するデータのファイルサイズが固定であるか、前記ファイルサイズに上限又は下限があるか、前記ファイルサイズが固定でなくかつ前記ファイルサイズに上限及び下限のいずれもないか、に基づいて決定される値パターンと、を組み合わせた判定条件を満たすことにより、前記デバイスに異常が生じていると判定した判定装置からの命令に応じて、前記デバイスから送信されるデータの前記判定装置への転送を停止し、前記データを蓄積する蓄積部を有することを特徴とするゲートウェイ。
4. 判定装置によって実行される判定方法であって、
   ネットワークに接続されたデバイスからデータが送信される際に生じるトラヒックの情報を収集する収集工程と、
   前記収集工程によって収集されたトラヒックの情報が、各デバイスがデータを常時送信し続けるか、所定の時間周期でデータを送信するか、所定の処理が行われたタイミング又はランダムなタイミングでデータを送信するか、に基づいて決定されるトラヒックパターンと、各デバイスが正常動作時に送信するデータのファイルサイズが固定であるか、前記ファイルサイズに上限又は下限があるか、前記ファイルサイズが固定でなくかつ前記ファイルサイズに上限及び下限のいずれもないか、に基づいて決定される値パターンと、を組み合わせた判定条件を満たす場合、前記トラヒックを生じさせたデバイスに異常が生じていると判定する判定工程と、
   を含むことを特徴とする判定方法。
5. コンピュータを、請求項１又は２に記載の判定装置、又は請求項３に記載のゲートウェイとして機能させるための判定プログラム。

Images