特許 6487883 障害回復方法、およびそれを用いたモノのインターネットシステムおよび充電システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6487883

(24)【登録日】2019年3月1日

(45)【発行日】2019年3月20日

(54)【発明の名称】障害回復方法、およびそれを用いたモノのインターネットシステムおよび充電システム

(51)【国際特許分類】

   H04M 3/00 20060101AFI20190311BHJP

   H02J 7/02 20160101ALI20190311BHJP

   G06F 13/00 20060101ALI20190311BHJP

【ＦＩ】

   H04M3/00 E

   H02J7/02 A

   G06F13/00 351M

【請求項の数】26

【外国語出願】

【全頁数】22

(21)【出願番号】特願2016-165572(P2016-165572)

(22)【出願日】2016年8月26日

(65)【公開番号】特開2017-79465(P2017-79465A)

(43)【公開日】2017年4月27日

【審査請求日】2016年11月18日

(31)【優先権主張番号】62/210,421

(32)【優先日】2015年8月26日

(33)【優先権主張国】US

(31)【優先権主張番号】105122779

(32)【優先日】2016年7月19日

(33)【優先権主張国】TW

(73)【特許権者】

【識別番号】396008783

【氏名又は名称】大同股▲ふん▼有限公司

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】100161148

【弁理士】

【氏名又は名称】福尾 誠

(74)【代理人】

【識別番号】100134577

【弁理士】

【氏名又は名称】石川 雅章

(73)【特許権者】

【識別番号】507369121

【氏名又は名称】大同大學

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(72)【発明者】

【氏名】鄭 福炯

(72)【発明者】

【氏名】劉 威成

(72)【発明者】

【氏名】潘 泰吉

【審査官】 西巻 正臣

(56)【参考文献】

【文献】 特開２０１４−０６４１２１（ＪＰ，Ａ）

【文献】 特開２０１３−１５００２８（ＪＰ，Ａ）

【文献】 特開２０１２−１７５１５８（ＪＰ，Ａ）

【文献】 特開２００４−２２２４５７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｈ０２Ｊ ７／００− ７／１２、

７／３４− ７／３６

Ｈ０３Ｊ ９／００− ９／０６

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｍ １／００、

１／２４− ３／００、

３／１６− ３／２０、

３／３８− ３／５８、

７／００− ７／１６、

１１／００−１１／１０、

９９／００

Ｈ０４Ｑ ９／００− ９／１６

Ｈ０４Ｗ ４／００− ８／２４、

８／２６−１６／３２、

２４／００−２８／００、

２８／０２−７２／０２、

７２／０４−７４／０２、

７４／０４−７４／０６、

７４／０８−８４／１０、

８４／１２−８８／０６、

８８／０８−９９／００

(57)【特許請求の範囲】

【請求項1】

複数のゲートウェイ装置を提供し、前記ゲートウェイ装置の少なくとも１つが、少なくとも１つのＩｏＴ装置に無線ネットワークサービスを提供するようプリセットされ、前記ゲートウェイ装置の少なくとも別の１つが、少なくとも１つのユーザー機器に無線ネットワークサービスを提供するようプリセットされたステップと、
前記ゲートウェイ装置により別の前記ゲートウェイ装置の動作状態を相互に確認するステップと、
前記ゲートウェイ装置の１つが故障していると判断された時、前記故障したゲートウェイ装置を前記ゲートウェイ装置の別の１つに置き換えることにより、前記ゲートウェイ装置の別の１つにより前記ＩｏＴ装置と前記ユーザー機器に無線ネットワークサービスを同時に提供するステップと、
を含み、
前記ゲートウェイ装置により別の前記ゲートウェイ装置の前記動作状態を相互に確認する前記ステップが、
前記ゲートウェイ装置の１つにより確認パケットを送信するステップと、
前記ゲートウェイ装置の別の１つがプリセット時間内に前記確認パケットを受信したかどうかを判断するステップと、
前記ゲートウェイ装置の別の１つが前記プリセット時間内に前記確認パケットを受信した場合、前記ゲートウェイ装置の１つが故障していないと判断するステップと、
前記ゲートウェイ装置の別の１つが前記プリセット時間内に前記確認パケットを受信していない場合、接続状態確認手順を実行して、障害の種類を判断するステップと、
を含むモノのインターネット（ＩｏＴ）システムの障害回復方法。

【請求項2】

前記ゲートウェイ装置のそれぞれが、有線送信回路、無線送信回路、およびコアハードウェア回路を含み、前記ゲートウェイ装置が、対応する前記有線送信回路により確立された有線ネットワークを介して前記確認パケットを送信するようプリセットされた請求項１に記載のＩｏＴシステムの障害回復方法。

【請求項3】

前記接続状態確認手順を実行して、前記障害の種類を判断する前記ステップが、
前記有線送信回路により接続状態確認パケットを送信するステップと、
接続状態確認応答を受信したかどうかを判断するステップと、
前記接続状態確認応答を受信した場合、前記ゲートウェイ装置の別の１つの前記有線送信回路が正常であると判断するステップと、
前記接続状態確認応答を受信していない場合、前記ゲートウェイ装置の別の１つの前記有線送信回路が故障していると判断するステップと、
を含む請求項２に記載のＩｏＴシステムの障害回復方法。

【請求項4】

前記接続状態確認手順を実行して、前記障害の種類を判断する前記ステップが、さらに、
前記ゲートウェイ装置の別の１つの前記有線送信回路が正常であると判断された時、代わりに無線ネットワークを介して前記無線送信回路により前記ゲートウェイ装置の１つに前記確認パケットを送信するステップと、
前記無線ネットワークを介して前記プリセット時間内に前記確認パケットを受信したかどうかを判断するステップと、
前記無線ネットワークを介して前記プリセット時間内に前記確認パケットを受信した場合、前記ゲートウェイ装置の１つの前記有線送信回路が故障していると判断するステップと、
前記無線ネットワークを介して前記プリセット時間内に前記確認パケットを受信していない場合、前記ゲートウェイ装置の１つの前記コアハードウェア回路が故障していると判断するステップと、
を含む請求項３に記載のＩｏＴシステムの障害回復方法。

【請求項5】

前記ゲートウェイ装置により別の前記ゲートウェイ装置の前記動作状態を相互に確認する前記ステップが、さらに、
前記ゲートウェイ装置のそれぞれにより自身の無線送信回路の前記動作状態をチェックするステップと、
前記自身の無線送信回路が故障していると前記ゲートウェイ装置の１つが判断した時、前記送信された確認パケットにエラーコードを追加するステップと、
前記ゲートウェイ装置の別の１つが前記エラーコードを追加した前記確認パケットを受信した時、前記ゲートウェイ装置の１つの前記無線送信回路が故障していると判断するステップと、
を含む請求項２に記載のＩｏＴシステムの障害回復方法。

【請求項6】

前記ゲートウェイ装置の１つが故障していると判断された時、前記故障したゲートウェイ装置を前記ゲートウェイ装置の別の１つに置き換えることにより、前記ゲートウェイ装置の別の１つにより前記ＩｏＴ装置と前記ユーザー機器に無線ネットワークサービスを同時に提供する前記ステップが、
前記ＩｏＴ装置または前記ユーザー機器と前記故障したゲートウェイ装置の間の無線ネットワーク接続を切断するステップと、
前記故障したゲートウェイ装置のサービス提供対象に基づいて、前記ゲートウェイ装置の別の１つの対応するサービス機能をイネーブルにするステップと、
前記ゲートウェイ装置の別の１つにより前記ＩｏＴ装置または前記ユーザー機器との前記無線ネットワーク接続を再確立するステップと、
を含む請求項１〜５のいずれか１項に記載のＩｏＴシステムの障害回復方法。

【請求項7】

前記ゲートウェイ装置に接続されたスイッチを提供し、前記スイッチが、複数のネットワーク回線を有するとともに、前記スイッチが、前記ネットワーク回線の１つを使用して前記ゲートウェイ装置にインターネットサービスを提供するステップをさらに含む請求項１〜６のいずれか１項に記載のＩｏＴシステムの障害回復方法。

【請求項8】

使用中の前記ネットワーク回線を介して接続状態確認パケットを周期的に送信するステップと、
接続状態確認応答を受信したかどうかを判断するステップと、
前記接続状態確認応答を受信した場合、使用中の前記ネットワーク回線が正常に接続されていると判断するステップと、
前記接続状態確認応答を受信していない場合、使用中の前記ネットワーク回線が切断されたと判断するステップと、
をさらに含む請求項７に記載のＩｏＴシステムの障害回復方法。

【請求項9】

