▶ エンヴィジョン デジタル インターナショナル ピーティーイー．エルティーディー．の特許一覧 ▶ シャンハイ エンヴィジョン デジタル シーオー．，エルティーディー．の特許一覧
特許7232965ＩｏＴシステムにおいてデータを送信するための方法および装置、並びにゲートウェイデバイスおよびそれらの記憶媒体
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-02-22
(45)【発行日】2023-03-03
(54)【発明の名称】ＩｏＴシステムにおいてデータを送信するための方法および装置、並びにゲートウェイデバイスおよびそれらの記憶媒体
(51)【国際特許分類】
H04L 47/56 20220101AFI20230224BHJP
【ＦＩ】
H04L47/56
【請求項の数】
10
(21)【出願番号】P 2022526522
(86)(22)【出願日】2020-11-04
(65)【公表番号】
(43)【公表日】2022-11-15
(86)【国際出願番号】 SG2020050637
(87)【国際公開番号】W WO2021091492
(87)【国際公開日】2021-05-14
【審査請求日】2022-07-08
(31)【優先権主張番号】201911076109.2
(32)【優先日】2019-11-06
(33)【優先権主張国・地域又は機関】CN
【早期審査対象出願】
(73)【特許権者】
【識別番号】522178636
【氏名又は名称】エンヴィジョン デジタル インターナショナル ピーティーイー．エルティーディー．
【氏名又は名称原語表記】ＥＮＶＩＳＩＯＮ ＤＩＧＩＴＡＬ ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＰＴＥ．ＬＴＤ．
【住所又は居所原語表記】１ Ｈａｒｂｏｕｒｆｒｏｎｔ Ａｖｅｎｕｅ，＃１７－０１ Ｋｅｐｐｅｌ Ｂａｙ Ｔｏｗｅｒ，Ｓｉｎｇａｐｏｒｅ ０９８６３２（ＳＧ）
(73)【特許権者】
【識別番号】522178647
【氏名又は名称】シャンハイ エンヴィジョン デジタル シーオー．，エルティーディー．
【氏名又は名称原語表記】ＳＨＡＮＧＨＡＩ ＥＮＶＩＳＩＯＮ ＤＩＧＩＴＡＬ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｎｏ．１５，Ｌａｎｅ ５５，Ｃｈｕａｎｈｅ Ｒｏａｄ Ｃｈｉｎａ（Ｓｈａｎｇｈａｉ）Ｐｉｌｏｔ Ｆｒｅｅ Ｔｒａｄｅ Ｚｏｎｅ Ｓｈａｎｇｈａｉ（ＣＮ）
(74)【代理人】
【識別番号】100116687
【弁理士】
【氏名又は名称】田村 爾
(74)【代理人】
【識別番号】100098383
【弁理士】
【氏名又は名称】杉村 純子
(74)【代理人】
【識別番号】100155860
【弁理士】
【氏名又は名称】藤松 正雄
(72)【発明者】
【氏名】チエン，ジアリン
(72)【発明者】
【氏名】カイ，チャンドン
(72)【発明者】
【氏名】チャン，ホンゼン
(72)【発明者】
【氏名】チャン，ヤン
【審査官】宮島 郁美
(56)【参考文献】
【文献】特開２０１９－１５３８９４（ＪＰ，Ａ）
【文献】特開２０１８－１４２９０１（ＪＰ，Ａ）
【文献】特開２０２０－０１０１９２（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ１２／００－１３／１８，４１／００－４９／９０５７，６１／００－６５／８０，６９／００－６９／４０
(57)【特許請求の範囲】
【請求項1】
モノのインターネット（ＩｏＴ）システムにおいてデータを送信するための方法であって、前記方法は、ＩｏＴデバイスによって送信されたデバイスデータをサーバーに送信するように構成されたゲートウェイデバイスに適用され、
前記方法は、
前記ゲートウェイデバイスと前記サーバーの間の接続が異常な場合に、前記ＩｏＴデバイスによって送信された前記デバイスデータのデータタイプを決定すること、ここで、前記データタイプには、リアルタイムデータタイプおよび履歴データタイプが含まれ、
前記リアルタイムデータタイプの前記デバイスデータをメッセージ指向ミドルウェアの第１のメッセージキューに格納し、前記履歴データタイプの前記デバイスデータを前記メッセージ指向ミドルウェアの第２のメッセージキューに格納すること、
前記第１のメッセージキュー内の前記デバイスデータを第１のメッセージキューテレメトリートランスポート（ＭＱＴＴ）チャネルを介して前記サーバーに送信し、前記第２のメッセージキュー内の前記デバイスデータを第２のＭＱＴＴチャネルを介して前記サーバーに送信すること、
を含むことを特徴とする方法。
【請求項2】
請求項１に記載の方法において、前記ＩｏＴデバイスによって送信された前記デバイスデータのデータタイプを決定することは、
前記デバイスデータのデータ受信時点を取得すること、ここで、前記データ受信時点は、前記ゲートウェイデバイスが前記デバイスデータを受信する時点であり、
前記データ受信時点、現在時点、予想処理時間、および送信遅延閾値に従って、前記デバイスデータの前記データタイプを決定すること、ここで、前記予想処理時間は、前記現在時点から送信完了時点までの予想時間であり、前記送信遅延閾値は、データ受信から送信完了までの最大遅延である、
を含むことを特徴とする方法。
【請求項3】
請求項２に記載の方法において、前記データ受信時点、前記現在時点、前記予想処理時間、および前記送信遅延閾値に従って、前記デバイスデータの前記データタイプを決定することは、
前記データ受信時点、前記現在時点、および前記予想処理時間に従って、前記デバイスデータの予想送信時間を決定すること、
前記予想送信時間が前記送信遅延閾値よりも大きい場合、前記デバイスデータが前記履歴データタイプであると判断すること、
前記予想送信時間が前記送信遅延閾値よりも小さい場合、前記デバイスデータが前記リアルタイムデータタイプであると判断すること、
を含むことを特徴とする方法。
【請求項4】
請求項２に記載の方法において、前記データ受信時点、前記現在時点、前記予想処理時間、および前記送信遅延閾値に従って、前記デバイスデータの前記データタイプを決定する前に、
前記方法は更に、
前記デバイスデータのデータ処理の難易度および事前設定された対応関係に従って、前記デバイスデータに対応する前記予想処理時間および前記送信遅延閾値を決定すること、ここで、前記事前設定された対応関係には、前記データ処理の難易度、前記予想処理時間、および前記送信遅延閾値の間の対応関係が含まれる、
を含むことを特徴とする方法。
【請求項5】
請求項１乃至請求項４のいずれかに記載の方法において、前記第１のメッセージキュー内の前記デバイスデータを前記第１のＭＱＴＴチャネルを介して前記サーバーに送信し、前記第２のメッセージキュー内の前記デバイスデータを第２のＭＱＴＴチャネルを介して前記サーバーに送信することは、
第１のキュー消費頻度に従って、前記第１のメッセージキュー内の前記デバイスデータを前記第１のＭＱＴＴチャネルを介して前記サーバーに送信すること、
前記第１のキュー消費頻度および接続帯域幅に従って、前記第２のメッセージキューの第２のキュー消費頻度を決定すること、ここで、前記第１のキュー消費頻度および前記第２のキュー消費頻度に対応する総占有帯域幅は、前記接続帯域幅よりも小さい、
前記第２のキュー消費頻度に従って、前記第２のメッセージキュー内の前記デバイスデータを前記第２のＭＱＴＴチャネルを介して前記サーバーに送信すること、
を含むことを特徴とする方法。
【請求項6】
請求項１乃至請求項４のいずれかに記載の方法において、前記第１のメッセージキュー内の前記デバイスデータを前記第１のＭＱＴＴチャネルを介して前記サーバーに送信し、前記第２のメッセージキュー内の前記デバイスデータを第２のＭＱＴＴチャネルを介して前記サーバーに送信する前に、
前記方法は更に、
前記ゲートウェイデバイスと前記サーバーの間の接続が通常の状態に戻ったときに、前記第１のメッセージキュー内の前記デバイスデータの前記データタイプを再決定し、前記第１のメッセージキュー内の前記履歴データタイプの前記デバイスデータを前記第２のメッセージキューに転送すること、
または、
所定の時間間隔毎に、前記第１のメッセージキュー内の前記デバイスデータの前記データタイプを再決定し、前記第１のメッセージキュー内の前記履歴データタイプの前記デバイスデータを前記第２のメッセージキューに転送すること、
を含むことを特徴とする方法。
【請求項7】
請求項２乃至請求項４のいずれかに記載の方法において、前記ゲートウェイデバイスと前記サーバーの間の接続が異常な場合に、前記ＩｏＴデバイスによって送信された前記デバイスデータのデータタイプを決定することは、
前記ゲートウェイデバイスと前記サーバーの間の接続が異常で、第１のブレークポイント再開モードが採用された場合に、前記ＩｏＴデバイスによって送信された前記デバイスデータの前記データタイプを決定すること、ここで、前記第１のブレークポイント再開モードは、前記リアルタイムデータが優先的に送信される送信モードであり、
を含み、
前記方法は更に、
前記ゲートウェイデバイスと前記サーバーの間の接続が異常で、第２のブレークポイント再開モードが採用された場合に、前記デバイスデータの前記データ受信時点に基づいて、先入れ先出し原則に従って前記デバイスデータを前記第１のメッセージキューに格納すること、ここで、前記第２のブレークポイント再開モードは、受信時系列に従ってデータがアップロードされる送信モードであり、
前記ゲートウェイデバイスと前記サーバーの間の接続が通常の状態に再開したときに、前記第１のメッセージキュー内の前記デバイスデータを前記第１のＭＱＴＴチャネルを介して送信すること、
を含むことを特徴とする方法。
【請求項8】
ＩｏＴシステムにおいてデータを送信するための装置であって、前記装置は、ＩｏＴデバイスによって送信されたデバイスデータをサーバーに送信するように構成されたゲートウェイデバイスに適用され、
前記装置は、
前記ゲートウェイデバイスと前記サーバーの間の接続が異常な場合に、前記ＩｏＴデバイスによって送信された前記デバイスデータのデータタイプを決定するように構成された、第１の決定モジュールと、ここで、前記データタイプには、リアルタイムデータタイプおよび履歴データタイプが含まれ、
前記リアルタイムデータタイプの前記デバイスデータをメッセージ指向ミドルウェアの第１のメッセージキューに格納し、前記履歴データタイプの前記デバイスデータを前記メッセージ指向ミドルウェアの第２のメッセージキューに格納するように構成された、第１の記憶モジュールと、
前記ゲートウェイデバイスと前記サーバーの間の接続が通常の状態に戻ったときに、前記第１のメッセージキュー内の前記デバイスデータを第１のＭＱＴＴチャネルを介して前記サーバーに送信し、前記第２のメッセージキュー内の前記デバイスデータを第２のＭＱＴＴチャネルを介して前記サーバーに送信する構成された、第１の送信モジュールと、
を備えたことを特徴とする装置。
【請求項9】
プロセッサおよびメモリを含むゲートウェイデバイスであって、前記メモリは、少なくとも１つの命令、少なくとも１つのプログラム、コードセット、または命令セットを記憶し、
前記少なくとも１つの命令、前記少なくとも１つのプログラム、前記コードセット、または前記命令セットは、前記プロセッサによってロードおよび実行されて、請求項１～７のいずれかに定義された、ＩｏＴシステムにおいてデータを送信するための方法を実施する、
ことを特徴とするゲートウェイデバイス。
【請求項10】
少なくとも１つの命令、少なくとも１つのプログラム、コードセット、または命令セットを記憶したコンピュータ可読記憶媒体であって、前記少なくとも１つの命令、前記少なくとも１つのプログラム、前記コードセット、または前記命令セットは、プロセッサによってロードおよび実行されて、請求項１～７のいずれかに定義された、ＩｏＴシステムにおいてデータを送信するための方法を実施する、
ことを特徴とするコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示の実施形態は、モノのインターネットの分野に関し、より具体的には、データを送信するための方法および装置、並びにゲートウェイデバイスおよびそれらの記憶媒体に関する。
【背景技術】
【0002】
モノのインターネット（ＩｏＴ）システムは、情報取得デバイスによるインフラストラクチャとインターネットとの間の情報交換を実施するコンピュータ制御システムである。ゲートウェイデバイスは、エッジのＩｏＴデバイスによって得られたデータを取得して、そのデータをクラウドに報告するものであり、関連する担当者がそのデータを分析する場合がある。
【0003】
ゲートウェイデバイスによってクラウドにデータをアップロードするプロセスにおいて、ネットワーク遅延またはインフラストラクチャ障害などのために通信が中断される場合がある。関連技術では、ブレークポイントデータは通常、破棄され、または、ディスクファイルやデータベースにキャッシュされ、通信が再開された後にクラウドにアップロードされる。
【0004】
しかしながら、関連技術におけるブレークポイントデータを処理するための方法では、キャッシュされたデータファイルは、一般に、タイムスタンプに従ってクラウドに手動でアップロードされる必要がある。その操作は複雑で時間がかかり、データの適時性が保証されない場合がある。
【発明の概要】
【0005】
本開示の実施形態は、ＩｏＴシステムにおいてデータを送信するための方法および装置、並びにゲートウェイデバイス、およびそれらの記憶媒体を提供する。技術的な解決策は以下のとおりである。
【0006】
一態様において、本開示の実施形態は、ＩｏＴシステムにおいてデータを送信するための方法を提供する。この方法には、以下が含まれる：
【0007】
ゲートウェイデバイスとサーバーの間の接続が異常な場合に、ＩｏＴデバイスによって送信されたデバイスデータのデータタイプを決定すること、ここで、データタイプには、リアルタイムデータタイプおよび履歴データタイプが含まれ；
【0008】
リアルタイムデータタイプのデバイスデータをメッセージ指向ミドルウェアの第１のメッセージキューに格納し、履歴データタイプのデバイスデータをメッセージ指向ミドルウェアの第２のメッセージキューに格納すること；
【0009】
第１のメッセージキュー内のデバイスデータを第１のメッセージキューテレメトリートランスポート（ＭＱＴＴ）チャネルを介してサーバーに送信し、第２のメッセージキュー内のデバイスデータを第２のＭＱＴＴチャネルを介してサーバーに送信すること。
【0010】
別の態様において、本開示の実施形態は、ＩｏＴシステムにおいてデータを送信するための装置を提供する。この装置には、以下が含まれる：
【0011】
ゲートウェイデバイスとサーバーの間の接続が異常な場合に、ＩｏＴデバイスによって送信されたデバイスデータのデータタイプを決定するように構成された、第１の決定モジュール、ここで、データタイプには、リアルタイムデータタイプおよび履歴データタイプが含まれ；
【0012】
リアルタイムデータタイプのデバイスデータをメッセージ指向ミドルウェアの第１のメッセージキューに格納し、履歴データタイプのデバイスデータをメッセージ指向ミドルウェアの第２のメッセージキューに格納するように構成された、第１の記憶モジュール；
【0013】
ゲートウェイデバイスとサーバーの間の接続が通常の状態に戻ったときに、第１のメッセージキュー内のデバイスデータを第１のＭＱＴＴチャネルを介してサーバーに送信し、第２のメッセージキュー内のデバイスデータを第２のＭＱＴＴチャネルを介してサーバーに送信するように構成された、第１の送信モジュール。
【0014】
別の態様において、本開示の実施形態は、ゲートウェイデバイスを提供する。このゲートウェイデバイスは、プロセッサおよびメモリを含み、メモリは、少なくとも１つの命令、少なくとも１つのプログラム、コードセット、または命令セットを記憶し、少なくとも１つの命令、少なくとも１つのプログラム、コードセット、または命令セットは、上記の態様で説明したように、ＩｏＴシステムでデータを送信するための方法を実施するために、プロセッサによってロードおよび実行される。
【0015】
別の態様において、本開示の実施形態は、コンピュータ可読記憶媒体を提供する。このコンピュータ可読記憶媒体は、少なくとも１つの命令、少なくとも１つのプログラム、コードセット、または命令セットを記憶し、少なくとも１つの命令、少なくとも１つのプログラム、コードセット、または命令セットは、上記の態様で説明したように、ＩｏＴシステムでデータを送信するための方法を実装するために、プロセッサによってロードおよび実行される。
【0016】
本開示の実施形態による技術的解決策によって達成される有益な効果には、少なくとも以下が含まれる：
【0017】
ゲートウェイデバイスとサーバーの間の接続が異常な場合に、送信されるデータは、リアルタイムデータと履歴データに分割され、接続が通常の状態に戻ったときに、メッセージキュー内のデバイスデータが異なるチャネルを介してサーバーにアップロードされるように、それぞれ異なるメッセージキューに格納され、これにより、データの整合性を確保しながらリアルタイムデータのアップロードの適時性が向上し、ブレークポイントデータを補完的にアップロードするための手動の介入が不要になるため、操作手順が簡素化される。
【図面の簡単な説明】
【0018】
【図1】例示的な実施形態に関する実装環境の概略図である。
【0019】
【図2】例示的な実施形態に関するＩｏＴシステムにおいてデータを送信するための方法のフローチャートである。
【0020】
【図3】例示的な実施形態に関するＩＯＴシステムにおけるデータ送信プロセスの概略図である。
【0021】
【図4】別の例示的な実施形態に関するＩＯＴシステムにおいてデータを送信するための方法のフローチャートである。
【0022】
【図5】別の例示的な実施形態に関するデータ送信プロセスの概略図である。
【0023】
【図6】別の例示的な実施形態に関するＩｏＴシステムにおいてデータを送信するための方法のフローチャートである。
【0024】
【図7】別の例示的な実施形態に関するＩｏＴシステムにおいてデータを送信するための方法のフローチャートである。
【0025】
【図8】例示的な実施形態に関するＩｏＴシステムにおいてデータを送信するための装置の構造ブロック図である。
【0026】
【図9】例示的な実施形態に関するゲートウェイデバイスの概略構造図である。
【発明を実施するための形態】
【0027】
本開示は、添付の図面を参照して以下で更に詳細に説明され、本開示の目的、技術的解決策、および利点をより明確に提示する。
【0028】
本明細書で言及される「複数」という用語は、２つ以上を意味する。本明細書における「および／または」という用語は、対応するオブジェクトの対応関係を説明し、３種類の関係を示す。例えば、Ａおよび／またはＢは、Ａが単独で存在、ＡとＢが同時に存在、Ｂが単独で存在、を表す可能性がある。文字「／」は通常、前後の関係上のオブジェクトが「ＯＲ（または）」関係であることを示す。
【0029】
関連技術では、ＩｏＴシステムにおいて、ゲートウェイデバイスとサーバーの間の接続が異常な場合に、ゲートウェイデバイスは、受信したデバイスデータをローカルキャッシュファイルに記憶し、接続が通常の状態に戻った後、キャッシュファイル内のデータは、手動の介入操作によって補完的にサーバーにアップロードされる。短時間のネットワークジッターまたはその他の要因によって引き起こされる瞬間的なブレークポイントデータの場合、ゲートウェイデバイスは通常、データを直接破棄する。
【0030】
上記の技術によるブレークポイントデータの補足的なアップロードに関して、前者は、手動の介入操作を必要とし、そのステップは面倒で時間がかかり、データのサービス価値の損失をもたらす可能性があり；一定期間内に複数の接続異常が発生した場合、デバイスデータの補足アップロードもデータのインポートとエクスポートを複数回行う必要があり、手動操作でエラーが発生しやすく、タイムウィンドウの重複、欠落、乱れが発生する可能性があり；また、補足アップロードのためのデータエクスポートの過程で、データを外部ストレージの方法で保存する必要があり、デバイスデータの漏洩を引き起こす可能性がある。後者は、瞬間的なブレークポイントデータを直接破棄するため、デバイスデータの整合性が保証されない場合がある。
【0031】
上記の問題を解決するために、本開示の一実施形態は、ＩｏＴシステムにおいてデータを送信するための方法を提供する。図１を参照すると、本開示の例示的な実施形態に関する実装環境の概略図が示されている。実装環境には、ＩｏＴデバイス１０１と、ゲートウェイデバイス１０２と、サーバー１０３とが含まれる。
【0032】
ＩｏＴデバイス１０１は、ＩｏＴシステムにおける情報取得デバイスであり、主にデータを取得するように構成されており、センサー（光起電センサー、速度センサー、圧力センサーなど）およびアクチュエータ（油圧アクチュエータ、パルス信号アクチュエータなど）を通常備えている。センサーは、デバイスによって取得された情報を、特定の規則に従って出力するための電気信号または他の所望の形式の情報に変換することができる。アクチュエータは通常、自動制御システムでクラウドやその他のデバイスから制御信号を受信するために使用され、それによって制御された量を必要な範囲内に維持する。ＩｏＴデバイスは、データの取得と送信に加えて、産業、送電網、スマートホーム、高度道路交通などの分野で一般的に使用されているデータ処理およびストレージ機能もサポートする必要がある。
【0033】
ＩｏＴデバイス１０１とゲートウェイデバイス１０２は、有線または無線ネットワークによって接続されている。
【0034】
ゲートウェイデバイス１０２は、複数のネットワーク間でデータ変換サービスを提供するコンピュータシステムまたはデバイスである。ＩｏＴシステムにおいて、ゲートウェイデバイス１０２は、複数のＩｏＴデバイスによってアップロードされたデバイスデータを受信し、デバイスデータがサーバー１０３にアップロードされるように、デバイスデータを所定のフォーマットに変換するように構成される。
【0035】
本開示の実施形態において、第１のＭＱＴＴチャネルおよび第２のＭＱＴＴチャネルは、ゲートウェイデバイス１０２とサーバー１０３の間に配置され；ゲートウェイデバイス１０２とサーバー１０３の間の接続が中断された場合に、ゲートウェイデバイス１０２は、ＩｏＴデバイスによって報告されたデバイスデータを履歴データとリアルタイムデータに分割し；接続が再開されたときに、リアルタイムデータは第１のＭＱＴＴチャネルを介してサーバー１０３にアップロードされ、履歴データは第２のＭＱＴＴチャネルを介してアップロードされ；また、第１のＭＱＴＴチャネルおよび第２のＭＱＴＴチャネルを介してデバイスデータをアップロードしたときに、ゲートウェイデバイス１０２は、リアルタイムデータ送信が影響を受けないことを保証するという前提条件の下で、履歴データが補完的にアップロードされるように、履歴データの消費率を制御する。
【0036】
サーバー１０３は、ＩｏＴシステムにおけるクラウドであり、ゲートウェイデバイス１０２からデバイスデータを受信し、デバイスデータを記憶、処理、および分析するように構成され、それにより、サービスディスカバリを実行し、サービスクエリ機能を提供して、ＩｏＴアプリケーションサービスロジックを実装する。
【0037】
オプションとして、ＩｏＴシステムは、サーバー１０３に接続されてサーバー１０３にデータクエリ要求を送信するように構成された監視デバイスを更に含み、サーバー１０３は、データクエリ要求に従って、記憶されたデバイスデータを照会し、照会されたデバイスデータを表示するために監視デバイスにフィードバックして、スタッフが各ＩｏＴデバイス１０１の動作状態を監視するのを助ける。
【0038】
図２を参照すると、本開示の例示的な実施形態に関するＩｏＴシステムにおいてデータを送信するための方法のフローチャートが示されている。この実施形態は、一例としてゲートウェイデバイスで使用される方法を取り上げることによって示される。この方法には、以下のステップが含まれる。
【0039】
ステップ２０１：ゲートウェイデバイスとサーバーの間の接続が異常な場合、ＩｏＴデバイスによって送信されたデバイスデータのデータタイプが決定され、ここで、データタイプには、リアルタイムデータタイプおよび履歴データタイプが含まれる。
【0040】
ＩｏＴシステムにおいて、ゲートウェイデバイスは、ＩｏＴデバイスからデバイスデータを受信し、そのデータをクラウドサーバーに送信して、データ統計を実装し、ビジネス価値を発見する。しかしながら、ネットワークのジッターや機器の故障などにより、ゲートウェイデバイスとクラウドサーバーの間のデータ伝送チャネルに接続異常が発生し、データ伝送が中断する場合がある。
【0041】
可能な実装において、ゲートウェイデバイスは、事前設定された判断メカニズムに従って、ＩｏＴデバイスによって送信されたデバイスデータをリアルタイムデータと履歴データに分割する。ゲートウェイデバイスとサーバーの間の接続が異常な場合、送信する現在のデータのデータタイプを最初に判別し、その後、異なるタイプのデータに対して対応する処理を実行する。
【0042】
ステップ２０２：リアルタイムデータタイプのデバイスデータは、メッセージ指向ミドルウェアの第１のメッセージキューに格納され、履歴データタイプのデバイスデータは、メッセージ指向ミドルウェアの第２のメッセージキューに格納される。
【0043】
メッセージ指向ミドルウェアは、リアルタイムデータ伝送、信頼キュー、イベントサービスなどの様々な機能を含む、分散ネットワークにおける様々なエンドツーエンドのデータ通信サービスを提供する、メッセージ転送に基づく通信ソフトウェアである。ゲートウェイデバイスは、送信するデータのデータタイプを決定した後、データタイプに応じて、メッセージ指向ミドルウェアの対応するメッセージキューにデータを格納する。
【0044】
概略的には、図３を参照すると、ＩｏＴシステムは、アクティブメッセージキュー（ＡＭＱ）を採用し、パブリッシュ／サブスクライブモードを選択する、つまり、ゲートウェイデバイス３０１は、サブスクリプション後にのみメッセージキューを取得し、それをサーバー３０３に送信することができる。メッセージキューテレメトリトランスポート（ＭＱＴＴ）プロトコルのサーバー側実装、すなわち、サーバー３０３で実行されるＭＱＴＴブローカーが存在する。パブリッシュ／サブスクライブ機能を実装する前に、ＡＭＱをＭＱＴＴブローカーに接続する必要がある。ゲートウェイデバイス３０１は、ＩｏＴデバイス３０２からデバイスデータを受信し、デバイスデータをサーバー３０３に送信する。ゲートウェイデバイス３０１とサーバー３０３の間の接続が異常な場合に、送信される現在のデバイスデータがＡＭＱのメッセージキューに公開され；接続が通常の状態に戻ったときに、ゲートウェイデバイス３０１はＡＭＱのメッセージキュー内のデバイスデータをサブスクライブし、対応するデータチャネルからサーバー３０３にデバイスデータを送信する。
【0045】
ステップ２０３：ゲートウェイデバイスとサーバーの間の接続が再開されたときに、第１のメッセージキュー内のデバイスデータは第１のＭＱＴＴチャネルを介してサーバーに送信され、第２のメッセージキュー内のデバイスデータは第２のＭＱＴＴチャネルを介してサーバーに送信される。
【0046】
可能な実装において、２つのＭＱＴＴチャネルは、ゲートウェイデバイスとサーバーの間に配置される。ゲートウェイデバイスとサーバーの間のデータ伝送ステータスが正常な場合、ゲートウェイデバイスは、第１のメッセージキュー内のデバイスデータを第１のＭＱＴＴチャネルを介してサーバーに送信する。第２のメッセージキューに保存されている履歴データの場合、ゲートウェイデバイスは、最初に第２のＭＱＴＴチャネルが確立されているかどうかを検出し、第２のＭＱＴＴチャネルが確立されている場合は、第２のメッセージキュー内のデバイスデータを第２のＭＱＴＴチャネルを介してサーバーに送信し、第２のＭＱＴＴチャネルが確立されていない場合は、第２のＭＱＴＴチャネルの接続を初期化してから、第２のメッセージキュー内のデバイスデータを第２のＭＱＴＴチャネルを介してサーバーに送信する。第２のＭＱＴＴチャネルは、履歴データのみをアップロードするためのチャネルであり、データはチャネル内で暗号化された方法で送信されるため、漏洩や盗難のリスクが軽減される。
【0047】
要約すると、本開示の実施形態では、ゲートウェイデバイスとサーバーの間の接続が異常な場合に、送信されるデータは、リアルタイムデータと履歴データに分割され、接続が通常の状態に戻ったときに、メッセージキュー内のデバイスデータが異なるチャネルを介してサーバーにアップロードされるように、それぞれ異なるメッセージキューに格納され、これにより、データの整合性を確保しながらリアルタイムデータのアップロードの適時性が向上し、ブレークポイントデータを補完的にアップロードするための手動の介入が不要になるため、操作手順が簡素化される。
【0048】
図４を参照すると、本開示の別の例示的な実施形態に関するＩｏＴシステムにおいてデータを送信するための方法のフローチャートが示されている。この実施形態は、一例としてゲートウェイデバイスで使用される方法を取り上げることによって示される。この方法には、以下のステップが含まれる。
【0049】
ステップＳ４０１：デバイスデータのデータ受信時点が受信され、ここで、データ受信時点は、ゲートウェイデバイスがデバイスデータを受信する時点である。
【0050】
可能な実装において、ＩｏＴデバイスによって得られたデバイスデータを取得する場合、ゲートウェイデバイスは、デバイスデータを所定のフォーマットのデータ構造に変換し、ここで、データ構造には、データ受信時点を記憶するためのフィールドが含まれる。デバイスデータをアップロードする前に、ゲートウェイデバイスは最初にフィールドからデバイスデータのデータ受信時間を読み取る。
【0051】
ステップ４０２：デバイスデータのデータタイプは、データ受信時点、現在時点、予想処理時間、および送信遅延閾値に従って決定され、ここで、予想処理時間は、現在時点から 送信完了時点までの予想時間であり、送信遅延閾値は、データ受信から送信完了までの最大遅延である。
【0052】
予想処理時間は、ＩｏＴデバイスのデバイスデータタイプ、データ容量、ネットワーク帯域幅などの要因に基づいて、ゲートウェイデバイスによって決定および取得されるものであり、デバイスデータに対して現在時点から送信成功時点までに望まれる時間である。送信遅延閾値は、デバイスデータタイプおよび履歴送信レコードに基づいて、ゲートウェイデバイスによって取得されるものであり、データ受信から送信完了までに許容される最大遅延である。ゲートウェイデバイスは、ＩｏＴデバイスのデバイスデータを受信する場合に、デバイスデータのデータ受信時間を取得し、対応する予想処理時間および送信遅延閾値を取得し、現在時点に基づいて、デバイスデータのデータタイプを決定する。
【0053】
可能な実装において、プロセスには、以下のステップが含まれ得る：
【0054】
１．デバイスデータの予想送信時間は、データ受信時点、現在時点、および予想処理時間に従って決定される。
【0055】
あるいは、予想処理時間は、現在のネットワーク状態、第１のＭＱＴＴチャネルのデータ伝送速度、およびデータ伝送キュー内のデバイスデータの容量などの要因に基づいて、ゲートウェイデバイスによって事前設定および決定される、つまり、現在時点から送信完了時点までの予想時間である。ゲートウェイデバイスは、データ受信時点、現在時点、および予想処理時間に従って、デバイスデータの予想送信時間を決定する。可能な実装において、デバイスデータの予想送信時間は、現在時点からデータ受信時間を差し引いて予想処理時間を加えたものに等しい。
【0056】
概略的には、現在時点が１０：００：１０である場合、データ受信瞬間が１０：００：０８、予想処理時間が１秒のデバイスデータに対しては、予想送信時間は３秒である。
【0057】
２．予想送信時間が送信遅延閾値よりも大きい場合、デバイスデータは履歴データタイプであると判断される。
【0058】
ゲートウェイデバイスは、デバイスデータの予想送信時間を送信遅延閾値と比較し、比較結果に従って、デバイスデータのデータタイプを履歴データタイプとリアルタイムデータタイプに分割し、予想送信時間が送信遅延閾値よりも大きい場合、デバイスデータは履歴データタイプである。
【0059】
概略的に、ゲートウェイデバイスは、２秒の送信遅延閾値を事前設定しており、現在時点が１０：００：１０である場合に、データ受信瞬間が１０：００：０８、予想処理時間が１秒のデバイスデータに対して、その予想送信時間は３秒であり、これは送信遅延閾値よりも大きく、ゲートウェイデバイスは、デバイスデータが履歴データタイプであると判断する。
【0060】
３．予想送信時間が送信遅延閾値よりも小さい場合、デバイスデータはリアルタイムデータタイプであると判断される。
【0061】
デバイスデータの予想送信時間が送信遅延閾値よりも小さい場合、デバイスデータの予想送信時間はリアルタイムデータの範囲内にあり、すなわち、データはリアルタイムデータタイプである。
【0062】
概略的に、ゲートウェイデバイスは、２秒の送信遅延閾値を事前設定しており、現在時点が１０：０：１０である場合、データ受信の瞬間が１０：０：１０、予想処理時間が１秒のデバイスデータに対して、その予想送信時間は１秒であり、これは送信遅延閾値よりも小さく、ゲートウェイデバイスは、デバイスデータがリアルタイムデータタイプであると判断する。
【0063】
可能な実装において、１つのゲートウェイデバイスは、複数のＩｏＴデバイスによって取得されたデータを受信し、そのデータをサーバーにアップロードする。取得デバイスが異なるため、デバイスデータのデータ構造、データ容量、送信時に消費されるネットワークリソースなども異なる。したがって、ステップ４０２の前に、ゲートウェイデバイスは、デバイスデータのデータ処理の難易度および事前設定された対応関係に従って、デバイスデータに対応する予想処理時間および送信遅延閾値を決定し、これに応じて、ゲートウェイデバイスはその後、デバイスデータに対応する予想処理時間および送信遅延閾値に従って、デバイスデータがリアルタイムデータまたは履歴データに属することを決定するものであり、事前設定された対応関係には、データ処理の難易度、予想処理時間、および送信遅延閾値の間の対応関係が含まれる。
【0064】
概略的には、大量の取得データ、複雑なデータ構造、および長い送信時間を有する取得デバイスに対して、ゲートウェイデバイスは、そのデバイスデータの予想処理時間をＴ１に設定し、送信遅延閾値をＴ２に設定し；取得データの量が少ない、または送信時間が短い取得デバイスに対して、ゲートウェイデバイスは、そのデバイスデータの予想処理時間をＴ３に設定し、送信遅延閾値をＴ４に設定する。後者のデータ処理の難易度は前者よりも低く、Ｔ２はＴ４よりも大きくなる。
【0065】
ステップ４０３：リアルタイムデータタイプのデバイスデータは、メッセージ指向ミドルウェアの第１のメッセージキューに格納され、履歴データタイプのデバイスデータは、メッセージ指向ミドルウェアの第２のメッセージキューに格納される。
【0066】
ステップ４０３の実装については、ステップ２０２を参照することができ、これは、本実施形態では再度の説明をしない。
【0067】
ステップＳ４０４：第１のメッセージキュー内のデバイスデータのデータタイプは、ゲートウェイデバイスとサーバーの間の接続が通常の状態に戻ったときに再決定され；第１のメッセージキュー内の履歴データタイプのデバイスデータは、第２のメッセージキューに転送される。
【0068】
ゲートウェイデバイスとサーバーの間の接続が正常な状態に戻るまでには時間がかかるため、異常な接続の前のリアルタイムデータを履歴データに変換することができる。したがって、ゲートウェイデバイスとサーバーの間の接続が通常の状態に戻ったときに、第１のメッセージキュー内のデバイスデータのデータタイプが再決定され；履歴データが存在する場合、履歴データタイプのデバイスデータは第２のメッセージキューに転送される。
【0069】
概略的には、図５に示すように、ゲートウェイデバイスは、２秒の送信遅延閾値を事前設定しており、送信チャネル接続が異常な時点が１０：００：０８である場合、データ受信時点が１０：００：０８で、予想処理時間が１秒のデバイスデータに対して、接続が異常な場合の予想送信時間は１秒であり、デバイスデータはリアルタイムデータタイプであり、接続が正常状態に戻った場合の予想送信時間は３秒であり、これは送信遅延閾値より大きく、デバイスデータは履歴データタイプであり、ゲートウェイデバイスはデバイスデータを第２のメッセージキューに転送する。
【0070】
別の可能な実装において、ステップ４０４は、以下によって更に置き換えることができる：所定の時間間隔毎に、第１のメッセージキュー内のデバイスデータのデータタイプを再決定し、第１のメッセージ内の履歴データタイプのデバイスデータを第２のメッセージキューに転送する。
【0071】
ゲートウェイデバイスとサーバーの間の接続が異常である場合でも、接続が通常の状態に戻ったときに、第１のメッセージキューのデバイスデータが対応するチャネルから迅速にアップロードされ得るように、ゲートウェイデバイスは、デバイスデータのデータタイプを決定することができ、ゲートウェイデバイスは、所定の時間間隔毎に、第１のメッセージキュー内のデバイスデータのデータタイプを再決定し、第１のメッセージキュー内の履歴データタイプのデバイスデータを第２のメッセージキューに転送する。
【0072】
ステップ４０５：第１のメッセージキュー内のデバイスデータは、第１のキュー消費頻度に従って、第１のＭＱＴＴチャネルを介してサーバーに送信される。
【0073】
第１のＭＱＴＴチャネル接続が通常の状態に戻った後、ゲートウェイデバイスは、メッセージ指向ミドルウェア内の第１のメッセージキューのデバイスデータを、第１のキュー内のリアルタイムデータの消費頻度に従って、第１のＭＱＴＴチャネルを介してサーバーに送信する。
【0074】
可能な実装において、１つのゲートウェイデバイスが複数のＩｏＴデバイスに接続されており、受信されたデバイスデータには複数のタイプがあるため、第１のメッセージキューの第１のキュー消費頻度は常に変換する可能性があり、例えば、ＩｏＴデバイスＡが取得したデバイスデータを集中的に送信する場合、第１のキュー消費頻度は１時間あたり１８００であり、ＩｏＴデバイスＢが取得したデバイスデータを集中的に送信する場合、データ量は少なく、 第１のキュー消費頻度は１時間あたり１０００である。
【0075】
ステップ４０６：第２のメッセージキューの第２のキュー消費頻度は、第１のキュー消費頻度および接続帯域幅に従って決定され、ここで、第１のキュー消費頻度および第２のキュー消費頻度に対応する総占有帯域幅は、接続帯域幅よりも小さい。
【0076】
第１のＭＱＴＴチャネルおよび第２のＭＱＴＴチャネルは、同じネットワーク環境でデバイスデータを送信し、占有帯域幅の合計が優先されるため、履歴データの送信は、リアルタイムデータの送信速度に影響を与える可能性がある。リアルタイムデータが通常の速度に従ってサーバーに優先的に送信されることを保証するために、ゲートウェイデバイスは、第１のキュー消費頻度および接続帯域幅に従って、第２のメッセージキューの第２のキュー消費頻度を決定する。
【0077】
可能な実装において、ユーザは、第２のキュー消費頻度と第１のキュー消費頻度および接続帯域幅との関係を事前設定して、第１のキュー消費頻度が変化するにつれて第２キュー消費頻度を動的に調整することができる。
【0078】
概略的には、現在の期間内で、接続帯域幅によって許容される最高のメッセージキュー消費頻度は、１時間あたり２０００である。ＩｏＴデバイスＡによって取得されたデバイスデータが集中的に送信される場合、第１のキュー消費頻度は１時間あたり１８００であり、ゲートウェイデバイスは、第２のキュー消費頻度を１時間あたり２００を超えないように調整し；ＩｏＴデバイスＢによって取得されたデバイスデータが集中的に送信される場合、データ容量は少なく、第１のキューの消費頻度は１時間あたり１０００であり、ゲートウェイデバイスは、第２のキュー消費頻度を１時間あたり１０００を超えないように調整する。
【0079】
ステップＳ４０７：第２のメッセージキュー内のデバイスデータは、第２のキュー消費頻度に従って、第２のＭＱＴＴチャネルを介してサーバーに送信される。
【0080】
第１のキュー消費頻度および接続帯域幅に従って、現在の第２のキュー消費頻度を決定した後、ゲートウェイデバイスは、第２のキュー消費頻度に従って、第２のＭＱＴＴチャネルを介して第２のメッセージキュー内の履歴データをサーバーに送信し、これにより、リアルタイムデータが優先的にアップロードされるようになる。
【0081】
本開示の実施形態において、異なるＩｏＴデバイスのデバイスデータについて、履歴データとリアルタイムデータは実際のニーズに応じて分割され、第２のキュー消費頻度が第１のキュー消費に応じて決定され；リアルタイムデータが優先的に送信されるという条件の下で、履歴データは第２のＭＱＴＴチャネルを介してサーバーに送信され、これにより、データの整合性と適時性を確保することを前提として、データ処理と送信効率が向上する。
【0082】
上記の実施形態において、デバイスデータは、リアルタイムデータが優先的に送信される送信モードで送信され、つまり、履歴データは、リアルタイムデータの優先的な送信を確実にすることを前提としてアップロードされ、より厳密な取得時系列を必要とする一部のデータの場合、ブレークポイント再開モードにより、サーバーによって取得されたデバイスデータの時系列が乱れる可能性がある。したがって、図６を参照すると、可能な実装において、ステップ４０１の前に、以下のステップも含まれる。
【0083】
ステップ４０８：デバイスデータのブレークポイント再開モードが取得される。
【0084】
可能な実装において、異なるＩｏＴデバイスについて、ユーザは、実際のニーズに応じて異なるブレークポイント再開モードを設定することができ、ゲートウェイデバイスは、デバイスデータを送信する前に、最初にデバイスデータのブレークポイント再開モードを取得する。
【0085】
ステップ４０９：ＩｏＴデバイスによって送信されたデバイスデータのデータタイプは、ゲートウェイデバイスとサーバーの間の接続が異常で、第１のブレークポイント再開モードが採用された場合に決定され、ここで、第１のブレークポイント再開モードは、リアルタイムデータが優先的に送信される送信モードである。
【0086】
ゲートウェイデバイスは、デバイスデータのブレークポイント再開モードに基づいて、対応する送信モードを採用する。ゲートウェイデバイスとサーバーの間の接続が正常な場合、デバイスデータは第１のＭＱＴＴチャネルを介してサーバーに送信され；ゲートウェイデバイスとサーバーの間の接続が異常な場合、現在のデバイスデータが第１のブレークポイント再開モードを採用すると、そのデータタイプが決定され、ステップ４０１～４０７が実行される。
【0087】
ステップ４１０：デバイスデータは、ゲートウェイデバイスとサーバーの間の接続が異常で、第２のブレークポイント再開モードが採用された場合に、デバイスデータのデータ受信時点に基づいて、先入れ先出し原則に従って第１のメッセージキューに格納され、ここで、第２のブレークポイント再開モードは、受信時系列に従ってデータがアップロードされる送信モードである。
【0088】
ゲートウェイデバイスとサーバーの間の接続が異常な場合、厳密な時系列を必要とする一部のデバイスデータについて、ゲートウェイデバイスは、送信のために、つまり、デバイスデータのデータ受信時点に応じて第２のブレークポイント再開モードを採用し、デバイスデータは、ＡＭＱの最初のメッセージキューに厳密な順番で格納される。
【0089】
ステップ４１１：ゲートウェイデバイスとサーバーの間の接続が通常の状態に戻ったときに、第１のメッセージキュー内のデバイスデータが最初のＭＱＴＴチャネルを介して送信される。
【0090】
ゲートウェイデバイスとサーバーの間の接続が通常の状態に戻ったときに、第１のメッセージキュー内のデバイスデータは、最初に第１のＭＱＴＴチャネルを介してサーバーに送信され、この期間中に受信されたデータは送信キュー内に順番に待機している。第１のメッセージキュー内の先入れ先出しモードのデバイスデータが全て正常に送信された場合、残りのデバイスデータは継続的に送信される。
【0091】
ステップ４０９とステップ４１０～４１１との間に厳密な順序は定義されていないこと、つまり、この実施形態に限定されず、ステップ４０９とステップ４１０～４１１とを同時に実行できることに留意されたい。
【0092】
本開示の実施形態において、ユーザは、異なるデバイスデータの実際の要件に従って、異なるブレークポイント再開モードを設定することができ；データ取得時系列を考慮せずに厳密なデータ整合性を必要とするデバイスデータに対して、リアルタイムデータが優先されるブレークポイント再開モードを採用することができ；厳密なデータ取得時系列を必要とするデバイスデータに対して、先入れ先出しのブレークポイント再開モードを採用することができ、これにより、ユーザの要件が満たされ、ゲートウェイデバイスによるデータ送信の適時性が向上する。
【0093】
上記の実施形態と組み合わせて、概略的な例では、ＩｏＴシステムにおけるデータ送信の流れは、図７に示されるようなものである。
【0094】
ステップ７０１：デバイスデータは前処理される。
【0095】
ＩｏＴデバイスによって取得されたデバイスデータを受信する場合、ゲートウェイデバイスは最初に、デバイスデータの構造をコンピュータデバイスが処理することができるデータ構造に変換する。
【0096】
ステップ７０２：ゲートウェイデバイスとサーバーの間の接続が正常か否かが検出される。
【0097】
接続が異常な場合、ステップ７０３が実行され；接続が正常な場合、ステップ７０８が実行され、ゲートウェイデバイスは、現在の接続状態に従って、対応するデータ送信モードを採用する必要がある。
【0098】
ステップ７０３：ブレークポイント再開モードが決定される。
【0099】
ブレークポイント再開モードが先入れ先出しモードである場合、ステップ７０５が実行され；ブレークポイント再開モードがリアルタイム優先モードである場合、ステップ７０４が実行され、次にステップ７０５が実行される。異なるＩｏＴデバイスに対して、ユーザは、実際のニーズに応じて異なるブレークポイント再開モードを設定することができる。デバイスデータを送信する前に、ゲートウェイデバイスは、最初にデバイスデータのブレークポイント再開モードを取得する。
【0100】
ステップ７０４：デバイスデータのデータタイプが決定される。
【0101】
ブレークポイント再開モードがリアルタイム優先モードである場合、ゲートウェイデバイスは、デバイスデータがリアルタイムデータまたは履歴データのどちらに属するかを決定する必要があり、データタイプに応じて対応する送信モードを採用する。
【0102】
ステップ７０５：デバイスデータがメッセージ指向ミドルウェアに格納される。
【0103】
ゲートウェイデバイスは、デバイスデータのデータタイプに従って、メッセージ指向ミドルウェアの対応するメッセージキューにデバイスデータを格納し、デバイスデータを先入れ先出しモードで格納し、リアルタイムデータタイプのデバイスデータをブレークポイント再開モードでメッセージ指向ミドルウェアの第１のメッセージキューに格納し、履歴データタイプのデバイスデータをメッセージ指向ミドルウェアの第２のメッセージキューに格納する。
【0104】
ステップ７０６：接続が再開された後にデバイスデータが対応するチャネルからアップロードされる。
【0105】
ゲートウェイデバイスとサーバーの間の接続が通常の状態に戻った後、第１のメッセージキューにおける先入れ先出しモードのデバイスデータについては、第１のＭＱＴＴチャネルを介して優先的に送信され、その後に取得されたデバイスデータが送信され；リアルタイム優先モードのデバイスデータについては、データタイプが再決定され、履歴データは第２のＭＱＴＴチャネルから送信され、リアルタイムデータは第１のＭＱＴＴチャネルから送信される。
【0106】
ステップ７０７：ブレークポイント再開モードが決定される。
【0107】
ゲートウェイデバイスとサーバーの間の接続が正常である場合、ゲートウェイデバイスはまた、デバイスデータのブレークポイント再開モードを取得する必要がある。ブレークポイント再開モードがリアルタイム優先モードである場合、ステップ７０８が実行された後にステップ７０９が実行され；ブレークポイント再開モードが先入れ先出しモードである場合、ステップ７０９が実行される。
【0108】
ステップ７０８：デバイスデータのデータタイプが決定される。
【0109】
ブレークポイント再開モードがリアルタイム優先モードである場合、デバイスデータがリアルタイムデータに属するか履歴データに属するかが決定される。データタイプが履歴データである場合、ステップ７０５が実行され；データタイプがリアルタイムデータである場合、ステップ７０９が実行される。
【0110】
ステップ７０９：デバイスデータが対応するチャネルからアップロードされる。
【0111】
先入れ先出しモードのデバイスデータについては、第１のメッセージキュー内のデバイスデータが優先的に送信され、その後、取得されたデバイスデータが送信される。リアルタイム優先モードのデバイスデータについては、履歴データは第２のＭＱＴＴチャネルから送信され、リアルタイムデータは第１のＭＱＴＴチャネルから送信される。
【0112】
図８は、本開示の例示的な実施形態に関するＩｏＴシステムにおいてデータを送信するための装置の構造ブロック図である。この装置は、上記の実施形態に記載されたゲートウェイデバイスにおいて構成され得る。図８に示されるように、この装置には、以下が含まれる：
【0113】
ゲートウェイデバイスとサーバーの間の接続が異常な場合に、ＩｏＴデバイスによって送信されたデバイスデータのデータタイプを決定するように構成された、第１の決定モジュール８０１、ここで、データタイプには、リアルタイムデータタイプおよび履歴データタイプが含まれ；
【0114】
リアルタイムデータタイプのデバイスデータをメッセージ指向ミドルウェアの第１のメッセージキューに格納し、履歴データタイプのデバイスデータをメッセージ指向ミドルウェアの第２のメッセージキューに格納するように構成された、第１の記憶モジュール８０２；
【0115】
ゲートウェイデバイスとサーバーの間の接続が通常の状態に戻ったときに、第１のメッセージキュー内のデバイスデータを第１のＭＱＴＴチャネルを介してサーバーに送信し、第２のメッセージキュー内のデバイスデータを第２のＭＱＴＴチャネルを介してサーバーに送信するように構成された、第１の送信モジュール８０３。
【0116】
オプションとして、第１の決定モジュール８０１には、以下が含まれる：
【0117】
デバイスデータのデータ受信時点を取得するように構成された、取得ユニット、ここで、データ受信時点は、ゲートウェイデバイスがデバイスデータを受信する時点である；
【0118】
データ受信時点、現在時点、予想処理時間、および送信遅延閾値に従って、デバイスデータのデータタイプを決定するように構成された、第１の決定ユニット、ここで、予想処理時間は、現在時点から送信完了時点までの予想時間であり、送信遅延閾値は、データ受信から送信完了までの最大遅延である。
【0119】
オプションとして、第１の決定ユニットは、更に以下のように構成される：
【0120】
データ受信時点、現在時点、および予想処理時間に従って、デバイスデータの予想送信時間を決定する；
【0121】
予想送信時間が送信遅延閾値よりも大きい場合、デバイスデータが履歴データタイプであると判断する；
【0122】
予想送信時間が送信遅延閾値よりも小さい場合、デバイスデータがリアルタイムデータタイプであると判断する。
【0123】
オプションとして、第１の決定モジュール８０１には、更に以下が含まれる：
【0124】
デバイスデータのデータ処理の難易度および事前設定された対応関係に従って、デバイスデータに対応する予想処理時間および送信遅延閾値を決定するように構成された、第２の決定ユニット、ここで、事前設定された対応関係は、データ処理の難易度、予想処理時間、および送信遅延閾値の間の対応関係が含まれる。
【0125】
オプションとして、第１の送信モジュール８０３には、以下が含まれる。
【0126】
第１のキュー消費頻度に従って、第１のメッセージキュー内のデバイスデータを第１のＭＱＴＴチャネルを介してサーバーに送信するように構成された、第１の送信ユニット；
【0127】
第１のキュー消費頻度および接続帯域幅に従って、第２のメッセージキューの第２のキュー消費頻度を決定するように構成された、第３の決定ユニット、ここで、第１のキュー消費頻度および第２のキュー消費頻度に対応する総占有帯域幅は、接続帯域幅よりも小さい；
【0128】
第２のキュー消費頻度に従って、第２のメッセージキュー内のデバイスデータを第２のＭＱＴＴチャネルを介してサーバーに送信するように構成された、第２の送信ユニット。
【0129】
オプションとして、この装置には、更に以下が含まれる：
【0130】
ゲートウェイデバイスとサーバーの間の接続が通常の状態に戻ったときに、第１のメッセージキュー内のデバイスデータのデータタイプを再決定し、第１のメッセージキュー内の履歴データタイプのデバイスデータを第２のメッセージキューに転送するように構成された、第２の決定モジュール；または
【0131】
所定の時間間隔毎に、第１のメッセージキュー内のデバイスデータのデータタイプを再決定するように構成され；第１のメッセージキュー内の履歴データタイプのデバイスデータを第２のメッセージキューに転送する、第３の決定モジュール。
【0132】
オプションとして、第１の決定モジュール８０１には、更に以下が含まれる。
【0133】
ゲートウェイデバイスとサーバーの間の接続が異常で、第１のブレークポイント再開モードが採用された場合に、ＩｏＴデバイスによって送信されたデバイスデータのデータタイプを決定するように構成された、第４の決定ユニット、ここで、第１のブレークポイント再開モードは、リアルタイムデータが優先的に送信される送信モードである。
【0134】
この装置には、更に以下が含まれる：
【0135】
ゲートウェイデバイスとサーバーの間の接続が異常で、第２のブレークポイント再開モードが採用された場合に、デバイスデータのデータ受信時点に基づいて、先入れ先出し原則に従ってデバイスデータを第１のメッセージキューに格納するように構成された、第２の記憶モジュール、ここで、第２のブレークポイント再開モードは、受信時系列に従ってデータがアップロードされる送信モードであり；
【0136】
ゲートウェイデバイスとサーバーの間の接続が通常の状態に再開したときに、第１のメッセージキュー内のデバイスデータを第１のＭＱＴＴチャネルを介して送信するように構成された、第２の送信モジュール。
【0137】
図９を参照すると、本開示の例示的な実施形態に関するゲートウェイデバイスの構造ブロック図が示されている。本開示におけるゲートウェイデバイスは、以下のコンポーネントのうちの１つ以上を含み得る：プロセッサ９０１、メモリ９０２、およびネットワーク通信コンポーネント９０３。
【0138】
プロセッサ９０１は、１つまたは複数の処理コアを含み得る。プロセッサ９０１は、様々なインターフェースおよびラインを使用して端末９０１全体内の様々な部分と接続し、ゲートウェイデバイスの様々な機能を実行し、また、メモリ９０２に記憶された命令、プログラム、コードセットまたは命令セットを実行または実施し、メモリ９０２に記憶されたデータを呼び出すことによってデータを処理する。あるいは、プロセッサ９０１は、デジタル信号処理（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、およびプログラマブルロジックアレイ（ＰＬＡ）のハードウェア形式のうちの少なくとも１つを使用することによって実装され得る。プロセッサ９０１は、中央処理装置（ＣＰＵ）、モデムなどのうちの１つまたは２つの組み合わせを統合することができる。ＣＰＵは主にオペレーティングシステムやアプリケーションなどを処理し；モデムは無線通信を処理するために使用される。上記のモデムはまた、プロセッサ９０１に統合されずに、単一の通信チップによって実装される場合があることが理解され得る。
【0139】
メモリ９０２は、ランダムアクセスメモリ（ＲＡＭ）を含んでもよく、読み取り専用メモリ（ＲＯＭ）を含んでもよい。あるいは、メモリ９０２は、非一時的なコンピュータ可読記憶媒体を含む。メモリ９０２は、命令、プログラム、コード、コードセット、または命令セットを記憶するために使用され得る。メモリ９０２は、メモリプログラム領域およびメモリデータ領域を含んでもよく、ここで、メモリプログラム領域は、オペレーティングシステムを実装するための命令、少なくとも１つの機能を実装するための命令、上記の様々な方法の実施形態を実装するための命令などを記憶し得る。メモリデータ領域はまた、使用中のゲートウェイデバイスなどによって作成されたデータを記憶し得る。
【0140】
ネットワーク通信コンポーネント９０３は、ゲートウェイデバイスと他のデバイスの間の有線または無線通信のために使用される。ゲートウェイデバイスは、Ｗｉ－Ｆｉ、２Ｇ、３Ｇ、１Ｇ、５Ｇ、またはそれらの組み合わせなどの通信規格に基づいて無線ネットワークにアクセスできる。例示的な実施形態において、ネットワーク通信コンポーネント９０３は、ブロードキャストチャネルを介して外部ブロードキャスト管理システムからブロードキャスト信号またはブロードキャスト関連情報を受信する。例示的な実施形態において、ネットワーク通信コンポーネント９０３はまた、短距離通信を容易にするための近距離無線通信（ＮＦＣ）モジュールを含む。
【0141】
本開示の一実施形態は、前述の実施形態で説明したように、ＩｏＴシステムにおいてデータを送信するための方法を実装するために、プロセッサによってロードおよび実行される少なくとも１つの命令を記憶するコンピュータ可読記憶媒体を更に提供する。
【0142】
本開示の一実施形態は、前述の実施形態で説明したように、ＩｏＴシステムにおいてデータを送信するための方法を実装するために、プロセッサによってロードおよび実行される少なくとも１つの命令を記憶するコンピュータプログラム製品を更に提供する。
【0143】
上記の実施例の１つまたは複数において、本開示の実施形態に記載される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで実装され得ることを当業者は理解されたい。ソフトウェアに実装される場合、これらの機能は、コンピュータ可読記憶媒体に記憶され、またはコンピュータ可読記憶媒体上の１つまたは複数の命令またはコードとして送信され得る。コンピュータ可読記憶媒体は、コンピュータ記憶媒体および通信媒体を含み、ここで、通信媒体は、ある場所から別の場所へのコンピュータプログラムの送信を容易にする任意の媒体を含む。記憶媒体は、一般的なコンピュータまたは専用のコンピュータによってアクセス可能な任意の利用可能な媒体であり得る。
【0144】
上記に記載されているのは、本開示の単なる例示的な実施形態であり、本開示を限定することを意図するものではない。本開示の精神および原則の範囲内において、いかなる修正、同等物の置換、改善なども、本開示の保護範囲内にある。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】