使用中の前記ネットワーク回線が切断されたと判断された時、前記ネットワーク回線の別の１つを使用してインターネットサービスを提供するよう切り替えるステップをさらに含む請求項８に記載のＩｏＴシステムの障害回復方法。

【請求項10】

前記ゲートウェイ装置の少なくとも１つの監視パラメータを設定するステップと、
前記ゲートウェイ装置の１つの前記監視パラメータが変化した時、前記ゲートウェイ装置の１つにより前記変化した監視パラメータを別の前記ゲートウェイ装置に同期させるステップと、
をさらに含む請求項１〜９のいずれか１項に記載のＩｏＴシステムの障害回復方法。

【請求項11】

前記ゲートウェイ装置の少なくとも１つの監視パラメータを設定するステップと、
前記ゲートウェイ装置の前記監視パラメータをクラウドサーバーに周期的にアップロードするステップと、
をさらに含む請求項１〜９のいずれか１項に記載のＩｏＴシステムの障害回復方法。

【請求項12】

前記ゲートウェイ装置の前記監視パラメータを前記クラウドサーバーに周期的にアップロードする前記ステップが、
前記クラウドサーバーにより保存された前記監視パラメータと前記ゲートウェイ装置にアップロードしたい前記監視パラメータを比較するステップと、
変化した前記監視パラメータのみを前記クラウドサーバーにアップロードするステップと、
を含む請求項１１に記載のＩｏＴシステムの障害回復方法。

【請求項13】

複数のゲートウェイ装置を含み、前記ゲートウェイ装置の少なくとも１つが、少なくとも１つのＩｏＴ装置に無線ネットワークサービスを提供するようプリセットされ、前記ゲートウェイ装置の少なくとも別の１つが、少なくとも１つのユーザー機器に無線ネットワークサービスを提供するようプリセットされ、
前記ゲートウェイ装置が、別の前記ゲートウェイ装置の動作状態を相互に確認し、
前記ゲートウェイ装置の１つが故障していると判断された時、前記故障したゲートウェイ装置を前記ゲートウェイ装置の別の１つに置き換えて、前記ＩｏＴ装置と前記ユーザー機器に無線ネットワークサービスを同時に提供し、
前記ゲートウェイ装置のそれぞれが、
近くの前記ユーザー機器と前記ＩｏＴ装置を無線で接続するのに適した無線送信回路と、
別の前記ゲートウェイ装置を有線で接続するのに適した有線送信回路と、
複数のモジュールを保存する記憶回路と、
前記無線送信回路、前記有線送信回路、および前記記憶回路に結合され、前記無線送信回路および前記有線送信回路の操作を制御して、前記記憶回路にアクセスし、前記モジュールを実行するプロセッサと、
を含むコアハードウェアと、
を含み、前記モジュールが、
前記ゲートウェイ装置の１つが故障していると判断された時に、前記故障したゲートウェイ装置のサービス提供対象を引き継ぐよう構成された障害回復モジュールと、
別の前記ゲートウェイ装置と確認パケットを交換して、それ自身と別の前記ゲートウェイ装置の動作状態を確認するよう構成された接続状態確認モジュールと、
現サービス提供対象に基づいて、対応するサービス機能をイネーブルまたはディセーブルにするよう構成されたサービスモジュールと、
を含むＩｏＴシステム。

【請求項14】

前記ゲートウェイ装置のそれぞれの前記有線送信回路に接続されたスイッチをさらに含み、前記スイッチが、複数のネットワーク回線を有するとともに、前記スイッチが、前記ネットワーク回線の１つを使用して前記ゲートウェイ装置にインターネットサービスを提供する請求項１３に記載のＩｏＴシステム。

【請求項15】

前記接続状態確認モジュールが、プリセット時間内に前記確認パケットを受信したかどうかを判断し、前記接続状態確認モジュールが前記プリセット時間内に前記確認パケットを受信した場合、それ自身が故障していないと判断し、前記接続状態確認モジュールが前記プリセット時間内に前記確認パケットを受信していない場合、前記接続状態確認モジュールが、接続状態確認手順を実行して、障害の種類を判断する請求項１４に記載のＩｏＴシステム。

【請求項16】

前記接続状態確認モジュールが、前記接続状態確認手順を実行し、前記接続状態確認モジュールが、前記有線送信回路により接続状態確認パケットを送信して、接続状態確認応答を受信したかどうかを判断し、前記有線送信回路が前記接続状態確認応答を受信した場合、自身の有線送信回路が正常であると前記接続状態確認モジュールが判断し、前記有線送信回路が前記接続状態確認応答を受信していない場合、前記自身の有線送信回路が故障していると前記接続状態確認モジュールが判断する請求項１５に記載のＩｏＴシステム。

【請求項17】

前記自身の有線送信回路が正常であると前記接続状態確認モジュールが判断した時、前記接続状態確認モジュールが、代わりに前記無線送信回路によりゲートウェイ装置の別の１つに前記確認パケットを送信して、前記無線送信回路が前記プリセット時間内に前記ゲートウェイ装置の別の１つにより送信された前記確認パケットを受信したかどうかを判断し、前記無線送信回路が前記プリセット時間内に前記確認パケットを受信した場合、前記ゲートウェイ装置の別の１つの前記有線送信回路が故障していると前記接続状態確認モジュールが判断し、前記無線送信回路が前記プリセット時間内に前記確認パケットを受信していない場合、前記ゲートウェイ装置の別の１つの前記コアハードウェアが故障していると前記接続状態確認モジュールが判断する請求項１６に記載のＩｏＴシステム。

【請求項18】

前記接続状態確認モジュールが、さらに、自身の無線送信回路の前記動作状態をチェックし、前記自身の無線送信回路が故障していると前記接続状態確認モジュールが判断した時、送信された前記確認パケットにエラーコードを追加する請求項１５に記載のＩｏＴシステム。

【請求項19】

前記モジュールが、さらに、
使用中の前記ネットワーク回線を介して接続状態確認パケットを周期的に送信し、接続状態確認応答を受信したかどうかを判断することにより、使用中の前記ネットワーク回線が正常に接続されているかどうかを確認するよう構成されたネットワーク接続モジュールを含み、
前記接続状態確認応答を受信した場合、使用中の前記ネットワーク回線が正常に接続されていると前記ネットワーク接続モジュールが判断し、前記接続状態確認応答を受信していない場合、使用中の前記ネットワーク回線が切断されたと前記ネットワーク接続モジュールが判断する請求項１４〜１８のいずれか１項に記載のＩｏＴシステム。

【請求項20】

使用中の前記ネットワーク回線が切断されたと前記ネットワーク接続モジュールが判断した時、前記ネットワーク接続モジュールが、前記ネットワーク回線の別の１つを使用してインターネットサービスを提供するよう切り替える請求項１９に記載のＩｏＴシステム。

【請求項21】

前記モジュールが、さらに、
少なくとも１つの監視パラメータを別の前記ゲートウェイ装置に同期させる、または前記監視パラメータをクラウドサーバーにアップロードするよう構成されたバックアップモジュールをさらに含む請求項１４〜２０のいずれか１項に記載のＩｏＴシステム。

【請求項22】

前記監視パラメータが変化した時、前記バックアップモジュールが、前記変化した監視パラメータを別の前記ゲートウェイ装置に同期させる請求項２１に記載のＩｏＴシステム。

【請求項23】

前記バックアップモジュールが、前記監視パラメータを前記クラウドサーバーに周期的にアップロードする請求項２１に記載のＩｏＴシステム。

【請求項24】

前記ＩｏＴ装置が、前記ユーザー機器に充電装置を提供するよう構成された請求項１３〜２３のいずれか１項に記載のＩｏＴシステム。

【請求項25】

少なくとも１つのユーザー機器を充電するのに適した少なくとも１つの充電装置と、
少なくとも１つが前記充電装置に無線ネットワークサービスを提供するようプリセットされ、少なくとも別の１つが前記ユーザー機器に無線ネットワークサービスを提供するようプリセットされた複数のゲートウェイ装置と、
前記ゲートウェイ装置と通信するのに適し、前記充電装置と前記ユーザー機器のデータメッセージを保存するよう構成されたデータセンターと、
を含み、前記ゲートウェイ装置が、別の前記ゲートウェイ装置の動作状態を相互に確認し、
前記ゲートウェイ装置の１つが故障していると判断された時、前記故障したゲートウェイ装置を前記ゲートウェイ装置の別の１つに置き換えて、前記充電装置と前記ユーザー機器に無線ネットワークサービスを同時に提供するＩｏＴに基づく充電システム。

【請求項26】

前記少なくとも１つの充電装置のそれぞれが、
前記ユーザー機器を充電するよう構成された充電回路と、
前記ユーザー機器を充電している間に充電データを収集するよう構成された動作監視回路と、
対応するゲートウェイ装置と通信して、前記収集した充電データを前記対応するゲートウェイ装置に返信するよう構成された通信回路と、
を含む請求項２５に記載のＩｏＴに基づく充電システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、無線通信技術に関するものであり、特に、障害回復方法、およびそれを用いたモノのインターネットシステムおよび充電システムに関するものである。

【背景技術】

【0002】

モノのインターネット（Internet of Things, IoT）の概念は、１９９９年に初めて提案された。この概念は、無線周波数識別（radio frequency identification, RFID）、赤外線、全地球測位システム（global positioning system, GPS）、レーザースキャン、および他の情報センシング装置を使用して、インターネットに無線で接続する方法のことを言う。情報を交換、通信、スマート認証、位置付け、追跡、監視、および管理することにより、情報を取得および管理する範囲を知覚層までさらに拡張し、幅広い相互運用性を達成することができる。

【0003】

ＩｏＴ装置は、各製造業者によって異なる接続用インターフェースを使用するため、異なる通信用プロトコルを採用する。そのため、通常、制御やプロトコル間の変換を行うメカニズムとしてＩｏＴ装置にゲートウェイ装置（gateway device）を設置して、異なる規格を有するＩｏＴ装置が互いに通信できるようにする必要がある。

【0004】

このように、ゲートウェイ装置は、ＩｏＴシステムにおいて重要な役割を果たすことがわかる。１日２４時間、週７日稼働するビジネス環境では、いったんゲートウェイ装置が故障すると、ＩｏＴ装置が互いに通信できない、あるいは制御できなくなるため、ビジネス全体のサービスが中断されて、業務に大きな損失を与える。したがって、サービスを中断せずに継続して提供するために、いかにして耐障害メカニズムを開発し、ゲートウェイ装置が迅速に故障から回復できるようにするかが、非常に重要になっている。

【発明の概要】

【発明が解決しようとする課題】

【0005】

本発明は、上述した問題を解決することのできる障害回復方法、およびそれを用いたＩｏＴシステムおよび充電システムを提供する。

【課題を解決するための手段】

【0006】

本発明のＩｏＴシステムの障害回復方法は、複数のゲートウェイ装置を提供し、ゲートウェイ装置の少なくとも１つが、少なくとも１つのＩｏＴ装置に無線ネットワークサービスを提供するようプリセットされ、ゲートウェイ装置の少なくとも別の１つが、少なくとも１つのユーザー機器に無線ネットワークサービスを提供するようプリセットされたステップと；ゲートウェイ装置により別のゲートウェイ装置の動作状態を相互に確認するステップと；ゲートウェイ装置の１つが故障していると判断された時、故障したゲートウェイ装置をゲートウェイ装置の別の１つに置き換えることにより、ゲートウェイ装置の別の１つによりＩｏＴ装置とユーザー機器に無線ネットワークサービスを同時に提供するステップを含む。

【0007】

本発明のＩｏＴシステムは、複数のゲートウェイ装置を含む。ゲートウェイ装置の少なくとも１つは、少なくとも１つのＩｏＴ装置に無線ネットワークサービスを提供するようプリセットされ、ゲートウェイ装置の少なくとも別の１つは、少なくとも１つのユーザー機器に無線ネットワークサービスを提供するようプリセットされる。ゲートウェイ装置は、別のゲートウェイ装置の動作状態を相互に確認する。ゲートウェイ装置の１つが故障していると判断された時、故障したゲートウェイ装置をゲートウェイ装置の別の１つに置き換えて、ＩｏＴ装置とユーザー機器に無線ネットワークサービスを同時に提供する。

【0008】

本発明のＩｏＴに基づく充電システムは、少なくとも１つの充電装置と、複数のゲートウェイ装置と、データセンターとを含む。充電装置は、少なくとも１つのユーザー機器を充電するのに適している。ゲートウェイ装置の少なくとも１つは、充電装置に無線ネットワークサービスを提供するようプリセットされ、ゲートウェイ装置の少なくとも別の１つは、ユーザー機器に無線ネットワークサービスを提供するようプリセットされる。データセンターは、ゲートウェイ装置と通信するのに適しており、充電装置とユーザー機器のデータメッセージを保存するよう構成される。ゲートウェイ装置は、別のゲートウェイ装置の動作状態を相互に確認する。ゲートウェイ装置の１つが故障していると判断された時、故障したゲートウェイ装置をゲートウェイ装置の別の１つに置き換えて、充電装置とユーザー機器に無線ネットワークサービスを同時に提供する。

【発明の効果】

【0009】

以上のように、本発明の実施形態は、障害回復方法、およびそれを用いたＩｏＴシステムおよび充電システムを提供する。ＩｏＴシステムは、ＩｏＴ装置とユーザー機器に対して異なるゲートウェイ装置を提供するようプリセットされる。ゲートウェイ装置は、別のゲートウェイ装置の動作状態を相互に確認し、ゲートウェイ装置の１つが故障していると判断された時、故障したゲートウェイ装置を故障していないゲートウェイ装置に置き換える。その結果、ＩｏＴシステムは、故障した動作状態から迅速に回復することができるため、ＩｏＴシステム全体が高い可用性を提供することができる。また、本発明の実施形態は、上述したＩｏＴシステムの概念に基づいて、可用性の高い充電システムを構築することもできる。

【0010】

本発明の上記および他の目的、特徴、および利点をより分かり易くするため、図面と併せた幾つかの実施形態を以下に説明する。
添付図面は、本発明の原理がさらに理解されるために含まれており、本明細書に組み込まれかつその一部を構成するものである。図面は、本発明の実施形態を例示しており、説明とともに、本発明の原理を説明する役割を果たしている。

【図面の簡単な説明】

【0011】

【図1】本発明の１つの実施形態に係るＩｏＴシステムの概略図である。

【図2】本発明の１つの実施形態に係るＩｏＴに基づく充電システムの概略図である。

【図3】本発明の１つの実施形態に係るＩｏＴシステムの障害回復方法のステップのフローチャートである。

【図4】本発明の１つの実施形態に係るゲートウェイ装置の動作状態および障害の種類を確認するステップのフローチャートである。

【図5】本発明の１つの実施形態に係るゲートウェイ装置の有線送信回路が故障した時に行う障害回復フローの概略図である。

【図6】本発明の１つの実施形態に係るゲートウェイ装置のコアハードウェア回路が故障した時に行う障害回復フローの概略図である。

【図7】本発明の１つの実施形態に係るゲートウェイ装置の無線送信回路が故障した時に行う障害回復フローの概略図である。

【図8】本発明の１つの実施形態に係るスイッチのネットワーク回線が切断された時に行う障害回復フローの概略図である。

【図9】本発明の１つの実施形態に係るゲートウェイ装置のデータ同期フローの概略図である。

【図10】本発明の別の実施形態に係るゲートウェイ装置のデータ同期フローの概略図である。

【発明を実施するための形態】

【0012】

以下、添付の図面を例として、本発明の実施形態を詳細に説明する。各図面および関連説明において、同一または類似する構成要素には、同一の参照番号を使用する。

【0013】

本発明の内容をより理解できるようにするため、以下の実施形態を例として、本発明が実際に実現できるものであることを証明する。ここで、同じ参照符合の素子／構成要素／ステップは、図面および実施形態において同じまたは類似する部品を示す。

【0014】

図１は、本発明の１つの実施形態に係るＩｏＴシステムの概略図である。図１を参照すると、本実施形態のＩｏＴシステム１００は、複数のゲートウェイ装置１１０＿１〜１１０＿ｎを含み、ｎは、２以上の正の整数である。

【0015】

ゲートウェイ装置１１０＿１〜１１０＿ｎのうち、少なくとも１つのゲートウェイ装置（ここでは、ゲートウェイ装置１１０＿１を例に挙げる）は、ＩｏＴ装置ＩｏＴＤに無線ネットワークサービスを提供するようプリセットされるため、ＩｏＴ装置ＩｏＴＤは、ゲートウェイ装置１１０＿１を介して自身の動作情報とデータを前端にあるデータセンター（図示せず）に返信することができ、システム管理者も、ゲートウェイ装置１１０＿１を介して対応するＩｏＴ装置ＩｏＴＤの操作行為を制御することができる。

【0016】

一方、ゲートウェイ装置１１０＿１〜１１０＿ｎのうち、無線ネットワークサービスを提供するようプリセットされたゲートウェイ装置１１０＿１の他に、少なくとも１つのゲートウェイ装置（ここでは、ゲートウェイ装置１１０＿２を例に挙げる）をさらに含み、ユーザー機器ＵＤに無線ネットワークサービスを提供するようプリセットされるため、ユーザー機器ＵＤは、ゲートウェイ装置１１０＿２を介してインターネットに接続することができる。ＩｏＴを応用する時、ＩｏＴ装置ＩｏＴＤは、全体のシステム要求に応じて、充電スタンド、空調機、冷蔵庫、テレビ等の備え付けの家電機器を選択的に使用することによって実施される。ユーザー機器ＵＤは、例えば、車両や携帯電話等のユーザーが操作する一般的な移動式電子設備により実施される。しかしながら、本発明は、これに限定されない。

【0017】

本実施形態において、各ゲートウェイ装置１１０＿１〜１１０＿ｎは、無線送信回路、有線送信回路、およびコアハードウェア回路を含む。ゲートウェイ装置１１０＿１を例に挙げると、無線送信回路１１２、有線送信回路１１４、およびコアハードウェア回路ＣＨＣを含む。これらのうち、コアハードウェア回路ＣＨＣは、記憶回路１１６および処理ユニット１１８等のハードウェア部品を含む。無線送信回路１１２は、処理ユニット１１８に結合され、近くのユーザー機器ＵＤとＩｏＴ装置ＩｏＴＤを無線で接続するのに適している。無線送信回路１１２は、無線トランシーバまたは無線ネットワークカードを用いて実施され、無線トランシーバまたは無線ネットワークカードは、Ｗｉ−Ｆｉプロトコル（wireless fidelity protocol）等の無線通信プロトコルと互換性がある。

【0018】

有線送信回路１１４は、処理ユニット１１８に結合され、他のゲートウェイ装置１１０＿２〜１１０＿ｎに有線で接続するのに適している。有線送信回路１１４は、イーサネット（Ethernet）、ファストイーサネット（fast Ethernet, 100BASE-T）、およびギガビットイーサネット（gigabit Ethernet）等の有線ネットワークプロトコルと互換性があるが、本発明は、これに限定されない。

【0019】

記憶回路１１６は、処理ユニット１１８に結合され、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、キャッシュメモリ、およびこれらに類似する素子、またはこれらの組み合わせで構成されてもよい。本実施形態において、記憶回路１１６は、複数のモジュールを保存するよう構成され、これらのモジュールは、プログラムまたはアプリケーションの形式で記憶回路１１６に保存され、異なる機能を提供する。

【0020】

処理ユニット１１８は、演算能力を有し、ゲートウェイ装置１１０＿１の操作を制御することのできるハードウェア（例えば、チップセット、プロセッサ等）である。本実施形態において、処理ユニット１１８は、中央処理装置（central processing unit, CPU）または他のプログラム可能なマイクロプロセッサまたはデジタル信号プロセッサ（digital signal processor, DSP）、プログラムされたコントローラ、特定用途向け集積回路（application specific integrated circuits, ASIC）、プログラム可能論理デバイス（programmable logic device, PLD）、または類似するデバイスであってもよい。処理ユニット１１８は、記憶回路１１６に保存されたモジュールにアクセスして、これらのモジュールの機能を実行することができる。

【0021】

また、１つの実施形態において、本実施形態のゲートウェイ装置１１０＿１〜１１０＿ｎは、さらに、スイッチ１２０を介して互いに接続するようプリセットされる。つまり、各ゲートウェイ装置１１０＿１〜１１０＿ｎの有線送信回路１１４は、スイッチ１２０を介してパケットとデータを交換することができる。しかしながら、本発明は、これに限定されない。

【0022】

詳しく説明すると、ゲートウェイ装置１１０＿１の記憶回路１１６に保存されたモジュールは、障害回復モジュールＥＲＭ、接続状態確認モジュールＣＳＭ、サービスモジュールＳＭ、ネットワーク接続モジュールＮＣＭ、およびバックアップモジュールＢＵＭを含む。

【0023】

障害回復モジュールＥＲＭは、ゲートウェイ装置１１０＿１〜１１０＿ｎの１つが故障していると判断された時に、故障したゲートウェイ装置１１０＿１〜１１０＿ｎのサービス提供対象を引き継ぐよう構成される。接続状態確認モジュールＣＳＭは、他のゲートウェイ装置１１０＿１〜１１０＿ｎと確認パケットを交換して、それ自身と別のゲートウェイ装置１１０＿１〜１１０＿ｎの動作状況を確認するよう構成される。サービスモジュールＳＭは、現サービス提供対象に基づいて、対応するサービス機能をイネーブル（enable）またはディセーブル（disable）にするよう構成される。ネットワーク接続モジュールＮＣＭは、使用中のネットワーク回線ＷＡＮ１／ＷＡＮ２を介して接続状態確認パケットを周期的に送信し、接続状態確認応答を受信したかどうかを判断することによって、使用中のネットワーク回線ＷＡＮ１／ＷＡＮ２が正常に接続されているかどうかを確認するよう構成される。バックアップモジュールＢＵＭは、設定監視パラメータを別のゲートウェイ装置１１０＿１〜１１０＿ｎに同期させる、あるいは監視パラメータをクラウドサーバーにアップロードするよう構成される。このようにして、ゲートウェイ装置１１０＿１〜１１０＿ｎの１つが故障した時、残りのゲートウェイ装置１１０＿１〜１１０＿ｎは、故障したゲートウェイ装置１１０＿１〜１１０＿ｎの監視パラメータに基づいて、故障したゲートウェイ装置１１０＿１〜１１０＿ｎのサービス機能を上手く引き継ぐことができる。

【0024】

全体のシステム操作に関しては、対応するゲートウェイ装置１１０＿２によって提供された無線ネットワークサービスを介して、ユーザー機器ＵＤをＩｏＴシステム１００のデータセンターに接続することができる。いくつかの設定が完了した後（例えば、必要な情報を入力する、所望のサービスをユーザーが選択する等）、データセンターは、ゲートウェイ装置１１０＿１を介してＩｏＴ装置ＩｏＴＤをイネーブルにし、ユーザー機器ＵＤと相互作用することができる。これらのうち、ＩｏＴ装置ＩｏＴＤとユーザー機器ＵＤが相互作用している間、ＩｏＴ装置ＩｏＴＤは、ゲートウェイ装置１１０＿１によって提供された無線ネットワークサービスを介して、相互作用中の情報およびデータをデータセンターに返信することもできるため、システム管理者は、収集した情報に基づいて、最適化、分析、他の必要な測定を行うことができる。

【0025】

特定の応用例において、ＩｏＴシステム１００は、例えば、図２に示すように、ＩｏＴに基づく充電システムであってもよい。本実施形態の充電システム２００は、充電装置ＩｏＴＤ（すなわち、上述した実施形態のＩｏＴ装置）、無線ネットワークサービスを充電装置ＩｏＴＤに提供するようプリセットされたゲートウェイ装置２１０ｉｏｔ、無線ネットワークサービスをユーザー機器ＵＤに提供するようプリセットされたゲートウェイ装置２１０ｕｄ、スイッチ２２０、およびデータセンター２３０を含む。

【0026】

充電装置ＩｏＴＤは、充電回路ＣＧＣ、操作監視回路ＯＭＣ、および通信回路ＣＭＣを含む。これらのうち、充電回路ＣＧＣは、ユーザー機器ＵＤを充電するよう構成される。操作監視回路ＯＭＣは、ユーザー機器ＵＤを充電している間に充電データを収集するよう構成される。通信回路ＣＭＣは、対応するゲートウェイ装置２１０ｉｏｔと通信して、収集した充電データを対応するゲートウェイ装置２１０ｉｏｔに送信した後、ゲートウェイ装置２１０ｉｏｔを介して収集した充電データをデータセンター２３０に返送するよう構成される。

【0027】

スイッチ２２０は、ゲートウェイ装置２１０ｉｏｔおよび２１０ｕｄの有線送信回路を接続し、スイッチ２２０は、複数のネットワーク回線を有する（本実施形態では２つのネットワーク回線ＷＡＮ１およびＷＡＮ２のみを例に挙げて説明するが、本発明は、これに限定されない）。スイッチ２２０は、ネットワーク回線ＷＡＮ１およびＷＡＮ２の１つを用いて、ゲートウェイ装置２１０ｉｏｔおよび２１０ｕｄにインターネットサービスを提供する。これらのうち、使用されていないネットワーク回線ＷＡＮ１／ＷＡＮ２は、使用中のネットワーク回線ＷＡＮ１／ＷＡＮ２のバックアップ回線に相当し、スイッチ２２０は、使用中のネットワーク回線ＷＡＮ１／ＷＡＮ２が切断されたと判断された時に、代わりにバックアップ回線を使用して、インターネットサービスを提供するよう自動的に切り替えることができる。

【0028】

データセンター２３０は、ゲートウェイ装置２１０ｉｏｔおよび２１０ｕｄと通信して、充電装置ＩｏＴＤおよびユーザー機器ＵＤのデータメッセージを保存および処理するよう構成される。これらのうち、データセンター２３０は、例えば、２つの異なる対象サーバーＴＳ１およびＴＳ２と、クラウドサーバーＣＳを含んでもよい。プリセット設定において、ユーザー機器ＵＤは、ゲートウェイ装置２１０ｕｄを介してデータセンター２３０に接続され、充電装置ＩｏＴＤの充電機能をイネーブルにする、または充電状態等の情報を問い合わせることを要求することができる。さらに、データセンター２３０は、ゲートウェイ装置２１０ｉｏｔを介して充電装置ＩｏＴＤに制御命令を与えることができる。本発明の実施形態において、対象サーバーＴＳ１およびＴＳ２は、データセンター（２３０等）の内部、またはインターネット内の任意のＩＣＭＰサーバーであってもよい。

【0029】

本実施形態の充電システム２００の構造において、ユーザーは、ゲートウェイ装置２１０ｕｄおよびスイッチ２２０を介してデータセンター２３０に接続し、充電装置ＩｏＴＤを用いて要求されたアプリケーションをダウンロードする、または充電装置ＩｏＴＤの充電機能をイネーブルにするための関連情報を登録することができる。設定が完了した後、データセンター２３０は、ゲートウェイ装置２１０ｉｏｔおよびスイッチ２２０を介してユーザー機器ＵＤの充電を開始するよう充電装置ＩｏＴＤを制御することができる。充電プロセスの間、充電装置ＩｏＴＤは、ゲートウェイ装置２１０ｉｏｔおよびスイッチ２２０を介してデータセンター２３０に充電情報を返送して保存してもよい。

【0030】

詳しく説明すると、ＩｏＴシステムの従来の構造では、通常、同じゲートウェイ装置を適用して、ＩｏＴ装置とユーザー機器に無線ネットワークサービスを提供する。いったんゲートウェイ装置が故障すると、ＩｏＴシステムは作動しない。

【0031】

反対に、本実施形態のＩｏＴシステム１００または充電システム２００は、複数のゲートウェイ装置１１０＿１および１１０＿２／２１０ｉｏｔおよび２１０ｕｄを配置する。そのため、本実施形態のゲートウェイ装置１１０＿１および１１０＿２／２１０ｉｏｔおよび２１０ｕｄは、図３のフローチャートのステップを適用して、自動化された障害回復を実現することができる。したがって、ゲートウェイ装置の１つが故障した時、故障していないゲートウェイ装置がユーザー機器ＵＤとＩｏＴ装置ＩｏＴＤに無線ネットワークサービスを同時に提供するよう切り替えられるため、全体のＩｏＴシステム１００は、高い可用性を提供することができる。

【0032】

図３に示した方法は、ゲートウェイ装置が対応する記憶回路１１６に保存されたモジュールをアクセスおよび実行することによって実行される。図３は、本発明の１つの実施形態に係るＩｏＴシステムの障害回復方法のステップのフローチャートである。

【0033】

ここで、図１の構造および図３の方法を用いて、関連説明を提供する。図１および図３を同時に参照すると、まず、ＩｏＴシステム１００に複数のゲートウェイ装置１１０＿１〜１１０＿ｎを提供する。ゲートウェイ装置１１０＿１および１１０＿２は、ＩｏＴ装置ＩｏＴＤとユーザー機器ＵＤにそれぞれ無線ネットワークサービスを提供するようプリセットされる（ステップＳ３１０）。

【0034】

この構造において、ＩｏＴシステム１００は、ゲートウェイ装置１１０＿１および１１０＿２を用いて互いの動作状態を相互に確認する（ステップＳ３２０）。ゲートウェイ装置１１０＿１および１１０＿２の１つが故障していると判断された時、故障したゲートウェイ装置をゲートウェイ装置１１０＿１および１１０＿２の別の１つに置き換えて、故障していないゲートウェイ装置によりＩｏＴ装置ＩｏＴＤとユーザー機器ＵＤに無線ネットワークサービスを同時に提供する（ステップＳ３３０）。

【0035】

さらに詳しく説明すると、ゲートウェイ装置１１０＿１および１１０＿２の動作状態を確認する詳しいステップを図４に示す。図４は、本発明の１つの実施形態に係るゲートウェイ装置の動作状態および障害の種類を確認するステップのフローチャートである。

【0036】

図１〜図４を参照すると、ここでは、ゲートウェイ装置１１０＿１を主体として説明する。ステップＳ３２０において、処理ユニット１１８は、まず、有線送信回路１１４がゲートウェイ装置１１０＿２に確認パケットを送信するよう接続状態確認モジュールＣＳＭを実行し（ステップＳ３２１）、ゲートウェイ装置１１０＿２により送信された確認パケットを受信するかどうかを判断する（ステップＳ３２２）。ここで、上述した確認パケットは、例えば、ホスト状態を含む心拍パケット（heartbeat packet）であってもよい。

【0037】

ゲートウェイ装置１１０＿２により送信された確認パケットを受信して、確認パケットに示されたゲートウェイ装置１１０＿２の動作状態が正常であると処理ユニット１１８が判断した場合、２つのゲートウェイ装置１１０＿１および１１０＿２がいずれも正常に動作していると判断する（ステップＳ３２３）。

【0038】

ゲートウェイ装置１１０＿２により送信された確認パケットを受信していないと処理ユニット１１８が判断した場合、確認パケットを受信していない時間がプリセット時間を超過するかどうかを判断する（ステップＳ３２４）。プリセット時間を超過していない場合、処理ユニット１１８は、確認パケットを受信したかどうかを継続して判断し；一方、プリセット時間が経過してもまだ確認パケットを受信していない場合、処理ユニット１１８は、接続状態確認手順を実行して、ゲートウェイ装置１１０＿１および１１０＿２の障害の種類を判断する（ステップＳ３２５）。

【0039】

接続状態確認手順を実行した後、処理ユニット１１８は、ゲートウェイ装置１１０＿１および１１０＿２の障害の種類が有線送信回路１１４の故障に属するか（ステップＳ３２６）、コアハードウェア回路ＣＨＣの故障に属するか（ステップＳ３２７）、無線送信回路１１２の故障に属するか（ステップＳ３２８）を判断することができる。したがって、処理ユニット１１８は、検出した障害情報をデータセンターに返送し（ステップＳ３２９）、その後、障害回復モジュールＥＲＭおよびサービスモジュールＳＭを実行して、故障したゲートウェイ装置１１０＿１／１１０＿２の機能を故障していないゲートウェイ装置１１０＿１／１１０＿２に置き換えることができる（ステップＳ３３０）。

【0040】

ＩｏＴ装置ＩｏＴＤとゲートウェイ装置１１０＿１および１１０＿２の間の相互作用を例に挙げて、本実施形態に基づく障害回復方法および接続状態確認手順の詳細ステップについて説明する。図５、図６、および図７は、それぞれ有線送信回路１１４が故障した時、コアハードウェア回路ＣＨＣが故障した時、および無線送信回路１１２が故障した時のゲートウェイ装置１１０＿１の障害回復フローの概略図である。さらに、図８は、スイッチ１２０のネットワーク回線ＷＡＮ１が切断された時に行う障害回復フローの概略図である。

【0041】

本分野において通常の知識を有する者であれば、下記の説明に基づいて、ユーザー機器ＵＤとゲートウェイ装置１１０＿１および１１０＿２の間の類似する障害回復方法をいかにして実現するかを理解することができるため、他のユーザー機器ＵＤとゲートウェイ装置１１０＿２の間の相互作用については、ここでは繰り返し説明しない。

【0042】

図５は、本発明の１つの実施形態に係るゲートウェイ装置の有線送信回路が故障した時に行う障害回復フローの概略図である。図１および図５を同時に参照すると、ゲートウェイ装置１１０＿１および１１０＿２がいずれも正常に動作している場合、ゲートウェイ装置１１０＿１は、確認パケットＨＢＰをゲートウェイ装置１１０＿２に定期的に送信する（ステップＳ５０１）。ゲートウェイ装置１１０＿１により送信された確認パケットＨＢＰをゲートウェイ装置１１０＿２が受信した時、ゲートウェイ装置１１０＿２は、確認パケットＨＢＰの内容に基づいて、ゲートウェイ装置１１０＿１の状態を記録する。

【0043】

同様に、ゲートウェイ装置１１０＿２も確認パケットＨＢＰをゲートウェイ装置１１０＿１に定期的に送信する（ステップＳ５０２）。ゲートウェイ装置１１０＿２により送信された確認パケットＨＢＰをゲートウェイ装置１１０＿１が受信した時、ゲートウェイ装置１１０＿１は、確認パケットＨＢＰの内容に基づいて、ゲートウェイ装置１１０＿２の状態を記録する。有線送信回路１１４を用いてゲートウェイ装置１１０＿１と１１０＿２の間で確認パケットＨＢＰを交換するようプリセットされているため、以下、確認パケットＨＢＰの後に「ＬＣ」（有線ネットワーク接続）の注釈を付ける。

【0044】

この時、ゲートウェイ装置１１０＿１および１１０＿２は、両側が正常に動作している状態にあることを確認するため、ＩｏＴ装置ＩｏＴＤは、サービスを提供するようプリセットされたゲートウェイ装置１１０＿１に接続リクエストを送信することができる（ステップＳ５０３）。接続リクエストが許可されたことを確認した後、ゲートウェイ装置１１０＿１は、無線送信回路１１２を介して接続確認応答をＩｏＴ装置ＩｏＴＤに返送して（ステップＳ５０４）、ＩｏＴ装置ＩｏＴＤとの無線ネットワーク接続を確立する。

【0045】

無線ネットワーク接続が上手く確立された後に、ゲートウェイ装置１１０＿１の有線送信回路１１４が故障した（例えば、ネットワークが故障した）と仮定する。この場合、ゲートウェイ装置１１０＿１は、有線送信回路１１４を介してゲートウェイ装置１１０＿２に確認パケットＨＢＰを送信することができない。また、ゲートウェイ装置１１０＿２が有線送信回路１１４を介してゲートウェイ装置１１０＿１に確認パケットＨＢＰを送信した時（ステップＳ５０５）、ゲートウェイ装置１１０＿１は、ゲートウェイ装置１１０＿２から送信された確認パケットＨＢＰを受信することもできない。

【0046】

このような状況で、プリセット時間が経過してもまだ別のゲートウェイ装置１１０＿１および１１０＿２から送信された確認パケットＨＢＰを受信していないと判断した後、各ゲートウェイ装置１１０＿１および１１０＿２は、スイッチ１２０内の有線ネットワークゲートウェイに接続状態確認パケットＩＣＭＰを送信することにより（ステップＳ５０６およびＳ５０７）、それぞれの有線送信回路１１４の動作状態が正常であるかどうかを確認する。

【0047】

ゲートウェイ装置１１０＿２は、この時点で故障していないため、スイッチ１２０内の有線ネットワークゲートウェイから返送された接続状態確認応答ＩＣＭＰ＿Ｒを受信して、自身の有線送信回路１１４が正常に動作していると判断することができる。一方、有線送信回路１１４は故障しているため、ゲートウェイ装置１１０＿１は、スイッチ１２０内の有線ネットワークゲートウェイから返送された接続状態確認応答ＩＣＭＰ＿Ｒを受信することができない。プリセット時間が経過すると、ゲートウェイ装置１１０＿１は、自身の有線送信回路１１４が故障していると判断する（ステップＳ５０９）。

【0048】

自身の有線送信回路１１４が故障していると判断された後、ゲートウェイ装置１１０＿１は、無線送信回路１１２の局モード（station mode）をイネーブルにすることにより、無線ネットワークを介してゲートウェイ装置１１０＿２との接続の確立を試みる（ステップＳ５１０）。接続リクエストを受信した後、ゲートウェイ装置１１０＿２は、ゲートウェイ装置１１０＿１からの無線ネットワークに対する接続リクエストに応じて、ゲートウェイ装置１１０＿１と１１０＿２の間の無線ネットワーク接続を確立する（ステップＳ５１１）。ゲートウェイ装置１１０＿２は、また、無線送信回路１１２の局モードをイネーブルにすることにより、無線ネットワークを介してゲートウェイ装置１１０＿１との接続の確立も試みる。接続リクエストを受信した後、ゲートウェイ装置１１０＿１は、ゲートウェイ装置１１０＿２からの無線ネットワークに対する接続リクエストに応じて、ゲートウェイ装置１１０＿１と１１０＿２の間の無線ネットワーク接続を確立する。

【0049】

ゲートウェイ装置１１０＿１と１１０＿２の間の無線ネットワーク接続を確立した後、ゲートウェイ装置１１０＿１は、代わりに無線ネットワーク接続ＷＣを介してゲートウェイ装置１１０＿２に確認パケットＨＢＰを送信する（ステップＳ５１２）。確認パケットＨＢＰを受信した後、ゲートウェイ装置１１０＿２は、ゲートウェイ装置１１０＿１の状態を記録して、ゲートウェイ装置１１０＿１の有線送信回路１１４が故障していることを知る。同様に、ゲートウェイ装置１１０＿２は、代わりに無線ネットワーク接続ＷＣを介してゲートウェイ装置１１０＿１に確認パケットＨＢＰを送信する（ステップＳ５１３）。確認パケットＨＢＰを受信した後、ゲートウェイ装置１１０＿１は、ゲートウェイ装置１１０＿２の状態を記録して、ゲートウェイ装置１１０＿２が正常に動作していることを知る。

【0050】

この時、各ゲートウェイ装置１１０＿１および１１０＿２は、別のゲートウェイ装置１１０＿１および１１０＿２の動作状態を既に知っている。ゲートウェイ装置１１０＿１は故障しているため、ゲートウェイ装置１１０＿１は、自身の無線ネットワークをディセーブルにして（ステップＳ５１４）、ＩｏＴ装置ＩｏＴＤとゲートウェイ装置１１０＿１の間の無線ネットワーク接続を切断する。その間、ゲートウェイ装置１１０＿２は、ＩｏＴ装置ＩｏＴＤに提供したいゲートウェイ装置１１０＿１のサービスを合併しながら、同時に、ユーザー機器ＵＤに提供したいサービスを継続的に実行する（ステップＳ５１５）。つまり、ゲートウェイ装置１１０＿２は、故障したゲートウェイ装置１１０＿１のサービス提供対象（ＩｏＴ装置ＩｏＴＤ）に基づいて、対応するサービス機能をイネーブルにする。

【0051】

その後、ＩｏＴ装置ＩｏＴＤは、代わりにゲートウェイ装置１１０＿２との無線ネットワーク接続の確立を試み（ステップＳ５１６）、ＩｏＴ装置ＩｏＴＤの接続リクエストがゲートウェイ装置１１０＿２により確認された後、ゲートウェイ装置１１０＿２は、代わりにＩｏＴ装置ＩｏＴＤを制御する（ステップＳ５１７）。

【0052】

図６は、本発明の１つの実施形態に係るゲートウェイ装置のコアハードウェア回路が故障した時に行う障害回復フローの概略図である。次に、図１および図６を同時に参照すると、ゲートウェイ装置１１０＿１および１１０＿２がいずれも正常に動作している場合、ゲートウェイ装置１１０＿１は、有線ネットワークＬＣを介してゲートウェイ装置１１０＿２に確認パケットＨＢＰを定期的に送信する（ステップＳ６０１）。ゲートウェイ装置１１０＿１によって送信された確認パケットＨＢＰをゲートウェイ装置１１０＿２が受信した時、ゲートウェイ装置１１０＿２は、確認パケットＨＢＰの内容に基づいて、ゲートウェイ装置１１０＿１の状態を記録する。

【0053】

同様に、ゲートウェイ装置１１０＿２も有線ネットワークＬＣを介してゲートウェイ装置１１０＿１に確認パケットＨＢＰを定期的に送信する（ステップＳ６０２）。ゲートウェイ装置１１０＿２によって送信された確認パケットＨＢＰをゲートウェイ装置１１０＿１が受信した時、ゲートウェイ装置１１０＿１は、確認パケットＨＢＰの内容に基づいて、ゲートウェイ装置１１０＿２の状態を記録する。

【0054】

この時点で、ゲートウェイ装置１１０＿１および１１０＿２は、両側が正常に動作している状態にあることを確認するため、ＩｏＴ装置ＩｏＴＤは、サービスを提供するようプリセットされたゲートウェイ装置１１０＿１に接続リクエストを送信することができる（ステップＳ６０３）。接続リクエストが許可されたことを確認した後、ゲートウェイ装置１１０＿１は、無線送信回路１１２を介してＩｏＴ装置ＩｏＴＤに接続確認応答を返送して（ステップＳ６０４）、ＩｏＴ装置ＩｏＴＤとの無線ネットワーク接続を確立する。

【0055】

無線ネットワーク接続が上手く確立された後に、ゲートウェイ装置１１０＿１のコアハードウェア回路ＣＨＣが故障したと仮定する。この時点で、ゲートウェイ装置１１０＿１の有線送信回路１１４と無線送信回路１１２は、いずれも正常に動作できない。

【0056】

この状況で、ゲートウェイ装置１１０＿２は、依然として、有線ネットワークＬＣを介して確認パケットＨＢＰを送信し（ステップＳ６０５）、プリセット時間が経過してもまだゲートウェイ装置１１０＿１から送信された確認パケットＨＢＰを受信していないと判断した後、スイッチ１２０内の有線ネットワークゲートウェイに接続状態確認パケットＩＣＭＰを送信して（ステップＳ６０６）、自身の有線送信回路１１４の動作状態が正常であるかどうかを確認する。

【0057】

スイッチ１２０から返送された接続状態確認応答ＩＣＭＰ＿Ｒをゲートウェイ装置１１０＿２が受信した時（ステップＳ６０７）、ゲートウェイ装置１１０＿２は、自身の有線送信回路１１４が正常に動作していると判断することができる。この場合、ゲートウェイ装置１１０＿２は、無線送信回路１１２の局モードをイネーブルにすることにより、無線ネットワークを介してゲートウェイ装置１１０＿１に確認パケットＨＢＰを送信するために、無線ネットワークを介してゲートウェイ装置１１０＿１との接続の確立を試みる。

【0058】

しかしながら、ゲートウェイ装置１１０＿１は、既に故障しており、確認パケットＨＢＰを返送することができないため、ゲートウェイ装置１１０＿２は、プリセット時間が経過した後に、ゲートウェイ装置１１０＿１のコアハードウェア回路ＣＨＣが故障したと判断することができる（ステップＳ６０９）。その間、ゲートウェイ装置１１０＿２は、ＩｏＴ装置ＩｏＴＤに提供したいゲートウェイ装置１１０＿１のサービスを合併しながら、同時に、ユーザー機器ＵＤに提供したいサービスを継続的に実行する（ステップＳ６１０）。つまり、ゲートウェイ装置１１０＿２は、故障したゲートウェイ装置１１０＿１のサービス提供対象（ＩｏＴ装置ＩｏＴＤ）に基づいて、対応するサービス機能をイネーブルにする。

【0059】

その後、ＩｏＴ装置ＩｏＴＤは、代わりにゲートウェイ装置１１０＿２との無線ネットワーク接続の確立を試み（ステップＳ６１１）、ＩｏＴ装置ＩｏＴＤの接続リクエストがゲートウェイ装置１１０＿２により確認された後、ゲートウェイ装置１１０＿２は、代わりにＩｏＴ装置ＩｏＴＤを制御する（ステップＳ６１２）。

【0060】

図７は、本発明の１つの実施形態に係るゲートウェイ装置の無線送信回路が故障した時に行う障害回復フローの概略図である。次に、図１および図７を同時に参照すると、ゲートウェイ装置１１０＿１および１１０＿２がいずれも正常に動作している場合、ゲートウェイ装置１１０＿１および１１０＿２の動作（ステップＳ７０１〜Ｓ７０４）は、上述した実施形態のステップＳ５０１〜Ｓ５０４およびＳ６０１〜Ｓ６０４と実質的に同じであるため、ここでは繰り返し説明しない。

【0061】

無線ネットワーク接続が上手く確立された後に、ゲートウェイ装置１１０＿１の無線送信回路１１２が故障した（例えば、無線ネットワーク回路が故障した）と仮定する。この場合、ゲートウェイ装置１１０＿１とＩｏＴ装置ＩｏＴＤの間の無線ネットワーク接続が切断されるが、ゲートウェイ装置１１０＿１と１１０＿２の間の送信は、依然として有線ネットワークを介して行うことができる。

【0062】

本実施形態において、自身の無線送信回路１１２の動作状態は、ゲートウェイ装置１１０＿１および１１０＿２が動作している間、絶えずチェックされる。そのため、ゲートウェイ装置１１０＿１の無線送信回路１１２が故障した時、ゲートウェイ装置１１０＿１は、動作状態の検出結果に基づいて、自身の無線送信回路１１２が故障していることをリアルタイムで判断することができる（ステップＳ７０５）。

【0063】

自身の無線送信回路が故障しているとゲートウェイ装置１１０＿１が判断した時、ゲートウェイ装置１１０＿１は、送信された確認パケットに無線送信回路１１２が故障していることを示すエラーコードを追加し（ステップＳ７０６）、有線ネットワークＬＣを介してエラーコードが追加された確認パケットＨＢＰｅをゲートウェイ装置１１０＿２に送信する（ステップＳ７０７）。一方、ゲートウェイ装置１１０＿２は、正常に動作しているため、ゲートウェイ装置１１０＿２は、ゲートウェイ装置１１０＿１に一般的な確認パケットＨＢＰを送信する（ステップＳ７０８）。

【0064】

エラーコードが追加された確認パケットＨＢＰｅをゲートウェイ装置１１０＿２が受信した時、ゲートウェイ装置１１０＿２は、エラーコードに基づいて、ゲートウェイ装置１１０＿１の無線送信回路１１２が故障していると判断する（ステップＳ７０９）。この場合、ゲートウェイ装置１１０＿２は、ＩｏＴ装置ＩｏＴＤに提供したいゲートウェイ装置１１０＿１のサービスを合併しながら、同時に、ユーザー機器ＵＤに提供したいサービスを継続的に実行する（ステップＳ７１０）。つまり、ゲートウェイ装置１１０＿２は、故障したゲートウェイ装置１１０＿１のサービス提供対象（ＩｏＴ装置ＩｏＴＤ）に基づいて、対応するサービス機能をイネーブルにする。

【0065】

その後、ＩｏＴ装置ＩｏＴＤは、代わりにゲートウェイ装置１１０＿２との無線ネットワーク接続の確立を試み（ステップＳ７１０）、ＩｏＴ装置ＩｏＴＤの接続リクエストがゲートウェイ装置１１０＿２により確認された後、ゲートウェイ装置１１０＿２は、代わりにＩｏＴ装置ＩｏＴＤを制御する（ステップＳ７１１）。

【0066】

図８は、本発明の１つの実施形態に係るスイッチのネットワーク回線が切断された時に行う障害回復フローの概略図である。図２は、全体のネットワーク構造を図示しているため、本実施形態を図２の構造と併せて説明する。本実施形態において、サーバーＴＳ１およびＴＳ２は、例えば、インターネットサービスプロバイダ（server of an internet service provider, ISP）のドメインネームシステム（domain name system, DNS）等のＩＣＭＰプロトコルをサポートするサーバーであってもよいが、本発明は、これに限定されない。スイッチ２２０内のルーティングテーブル（routing table）をサーバーＴＳ１およびＴＳ２のＩＰアドレスのスタティックルートで構成することにより、ゲートウェイ装置からサーバーＴＳ１に送信されたパケットがネットワーク回線ＷＡＮ１を使用するよう指定し、サーバーＴＳ２に送信されたパケットがネットワーク回線ＷＡＮ２を使用するよう指定してもよい。本実施形態において、ＩｏＴシステム／充電システム２００は、パケットの送信にネットワーク回線ＷＡＮ１を使用するようプリセットされる。

【0067】

図２および図８を同時に参照すると、ここでは、ゲートウェイ装置２１０ｉｏｔを主体として説明する。まず、ゲートウェイ装置２１０ｉｏｔは、サーバーＴＳ１に接続状態確認パケットＩＣＭＰを定期的／周期的に送信する。スタティックルートは、スイッチ２２０のルーティングテーブルの中に設定されるため、送信先がサーバーＴＳ１のパケットは、ネットワーク回線ＷＡＮ１に送信される。そのため、接続状態確認パケットＩＣＭＰをゲートウェイ装置２１０ｉｏｔからスイッチ２２０に送信し（ステップＳ８０１）、その後、ネットワーク回線ＷＡＮ１を介してインターネットにアップロードし（ステップＳ８０２）、インターネットを介してサーバーＴＳ１に送信する（ステップＳ８０３）。

【0068】

接続状態確認パケットＩＣＭＰを受信した後、サーバーＴＳ１は、同じ経路（サーバーＴＳ１→インターネット→ネットワーク回線ＷＡＮ１→スイッチ→ゲートウェイ装置２１０ｉｏｔ）により、接続状態確認応答ＩＣＭＰ＿Ｒをゲートウェイ装置２１０ｉｏｔに返送する（ステップＳ８０４〜ステップＳ８０６）。ゲートウェイ装置２１０ｉｏｔが接続状態確認応答ＩＣＭＰ＿Ｒを受信した場合、ネットワーク回線ＷＡＮ１が正常に接続されていると判断する。同様に、ゲートウェイ装置２１０ｉｏｔは、同様の方法を用いて、ネットワーク回線ＷＡＮ２が正常に接続されているかどうかも検出することができる（ステップＳ８０７〜Ｓ８１２に示す）。

【0069】

ステップＳ８１２の後、ゲートウェイ装置２１０ｉｏｔは、２つのネットワーク回線ＷＡＮ１およびＷＡＮ２がいずれも正常な接続状態にあると判断する。そのため、プリセットされたネットワーク回線ＷＡＮ１を用いてインターネットにデータをアップロードし（ステップＳ８１３およびＳ８１４）、ネットワーク回線ＷＡＮ１を用いてインターネットからデータのダウンロードも行う（ステップＳ８１５およびＳ８１６）。

【0070】

使用中のネットワーク回線ＷＡＮ１が切断されたと仮定する。この場合、接続状態確認パケットＩＣＭＰの送信が連続失敗を示すことを確認した後（ステップＳ８１７およびＳ８１８；ここでは、２回の連続失敗を例とするが、本発明は、これに限定されない）、ゲートウェイ装置２１０ｉｏｔは、使用中のネットワーク回線ＷＡＮ１が切断されたと判断し、使用中のネットワーク回線をＷＡＮ２に切り替える（ステップＳ８１９）。したがって、ゲートウェイ装置２１０ｉｏｔは、代わりにネットワーク回線ＷＡＮ２を使用して、インターネットにデータをアップロードし（ステップＳ８２０およびＳ８２１）、インターネットからデータをダウンロードする（ステップＳ８２２およびＳ８２３）。

【0071】

図９および図１０の実施形態は、本発明の実施形態に係るＩｏＴシステム中の各ゲートウェイ装置のデータバックアップ／同期方法を示したものである。

【0072】

図１および図９を参照すると、本実施形態において、各ゲートウェイ装置１１０＿１および１１０＿２は、それぞれの監視パラメータを前もって設定する（ステップＳ９０１およびＳ９０２）。監視パラメータは、ＩｏＴ装置およびユーザー機器ＵＤの動作状態パラメータまたは動作セットアップファイルであってもよいが、本発明は、これに限定されない。

【0073】

各ゲートウェイ装置１１０＿１および１１０＿２の監視パラメータが変化しない場合、ゲートウェイ装置１１０＿１および１１０＿２は、同期の動作を実行しない。ゲートウェイ装置１１０＿１の監視パラメータが変化した時、ゲートウェイ装置１１０＿１は、変化した監視パラメータをゲートウェイ装置１１０＿２に同期させる（ステップＳ９０３）。同様に、ゲートウェイ装置１１０＿２の監視パラメータが変化した時、ゲートウェイ装置１１０＿２は、変化した監視パラメータをゲートウェイ装置１１０＿１に同期させる（ステップＳ９０４）。

【0074】

したがって、ゲートウェイ装置１１０＿１および１１０＿２が取得した情報は、いつでも同期を維持することができる。こうすることによって、ゲートウェイ装置１１０＿１／１１０＿２の１つが故障すると、故障したゲートウェイ装置１１０＿１／１１０＿２をすぐに別のゲートウェイ装置１１０＿２／１１０＿１に置き換えることができる。

【0075】

実際の応用において、ゲートウェイ装置１１０＿１および１１０＿２は、Ｌｉｎｕｘのカーネルサブシステム（kernel subsystem）のｉｎｏｔｉｆｙを使用して、上述した監視データおよび構成ファイルの機能を実現することができる。例えば、監視したファイルの内容が変化した時、ｉｎｏｔｉｆｙは、状態コードを送信するため、ゲートウェイ装置１１０＿１／１１０＿２は、ｒｓｙｎｃをリコールして、別のゲートウェイ装置１１０＿１／１１０＿２に変更されたファイルを同期させることができる。

【0076】

次に、図１および図１０を参照すると、本実施形態において、各ゲートウェイ装置１１０＿１および１１０＿２は、また、それぞれの監視パラメータを前もって設定する（ステップＳ１００１およびＳ１００２）。図９の実施形態とは異なり、ゲートウェイ装置１１０＿１および１１０＿２は、監視パラメータをクラウドサーバーＣＳに周期的にアップロードする。

【0077】

詳しく説明すると、図１０に示すように、各ゲートウェイ装置１１０＿１および１１０＿２は、設定された監視パラメータをクラウドサーバーＣＳにアップロードし（ステップＳ１００３およびＳ１００４）、固定された時間間隔ＰＴが経過した後、設定された監視パラメータを再びクラウドサーバーＣＳにアップロードする（ステップＳ１００５およびＳ１００６）。同様に、ステップＳ１００５およびＳ１００６の後、ゲートウェイ装置１１０＿１および１１０＿２は、時間間隔ＰＴが経過した後、設定された監視パラメータを再びクラウドサーバーＣＳにアップロードし（ステップＳ１００７およびＳ１００８）、以下同様である。

【0078】

したがって、ゲートウェイ装置１１０＿１／１１０＿２の１つが故障すると、別のゲートウェイ装置１１０＿２／１１０＿１が故障したゲートウェイ装置１１０＿１／１１０＿２の監視パラメータをクラウドサーバーＣＳからダウンロードして、故障したゲートウェイ装置１１０＿１／１１０＿２と置き換える。

【0079】

以上のように、本発明の実施形態は、障害回復方法、およびそれを用いたＩｏＴシステムおよび充電システムを提供する。ＩｏＴシステムは、ＩｏＴ装置とユーザー機器に対して異なるゲートウェイ装置を提供するようプリセットすることができる。ゲートウェイ装置は、別のゲートウェイ装置の動作状態を相互に確認することができるため、ゲートウェイ装置の１つが故障していると判断された時、故障したゲートウェイ装置を故障していないゲートウェイ装置に置き換える。その結果、ＩｏＴシステムは、故障した動作状態から迅速に回復することができるため、全体のＩｏＴシステムは、高い可用性を提供することができる。また、本発明の実施形態は、上述したＩｏＴシステムの概念に基づいて、可用性の高い充電システムを構築することもできる。

【0080】

以上のごとく、この発明を実施形態により開示したが、もとより、この発明を限定するためのものではなく、当業者であれば容易に理解できるように、この発明の技術思想の範囲内において、適当な変更ならびに修正が当然なされうるものであるから、その特許権保護の範囲は、特許請求の範囲および、それと均等な領域を基準として定めなければならない。

【産業上の利用可能性】

【0081】

本発明は、障害回復方法、およびそれを用いたＩｏＴシステムおよび充電システムを提供する。ゲートウェイ装置は、別のゲートウェイ装置の動作状態を相互に確認することができるため、ゲートウェイ装置の１つが故障していると判断された時、故障したゲートウェイ装置を故障していないゲートウェイ装置に交換する。その結果、ＩｏＴシステムは、故障した動作状態から迅速に回復することができるため、全体のＩｏＴシステムは、高い可用性を提供することができる。

【符号の説明】

【0082】

１００ ＩｏＴシステム
１１０＿１〜１１０＿ｎ、２１０ｉｏｔ、２１０ｕｄ ゲートウェイ装置
１１２ 無線送信回路
１１４ 有線送信回路
１１６ 記憶回路
１１８ 処理回路
１２０、２２０ スイッチ
２００ ＩｏＴに基づく充電システム
２３０ データセンター
ＢＵＭ バックアップモジュール
ＣＧＣ 充電回路
ＣＭＣ 通信回路
ＣＳ クラウドサーバー
ＣＳＭ 接続状態確認モジュール
ＥＲＭ 障害回復モジュール
ＩｏＴＤ ＩｏＴ装置／充電装置
ＮＣＭ ネットワーク接続モジュール
ＯＭＣ 動作監視回路
ＳＭ サービスモジュール
ＴＳ１、ＴＳ２ 対象サーバー
ＵＤ ユーザー機器
ＷＡＮ１、ＷＡＮ２ ネットワーク回線
Ｓ３１０〜Ｓ３３０、Ｓ３２１〜Ｓ３２９、Ｓ５０１〜Ｓ５１７、Ｓ６０１〜Ｓ６１２、Ｓ７０１〜Ｓ７１１、Ｓ８０１〜Ｓ８２３、Ｓ９０１〜Ｓ９０４、Ｓ１００１〜Ｓ１００８ ＩｏＴシステムの障害回復方法のステップ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】