JP2021521528A - タスク処理方法、装置及びシステム - Google Patents

Abstract

本開示は、タスク処理方法、装置及びシステムを開示する。ある例示的なタスク処理方法は、ターゲットデバイスに対してデプロイされるターゲットタスクを取得することと、ターゲットタスクに応じて確認信号を生成することであって、確認信号は、ターゲットタスクのタスク内容を含む、生成することと、ターゲットデバイスからのハートビートリクエストが受信されると、確認信号をターゲットデバイスに送信することとを含む。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。開示される実施形態に一致して、ターゲットデバイスは、データソースに近いエッジデバイスであり得、及びターゲットタスクを実行することは、クラウドコンピューティング論理及びアプリケーションをエッジデバイスで実行することを含み得る。

Description

関連出願の相互参照
[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]本開示の幾つかの実施形態による例示的タスク処理方法のフローチャートである。 [27]本開示の幾つかの実施形態による例示的タスク処理方法のフローチャートである。 [28]本開示の幾つかの実施形態による例示的タスク処理装置の概略構造図である。 [29]本開示の幾つかの実施形態による例示的タスク処理装置の概略構造図である。 [30]本開示の幾つかの実施形態による例示的タスク処理装置の概略構造図である。

詳細な説明
[31] 本開示における解決策の理解を容易にするために、本開示の実施形態の幾つかにおける技術的解決策を、添付の図面を参照して説明する。記載する実施形態は、本開示の実施形態の全てではなく、一部に過ぎないことが認識される。本開示に一致して、本明細書で開示される原理から逸脱することなく、他の実施形態を得ることができる。このような実施形態も本開示の保護範囲内に入るものとする。

[32] 本開示の明細書、特許請求の範囲及び添付の図面における「第１の」及び「第２の」などの用語は、類似物を区別するために使用されることが認識される。これらの用語及び類似の用語は、特定のシーケンス又は順序を表すことを意図していない。このように記載された内容は、適宜の状況で置き換え可能であることが認識されるものとする。例えば、ここで記載する本開示の実施形態は、ここで図示又は記載されたシーケンス以外のシーケンスで実施され得る。さらに、「包含する」、「含む」及びこれらのあらゆる変形形態の用語は、非排他的包含を対象として含むことが意図される。例えば、一連のステップ又はユニットを含むプロセス、方法、システム、製品又はデバイスは、明確に列挙されたステップ又はユニットに限定されず、明示的に列挙されていないか、又は上記のプロセス、方法、製品若しくはデバイスに固有の他のステップ又はユニットを含み得る。

[33] 本開示の幾つかの実施形態によれば、タスク処理方法が提供される。添付の図面のフローチャートに示されるプロシージャは、コンピュータ実行可能命令の組によりコンピュータシステムにおいて実行され得ることが認識される。また、論理順序がフローチャートに示される場合があるが、幾つかの実施形態では、図示又は記載されるプロシージャは、ここに記載する順序と異なる順序で実行され得る。

[34] 本開示で提供される方法実施形態は、モバイル端末、コンピュータ端末又は類似のコンピューティングデバイスで実行され得る。図１は、本開示の幾つかの実施形態によるタスク処理方法を実施するように構成された例示的コンピュータ端末の構造的ハードウェアブロック図である。幾つかの実施形態では、コンピュータ端末は、モバイルデバイスの形態であり得る。図１に示すように、コンピュータ端末１００（又はモバイルデバイス１００）は、１つ又は複数のプロセッサ１０２（図では、１０２ａ、１０２ｂ、．．．、１０２ｎで示される）を含み得る。上述のように、コンピュータ端末１００は、モバイルデバイスでもあり得る。プロセッサ１０２は、マイクロプロセッサ（例えば、マイクロコントローラユニット（ＭＣＵ））などの処理装置又はプログラマブル論理デバイス（例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ））を含み得るが、これらに限定されない。

[35] コンピュータ端末１００は、データを格納するように構成されたメモリ１０４及び通信機能を提供するように構成された伝送装置１０６も含み得る。加えて、コンピュータ端末１００は、入力／出力インタフェース１０８（Ｉ／Ｏインタフェース）、ユニバーサルシリアルバス（ＵＳＢ）ポート、ネットワークインタフェース、電源及び／又はカメラをさらに含み得る。ＵＳＢポートは、Ｉ／Ｏインタフェースのポートの１つとしても含まれ得る。図１に示すように、コンピュータ端末は、カーソル制御デバイス１１０ａ、キーボード１１０ｂ及びディスプレイ１１０ｃをさらに含み得る。当業者は、図１に示す構造が、例として提供される単なる概略図であることを理解できる。図１に示す構造は、上記の電子装置の構造を限定することを意図していない。例えば、幾つかの実施形態では、コンピュータ端末１００は、図１に示すコンポーネントよりも多い若しくは少ないコンポーネントを含み得るか、又は図１に示す構成と異なる構成を有し得る。

[36] １つ又は複数のプロセッサ１０２及び／又は他のデータ処理回路は、まとめてデータ処理回路とも呼ばれる場合があることが認識されるものとする。データ処理回路は、全体的又は部分的に、ソフトウェア、ハードウェア、ファームウェア又は任意の他の組み合わせとして具現化され得る。また、データ処理回路は、単一の別個の処理モジュールであり得るか、又は全体的若しくは部分的にコンピュータ端末１００の他のコンポーネントの何れかに組み込まれ得る。本開示の幾つかの実施形態では、データ処理回路は、例えば、インタフェースに接続された可変抵抗端末経路の選択により、プロセッサとして制御され得る。

[37] メモリ１０４は、アプリケーションソフトウェアのソフトウェアプログラム又はモジュール（例えば、本開示で提供されるタスク処理方法に対応するプログラム命令／データ記憶装置）を格納するように構成され得る。プロセッサ１０２は、メモリ１０４に格納されたソフトウェアプログラム又はモジュールを実行して、様々な機能及びアプリケーションを実行し、且つデータ処理を行うことができる。例えば、プロセッサ１０２は、ソフトウェアプログラム又はモジュールを実行して、タスク処理方法を行うことができる。メモリ１０４は、高速ランダムアクセスメモリ又は１つ若しくは複数の磁気記憶装置、フラッシュメモリ若しくは他の不揮発性固体メモリなどの不揮発性メモリを含み得る。幾つかの実施形態では、メモリ１０４は、プロセッサ１０２に対してリモートに配置されたメモリをさらに含み得る。リモートメモリは、ネットワークにより、コンピュータ端末１００に接続され得る。ネットワークの例には、インターネット、イントラネット、ローカルエリアネットワーク、移動通信ネットワーク及びこれらの組み合わせが含まれ得るが、これらに限定されない。

[38] 伝送装置１０６は、ネットワークを介してデータを受信又は送信するように構成され得る。例えば、ネットワークは、コンピュータ端末１００の通信プロバイダによって提供される無線ネットワークを含み得る。幾つかの実施形態では、伝送装置１０６は、インターネットと通信するために基地局を介して別のネットワークデバイスに接続され得るネットワークインタフェースコントローラ（ＮＩＣ）を含み得る。幾つかの実施形態では、伝送装置１０６は、無線でインターネットと通信するように構成され得る無線周波数（ＲＦ）モジュールであり得る。

[39] ディスプレイ１１０ｃは、例えば、ユーザがコンピュータ端末１００のユーザインタフェースとインタラクトすることを可能にするタッチスクリーン液晶ディスプレイ（ＬＣＤ）であり得る。

[40] 図１に示される構造的ハードウェアブロック図は、単なるコンピュータ端末１００の例示的ブロック図として提供されることが認識される。幾つかの実施形態では、コンピュータ端末１００は、ある例示的サーバの一部であり得るか、又はある例示的サーバに接続され得る。コンピュータ端末１００は、クラウドサーバ、セキュリティサーバ、リソースサーバ及びゲームサーバなどの１つ又は複数のサーバに接続され得る。接続は、データネットワーク接続又は電気接続の形態であり得る。幾つかの実施形態では、コンピュータ端末１００は、モバイルコンピューティングデバイスなどであり得る。データネットワーク接続は、ローカルエリアネットワーク接続、広域ネットワーク接続、インターネット接続又は他のタイプのデータネットワーク接続であり得る。コンピュータ端末１００は、ネットワークサービスにより、１つのサーバ（例えば、セキュリティサーバ）又はサーバの群に接続し得る。ネットワークサービスは、ソーシャルネットワーク、クラウドリソース、電子メール、オンライン決済又は他のオンラインアプリケーションなどのネットワークベースのユーザサービスであり得る。

[41] 本開示で提供される幾つかの実施形態では、論理ユニット（例えば、データフィルタリング、フォーマット変換、基本演算、スクリプト及びルールに関連する論理ユニット）がエッジゲートウェイでデプロイされ得る。このようにして、デバイスからのリクエストに対する応答時間を短縮することができる。さらに、デバイスとクラウドとの間の通信のネットワークコスト及びクラウドのサービス負荷を減らすことができる。

[42] クラウドにおける分散リソーススケジューリングデバイスは、クラウドコンピューティングリソースの集中管理に使用され、アプリケーション論理ホスティング能力をユーザに提供することができる。スケジューリングデバイスの主な機能の１つは、テナントリソースの分離及びリソースの配分に関する。しかし、エッジ側の実行ノードが一般にエッジコンピューティングユーザ自身によって提供されるため、テナント分離は、重大な問題を提示しない。

[43] エッジコンピューティングは、クラウドロジックをエッジでスケジューリング及びデプロイすることができる技術を指し得る。オブジェクト又はデータソースに近い側において、エッジコンピュータ技術は、ニアエンドサービスを提供するためにネットワーク、コンピューティング、記憶及びアプリケーションコア能力を統合するオープンプラットフォームを使用する。エッジコンピューティングのアプリケーションは、より速いネットワークサービス応答を提供するためにエッジ側で開始することができる。このようにして、エッジコンピューティングは、リアルタイムサービス、アプリケーションインテリジェンス、セキュリティ及びプライバシー保護に関連する基本要件を満たすことができる。

[44] クラウドベースの統合開発により、エッジ側のランタイム環境は、クラウド側のランタイム環境よりもはるかに厳しくなり得る。上記を考慮して、エッジ側のランタイム環境の安定性及びデータ整合性を保証する必要がある。クラウドのタスクがエッジのランタイム環境にデプロイされる場合、エッジのランタイム環境で例外が生じたか否かをモニタリングするために、自己検出機構がエッジで構成されることが必要とされ得る。このようにして、特定の例外事象に応じて、対応する例外処理を行うことができる。加えて、上位開発者は、デプロイされたタスクのライフサイクルを知る必要がある場合がある。従って、デプロイされたタスクのライフサイクル及びタスクステータスをモニタリングするために、エッジで効果的なタスクステータス管理機構を構成することも必要となる場合がある。

[45] 上記のランタイム環境を考慮して、本開示は、以下に説明し、且つ図２に示すタスク処理方法などのタスク処理方法を提供する。本開示によって提供されるタスク処理方法の実施形態は、エッジコンピューティング以外のシナリオで実行され得ることが認識される。幾つかの実施形態によると、エッジ側ランタイム環境、タスクデプロイメントステータス、操作信号ステータスなどがモニタリング及び管理され得る。このようにして、エッジゲートウェイデバイスで例外の自己検出及び補償を行うことができる。本開示で提供される実施形態の利点の１つは、エッジ側ランタイム環境の安定性及びデータ整合性を向上させ得ることである。

[46] 本開示によって提供されるタスク処理方法の実施形態は、スマート産業、スマートシティ、無人スーパーマーケット及びスマートホテルなどの新興のＩｏＴ分野に適用され得ることが認識される。本明細書で提供される解決策は、エッジコンピューティングのタスク処理速度を向上させ、デバイスからのリクエストに対する応答時間を短縮することができる。

[47] 図２は、本開示の幾つかの実施形態による例示的タスク処理方法２００のフローチャートである。図２に示すように、タスク処理方法２００は、以下のプロシージャ：ステップＳ２０２〜ステップＳ２０６を含み得る。

[48] ステップＳ２０２では、ターゲットタスクが取得される。ターゲットタスクは、ターゲットデバイスでデプロイされる必要があるタスクであり得る。

[49] ここで記載する方法実施形態は、スケジューリングデバイス（例えば、クラウドスケジューリングデバイス）によって実行され得ることが認識される。スケジューリングデバイスは、エッジでデプロイされる必要があるターゲットタスクを取得することができ、ターゲットタスクに応じて、対応する確認信号を生成する。ターゲットデバイスからハートビートリクエストを受信すると、スケジューリングデバイスは、確認信号をターゲットデバイスに送信し得る。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。

[50] 幾つかの実施形態では、ターゲットタスクは、ターゲットデバイスでデプロイ及び実行され得るタスクであり得る。ターゲットタスクは、データフィルタリング、フォーマット変換、基本演算、スクリプト、ルール、構成及びアプリケーションに関連するタスクであり得るが、これらに限定されない。ターゲットデバイスは、エッジゲートウェイデバイス、基地局又はエッジクラウドサーバなどのクラウドサーバであり得る。様々な実行エンジンにランタイム環境を提供するエッジ側の実行ノードは、ターゲットデバイスでデプロイされ得る。

[51] エッジ側実行ノードは、様々な実行エンジンにランタイム環境を提供することができ、エッジゲートウェイデバイス又はDockerコンテナなどのオープンソースアプリケーションコンテナでデプロイされ得るノードを指し得る。エンジンドライバは、ランタイム環境におけるプラグインとして規格準拠実行エンジンの統合を支援し得る。様々な言語を使用して実施される実行エンジンは、データバスによるプロセス間通信を用いて管理され得る。

[52] 幾つかの実施形態では、ターゲットタスクは、以下のように取得され得るが、これに限定されない。

[53] ステップＳ２０２１（図２には図示されない）では、コンソールによって送信された第１のタスクを受信する。第１のタスクは、例えば、スケジューリングポリシー、デプロイメントアドレス及びタスク内容を含み得る。スケジューリングデバイスは、コンソールによって提出された第１のタスクを受信し得る。コンソールがデプロイメントのために第１のタスクをスケジューリングデバイスに提出すると、第１のタスクにおけるスケジューリングポリシー、デプロイメントアドレス、タスク内容及び実行エンジンなどの情報が指定され得る。

[54] ステップＳ２０２３（図２には図示されない）では、デプロイメントアドレスをパージングし、且つデプロイメントアドレスによって示されるターゲットデバイスのステータスを検出する。ターゲットデバイスのステータスは、ターゲットデバイスの実行ノードのステータスであり得るが、これに限定されない。

[55] 幾つかの実施形態では、スケジューリングデバイスは、デプロイメントアドレスをパージングし、且つターゲットデバイスの実行ノードのステータスを検出し得る。スケジューリングデバイスは、さらに、ターゲットデバイスのタスクスナップショットを記録し、タスク内容のフォーマットをチェックし得る。上記の情報を用いて、スケジューリングデバイスは、ターゲットデバイスのステータスが正常であるか否かを決定することができる。

[56] ステップＳ２０２５（図２には図示されない）では、ターゲットデバイスが正常状態であれば、タスク内容及びスケジューリングポリシーに従ってターゲットタスクを生成する。幾つかの実施形態では、スケジューリングポリシーは、以下のスケジューリングポリシー：シングルポイントスケジューリング、指定スケジューリング、フルスケジューリング、分散スケジューリングなどの何れか１つであり得るが、これらに限定されない。幾つかの実施形態では、ターゲットデバイスが正常状態であると決定されると、ターゲットタスクがタスク内容及びスケジューリングポリシーに応じて生成され得る。

[57] 図２を再び参照すると、ステップＳ２０４では、ターゲットタスクに応じて、対応する確認信号が生成される。確認信号は、ターゲットタスクのタスク内容を含み得る。

[58] 確認信号は、以下：タスクスナップショット、戻りコード及び消費ステータスの少なくとも１つをさらに含み得る。

[59] 幾つかの実施形態では、スケジューリングデバイスは、ターゲットデバイスのデバイス情報を取得し得る。対応する確認信号は、取得されたターゲットタスク及びデバイス情報に応じて生成され得る。

[60] 幾つかの実施形態では、確認信号は、応答内容フィールドを含むことができ、ステップＳ２０４では、ターゲットタスクに応じて対応する確認信号を生成することは、以下のプロシージャ：確認信号を取得するために、タスク内容を確認信号の応答内容フィールドに加えることを行うことによって実施され得る。

[61] 幾つかの実施形態では、応答内容フィールドは、下記の表１に示すような応答内容フィールドのＡｃｋ内容であり得る。確認信号は、ターゲットタスクのタスク内容を応答内容フィールドのＡｃｋ内容に加えることによって取得され得る。

[62] 幾つかの実施形態では、応答内容フィールドのＡｃｋ内容＝１０２０１の場合、スケジューリングデバイスが新しいタスクをターゲットデバイスに提出することを示すことができ、応答内容フィールドが新しいタスクに関する情報を運ぶ。応答内容フィールドのＡｃｋ内容＝１０２０４の場合、それは、ターゲットデバイスで指定されたタスクを削除することを示すことができ、応答内容フィールドのＡｃｋ内容は、削除されるタスク識別子であり得る。

[63] 応答内容フィールドのＡｃｋ内容のフィールド値は、上述の例であり得る（ただし、これらに限定されない）ことが認識される。異なる実際の実施に応じて異なるフィールドが選択され得る。幾つかの実施形態では、確認信号のデータ構造は、下記の表１に示されるような構造であり得るが、これに限定されない。

[64] 幾つかの実施形態では、ターゲットデバイスが起動されると、ランタイムマネージャが様々な実行エンジンをロードし得る。各実行エンジンは、対応する名前空間を有し得る。異なる言語を使用して実施される実行エンジンは、プロセス間通信を用いて管理され得る。例えば、ランタイムマネージャは、データバスにブロードキャストを送信し得る。ブロードキャストの受信後、各実行エンジンプロセスは、ランタイムマネージャのアドレスに対するエンジン登録リクエストを開始し得る。

[65] スケジューリングデバイスがターゲットタスクを取得する前に、ターゲットデバイスは、ローカルデバイス情報を取得し得ることが認識される。例えば、ローカルデバイス情報は、中央処理装置（ＣＰＵ）に関する情報、メモリサイズ、ディスクサイズ、ネットワークリンク、ソフトウェア開発キット（ＳＤＫ）バージョン番号、実行エンジン情報、アドレス情報、同期時間間隔、構成情報などを含み得る。ターゲットデバイスは、スケジューリングデバイス側で登録を実施するために、デバイス情報をスケジューリングデバイスに送信し得る。

[66] 加えて、スケジューリングデバイスは、デバイス情報の持続性を達成するためにデバイス情報を保存し得る。スケジューリングデバイスは、ターゲットデバイスに対応する一意のランタイム環境識別子も生成し得る。ターゲットデバイスに対応するランタイム環境識別子は、ＡＣＫ情報を返すことによってターゲットデバイスに提供され得る。

[67] ステップＳ２０６では、ターゲットデバイスからのハートビートリクエストが受信されると、確認信号がターゲットデバイスに送信される。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。

[68] 幾つかの実施形態では、ハートビートリクエストは、以下：ＣＰＵ使用状況、メモリ使用状況、ディスク使用状況及び１つ又は複数のタスクの実行ステータスの少なくとも１つに関する情報を含み得る。

[69] 幾つかの実施形態では、ハートビートリクエストは、一定の時間間隔（例えば、３０〜４０秒）又は他の間隔でターゲットデバイスによってスケジューリングデバイスに送信されたハートビートパケットであり得る。ハートビートリクエストは、ターゲットデバイスとスケジューリングデバイスとの間の現在の接続が正常であることを示すために使用され得る。ハートビートリクエストのパケット内容は、本開示において限定されない。幾つかの実施形態では、パケット内容は、パケットが長い接続のキープアライブ及び切断に使用され得る限り、ヘッダのみを含むヌルパケットであり得るが、これに限定されない。

[70] 幾つかの実施形態では、ターゲットデバイスがスケジューリングデバイスへの登録に成功すると、ターゲットデバイスは、ローカルでハートビートデーモンスレッドを開始し、予め設定されたハートビートレートの一定頻度に従ってハートビートリクエストをスケジューリングデバイスに送信し得る。

[71] 幾つかの実施形態では、ステップＳ２０６において、確認信号をターゲットデバイスに送信することは、以下のプロシージャを行うことによって実施され得る。

[72] 確認信号をハートビート応答のデータフィールドに加えること、及び

[73] 確認信号を含むハートビート応答をターゲットデバイスに送信すること。

[74] 幾つかの実施形態では、ターゲットデバイスによって送信されたハートビートリクエストを受信すると、スケジューリングデバイスは、対応する確認信号がローカルで存在するか否かを検出し得る。対応する確認信号が存在する場合、スケジューリングデバイスは、確認信号を現在のハートビートリクエストのハートビート応答に加え、確認信号を含むハートビート応答をターゲットデバイスに送信し得る。幾つかの実施形態では、スケジューリングデバイスは、タスク内容を確認信号の応答内容フィールドに加えることによって確認信号を取得し得る。確認信号のデータ構造は、上記の表１に示すような例示的構造であり得るが、これに限定されない。加えて、確認信号は、ハートビート応答のデータに加えられ得るが、これに限定されない。ハートビート応答のデータ構造は、下記の表２に示すような例示的構造であり得る。

[76] 幾つかの実施形態では、スケジューリングデバイスは、対応する確認信号がローカルで存在しないことを検出し得る。ハートビートリクエストが受信されたことを示す肯定応答キャラクターは、ターゲットデバイスのハートビートリクエストの受信を肯定応答するためにターゲットデバイスに返され得る。

[77] 幾つかの実施形態では、上記のプルモードに加えて、プッシュモードも適用され得る。上記のプルモードでは、スケジューリングデバイスがターゲットタスクに応じて対応する確認信号を生成した後に、スケジューリングデバイスは、ターゲットデバイスのハートビートリクエストを受信した後、ターゲットデバイスに対して、ハートビートリクエストに対応する確認信号を送信し得る。プッシュモードでは、スケジューリングデバイスは、確認信号（確認信号は、ターゲットタスクのタスク内容を含む）を生成した後、ターゲットデバイスに確認信号を能動的にプッシュし得る。プッシュモードは、幾つかの低性能デバイスに対してより適切であり得る。プッシュモードの特徴の１つは、それが低性能デバイスの電力消費を減らし得ることである。

[78] 幾つかの実施形態では、タスク内容を含む確認信号は、プッシュモード及びプルモードを組み合わせた複合プロトコル様式を使用することによってもターゲットデバイスに送信され得る。このようにして、開発者は、実際の実施シナリオに応じてモード間の切り替えを行い得る。例えば、複合プロトコル様式は、スケジューリングデバイスが確認信号を生成した後、ターゲットデバイスにメッセージをプッシュすることによって実施され得るが、これに限定されない。ターゲットデバイスは、ターゲットタスクを運ぶ確認信号をスケジューリングデバイスからプルするように命令され得る。

[79] 幾つかの実施形態では、確認信号の受信後、ターゲットデバイスは、確認信号をパージングして、確認信号に含まれるターゲットタスクのタスク内容を取得し、ターゲットタスクのデプロイメントを完了し、且つタスク内容に応じてターゲットタスクを実行し得る。

[80] 本開示の上記の実施形態によれば、ターゲットタスクが取得され、かかるターゲットタスクは、ターゲットデバイスでデプロイされる必要があるタスクである。ターゲットタスクに応じて、対応する確認信号を生成することができ、かかる確認信号は、ターゲットタスクのタスク内容を含む。ターゲットデバイスからのハートビートリクエストが受信されると、確認信号がターゲットデバイスに送信され得る。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。本開示で提供される解決策を用いて、エッジコンピューティングのタスク処理速度及びエッジオペレーティングシステムの安定性を向上させることができる。デバイスからのリクエストに対する応答時間を短縮する技術的効果は、エッジコンピューティングのタスク処理速度を上げることによって達成することができる。本明細書で提供される解決策は、データソース側に近いエッジデバイスでクラウドコンピューティングロジック及びアプリケーションをデプロイ及び実行する方法の技術的問題に対処することができる。

[81] 本開示によって提供される解決策は、ある例示的実施シナリオを用いて以下に説明される。幾つかの実施形態では、スケジューリングデバイスは、パーサ、デプロイヤ、状態機械及びスキャナなどのユニット／モジュールを含み得るが、これらに限定されない。パーサは、上位アプリケーションシステムに接続され得る。パーサは、バッチデプロイメントのために上位アプリケーションシステムの論理タスクを受信し、且つ上位アプリケーションシステムの多次元ステータスクエリを受理する。

[82] 幾つかの実施形態では、コンソールとしての上位アプリケーションシステムは、第１のタスクをスケジューリングデバイスのパーサに配信し得る。第１のタスクは、スケジューリングポリシー、デプロイメントアドレス及びタスク内容を含み得る。パーサは、デプロイメントアドレスをパージングして、デプロイメントアドレスによって示されるターゲットデバイスのステータスを検出し得る。次いで、パーサは、ターゲットデバイスが正常状態である場合、タスク内容及びスケジューリングポリシーに応じてターゲットタスクを生成し得る。

[83] 幾つかの実施形態では、デプロイヤは、パーサに接続され得る。ターゲットタスクの受信後、デプロイヤは、ターゲットタスクの二状態をマーキングし、ターゲット状態に対応する二状態レコードを生成し得る。二状態レコードは、期待される状態及び実際の状態を含み得る。デプロイヤは、例えば、ターゲットタスクを管理し、ターゲットタスクを保存し、ターゲットタスクに対応するＡＣＫ信号を生成し、且つターゲットタスクの接続を許可し得る。

[84] 幾つかの実施形態では、状態機械は、デプロイヤに接続され得る。状態機械は、ターゲットデバイスによって送信されたタスク同期リクエストを受信し、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、二状態レコードの実際の状態を更新し得る。

[85] 幾つかの実施形態では、スケジューリングデバイスでデプロイされた状態機械は、ターゲットタスクの二状態の記録及び識別を行い得る。状態機械は、ターゲットタスクのライフサイクルにおける状態遷移を管理するために使用され得る。期待される状態及び実際の状態は、以下：非実行状態、実行状態、実行終了状態、実行失敗状態及び実行一時停止状態の少なくとも１つを含み得る。

[86] ターゲットデバイスのタスク同期リクエストの受信後、スケジューリングデバイスは、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、ローカル二状態レコードのターゲットタスクの実際の状態を更新し得ることが認識される。スケジューリングデバイスは、さらに、ターゲットデバイスが対応する確認信号を受信したことを決定し、ローカル確認信号を削除し得る。

[87] 幾つかの実施形態では、スキャナは、ローカルホスト又はリモートホストのセキュリティ上の脆弱性を自動的に検出するプログラムを含むことができ、スキャンターゲットにおける脆弱性を迅速且つ正確に検出することができる。スキャン結果は、ユーザに提供され得る。例えば、スキャナは、パケットをターゲットコンピュータに送信し、ターゲットコンピュータによってフィードバックされた情報に基づいて情報を決定し得る。決定された情報は、オペレーティングシステムのタイプ、開発ポート及びターゲットコンピュータによって提供されるサービスに関する情報を含み得る。

[88] 本開示の幾つかの実施形態では、スケジューリングデバイスのパーサ、デプロイヤ、状態機械及びスキャナなどの様々なユニット／モジュールが、スケジューリングデバイスにおいてデプロイされ得る。エッジコンピューティングのタスク処理速度及びエッジオペレーティングシステムの安定性を向上させることができる。デバイスからのリクエストに対する応答時間を短縮する技術的効果は、エッジコンピューティングのタスク処理速度の向上によって達成することができる。さらに、ターゲットデバイス及びターゲットタスクが異常であるか否かが検出され得るため、特定の異常状況に応じて、対応する例外処理プロセスを行うことができる。このようにして、デプロイされたターゲットタスクのライフサイクル及びタスクステータスを効果的にモニタリングすることができる。

[89] 幾つかの実施形態では、ターゲットタスクの実行ステータスの検出を行うために、ターゲットタスクを取得するステップＳ２０２の後、方法は、以下のプロシージャをさらに含み得る。

[90] ステップＳ２０３（図２には図示されない）において、ターゲットタスクに対応して、二状態レコードが生成され得る。

[91] ターゲットタスクを取得した後、スケジューリングデバイスは、ターゲットタスクに対応する二状態レコードを生成し得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。幾つかの実施形態では、実行コンテナにおけるターゲットタスクのデプロイメントは、スケジューリングデバイスのデプロイヤを使用して実施され得る。デプロイヤは、まず、ターゲットタスクの二状態をマーキングし、ターゲット状態に対応する二状態レコードを生成し得る。

[92] 確認信号をターゲットデバイスに送信するステップＳ２０６の後、方法は、以下のプロシージャをさらに含み得る。

[93] ステップＳ２０８（図２には図示されない）では、ターゲットデバイスによって送信されたタスク同期リクエストを受信する。

[94] ステップＳ２１０（図２には図示されない）では、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、二状態レコードの実際の状態を更新する。

[95] ステップＳ２０８〜ステップＳ２１０によって提供されたプロシージャに基づき、確認信号を受信すると、ターゲットデバイスは、確認信号が運ぶターゲットタスクのタスク内容をパージングし、ターゲットタスクを実行し、且つタスク同期リクエストにより、ターゲットタスクの実行ステータスをスケジューリングデバイスに送信し得る。このようにして、スケジューリングデバイスは、ローカル二状態レコードの実際の状態を更新し得る。

[96] 幾つかの実施形態では、スケジューリングデバイスでデプロイされた状態機械は、ターゲットタスクの二状態の記録及び識別を行い得る。状態機械は、ターゲットタスクのライフサイクルにおける状態遷移を管理するために使用され得る。期待される状態及び実際の状態は、以下：非実行状態、実行状態、実行終了状態、実行失敗状態及び実行一時停止状態の少なくとも１つを含み得る。

[97] ターゲットデバイスのタスク同期リクエストの受信後、スケジューリングデバイスは、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、ローカル二状態レコードのターゲットタスクの実際の状態を更新し得ることが認識される。スケジューリングデバイスは、さらに、ターゲットデバイスが対応する確認信号を受信したことを決定し、ローカル確認信号を削除し得る。

[98] ターゲットデバイスとスケジューリングデバイスとの間のタスクステータス同期は、例えば、以下の２つの様式：アクティブ同期及びパッシブ同期で行われ得ることが認識される。

[99] パッシブ同期は、以下のプロシージャを指し得る。スケジューリングデバイスが開発者の操作によって生成された操作信号を受信すると、ターゲットデバイスは、ターゲットタスク及びターゲットタスクのタスク内容をプルするために、ハートビートリクエストをスケジューリングデバイスに送信し得る。ターゲットタスクのタスク内容を実行した後、ターゲットデバイスは、直ちに、タスクステータス同期のためにタスク同期リクエストをスケジューリングデバイスに送信し得る。

[100] アクティブ同期は、以下のプロシージャを指し得る。ターゲットデバイスは、タスクステータス同期のためにタスクステータス較正リクエストをスケジューリングデバイスに能動的に送信し得る。ターゲットデバイスがネットワークの中断又は障害から再起動又は回復した後、ターゲットデバイスは、１つ又は複数のタスクのタスクステータスを取得し、１つ又は複数のタスクのタスクステータスを含むタスクステータス較正リクエストを生成し得る。

[101] 本開示の上記の実施形態によれば、ターゲットタスクの実際の状態及びターゲット状態は、二状態レコードを用いてマーキングされ得る。ターゲットデバイスによって送信されたタスク同期リクエストが受信された後、ターゲットタスクの実際の状態が更新され、ローカル確認信号が削除され得る。二状態の識別機構及び確認信号の消費機構は、スケジューリングデバイスによってデプロイされたターゲットデバイスのターゲットタスクの処理安定性及び処理速度を向上させることができる。

[102] 幾つかの実施形態では、スケジューリングデバイスは、ターゲットタスクの現在のステータス（例えば、期待される状態及び実際の状態）を記述するために二状態レコードを使用し得る。上位パッケージ開発者が何らかの状態のターゲットタスクに対して操作を行うと、期待される状態が変更される。スケジューリングデバイスは、期待される状態に応じて操作信号を生成して、操作信号に従って対応する操作を実行するようにターゲットデバイスを制御する。対応する操作の実行後、ターゲットデバイスは、タスク同期リクエストを送信することにより、ターゲットタスクの実行ステータスをスケジューリングデバイスに送信し得る。

[103] 図３Ａは、本開示の幾つかの実施形態による任意選択の状態機械の例示的状態遷移を示す概略図３１０である。図３Ａに示すように、上位パッケージ開発者は、以下の状態：非デプロイメント状態、デプロイメント実行状態、デプロイメント失敗状態、デプロイメント成功状態、再設定実行状態及び再設定失敗状態を把握することができる。非デプロイメント状態は、再設定成功状態の場合がある。開発者は、いかなる状態でもデプロイメント操作及び再設定操作を行うことが許され得る。

[104] 幾つかの実施形態では、スケジューリングデバイスでデプロイされた状態機械は、ターゲットタスクの二状態の記録及び識別を行い得る。状態機械は、ターゲットタスクのライフサイクルにおける状態遷移を管理するために使用され得る。期待される状態及び実際の状態は、以下：非実行状態、実行状態、実行終了状態、実行失敗状態及び実行一時停止状態の少なくとも１つを含み得る。

[105] 図３Ａに示されるような接続関係を有する状態間の遷移関係は、以下のようになり得る。デプロイメントが提出されると、状態は、非デプロイメント状態からデプロイメント実行状態に変化する。デプロイメントが失敗すると、状態は、デプロイメント実行状態からデプロイメント失敗状態に変化する。デプロイメントの試みが再度行われると、状態は、デプロイメント失敗状態からデプロイメント実行状態に変化する。デプロイメントが成功すると、状態は、デプロイメント実行状態からデプロイメント成功状態に変化する。再デプロイメントが行われると、状態は、デプロイメント成功状態からデプロイメント実行状態に変化する。再設定操作が行われると、状態は、デプロイメント成功状態から再設定実行状態に変化する。再設定が成功すると、状態は、再設定実行状態から非デプロイメント状態に変化する。再設定が失敗すると、状態は、再設定実行状態から再設定失敗状態に変化する。再設定操作が再度行われると、状態は、再設定を再度行うために、再設定失敗状態から再設定実行状態に変化する。

[106] 上位パッケージ開発者によって把握可能であり、期待される状態及び実際の状態に含まれる状態の幾つかの状態マッピングテーブルは、下記の例示的表３に示すようになり得る。表３に示すように、タスクに対応する二状態レコード（期待される状態及び実際の状態を含む）によって使用されるフォーマットは、以下のように表される。

[107] 図３Ｂは、本開示の幾つかの実施形態による例示的状態機械の状態遷移を示す概略図３２０である。図３Ｂに示すように、タスクの初期状態は、（０，０）である（すなわち、上記の通り、期待される状態が非デプロイメントであり、且つ実際の状態が非デプロイメントである）。状態遷移の例は、以下にさらに提供される。デプロイメントが提出されると、タスクに対応する状態は、（２，１）に変化する。すなわち、期待される状態がデプロイメントの成功であり、実際の状態が非実行である。デプロイメントが失敗するか又は状態が異常であると、タスクに対応する状態は、（２，４）に変化する。それに応じて、デプロイメントの試みが再度行われると、状態は、直接（２，４）から（２，１）に変化し得る。デプロイメントが成功すると、タスクに対応する状態は、（２，２）に変化する。タスクの再デプロイメントが必要である場合、タスクに対応する状態は、（２，１）に変化する。取消操作が行われると、タスクに対応する状態は、（２，１）から（０，２）に変化する。タスクが異常である場合、タスクに対応する状態は、（０，４）に変化する。タスクに対応する状態が（２，４）であれば、例外が削除された後、タスクに対応する状態は、（０，４）に変化する。タスクに対応する状態が（０，４）であれば、デプロイメントの試みが再度行われた場合、タスクに対応する状態は、（０，２）に変化する。タスクに対応する状態が（０，２）であれば、取消操作が成功した場合、タスクに対応する状態は、（０，０）に変化する。タスクに対応する状態が（０，４）であれば、例外が削除された後、タスクに対応する状態は、（０，０）に変化する。

[108] ここで詳細に説明されていない状態アクション範囲に関して、上記の表３に示されるような且つ本開示の他の箇所に記載されるような、状態アクション範囲と状態記述との間の具体的なマッピング関係を参照し得ることが認識される。

[109] ターゲットタスクの状態記述は、ランタイム環境の同期に左右されることが認識される。しかし、エッジコンピューティングシナリオにおけるランタイム環境のネットワークの通信渋滞及び低信頼性が、以下の問題を提示し得る。例えば、エッジ側ランタイム環境は、ターゲットタスクがターゲットデバイスでデプロイされた後、どのような情報も返さない場合がある。この場合、ターゲットタスクの問題がタスク配信段階、ランタイム環境のタスク実行段階又はタスクステータス返送段階で生じたかを決定することができない。

[110] 本開示の幾つかの実施形態で提供される二状態識別機構により、スケジューリングデバイスは、任意の時点において、デプロイされたターゲットタスクに関する状態記述を行い得ることが認識される。ターゲットデバイスがターゲットタスクの実行ステータスに応答しない場合、スケジューリングデバイスは、過渡状態と最終状態との間でターゲットタスクの実行ステータスを切り替え得る。このようにして、ターゲットタスクの実行ステータスは、過渡状態に留められない。最終状態は、デプロイされたターゲットタスクが最終状態であることを示し得る。過渡状態は、デプロイされたターゲットタスクが中間状態（例えば、ターゲットタスクの期待される状態がターゲットタスクの実際の状態と異なる状態）にあることを示し得る。

[111] 幾つかの実施形態では、ターゲットタスクに対応する二状態レコードの生成後、方法は、以下のプロシージャ：二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かを決定することをさらに含み得る。幾つかの実施形態では、スケジューリングデバイスのスキャナは、ターゲットタスクが異常であるか否かを決定するために二状態レコードをスキャンするように構成され得る。

[112] モニタリングされる多数のターゲットデバイスが存在する場合、スキャナがグループ化され得ることが認識される。非同期スキャナスレッドの群を使用して、スケジューリングデバイスによって管理されるスキャン対象オブジェクトをスキャンし得る。

[113] 幾つかの実施形態では、ターゲットデバイスがスケジューリングデバイスへの登録に成功した後、クラウドスケジューリングデバイスがターゲットデバイスをスキャナスレッドに登録し得る。スキャナは、様々なターゲットデバイス及びターゲットタスクをモニタリングし得る。

[114] スキャナは、スキャンスレッドグループ、スキャン対象オブジェクトセット、スキャン論理機能、例外処理機能などを含み得るが、これらに限定されない。スキャンされるターゲットオブジェクトをスキャンすることは、以下のプロセス：入りマネージャ及び退出マネージャによって行われ得る。退出マネージャは、スキャン対象オブジェクトの正常な退出及び異常な退出を検出し得る。異常な退出の場合、スキャナの例外処理機能がトリガされ得る。

[115] 幾つかの実施形態では、二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かを決定することは、以下のプロシージャを行うことによって実施され得る。

[116] ステップＳ３０２（図３Ａ及び３Ｂには図示されない）では、期待される状態が実際の状態と同じであるか否かを検出する。予め設定された期間にわたり、期待される状態が実際の状態と異なる場合、例外処理機構がトリガされ得る。

[117] ステップＳ３０４（図３Ａ及び３Ｂには図示されない）では、実際の状態が異常状態を示すか否かを検出する。実際の状態が異常状態を示す場合、例外処理機構がトリガされ得る。

[118] 異常状態は、クラッシュ、ネットワークの中断などの例外を含み得るが、これらに限定されない。例えば、実際の状態がタスク例外を示し、且つそれが最終状態であることを示す場合、ターゲットタスクが異常であると決定することができ、例外処理機構がトリガされ得る。別の例として、期待される状態が実際の状態と一致しない場合（予め設定された期間にわたり、期待される状態が実際の状態と異なるなど）、ターゲットタスクが異常であると決定することができ、例外処理機構がトリガされ得る。

[119] 上記の実施形態に基づいて、ターゲットデバイス及びターゲットタスクが異常であるか否かが検出され得る。検出された異常状況に応じて、対応する例外処理が行われ得る。このようにして、デプロイされたターゲットタスクのライフサイクル及びタスクステータスが効果的にモニタリングされ得る。

[120] 実際の状態が期待される状態と一致する場合又はタスク例外が最終状態であると実際の状態が示す場合、過渡状態のターゲットタスクに対して、対応する操作が実行され得ることが認識される。例えば、スケジューリングデバイスは、過渡状態のターゲットタスクを破棄することができるか、又はそれを待ち行列に入れることができる。

[121] 幾つかの実施形態では、スケジューリングデバイスは、過渡状態のターゲットタスクを複数回チェックし得る。ターゲットタスクに対応するターゲットデバイスが正常であるが、ターゲットタスクの実際の状態が、予め設定された期間にわたり、過渡状態であることをスケジューリングデバイスが検出した場合、例外処理機構がトリガされ得る。これは、例えば、ターゲットタスクの実際の状態を失敗に強制的に変更し、ターゲットデバイスとの同期のために変更信号を生成することによって行われ得る。

[122] 幾つかの実施形態では、ターゲットデバイスの接続が切断されていることをスキャナが検出すると、スケジューリングデバイスは、ターゲットデバイスで現在実行しているターゲットタスクを検出し得る。スケジューリングデバイスは、対応するタスクスナップショットを生成し、確認信号にタスクスナップショットを記録し得る。

[123] 幾つかの実施形態では、ターゲットデバイスとスケジューリングデバイスとの間の接続が回復すると、スケジューリングデバイスは、故障前にターゲットデバイスで実行されていたターゲットタスクを回復するために、確認信号をターゲットデバイスの実行コンテナに同期させ得る。多数のターゲットタスクが現在予定されている場合、スケジューリングデバイスは、例えば、ターゲットデバイスによって送信されたハートビートリクエストにバッチで応答し得る。

[124] 幾つかの実施形態では、スキャナは、タスクに関して維持された二状態における実際の状態及び期待される状態が一致するか否かを検出し得る。予め設定された期間にわたり、期待される状態が実際の状態と異なる（例えば、中間状態が予め設定された期間にわたって持続される（すなわち期待される状態が実際の状態と異なる））場合、例外処理機構がトリガされ得る。もしくは、実際の状態が異常状態を示す場合、例外処理機構がトリガされ得る。

[125] 幾つかの実施形態では、スキャナは、スケジューリングデバイスによって返された肯定応答キャラクターの状態をさらに検出し得る。例えば、肯定応答キャラクターが１の状態値を有する場合、それは、確認信号が存在することを示し得る。肯定応答キャラクターが２の状態値を有する場合、それは、確認信号がターゲットデバイスに同期されたことを示し得る。

[126] 幾つかの実施形態では、確認信号がハートビートリクエストに対する応答としてターゲットデバイスに送信されたが、確認信号が受信された後、ターゲットデバイスがターゲットタスクの実行ステータスを同期させていないことをスキャナが検出する。この場合、スケジューリングデバイスは、ＡＣＫ例外処理プロシージャを開始し、現在の確認信号をマーキングし得る。このようにして、次にターゲットデバイスがハートビートリクエストを送信するとき、スケジューリングデバイスは、確認信号をターゲットデバイスに配信することを再度試み得る。ターゲットデバイスがスケジューリングデバイスへの応答に複数回失敗すると、ターゲットデバイスは、異常状態であるとマーキングされ得る。

[127] 幾つかの実施形態では、Ｎ回終了ごとに又は障害からの回復後、ターゲットデバイスは、現在のノードにおけるターゲットタスクの実行ステータスをスキャンし得る。ターゲットデバイスは、次回スケジューリングデバイスに送信されるハートビートリクエストにタスクステータスセットを加え得る。すなわち、ターゲットデバイスは、スケジューリングデバイスにタスク同期リクエストを送信し得る。

[128] 図４は、本開示の幾つかの実施形態による例示的タスク処理方法４００のフローチャートである。図４に示すように、ターゲットタスクの取得前に、方法４００は、以下のプロシージャ（ステップＳ４０２〜Ｓ４０８）を含む。

[129] ステップＳ４０２では、ターゲットデバイスによって送信されたデバイス情報を受信する。

[130] ステップＳ４０４では、デバイス情報を保存し、ターゲットデバイスに対応するランタイム環境識別子を生成する。

[131] ステップＳ４０６では、ランタイム環境識別子をターゲットデバイスに送信する。

[132] 幾つかの実施形態では、デバイス情報は、以下：ＣＰＵ、メモリサイズ、ディスクサイズ、ネットワークリンク、ＳＤＫバージョン番号、実行エンジン情報、アドレス情報、同期時間間隔及び構成情報の少なくとも１つに関する情報を含み得る。

[133] 上記のプロシージャに基づき、スケジューリングデバイスがターゲットタスクを取得する前に、ターゲットデバイスは、デバイス情報を取得し、かかるデバイス情報をスケジューリングデバイスに送信し得る。このようにして、スケジューリングデバイスへのターゲットデバイスの登録が実施され得る。

[134] 加えて、スケジューリングデバイスは、ターゲットデバイス情報の持続性を達成するために、デバイス情報を保存し得る。スケジューリングデバイスは、ターゲットデバイスに対応する一意のランタイム環境識別子をさらに生成し得る。ターゲットデバイスに対応するランタイム環境識別子は、例えば、ＡＣＫ情報を返すことによってターゲットデバイスに送信され得る。

[135] 幾つかの実施形態では、ランタイム環境識別子をターゲットデバイスに送信するステップＳ４０６の後、方法４００は、以下のプロシージャをさらに含み得る。

[136] ステップＳ４０８では、ターゲットデバイスによって送信されたハートビートリクエストをモニタリングすることにより、ターゲットデバイスが異常であるか否かを決定する。

[137] 幾つかの実施形態では、ターゲットデバイスがスケジューリングデバイスへの登録に成功した後、クラウドスケジューリングデバイスは、ターゲットデバイスをスキャナスレッドに登録し得る。スキャナは、各ターゲットデバイスをモニタリングし、例えばターゲットデバイスのハートビートが正常であるか否かをモニタリングすることにより、ターゲットデバイスが異常であるか否かを決定し得る。

[138] 図５は、本開示の幾つかの実施形態による例示的タスク処理方法５００のフローチャートである。図５に示すように、ターゲットデバイスによって送信されたハートビートリクエストをモニタリングすることにより、ターゲットデバイスが異常であるか否かを決定するプロセスは、以下のプロシージャ（ステップＳ５０２〜Ｓ５０８）を含み得る。

[139] ステップＳ５０２では、予め設定された期間にわたり、ハートビートリクエストが受信されていない場合、ターゲットデバイスの接続が切断されていると決定する。

[140] 予め設定された期間後又は予め設定された期間よりも長い期間後、スケジューリングデバイスが、ターゲットデバイスによって送信されたハートビートリクエストを受信していない場合、スケジューリングデバイスがターゲットデバイスから切断されていると決定することができる。この場合、ターゲットデバイスが異常であると決定することができる。

[141] ステップＳ５０４では、予め設定された対応表から、ターゲットデバイスによって現在実行しているタスクを取得する。

[142] ステップＳ５０６では、現在実行しているタスクの記述情報を確認信号に保存する。

[143] ステップＳ５０８では、ターゲットデバイスによって送信されたハートビートリクエストが受信されると、記述情報を保存した確認信号をターゲットデバイスに送信する。

[144] 上記のプロシージャに基づき、ターゲットデバイスの異常を検出した後、例外処理機能は、対応する処理を行うために呼び出され得る。このプロセスを促進するために、スケジューリングデバイスは、予め保存された対応表から、ランタイム環境識別子に応じて、ターゲットデバイスによって現在実行しているタスクを取得し得る。対応表は、例えば、スケジューリングデバイスのランタイム環境識別子と、スケジューリングデバイスで実行されるタスクとの間の対応のバッファリングされた表であり得る。スケジューリングデバイスは、現在実行しているタスクの記述情報を確認信号にさらに格納し得る。その後、ターゲットデバイスによって送信されたハートビートリクエストを受信した場合、スケジューリングデバイスは、記述情報を保存した確認信号をターゲットデバイスに送信し得る。

[145] 幾つかの実施形態では、タスク処理方法は、以下のプロシージャをさらに含み得る。

[146] ステップＳ５１０（図５には図示されない）では、ターゲットデバイスによって送信されたタスクステータス較正リクエストを受信する。ターゲットデバイスがネットワークの中断又は障害から再起動又は回復した場合、１つ又は複数のタスクのタスクステータスが取得され得る。タスクのタスクステータスを含むタスクステータス較正リクエストは、取得されたステータス情報に基づいて生成され得る。

[147] ステップＳ５１２（図５には図示されない）では、タスクステータス較正リクエストに応じてステータス較正を行う。

[148] 上記のプロシージャに基づき、ターゲットデバイスがネットワークの中断又は障害から再起動又は回復した後、ターゲットデバイスは、ランタイム環境における１つ又は複数のタスクのステータスを取得し得る。次いで、ターゲットデバイスは、タスクのタスクステータスを含むタスクステータス較正リクエストを生成し、ステータス較正リクエストをスケジューリングデバイスに送信し得る。ステータス較正リクエストは、アクティブ同期インタフェースによって送信され得る。スケジューリングデバイスは、タスクステータス較正リクエストに応じてステータス較正を行い得る。

[149] ステータス較正は、例えば、ターゲットタスクのタスクステータスを使用して、予め維持されたステータスレコードを更新することによって行われ得ることが認識される。幾つかの実施形態では、ステータス較正は、ターゲットタスクのタスクステータスを予め維持されたステータスレコードと比較することによっても行われ得る。ステータス較正を実施する方法は、本開示に記載される実施形態によって限定されない。これらの状態が異なることを比較結果が示す場合、それに応じてステータス較正情報がターゲットデバイスに返され得る。

[150] 本開示の実施形態で提供されるある例示的タスク処理方法の実施を以下に説明する。図６は、本開示の幾つかの実施形態による例示的タスク処理方法６００の概略的な相互作用図である。図６に示すように、タスク処理方法６００は、以下のプロシージャ及び相互作用（ステップＳ６０１〜Ｓ６１４）によって実施され得る。

[151] ステップＳ６０１では、コンソールがテナント情報を取得する。

[152] 幾つかの実施形態では、コンソールは、上位開発者（例えば、登録開発者）であり得る。コンソールは、事前に認証されたアカウント情報に基づいてテナント情報を取得し得る。

[153] ステップＳ６０２では、ターゲットデバイスがスケジューリングデバイスに登録する。

[154] スケジューリングデバイスに登録するプロセスでは、ターゲットデバイスは、デバイス情報をスケジューリングデバイスに送信し得るが、これに限定されない。デバイス情報は、以下：ＣＰＵ、メモリサイズ、ディスクサイズ、ネットワークリンク、ＳＤＫバージョン番号、実行エンジン情報、アドレス情報、同期時間間隔及び構成情報の少なくとも１つに関する情報を含み得る。

[155] スケジューリングデバイスがターゲットタスクを取得する前に、ターゲットデバイスがローカルデバイス情報を取得し得ることが認識される。例えば、ローカルデバイス情報は、ＣＰＵに関する情報、メモリサイズ、ディスクサイズ、ネットワークリンク、ＳＤＫバージョン番号、実行エンジン情報、アドレス情報、同期時間間隔、構成情報などを含み得る。ターゲットデバイスは、スケジューリングデバイス側で登録を実施するために、デバイス情報をスケジューリングデバイスに送信し得る。

[156] デバイス情報の受信後、スケジューリングデバイスは、ターゲットデバイス情報の持続性を達成するために、デバイス情報を保存し得ること及びターゲットデバイスに対応する一意のランタイム環境識別子を生成し得ることが認識される。スケジューリングデバイスは、例えば、ＡＣＫ情報を返すことにより、ターゲットデバイスに対応するランタイム環境識別子をターゲットデバイスにさらに送信し得る。

[157] 幾つかの実施形態では、スケジューリングデバイスは、スキャンスレッドを初期化し、上記のように二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かをさらに決定し得る。

[158] ステップＳ６０３では、スケジューリングデバイスは、コンソールによって送信された第１のタスクを受信する。

[159] 幾つかの実施形態では、スケジューリングデバイスは、コンソールによって提出された第１のタスクを受信し得る。コンソールがデプロイメントのために第１のタスクをスケジューリングデバイスに提出する場合、第１のタスクにおけるスケジューリングポリシー、デプロイメントアドレス、タスク内容及び実行エンジンなどの情報が指定され得る。

[160] ステップＳ６０４では、スケジューリングデバイスは、デプロイメントアドレスをパージングし、且つデプロイメントアドレスによって示されるターゲットデバイスのステータスを検出する。

[161] ターゲットデバイスのステータスは、ターゲットデバイスの実行ノードのステータスを指し得るが、これに限定されない。ターゲットデバイスが正常状態である場合、ステップＳ６０５が行われ得る。

[162] 幾つかの実施形態では、スケジューリングデバイスは、デプロイメントアドレスをパージングし、且つターゲットデバイスの実行ノードのステータスを検出する。スケジューリングデバイスは、さらに、ターゲットデバイスのステータスが正常であるか否かを決定するために、ターゲットデバイスのタスクスナップショットを記録し、タスク内容のフォーマットをチェックし得る。

[163] ステップＳ６０５では、スケジューリングデバイスは、タスク内容及びスケジューリングポリシーに応じてターゲットタスクを生成する。

[164] 幾つかの実施形態では、スケジューリングポリシーは、以下のスケジューリングポリシー：シングルポイントスケジューリング、指定スケジューリング、フルスケジューリング、分散スケジューリングなどの何れか１つであり得る。ターゲットデバイスが正常状態であると決定される場合、ターゲットタスクがタスク内容及びスケジューリングポリシーに応じて生成され得る。

[165] ステップＳ６０６では、スケジューリングデバイスは、ターゲットタスクを取得し、ターゲットタスクは、ターゲットデバイスでデプロイされる必要があるタスクである。

[166] 幾つかの実施形態では、スケジューリングデバイスは、クラウドスケジューリングデバイスであり得る。スケジューリングデバイスは、エッジでデプロイされる必要があるターゲットタスクを取得し、ターゲットタスクに応じて、対応する確認信号を生成し得る。ターゲットデバイスからハートビートリクエストを受信すると、スケジューリングデバイスは、確認信号をターゲットデバイスに送信し得る。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。

[167] 幾つかの実施形態では、ターゲットタスクは、ターゲットデバイスでデプロイ及び実行され得るタスクであり得る。例えば、また、データフィルタリング、フォーマット変換、基本演算、スクリプト、ルール、構成及びアプリケーションに関連するタスクであり得るが、これらに限定されない。ターゲットデバイスは、エッジゲートウェイデバイス、基地局又はエッジクラウドサーバであり得る。様々な実行エンジンにランタイム環境を提供するエッジ側の実行ノードは、ターゲットデバイスでデプロイされ得る。

[168] ステップＳ６０７では、スケジューリングデバイスは、ターゲットタスクに応じて、対応する確認信号を生成する。

[169] 確認信号は、ターゲットタスクのタスク内容を含み得る。確認信号は、以下：タスクスナップショット、戻りコード及び消費ステータスの少なくとも１つをさらに含み得る。幾つかの実施形態では、スケジューリングデバイスは、ターゲットデバイスのデバイス情報を取得し、取得されたターゲットタスク及びデバイス情報に応じて、対応する確認信号を生成し得る。

[170] 幾つかの実施形態では、確認信号は、応答内容フィールドを含み得る。スケジューリングデバイスは、確認信号を取得するためにタスク内容を確認信号の応答内容フィールドに加えるようにして、ターゲットタスクに応じて対応する確認信号を生成し得る。幾つかの実施形態では、応答内容フィールドは、上記の表１に示すような応答内容フィールドのＡｃｋ内容であり得る。確認信号は、ターゲットタスクのタスク内容を応答内容フィールドのＡｃｋ内容に加えることによって取得され得る。

[171] 幾つかの実施形態では、ターゲットデバイスが起動されると、ランタイムマネージャは、様々な実行エンジンをロードし得る。各実行エンジンは、それぞれの名前空間を有し得る。異なる言語を使用して実施される実行エンジンは、プロセス間通信を用いて管理され得る。ランタイムマネージャは、データバスにブロードキャストを送信し得る。ブロードキャストの受信後、各実行エンジンプロセスは、ランタイムマネージャのアドレスに対するエンジン登録リクエストを開始し得る。

[172] ステップＳ６０８では、スケジューリングデバイスは、確認信号をターゲットデバイスに送信する。例えば、ターゲットデバイスのハートビートリクエストが受信されると、スケジューリングデバイスは、確認信号をターゲットデバイスに送信し得る。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。幾つかの実施形態では、ハートビートリクエストは、以下：ＣＰＵ使用状況、メモリ使用状況、ディスク使用状況及びタスクの実行ステータスの少なくとも１つに関する情報を含み得る。

[173] 幾つかの実施形態では、ターゲットデバイスがスケジューリングデバイスへの登録に成功する場合、ターゲットデバイスは、ローカルでハートビートデーモンスレッドを開始し得る。ハートビートリクエストは、予め設定されたハートビートレートの一定の頻度に従ってスケジューリングデバイスに送信され得る。

[174] 幾つかの実施形態では、スケジューリングデバイスは、以下のプロシージャ：確認信号をハートビート応答のデータフィールドに加えること及び確認信号を含むハートビート応答をターゲットデバイスに送信することを行うことにより、確認信号をターゲットデバイスに送信し得る。

[175] 幾つかの実施形態では、ターゲットデバイスによって送信されたハートビートリクエストを受信すると、スケジューリングデバイスは、対応する確認信号がローカルで存在するか否かを検出し得る。対応する確認信号が存在する場合、スケジューリングデバイスは、現在のハートビートリクエストのハートビート応答に確認信号を加え、確認信号を含むハートビート応答をターゲットデバイスに送信し得る。

[176] 上記のように、スケジューリングデバイスは、タスク内容を確認信号の応答内容フィールドに加えることによって確認信号を取得し得る。確認信号の例示的データ構造は、上記で表１に示されるようなものであり得る。加えて、確認信号は、ハートビート応答のデータに加えられ得る。ハートビート応答の例示的データ構造は、上記で表２に示すようなものであり得る。対応する確認信号がローカルで存在しないことをスケジューリングデバイスが検出した場合、ハートビートリクエストが受信されたことを示す肯定応答キャラクターは、ターゲットデバイスに返され得ることが認識される。肯定応答キャラクターは、ターゲットデバイスのハートビートリクエストの受信を肯定応答するために使用され得る。

[178] 幾つかの実施形態では、上記のプルモードに加えて、プッシュモードも適用され得る。上記のプルモードでは、スケジューリングデバイスがターゲットタスクに応じて対応する確認信号を生成した後に、スケジューリングデバイスは、ターゲットデバイスのハートビートリクエストを受信した後、ターゲットデバイスに対して、ハートビートリクエストに対応する確認信号を送信し得る。プッシュモードでは、スケジューリングデバイスは、確認信号（確認信号は、ターゲットタスクのタスク内容を含む）を生成した後、ターゲットデバイスに確認信号を能動的にプッシュし得る。プッシュモードは、幾つかの低性能デバイスに対してより適切であり得る。プッシュモードの特徴の１つは、それが低性能デバイスの電力消費を減らし得ることである。

[179] 幾つかの実施形態では、タスク内容を含む確認信号は、プッシュモード及びプルモードを組み合わせた複合プロトコル様式を使用することによってもターゲットデバイスに送信され得る。このようにして、開発者は、実際の実施シナリオに応じてモード間の切り替えを行い得る。例えば、複合プロトコル様式は、ターゲットタスクを運ぶ確認信号をスケジューリングデバイスからプルするようにターゲットデバイスに命令するために、スケジューリングデバイスが確認信号を生成した後、ターゲットデバイスにメッセージをプッシュすることによって実施され得るが、これに限定されない。

[180] ステップＳ６０９では、ターゲットデバイスは、確認信号に応じてターゲットタスクの処理及び実行を行う。幾つかの実施形態では、確認信号の受信後、ターゲットデバイスは、確認信号をパージングして、確認信号に含まれるターゲットタスクのタスク内容を取得し得る。ターゲットデバイスは、ターゲットタスクのデプロイメントを完了し、且つタスク内容に応じてターゲットタスクを実行し得る。

[181] ステップＳ６１０では、スケジューリングデバイスは、ターゲットデバイスによって送信されたタスク同期リクエストを受信する。

[182] ステップＳ６１１では、スケジューリングデバイスは、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、二状態レコードの実際の状態を更新する。

[183] 上記のプロシージャに基づき、確認信号を受信すると、ターゲットデバイスは、確認信号が運ぶターゲットタスクのタスク内容をパージングし得る。ターゲットデバイスは、ターゲットタスクを実行し、且つタスク同期リクエストにより、ターゲットタスクの実行ステータスをスケジューリングデバイスに送信し得る。このようにして、スケジューリングデバイスは、ローカル二状態レコードの実際の状態を更新し得る。

[184] 幾つかの実施形態では、スケジューリングデバイスでデプロイされた状態機械は、ターゲットタスクの二状態の記録及び識別を行い得る。状態機械は、ターゲットタスクのライフサイクルにおける状態遷移を管理するために使用され得る。期待される状態及び実際の状態は、以下：非実行状態、実行状態、実行終了状態、実行失敗状態及び実行一時停止状態の少なくとも１つを含み得る。

[185] ターゲットデバイスのタスク同期リクエストの受信後、スケジューリングデバイスは、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、ローカル二状態レコードのターゲットタスクの実際の状態を更新し得ることが認識される。スケジューリングデバイスは、ターゲットデバイスが対応する確認信号を受信したことを決定し、ローカルな確認信号を削除し得る。

[186] ステップＳ６１２では、スケジューリングデバイスは、ステータス同期確認信号をターゲットデバイスに送信する。

[187] ステップＳ６１３では、スケジューリングデバイスは、二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かを決定する。

[188] 上記の例示的プロセスは、ターゲットタスクに対応する二状態レコードの生成後、二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かを決定することをさらに含み得る。幾つかの実施形態では、二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かを決定することは、以下のプロシージャ：期待される状態が実際の状態と同じであるか否かを検出することを行うことによって実施され得る。予め設定された期間にわたり、期待される状態が実際の状態と異なる場合、例外処理機構がトリガされ得る。代わりに、二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かを決定することは、実際の状態が異常状態を示すか否かを検出することによって実施され得る。実際の状態が異常状態を示す場合、例外処理機構がトリガされ得る。

[189] 異常状態は、クラッシュ、ネットワークの中断などの例外を含み得るが、これらに限定されない。例えば、実際の状態がタスク例外を示し、且つそれが最終状態であることを示す場合、ターゲットタスクが異常であると決定することができ、例外処理機構がトリガされ得る。別の例として、期待される状態が実際の状態と一致しない場合（予め設定された期間にわたり、期待される状態が実際の状態と異なるなど）、ターゲットタスクが異常であると決定することができ、例外処理機構がトリガされ得る。

[190] 上記の実施形態に基づいて、ターゲットデバイス及びターゲットタスクが異常であるか否かが検出され得る。検出された異常状況に応じて、対応する例外処理が行われ得る。このようにして、デプロイされたターゲットタスクのライフサイクル及びタスクステータスが効果的にモニタリングされ得る。

[191] 実際の状態が期待される状態と一致する場合又はタスク例外が最終状態であると実際の状態が示す場合、過渡状態のターゲットタスクに対して、対応する操作が実行され得ることが認識される。例えば、スケジューリングデバイスは、過渡状態のターゲットタスクを破棄することができるか、又はそれを待ち行列に入れることができる。

[192] 幾つかの実施形態では、スケジューリングデバイスは、過渡状態のターゲットタスクを複数回チェックし得る。ターゲットタスクに対応するターゲットデバイスが正常であるが、ターゲットタスクの実際の状態が、予め設定された期間にわたり、過渡状態であることを検出する場合、スケジューリングデバイスは、例外処理機構をトリガし得る。例えば、スケジューリングデバイスは、ターゲットタスクの実際の状態を失敗に強制的に変更し、変更信号を生成し、且つ変更信号をターゲットデバイスに同期させ得る。

[193] 幾つかの実施形態では、ターゲットデバイスの接続が切断されていることをスキャナが検出する場合、スケジューリングデバイスは、ターゲットデバイスで現在実行しているターゲットタスクを検出し得る。スケジューリングデバイスは、対応するタスクスナップショットを生成し、確認信号にタスクスナップショットを記録し得る。

[194] 幾つかの実施形態では、ターゲットデバイスとスケジューリングデバイスとの間の接続が回復すると、スケジューリングデバイスは、故障前にターゲットデバイスで実行されていたターゲットタスクを回復するために、確認信号をターゲットデバイスの実行コンテナに同期させ得る。多数のターゲットタスクが現在予定されている場合、スケジューリングデバイスは、ターゲットデバイスによって送信されたハートビートリクエストにバッチで応答し得る。

[195] ステップＳ６１４では、スケジューリングデバイスは、タスクデプロイメントが完了したことを示す肯定応答情報をコンソールに送信する。

[196] 図７は、本開示の幾つかの実施形態による例示的タスク処理方法７００のフローチャートである。例示的タスク処理方法７００は、上記のランタイム環境に類似したランタイム環境で行われ得る。本開示によって提供されるタスク処理方法は、エッジコンピューティングシナリオで実行又は実施され得ることが認識される。幾つかの実施形態によれば、エッジ側ランタイム環境、タスクデプロイメントステータス、操作信号ステータスなどがモニタリング及び管理され得る。このようにして、エッジゲートウェイデバイスで例外の自己検出及び補償を行うことができる。本開示で提供される実施形態の利点の１つは、エッジ側ランタイム環境の安定性及びデータ整合性を向上させ得ることである。

[197] 本開示によって提供されるタスク処理方法の実施形態は、スマート産業、スマートシティ、無人スーパーマーケット及びスマートホテルなどの新興のＩｏＴ分野に適用され得ることを認識されたい。本開示で提供される解決策は、エッジコンピューティングのタスク処理速度を向上させ、デバイスからのリクエストに対する応答時間を短縮することができる。

[198] 図７に示すように、提供される例示的タスク処理方法７００は、以下のプロシージャ（ステップＳ７０２〜Ｓ７０６）を含み得る。

[199] ステップＳ７０２では、スケジューリングデバイスにハートビートリクエストを送信する。本開示で提供される方法は、ターゲットデバイス（これは、例えば、エッジゲートウェイデバイス、基地局又はエッジクラウドサーバであり得る）によって実行され得ることが認識される。スケジューリングデバイスは、クラウドスケジューリングデバイスであり得る。様々な実行エンジンにランタイム環境を提供する実行ノードは、ターゲットデバイスでデプロイされ得る。

[200] 幾つかの実施形態では、ハートビートリクエストは、以下：ＣＰＵ使用状況、メモリ使用状況、ディスク使用状況及びタスクの実行ステータスの少なくとも１つに関する情報を含み得る。ハートビートリクエストは、一定の時間間隔（例えば３０〜４０秒、又は別の時間間隔）でターゲットデバイスによってスケジューリングデバイスに送信されたハートビートパケットであり得る。ハートビートリクエストは、ターゲットデバイスとスケジューリングデバイスとの間の接続が現在正常であることを示すために使用され得る。ハートビートリクエストのパケット内容は、本開示において本明細書に記載される実施形態によって限定されない。例えば、ハートビートリクエストは、長い接続のキープアライブ及び切断にパケットが使用され得る限り、ヘッダのみを含むヌルパケットであり得る。

[201] 幾つかの実施形態では、ターゲットデバイスがスケジューリングデバイスへの登録に成功すると、ターゲットデバイスは、ローカルでハートビートデーモンスレッドを開始し得る。スケジューリングデバイスへのハートビートリクエストは、予め設定されたハートビートレートの一定の頻度に従って送信され得る。

[202] ステップＳ７０４では、スケジューリングデバイスから、ハートビートリクエストに対応する確認信号を受信する。確認信号は、ターゲットタスクのタスク内容を含み得る。確認信号は、ターゲットタスクの取得後、スケジューリングデバイスによって生成され得る。

[203] 幾つかの実施形態では、ターゲットタスクは、ターゲットデバイスでデプロイ及び実行され得るタスクであり得る。タスクは、例えば、スクリプト、ルール、構成、アプリケーション、データフィルタリング、フォーマット変換及び基本演算に関連するタスクであり得る。

[204] 幾つかの実施形態では、スケジューリングデバイスは、エッジでデプロイされる必要があるターゲットタスクを取得し、ターゲットタスクに応じて、対応する確認信号を生成する。ターゲットデバイスからハートビートリクエストを受信すると、ターゲットデバイスがタスク内容に応じてターゲットタスクを実行し得るように、スケジューリングデバイスは、ハートビートリクエストに対応する確認信号をターゲットデバイスに送信し得る。

[205] さらに、スケジューリングデバイスは、ターゲットデバイスのデバイス情報を取得し得る。対応する確認信号は、取得されたターゲットタスク及びデバイス情報に応じて生成され得る。幾つかの実施形態では、確認信号は、応答内容フィールドを含み得る。ターゲットタスクに応じて対応する確認信号を生成することは、確認信号を取得するためにタスク内容を確認信号の応答内容フィールドに加えることを含み得る。

[206] 幾つかの実施形態では、ターゲットデバイスに確認信号を送信することは、確認信号をハートビート応答のデータフィールドに加えること及び確認信号を含むハートビート応答をターゲットデバイスに送信することを行うことによって実施され得る。

[207] 幾つかの実施形態では、ターゲットデバイスによって送信されたハートビートリクエストを受信すると、スケジューリングデバイスは、対応する確認信号がローカルに存在するか否かを検出し得る。対応する確認信号が存在する場合、スケジューリングデバイスは、確認信号を現在のハートビートリクエストのハートビート応答に加え得る。スケジューリングデバイスは、確認信号を含むハートビート応答をターゲットデバイスに送信し得る。対応する確認信号がローカルに存在しないことをスケジューリングデバイスが検出した場合、ハートビートリクエストが受信されたことを示す肯定応答キャラクターがターゲットデバイスに返され得る。

[209] 幾つかの実施形態では、上記のプルモードに加えて、プッシュモードも適用され得る。上記のプルモードでは、スケジューリングデバイスがターゲットタスクに応じて対応する確認信号を生成した後に、スケジューリングデバイスは、ターゲットデバイスのハートビートリクエストを受信した後、ターゲットデバイスに対して、ハートビートリクエストに対応する確認信号を送信し得る。プッシュモードでは、スケジューリングデバイスは、確認信号（確認信号は、ターゲットタスクのタスク内容を含む）を生成した後、ターゲットデバイスに確認信号を能動的にプッシュし得る。プッシュモードは、幾つかの低性能デバイスに対してより適切であり得る。プッシュモードの特徴の１つは、それが低性能デバイスの電力消費を減らし得ることである。

[210] 幾つかの実施形態では、タスク内容を含む確認信号は、プッシュモード及びプルモードを組み合わせた複合プロトコル様式を使用することによってもターゲットデバイスに送信され得る。このようにして、開発者は、実際の実施シナリオに応じてモード間の切り替えを行い得る。例えば、複合プロトコル様式は、ターゲットタスクを運ぶ確認信号をスケジューリングデバイスからプルするようにターゲットデバイスに命令するために、スケジューリングデバイスが確認信号を生成した後、ターゲットデバイスにメッセージをプッシュすることによって実施され得るが、これに限定されない。

[211] ステップＳ７０６では、タスク内容に応じてターゲットタスクを実行する。

[212] 幾つかの実施形態では、確認信号の受信後、ターゲットデバイスは、確認信号をパージングして、確認信号に含まれるターゲットタスクのタスク内容を取得し得る。次いで、ターゲットデバイスは、ターゲットタスクのデプロイメントを完了し、且つタスク内容に応じてターゲットタスクを実行し得る。

[213] 幾つかの実施形態では、タスク内容に応じたターゲットタスクの実行後、ターゲットデバイスは、タスク同期リクエストをスケジューリングデバイスに送信し得る。タスク同期リクエストは、ターゲットタスクの実行ステータスを示すために使用され得る。スケジューリングデバイスは、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、ターゲットタスクに対応する二状態レコードの実際の状態を更新し得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。

[214] 上記の実施形態に基づいて、ハートビートリクエストがスケジューリングデバイスに送信され得る。ハートビートリクエストに対応する確認信号がスケジューリングデバイスから受信され得る。確認信号は、ターゲットタスクのタスク内容を含み得る。ターゲットタスクの取得後、確認信号がスケジューリングデバイスによって生成され得る。ターゲットタスクは、タスク内容に応じて実行され得る。

[215] 本開示の上述の実施形態で提供される解決策により、エッジコンピューティングのタスク処理速度及びエッジオペレーティングシステムの安定性を向上させることができる。デバイスからのリクエストに対する応答時間は、エッジコンピューティングのタスク処理速度を向上させることによって短縮することができる。従って、本明細書で提供される解決策は、データソース側に近いエッジデバイスでクラウドコンピューティングロジック及びアプリケーションをデプロイ及び実行するという技術的問題に対処することができる。

[216] 図８は、本開示の幾つかの実施形態による例示的な任意選択のタスク処理方法８００のフローチャートである。例示的方法８００のプロシージャは、ハートビートリクエストをスケジューリングデバイスに送信するステップＳ７０２（図７）前に実施され得る。図８に示すように、例示的方法８００は、以下のプロシージャ（ステップＳ８０２〜Ｓ８０６）を含み得る。

[217] ステップＳ８０２では、デバイス情報を取得する。

[218] ステップＳ８０４では、デバイス情報をスケジューリングデバイスに送信する。スケジューリングデバイスは、デバイス情報を保存し、対応するランタイム環境識別子を生成し得る。

[219] ステップＳ８０６では、スケジューリングデバイスによって送信されたランタイム環境識別子を受信し、このランタイム環境識別子は、デバイス情報に基づいて生成されたものである。

[220] 幾つかの実施形態では、デバイス情報は、以下：ＣＰＵ、メモリサイズ、ディスクサイズ、ネットワークリンク、ＳＤＫバージョン番号、実行エンジン情報、アドレス情報、同期時間間隔及び構成情報の少なくとも１つを含み得る。

[221] 幾つかの実施形態では、スケジューリングデバイスがターゲットタスクを取得する前に、ターゲットデバイスは、ローカルデバイス情報を取得し得る。例えば、ローカルデバイス情報は、ＣＰＵに関する情報、メモリサイズ、ディスクサイズ、ネットワークリンク、ＳＤＫバージョン番号、実行エンジン情報、アドレス情報、同期時間間隔、構成情報などを含み得る。ターゲットデバイスは、スケジューリングデバイスへの登録を実施するために、デバイス情報をスケジューリングデバイスに送信し得る。スケジューリングデバイスは、デバイス情報を保存し、且つ対応するランタイム環境識別子を生成し得る。さらに、スケジューリングデバイスは、デバイス情報の持続性を達成するためにデバイス情報を保存し得る。スケジューリングデバイスは、ターゲットデバイスに対応する一意のランタイム環境識別子を生成し得る。スケジューリングデバイスは、例えば、ＡＣＫ情報を返すことにより、ターゲットデバイスに対応するランタイム環境識別子をターゲットデバイスに送信し得る。

[222] 幾つかの実施形態では、スケジューリングデバイスによって送信されたランタイム環境識別子を受信するステップＳ８０６の後、例示的方法８００は、予め構成された頻度に従ってハートビートリクエストをスケジューリングデバイスに送信することをさらに含み得る。ハートビートリクエストは、以下：ＣＰＵ使用状況、メモリ使用状況及びディスク使用状況の少なくとも１つを含み得る。

[223] 幾つかの実施形態では、ターゲットデバイスがスケジューリングデバイスへの登録に成功すると、ターゲットデバイスは、ローカルにハートビートデーモンスレッドを開始し得る。スケジューリングデバイスへのハートビートリクエストは、予め設定されたハートビートレートの一定の頻度に従って送信され得る。

[224] 図９は、本開示の幾つかの実施形態による例示的タスク処理方法９００のフローチャートである。図９に示すように、例示的タスク処理方法９００は、以下のプロシージャ（ステップＳ９０２〜Ｓ９０４）を含み得る。

[225] ステップＳ９０２では、１つ又は複数のタスクのタスクステータスを取得し、１つ又は複数のタスクのタスクステータスを含むタスクステータス較正リクエストを生成する。これは、ネットワークの中断又は障害からのデバイスの再起動又は回復後に行われ得る。

[226] ステップＳ９０４では、タスクステータス較正リクエストをスケジューリングデバイスに送信する。スケジューリングデバイスは、タスクステータス較正リクエストに応じてステータス較正を行い得る。

[227] 上記のプロシージャに基づき、ターゲットデバイスがネットワークの中断又は障害から再起動又は回復した後、ターゲットデバイスは、ランタイム環境におけるタスクのステータスを取得し得る。ターゲットデバイスは、タスクのタスクステータスを含むタスクステータス較正リクエストを生成し、例えば、アクティブ同期インタフェースにより、ステータス較正リクエストをスケジューリングデバイスに送信し得る。スケジューリングデバイスは、タスクステータス較正リクエストに応じてステータス較正を行い得る。

[228] ステータス較正は、例えば、ターゲットタスクのタスクステータスを使用して、予め維持されたステータスレコードを更新することによって行われ得ることが認識される。幾つかの実施形態では、ステータス較正は、ターゲットタスクのタスクステータスを予め維持されたステータスレコードと比較することによっても行われ得る。ステータス較正を実施する方法は、本開示に記載される実施形態によって限定されない。ステータスが異なることを比較結果が示す場合、それに応じてステータス較正情報がターゲットデバイスに返され得る。

[229] 上記のプロシージャの実施に関して、本開示の他の箇所で提供される関連の記載を参照し得ることが認識される。詳細は、ここでは繰り返さない。

[230] 上記のランタイム環境に類似したランタイム環境において、タスク処理方法がさらに提供される。本開示によって提供されるタスク処理方法は、エッジコンピューティングシナリオで実行又は実施され得ることを認識されたい。幾つかの実施形態によれば、エッジ側ランタイム環境、タスクデプロイメントステータス、操作信号ステータスなどがモニタリング及び管理され得る。このようにして、エッジゲートウェイデバイスで例外の自己検出及び補償を行うことができる。本開示で提供される実施形態の利点の１つは、エッジ側ランタイム環境の安定性及びデータ整合性を向上させ得ることである。

[231] 本開示によって提供されるタスク処理方法の実施形態は、スマート産業、スマートシティ、無人スーパーマーケット及びスマートホテルなどの新興のＩｏＴ分野に適用され得ることが認識される。本明細書で提供される解決策は、エッジコンピューティングのタスク処理速度を向上させ、デバイスからのリクエストに対する応答時間を短縮することができる。

[232] 図１０は、本開示の幾つかの実施形態による例示的タスク処理方法１０００のフローチャートである。図１０に示すように、タスク処理方法１０００は、以下のプロシージャ（ステップＳ１００２〜Ｓ１００６）を含み得る。

[233] ステップＳ１００２では、スキャンスレッドを開始する。図１０を参照して本明細書に記載する方法実施形態は、スケジューリングデバイスによって実行され得ることが認識される。１つのマネージャが複数のスキャンスレッドを開始するという問題を回避するために、スケジューリングデバイスのスキャナは、１つのマネージャによって開始されたスキャンスレッドをスキャンするために使用され得る。スキャンスレッドを開始する前に現在のスレッドの実行状態が検出され得る。

[234] ステップＳ１００４では、スキャン対象オブジェクトをスキャンするために、スキャンスレッドのスキャン論理機能を呼び出し、異常なスキャン対象オブジェクトの数を取得する。幾つかの実施形態では、スキャン対象オブジェクトは、ターゲットデバイス又はターゲットタスクを含み得る。モニタリングされる多数のターゲットデバイスが存在する場合、スキャナがグループ化され得ることを認識されたい。スキャン論理機能を呼び出すことにより、非同期スキャナスレッドの群を使用して、スケジューリングデバイスによって管理されるスキャン対象オブジェクトをスキャンし得る。

[235] 幾つかの実施形態では、スケジューリングデバイスが起動される場合、スケジューリングデバイスのスキャナは、バッファリングされた対応表に従い、マネージャによって開始されたスキャンスレッドをスキャンし得る。スキャンスレッドが開始される前に現在のスレッドの実行状態が検出され得る。このようにして、１つのマネージャが複数のスキャンスレッドを開始するという問題を回避することができる。加えて、バッファリングされた対応表が失われた場合、スキャンスレッドは、登録モニタリングプラットフォームプロシージャにより開始され得る。

[236] 本開示の幾つかの実施形態では、１つのスキャンスレッドは、スキャン対象オブジェクトの群を管理し得る。定期的に、スキャン論理機能は、スキャン対象オブジェクトセットに対して実行され得る。現在のスキャン対象オブジェクトが異常であると決定された場合、スケジューリングデバイスは、異常なスキャン対象オブジェクトの数をカウントする。カウント値は、異常なスキャン対象オブジェクトの数を表し得る。−１の値は、スキャン対象オブジェクトが正常であることを示し得る。１は、スキャン対象オブジェクトが異常であることを示し得る。カウントの最低値は、０である。本開示によって提供される幾つかの実施形態では、スキャンスレッドは、各スキャンスレッドが異なるスキャン時間間隔を有することを保証するために、その時間間隔をサフィックスとして使用して命名され得る。

[237] ステップＳ１００６では、異常なスキャン対象オブジェクトの数が、予め設定された閾値以上である場合、スキャン対象オブジェクトを処理するために例外処理機能を呼び出す。

[238] 幾つかの実施形態では、異常なスキャン対象オブジェクトの数を取得するために、異常なスキャン対象オブジェクトがカウントされ得る。異常なスキャン対象オブジェクトの数は、予め設定された閾値と比較され得る。その数が、予め設定された閾値以上である場合、スキャン対象オブジェクトを処理するために例外処理機能が呼び出され得る。代わりに、その数が、予め設定された閾値よりも小さい場合、追加の処理が行われなくてもよい。

[239] 加えて、幾つかの実施形態では、ターゲットデバイスがスケジューリングデバイスへの登録に成功した後、クラウドスケジューリングデバイスがターゲットデバイスをスキャナスレッドに登録し得る。スキャナは、様々なターゲットデバイス及びターゲットタスクをモニタリングし得る。スキャナは、例えば、スキャンスレッドグループ、スキャン対象オブジェクトセット、スキャン論理機能、例外処理機能などを含み得る。スキャンされるターゲットオブジェクトをスキャンすることは、以下のプロシージャ：入りマネージャ及び退出マネージャによって行われ得る。

[240] スキャン対象オブジェクトは、所与のルールに従って１つの入りマネージャに割り当てられ得る。割り当てルールは、実際の実施シナリオによって変化し得、本開示によって限定されない。退出マネージャは、スキャン対象オブジェクトの正常な退出及び異常な退出を検出し得る。異常な退出の場合、スキャナの例外処理機能がトリガされ得る。

[241] 上記の開示に基づいて、幾つかの実施形態では、スキャンスレッドが開始され得る。スキャンスレッドを用いて、スキャン対象オブジェクトをスキャンするために、スキャン論理機能を呼び出すことができ、異常なスキャン対象オブジェクトの数を取得することができる。異常なスキャン対象オブジェクトの数が、予め設定された閾値以上である場合、スキャン対象オブジェクトを処理するために例外処理機能が呼び出され得る。ターゲットデバイス及びターゲットタスクが異常であるか否かを検出し、異常状況に応じて、対応する例外処理を行うことにより、デプロイされたターゲットタスクのライフサイクル及びタスクステータスを効果的にモニタリングすることができる。

[242] 本開示の上述の実施形態で提供される解決策を用いて、エッジコンピューティングのタスク処理速度及びエッジオペレーティングシステムの安定性を向上させることができる。さらに、デバイスからのリクエストに対する応答時間を短縮する技術的効果は、エッジコンピューティングのタスク処理速度を上げることによって達成することができる。従って、本開示で提供される技術は、データソース側に近いエッジデバイスでクラウドコンピューティングロジック及びアプリケーションをデプロイ及び実行するという技術的問題に対処することができる。

[243] 幾つかの実施形態では、スキャン対象オブジェクトがターゲットデバイスを含む場合、スキャン対象オブジェクトを処理するために例外処理機能を呼び出すプロセスは、以下のプロシージャを含み得る。

[244] ステップＳ１００７（図１０には図示されない）では、予め設定された対応表から、ターゲットデバイスによって現在実行しているタスクを取得する。

[245] ステップＳ１００８（図１０には図示されない）では、現在実行しているタスクの記述情報を確認信号に格納する。

[246] ステップＳ１００９（図１０には図示されない）では、ターゲットデバイスによって送信されたハートビートリクエストが受信されると、記述情報を格納した確認信号をターゲットデバイスに送信する。

[247] 上記のプロシージャに基づき、ターゲットデバイスの異常を検出した後、例外処理機能は、対応する処理を行うために呼び出され得る。このプロセスを容易にするために、スケジューリングデバイスは、予め保存された対応表から、ランタイム環境識別子に応じて、ターゲットデバイスによって現在実行しているタスクを取得し得る。対応表は、例えば、スケジューリングデバイスのランタイム環境識別子と、スケジューリングデバイスで実行されるタスクとの間の対応関係がバッファリングされた表であり得る。スケジューリングデバイスは、現在実行しているタスクの記述情報を確認信号にさらに格納し得る。その後、ターゲットデバイスによって送信されたハートビートリクエストを受信した場合、スケジューリングデバイスは、記述情報を格納した確認信号をターゲットデバイスに送信し得る。

[248] 加えて、予め設定された期間後に、スケジューリングデバイスが、ターゲットデバイスによって送信されたハートビートリクエストを受信していない場合、スケジューリングデバイスがターゲットデバイスから切断されていると決定することができる。すなわち、ターゲットデバイスが異常であると決定することができる。ターゲットデバイスの異常を検出し、対応する処理を行うために例外処理機能を呼び出すために、異常なターゲットデバイスは、上記の処理方法を用いることによっても処理され得る。

[249] 幾つかの実施形態では、クラウドスケジューリングデバイスに登録する場合、ターゲットデバイスは、スケジューリングデバイスのスキャナに入る。ターゲットデバイスは、ターゲットデバイス又はターゲットタスクに関して異常が存在すると検出された後、異常であるとして退出し得る。スキャン時間間隔は、ターゲティングデバイスの登録されたハートレート値をまとめることによって取得された値の２倍であり得るが、これに限定されない。他の間隔も使用することができ、これは、本開示によって限定されない。

[250] 加えて、ターゲットデバイスで異常が生じると、その異常は、例えば、以下のプロシージャ：ターゲットデバイスで実行されるターゲットタスクのタスクスナップショットを捕捉し、操作信号セットを生成し、且つターゲットタスクを回復するために、ターゲットデバイスがネットワークに接続するまで又は再起動されるまで待つことによって、処理され得る。

[251] 幾つかの実施形態では、スキャン対象オブジェクトがターゲットタスクを含む場合、スキャン対象オブジェクトを処理するために例外処理機能を呼び出すプロセスは、以下のプロシージャ：ターゲットタスクに対応する二状態レコードの実際の状態を異常状態に設定することを含み得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。

[252] 幾つかの実施形態では、確認信号は、応答内容フィールドを含み得、スケジューリングデバイスは、確認信号を取得するためにタスク内容を確認信号の応答内容フィールドに加えるようにして、ターゲットタスクに応じて対応する確認信号を生成し得る。

[253] 幾つかの実施形態では、スケジューリングデバイスは、以下のプロシージャ：確認信号をハートビート応答のデータフィールドに加えること及び確認信号を含むハートビート応答をターゲットデバイスに送信することを行うことにより、確認信号をターゲットデバイスに送信し得る。

[254] 幾つかの実施形態では、ターゲットデバイスによって送信されたハートビートリクエストを受信すると、スケジューリングデバイスは、対応する確認信号がローカルに存在するか否かを検出し得る。対応する確認信号が存在する場合、スケジューリングデバイスは、確認信号を現在のハートビートリクエストのハートビート応答に加え得る。スケジューリングデバイスは、確認信号を含むハートビート応答をターゲットデバイスに送信し得る。幾つかの実施形態では、確認信号を受信すると、ターゲットデバイスは、確認信号が運ぶターゲットタスクのタスク内容をパージングし、且つターゲットタスクを実行し得る。ターゲットデバイスは、スケジューリングデバイスがローカルにある二状態レコードの実際の状態を更新し得るように、タスク同期リクエストにより、ターゲットタスクの実行ステータスをスケジューリングデバイスにさらに送信し得る。

[256] 幾つかの実施形態では、スケジューリングデバイスでデプロイされた状態機械は、ターゲットタスクの二状態の記録及び識別を行い得る。状態機械は、ターゲットタスクのライフサイクルにおける状態遷移を管理するために使用され得る。期待される状態及び実際の状態は、以下：非実行状態、実行状態、実行終了状態、実行失敗状態及び実行一時停止状態の少なくとも１つを含み得る。

[257] 幾つかの実施形態では、スキャナは、タスクに関して維持された二状態における実際の状態及び期待される状態が一致するか否かを検出し得る。予め設定された期間にわたり、期待される状態が実際の状態と異なる（例えば、中間状態が予め設定された期間にわたって持続される（すなわち期待される状態が実際の状態と異なる））場合、例外処理機構がトリガされ得る。代わりに、実際の状態が異常状態を示す場合、例外処理機構がトリガされ得る。

[258] ターゲットデバイスのタスク同期リクエストの受信後、スケジューリングデバイスは、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、ローカルにある二状態レコードのターゲットタスクの実際の状態を更新し得ることが認識される。スケジューリングデバイスは、さらに、ターゲットデバイスが確認信号を受信したことを決定し、ローカルな確認信号を削除し得る。

[259] 異常状態は、クラッシュ、ネットワークの中断などの例外を含み得るが、これらに限定されない。例えば、実際の状態がタスク例外を示し、且つそれが最終状態であることを示す場合、ターゲットタスクが異常であると決定することができ、例外処理機構がトリガされ得る。別の例として、期待される状態が実際の状態と一致しない場合（予め設定された期間にわたり、期待される状態が実際の状態と異なるなど）、ターゲットタスクが異常であると決定することができ、例外処理機構がトリガされ得る。

[260] 実際の状態が期待される状態と一致する場合又はタスク例外が最終状態であると実際の状態が示す場合、過渡状態のターゲットタスクに対して、対応する操作が実行され得ることが認識される。例えば、スケジューリングデバイスは、過渡状態のターゲットタスクを破棄することができるか、又はそれを待ち行列に入れることができる。

[261] 幾つかの実施形態では、スケジューリングデバイスは、過渡状態のターゲットタスクを複数回チェックし得る。ターゲットタスクに対応するターゲットデバイスが正常であるが、ターゲットタスクの実際の状態が、予め設定された期間にわたり、過渡状態であることをスケジューリングデバイスが検出した場合、例外処理機構がトリガされ得る。これは、例えば、ターゲットタスクの実際の状態を失敗に強制的に変更し、ターゲットデバイスとの同期のために変更信号を生成することによって行われ得る。

[262] 幾つかの実施形態では、ターゲットタスクがターゲットデバイスによってプルされると、ターゲットタスクは、スケジューリングデバイスのスキャナに入り、ターゲットタスクのステータスが返された後又は例外処理が終了した後に退出する。スキャン時間間隔は、一定の時間間隔であり得る。

[263] 加えて、ターゲットタスクに関して異常が生じると、以下のプロシージャが行われ得る。ランタイム環境のリンクが正常であるが、ある期間にわたり、ターゲットタスクが中間状態であったと決定された場合、状態が最終状態に変更され得る。すなわち、現在ターゲットタスクが異常状態であることが決定され得る。

[264] 上記のプロシージャの実施に関して、本開示の他の箇所で提供される関連の記載を参照し得ることが認識される。詳細は、ここでは繰り返さない。

[265] 説明を簡単にするために、上記の幾つかの方法実施形態は、一連のアクションの組み合わせとして記載されている場合があることが認識される。しかし、本開示は、ここに記載されるアクションの順序によって限定されないことを当業者は認識するであろう。プロシージャ及びステップは、本開示による幾つかの他の実施形態では、他の順序で又は同時に行われ得る。さらに、本開示に記載される実施形態は、単なる例示であることが認識される。本明細書に記載するプロシージャ及びモジュールは、実際の実施において変更又は調整され得る。

[266] 幾つかの例示的実施形態の上述の記載に基づいて、上記の実施形態による方法は、ソフトウェアと、必要なユニバーサルハードウェアプラットフォームとによって実施され得ることを当業者は認識し得る。これらの方法は、ハードウェアによっても実施され得る。このような理解に基づいて、本開示の技術的解決策は、ソフトウェア製品の形で具現化され得る。ソフトウェア製品は、ＲＯＭ／ＲＡＭ、磁気ディスク又は光ディスクなどの記憶媒体に保存され得る。記憶媒体は、本開示の実施形態で提供される方法を端末デバイスが行うことを可能にする幾つかの命令を含み得る。端末デバイスは、例えば、携帯電話、コンピュータ、サーバ、ネットワークデバイスなどであり得る。

[267] 本開示の幾つかの実施形態によれば、タスク処理方法を実施するように構成されたタスク処理装置がさらに提供される。図１１は、本開示の幾つかの実施形態による例示的タスク処理装置１１００の概略構造図である。図１１に示すように、例示的装置１１００は、取得モジュール１１０２、生成モジュール１１０４及び通信モジュール１１０６を含み得る。

[268] 取得モジュール１１０２は、ターゲットタスクを取得するように構成することができ、ターゲットタスクは、ターゲットデバイスでデプロイされる必要があるタスクである。

[269] 生成モジュール１１０４は、ターゲットタスクに応じて、対応する確認信号を生成するように構成することができ、確認信号は、ターゲットタスクのタスク内容を含む。

[270] 通信モジュール１１０６は、ターゲットデバイスからのハートビートリクエストが受信されると、確認信号をターゲットデバイスに送信するように構成することができる。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。

[271] 取得モジュール１１０２、生成モジュール１１０４及び通信モジュール１１０６は、図２を参照して上記で説明した類似のプロシージャを行い得ることを認識されたい。上記のモジュールは、図２を参照して上記で説明したアプリケーションシナリオと類似のアプリケーションシナリオで適用され得る。さらに、上記のモジュールは、装置の一部として、図１を参照して上記で説明したコンピュータ端末１００などのコンピューティングデバイスで実行し得る。上記のプロシージャの実施に関して、本開示の他の箇所で提供される関連の記載を参照し得ることが認識される。詳細は、ここでは繰り返さない。

[272] 図１２は、本開示の幾つかの実施形態による例示的タスク処理装置１２００の概略構造図である。図１２に示すように、例示的タスク処理装置１２００は、送信モジュール１２０２、受信モジュール１２０４及び実行モジュール１２０６を含み得る。

[273] 送信モジュール１２０２は、ハートビートリクエストをスケジューリングデバイスに送信するように構成され得る。

[274] 受信モジュール１２０４は、スケジューリングデバイスから、ハートビートリクエストに対応する確認信号を受信するように構成され得る。確認信号は、ターゲットタスクのタスク内容を含むことができ、確認信号は、ターゲットタスクの取得後、スケジューリングデバイスによって生成され得る。

[275] 実行モジュール１２０６は、タスク内容に応じてターゲットタスクを実行するように構成され得る。

[276] 送信モジュール１２０２、受信モジュール１２０４及び実行モジュール１２０６は、図７を参照して上記で説明した類似のプロシージャを行い得ることを認識されたい。上記のモジュールは、図７を参照して上記で説明したアプリケーションシナリオと類似のアプリケーションシナリオで適用され得る。さらに、上記のモジュールは、装置の一部として、図１を参照して上記で説明したコンピュータ端末１００などのコンピューティングデバイスで実行し得る。上記のプロシージャの実施に関して、本開示の他の箇所で提供される関連の記載を参照し得ることが認識される。詳細は、ここでは繰り返さない。

[277] 図１３は、本開示の幾つかの実施形態による例示的タスク処理装置１３００の概略構造図である。図１３に示すように、例示的タスク処理装置は、開始モジュール１３０２、スキャンモジュール１３０４及び呼び出しモジュール１３０６を含み得る。

[278] 開始モジュール１３０２は、スキャンスレッドを開始するように構成され得る。

[279] スキャンモジュール１３０４は、スキャン対象オブジェクトをスキャンするために、スキャンスレッドのスキャン論理機能を呼び出し、異常なスキャン対象オブジェクトの数を取得するように構成され得る。

[280] 呼び出しモジュール１３０６は、上記の数が予め設定された閾値以上である場合、スキャン対象オブジェクトを処理するために例外処理機能を呼び出すように構成され得る。

[281] 開始モジュール１３０２、スキャンモジュール１３０４及び呼び出しモジュール１３０６は、図１０を参照して上記で説明した類似のプロシージャを行い得ることを認識されたい。上記のモジュールは、図１０を参照して上記で説明したアプリケーションシナリオと類似のアプリケーションシナリオで適用され得る。さらに、上記のモジュールは、装置の一部として、図１を参照して上記で説明したコンピュータ端末１００などのコンピューティングデバイスで実行し得る。上記のプロシージャの実施に関して、本開示の他の箇所で提供される関連の記載を参照し得ることが認識される。詳細は、ここでは繰り返さない。

[282] 本開示の幾つかの実施形態によれば、タスク処理システムがさらに提供される。タスク処理システムは、図１１〜１３を参照して上記で説明したようなタスク処理装置の少なくとも１つを含み得る。

[283] 本開示の幾つかの実施形態によれば、タスク処理システムは、タスク処理方法を実施するように構成された、図１１を参照して上記で説明したようなタスク処理装置を含み得る。タスク処理装置は、図１１に示すような取得モジュール１１０２、生成モジュール１１０４及び通信モジュール１１０６を含み得る。取得モジュール１１０２は、ターゲットタスクを取得するように構成することができ、ターゲットタスクは、ターゲットデバイスでデプロイされる必要があるタスクである。生成モジュール１１０４は、ターゲットタスクに応じて、対応する確認信号を生成するように構成することができ、確認信号は、ターゲットタスクのタスク内容を含む。通信モジュール１１０６は、ターゲットデバイスからのハートビートリクエストが受信されると、確認信号をターゲットデバイスに送信するように構成することができる。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。

[284] 本開示の幾つかの実施形態によれば、タスク処理システムは、タスク処理方法を実施するように構成された、図１２を参照して上記で説明したようなタスク処理装置を含み得る。タスク処理装置は、図１２に示すような送信モジュール１２０２、受信モジュール１２０４及び実行モジュール１２０６を含み得る。送信モジュール１２０２は、ハートビートリクエストをスケジューリングデバイスに送信するように構成され得る。受信モジュール１２０４は、スケジューリングデバイスから、ハートビートリクエストに対応する確認信号を受信するように構成され得る。確認信号は、ターゲットタスクのタスク内容を含むことができ、確認信号は、ターゲットタスクの取得後、スケジューリングデバイスによって生成され得る。実行モジュール１２０６は、タスク内容に応じてターゲットタスクを実行するように構成され得る。

[285] 本開示の幾つかの実施形態によれば、タスク処理システムは、タスク処理方法を実施するように構成された、図１３を参照して上記で説明したようなタスク処理装置を含み得る。タスク処理装置は、開始モジュール１３０２、スキャンモジュール１３０４及び呼び出しモジュール１３０６を含み得る。開始モジュール１３０２は、スキャンスレッドを開始するように構成され得る。スキャンモジュール１３０４は、スキャン対象オブジェクトをスキャンするために、スキャンスレッドのスキャン論理機能を呼び出し、異常なスキャン対象オブジェクトの数を取得するように構成され得る。呼び出しモジュール１３０６は、上記の数が予め設定された閾値以上である場合、スキャン対象オブジェクトを処理するために例外処理機能を呼び出すように構成され得る。

[286] 上記のプロシージャの実施に関して、本開示の他の箇所で提供される関連の記載を参照し得ることが認識される。詳細は、ここでは繰り返さない。

[287] 本開示の幾つかの実施形態によれば、コンピュータ端末がさらに提供される。コンピュータ端末は、コンピュータ端末グループ内のコンピュータ端末デバイスであり得る。幾つかの実施形態では、コンピュータ端末は、モバイル端末などの端末デバイスにも置き換えられ得る。さらに、コンピュータ端末は、コンピュータネットワーク内の複数のネットワークデバイスの少なくとも１つに位置し得る。

[288] 本開示において上記で説明した方法実施形態は、モバイル端末、コンピュータ端末又は類似のコンピューティングデバイスで実行され得る。幾つかの実施形態では、図１に示すようなコンピュータ端末１００は、回路などのハードウェア要素、又はコンピュータ可読媒体に保存されたコンピュータコードを含むソフトウェア要素を含み得ることを認識されたい。コンピュータ端末１００は、ハードウェア要素及びソフトウェア要素の組み合わせも含み得る。図１は、特定の実施シナリオの一例に過ぎないことが認識される。図１に示される構造は、コンピュータ端末１０に存在し得るコンポーネントのタイプを限定する意図はない。

[289] 幾つかの実施形態では、上記のコンピュータ端末又はコンピュータ端末のプロセッサは、タスク処理方法を行うプロシージャに対応するプログラムコードを実行し得る。プロシージャは、ターゲットタスクを取得することであって、ターゲットタスクは、ターゲットデバイスでデプロイされる必要があるタスクである、取得することと、ターゲットタスクに応じて、対応する確認信号を生成することであって、確認信号は、ターゲットタスクのタスク内容を含む、生成することと、ターゲットデバイスからハートビートリクエストを受信すると、確認信号をターゲットデバイスに送信することとを含み得る。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。

[290] 幾つかの実施形態では、コンピュータ端末のプロセッサは、以下のプロシージャ：ターゲットタスクに対応する二状態レコードを生成することを行うプログラムコードを実行するようにさらに構成され得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。

[291] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：ターゲットデバイスによって送信されたタスク同期リクエストを受信することと、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、二状態レコードの実際の状態を更新することとを行うためのプログラムコードを実行するようにさらに構成され得る。

[292] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かを決定することを行うためのプログラムコードを実行するようにさらに構成され得る。

[293] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：期待される状態が実際の状態と同じであるか否かを検出することを行うためのプログラムコードを実行するようにさらに構成され得る。予め設定された期間にわたり、期待される状態が実際の状態と異なる場合、例外処理機構がトリガされ得る。さらに、プロセッサは、実際の状態が異常状態を示すか否かを検出するようにさらに構成され得る。実際の状態が異常状態を示す場合、例外処理機構がトリガされ得る。

[294] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：コンソールによって送信された第１のタスクを受信することであって、第１のタスクは、スケジューリングポリシー、デプロイメントアドレス及びタスク内容を含む、受信することと、デプロイメントアドレスをパージングして、デプロイメントアドレスによって示されるターゲットデバイスのステータスを検出することと、ターゲットデバイスが正常状態である場合、タスク内容及びスケジューリングポリシーに応じてターゲットタスクを生成することとを行うためのプログラムコードを実行するようにさらに構成され得る。

[295] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：ターゲットデバイスによって送信されたデバイス情報を受信することと、デバイス情報を保存し、且つターゲットデバイスに対応するランタイム環境識別子を生成することと、ランタイム環境識別子をターゲットデバイスに送信することとを行うためのプログラムコードを実行するようにさらに構成され得る。

[296] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：デバイス情報を取得することと、ターゲットタスク及びデバイス情報に応じて確認信号を生成することとを行うためのプログラムコードを実行するようにさらに構成され得る。確認信号は、以下：タスクスナップショット、戻りコード及び消費ステータスの少なくとも１つをさらに含み得る。

[297] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：ターゲットデバイスによって送信されたハートビートリクエストをモニタリングすることにより、ターゲットデバイスが異常であるか否かを決定することを行うためのプログラムコードを実行するようにさらに構成され得る。

[298] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：予め設定された期間にわたり、ハートビートリクエストが受信されていない場合、ターゲットデバイスの接続が切断されていると決定することを行うためのプログラムコードを実行するようにさらに構成され得る。プロセスは、予め設定された対応表から、ターゲットデバイスによって現在実行しているタスクを取得し、且つ現在実行しているタスクの記述情報を確認信号に格納するように構成され得る。ターゲットデバイスによって送信されたハートビートリクエストが受信されると、記述情報を保存した確認信号がターゲットデバイスに送信され得る。

[299] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：ターゲットデバイスによって送信されたタスクステータス較正リクエストを受信することを行うためのプログラムコードを実行するようにさらに構成され得る。ターゲットデバイスがネットワークの中断又は障害から再起動又は回復した場合、タスクのタスクステータスが取得され得る。タスクのタスクステータスを含むタスクステータス較正リクエストが生成され得る。タスクステータス較正リクエストに応じてステータス較正が行われ得る。

[300] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：スケジューリングデバイスにハートビートリクエストを送信することと、スケジューリングデバイスから、ハートビートリクエストに対応する確認信号を受信することであって、確認信号は、ターゲットタスクのタスク内容を含む、受信することと、タスク内容に応じてターゲットタスクを実行することとを行うためのプログラムコードを実行するようにさらに構成され得る。確認信号は、スケジューリングデバイスによって、ターゲットタスクの取得後、生成され得る。

[301] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：タスク同期リクエストをスケジューリングデバイスに送信することを行うためのプログラムコードを実行するようにさらに構成され得る。タスク同期リクエストは、ターゲットタスクの実行ステータスを示すために使用され得る。スケジューリングデバイスは、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、ターゲットタスクに対応する二状態レコードの実際の状態を更新し得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。

[302] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：デバイス情報を取得することと、デバイス情報をスケジューリングデバイスに送信することとを行うためのプログラムコードを実行するようにさらに構成され得る。スケジューリングデバイスは、デバイス情報を保存し、対応するランタイム環境識別子を生成し得る。プロセッサは、スケジューリングデバイスによって送信されたランタイム環境識別子を受信するようにさらに構成され得る。

[303] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：予め構成された頻度に従ってハートビートリクエストをスケジューリングデバイスに送信することを行うためのプログラムコードを実行するようにさらに構成され得る。ハートビートリクエストは、以下：ＣＰＵ使用状況、メモリ使用状況及びディスク使用状況の少なくとも１つに関する情報を含み得る。

[304] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：ネットワークの中断又は障害から再起動又は回復した後、１つ又は複数のタスクのタスクステータスを取得することを行うためのプログラムコードを実行するようにさらに構成され得る。タスクのタスクステータスを含むタスクステータス較正リクエストが生成され得る。スケジューリングデバイスがタスクステータス較正リクエストに応じてステータス較正を行うことができるように、タスクステータス較正リクエストがスケジューリングデバイスに送信され得る。

[305] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：スキャンスレッドを開始することと、スキャン対象オブジェクトをスキャンするために、スキャンスレッドのスキャン論理機能を呼び出すことと、異常なスキャン対象オブジェクトの数を取得することとを行うためのプログラムコードを実行するようにさらに構成され得る。上記の数が予め設定された閾値以上である場合、スキャン対象オブジェクトを処理するために例外処理機能が呼び出され得る。

[306] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：予め設定された対応表から、ターゲットデバイスによって現在実行しているタスクを取得することと、現在実行しているタスクの記述情報を確認信号に格納することと、ターゲットデバイスによって送信されたハートビートリクエストが受信されると、記述情報を格納した確認信号をターゲットデバイスに送信することとを行うためのプログラムコードを実行するようにさらに構成され得る。

[307] 幾つかの実施形態では、プロセッサは、以下のプロシージャ：ターゲットタスクに対応する二状態レコードの実際の状態を異常状態に設定することを行うためのプログラムコードを実行するようにさらに構成され得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。

[308] 図１に示す構造が概略的なものに過ぎないことを当業者は認識するであろう。図１を参照して説明したコンピュータ端末は、スマートフォンなどの端末デバイスでもあり得る。例えば、デバイスは、Android（登録商標）フォン、iOS（登録商標）フォン、タブレットコンピュータ、ハンドヘルドコンピュータ、モバイルインターネットデバイス（ＭＩＤ）、ＰＡＤなどであり得る。図１は、上記の電子装置の構造を限定しない。例えば、コンピュータ端末１００は、ネットワークインタフェース及びディスプレイ装置などの図１に示されるコンポーネントよりも多い又は少ないコンポーネントを含み得る。コンピュータ端末１００は、図１に示す構成と異なる構成も有し得る。

[309] 方法実施形態における上記で説明したプロシージャの全て又は一部は、端末デバイスに関連付けられたハードウェアに命令するプログラムにより実施され得ることが認識される。プログラムは、コンピュータ可読記憶媒体に保存され得る。記憶媒体は、フラッシュメモリディスク、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク、光ディスクなどを含み得る。

[310] 本開示の幾つかの実施形態によれば、記憶媒体がさらに提供される。例えば、記憶媒体は、上記のようなタスク処理方法に対応するプログラムコードを格納するように構成され得る。幾つかの実施形態では、任意選択で、記憶媒体は、コンピュータネットワーク内のコンピュータ端末グループの何れかのコンピュータ端末に位置し得るか、又はモバイル端末グループの何れかのモバイル端末に位置し得る。

[311] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：ターゲットタスクを取得することであって、ターゲットタスクは、ターゲットデバイスでデプロイされる必要があるタスクである、取得することと、ターゲットタスクに応じて、対応する確認信号を生成することであって、確認信号は、ターゲットタスクのタスク内容を含む、生成することと、ターゲットデバイスからハートビートリクエストを受信すると、確認信号をターゲットデバイスに送信することとに対応するプログラムコードを格納するように構成され得る。ターゲットデバイスは、タスク内容に応じてターゲットタスクを実行し得る。

[312] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：ターゲットタスクに対応する二状態レコードを生成することに対応するプログラムコードを格納するように構成され得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。

[313] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：ターゲットデバイスによって送信されたタスク同期リクエストを受信することと、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、二状態レコードの実際の状態を更新することとに対応するプログラムコードを格納するように構成され得る。

[314] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：二状態レコードをスキャンすることにより、ターゲットタスクが異常であるか否かを決定することに対応するプログラムコードを格納するように構成され得る。

[315] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：期待される状態が実際の状態と同じであるか否かを検出することに対応するプログラムコードを格納するように構成され得る。予め設定された期間にわたり、期待される状態が実際の状態と異なる場合、例外処理機構がトリガされ得る。さらに、プロセッサは、実際の状態が異常状態を示すか否かを検出するようにさらに構成され得る。実際の状態が異常状態を示す場合、例外処理機構がトリガされ得る。

[316] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：コンソールによって送信された第１のタスクを受信することであって、第１のタスクは、スケジューリングポリシー、デプロイメントアドレス及びタスク内容を含む、受信することと、デプロイメントアドレスをパージングして、デプロイメントアドレスによって示されるターゲットデバイスのステータスを検出することと、ターゲットデバイスが正常状態である場合、タスク内容及びスケジューリングポリシーに応じてターゲットタスクを生成することとに対応するプログラムコードを格納するように構成され得る。

[317] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：ターゲットデバイスによって送信されたデバイス情報を受信することと、デバイス情報を保存し、且つターゲットデバイスに対応するランタイム環境識別子を生成することと、ランタイム環境識別子をターゲットデバイスに送信することとに対応するプログラムコードを格納するように構成され得る。

[318] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：デバイス情報を取得することと、ターゲットタスク及びデバイス情報に応じて確認信号を生成することとに対応するプログラムコードを格納するように構成され得る。確認信号は、以下：タスクスナップショット、戻りコード及び消費ステータスの少なくとも１つをさらに含み得る。

[319] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：ターゲットデバイスによって送信されたハートビートリクエストをモニタリングすることにより、ターゲットデバイスが異常であるか否かを決定することに対応するプログラムコードを格納するように構成され得る。

[320] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：予め設定された期間にわたり、ハートビートリクエストが受信されていない場合、ターゲットデバイスの接続が切断されていると決定することに対応するプログラムコードを格納するように構成され得る。記憶媒体は、以下のプロシージャ：予め設定された対応表から、ターゲットデバイスによって現在実行しているタスクを取得することと、現在実行しているタスクの記述情報を確認信号に格納することとに対応するプログラムコードを格納するようにさらに構成され得る。ターゲットデバイスによって送信されたハートビートリクエストが受信されると、記述情報を格納した確認信号がターゲットデバイスに送信され得る。

[321] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：ターゲットデバイスによって送信されたタスクステータス較正リクエストを受信することに対応するプログラムコードを格納するように構成され得る。ターゲットデバイスがネットワークの中断又は障害から再起動又は回復した際、１つ又は複数のタスクのタスクステータスが取得され得る。タスクのタスクステータスを含むタスクステータス較正リクエストが生成され得る。タスクステータス較正リクエストに応じてステータス較正が行われ得る。

[322] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：スケジューリングデバイスにハートビートリクエストを送信することと、スケジューリングデバイスから、ハートビートリクエストに対応する確認信号を受信することであって、確認信号は、ターゲットタスクのタスク内容を含む、受信することと、タスク内容に応じてターゲットタスクを実行することとに対応するプログラムコードを格納するように構成され得る。確認信号は、スケジューリングデバイスによって、ターゲットタスクの取得後、生成され得る。

[323] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：タスク同期リクエストをスケジューリングデバイスに送信することに対応するプログラムコードを格納するように構成され得る。タスク同期リクエストは、ターゲットタスクの実行ステータスを示すために使用され得る。スケジューリングデバイスは、タスク同期リクエストに示されるターゲットタスクの実行ステータスに応じて、ターゲットタスクに対応する二状態レコードの実際の状態を更新し得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。

[324] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：デバイス情報を取得することと、デバイス情報をスケジューリングデバイスに送信することとに対応するプログラムコードを格納するように構成され得る。スケジューリングデバイスは、デバイス情報を保存し、対応するランタイム環境識別子を生成し得る。ランタイム環境識別子は、スケジューリングデバイスによって返され得る。

[325] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：予め構成された頻度に従ってハートビートリクエストをスケジューリングデバイスに送信することに対応するプログラムコードを格納するように構成され得る。ハートビートリクエストは、以下：ＣＰＵ使用状況、メモリ使用状況及びディスク使用状況の少なくとも１つに関する情報を含み得る。

[326] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：ネットワークの中断又は障害から再起動又は回復した後、１つ又は複数のタスクのタスクステータスを取得することに対応するプログラムコードを格納するように構成され得る。タスクのタスクステータスを含むタスクステータス較正リクエストが生成され得る。スケジューリングデバイスがタスクステータス較正リクエストに応じてステータス較正を行うことができるように、タスクステータス較正リクエストがスケジューリングデバイスに送信され得る。

[327] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：スキャンスレッドを開始することと、スキャン対象オブジェクトをスキャンするために、スキャンスレッドのスキャン論理機能を呼び出すことと、異常なスキャン対象オブジェクトの数を取得することとに対応するプログラムコードを格納するように構成され得る。上記の数が予め設定された閾値以上である場合、スキャン対象オブジェクトを処理するために例外処理機能が呼び出され得る。

[328] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：予め設定された対応表から、ターゲットデバイスによって現在実行しているタスクを取得することと、現在実行しているタスクの記述情報を確認信号に格納することと、ターゲットデバイスによって送信されたハートビートリクエストが受信されると、記述情報を格納した確認信号をターゲットデバイスに送信することとに対応するプログラムコードを格納するように構成され得る。

[329] 幾つかの実施形態では、記憶媒体は、以下のプロシージャ：ターゲットタスクに対応する二状態レコードの実際の状態を異常状態に設定することに対応するプログラムコードを格納するように構成され得る。二状態レコードは、期待される状態及び実際の状態を含み得る。期待される状態は、ターゲットタスクの予測される実行の状態を示すために使用され得る。実際の状態は、ターゲットタスクの実際の実行の状態を示すために使用され得る。

[330] 上記の記載では、本明細書で使用される参照符号は、単なる説明目的で使用されるものである。数字は、必須の順序を表すものではない。さらに、異なる実施形態は、本開示の異なる態様に焦点を当て得る。幾つかの実施形態で詳細に説明されていない部分について、他の実施形態における関連に記載が参照され得る。

[331] 本開示に提供される上記の実施形態に基づいて、技術的解決策が他の方法で実施され得ることが認識される。例えば、上記の装置実施形態は、概略的なものに過ぎない。ユニットの分割は、論理機能の例示的分割に過ぎない。実際の実施では、特定のシナリオに適用可能な他の分割の態様が存在し得る。さらに、複数のユニット又はコンポーネントが組み合わされ得るか、又は別のシステムに組み込まれ得る。幾つかの特徴は、幾つかの実施形態では、削除又は変更され得る。加えて、異なるユニット又はモジュール間の表示された又は論じられた結合、直接結合又は通信接続は、幾つかのインタフェースを使用して実施され得る。ユニット又はモジュール間の間接結合又は通信接続は、電気的形態又は他の形態で達成され得る。

[332] 分離した部分として記載されるユニットは、物理的に分離していても又は物理的に分離していなくてもよい。ユニットとして記載される部分は、物理的ユニットであっても又は物理的ユニットでなくてもよい。部分又はユニットは、同じ場所に位置し得るか、又は複数のネットワークユニットに分散され得る。本開示の目的及び解決策は、実際の要件に応じて、上記の実施形態に記載されるユニットの一部又は全てを選択することによって実施され得る。

[333] 加えて、本開示の実施形態に記載される様々な機能ユニットは、１つの処理ユニットに統合され得る。各ユニットが物理的に単独でも存在し得、且つ２つ以上のユニットが１つのユニットにも統合され得る。統合ユニットは、ハードウェアの形態で実施され得、且つソフトウェア機能ユニットの形態でも実施され得る。

[334] 統合ユニットは、ソフトウェア機能ユニットの形態で実施され、且つ独立した製品として販売又は使用される場合、コンピュータ可読記憶媒体に保存され得る。このような理解に基づいて、本開示の技術的解決策又はその一部は、ソフトウェア製品の形態で実施され得る。コンピュータソフトウェア製品は、記憶媒体に保存され得る。記憶媒体は、本開示の方法実施形態におけるプロシージャの全て又は一部を実行するようにコンピュータデバイスに命令する幾つかの命令を含み得る。コンピュータデバイスは、パーソナルコンピュータ、サーバ、ネットワークデバイスなどであり得る。記憶媒体は、ＵＳＢフラッシュディスク、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、モバイルハードディスク、磁気ディスク、光ディスク又はプログラムコードを保存することができる他の媒体を含み得る。例えば、記憶媒体は、非一時的コンピュータ可読媒体であり得る。非一時的媒体の一般的形態には、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、半導体ドライブ、磁気テープ又は任意の他の磁気データ記憶媒体、ＣＤ−ＲＯＭ、任意の他の光学式データ記憶媒体、孔のパターンを有する物理的媒体、ＲＡＭ、ＰＲＯＭ及びＥＰＲＯＭ、ＦＬＡＳＨ(登録商標）−ＥＰＲＯＭ又は任意の他のフラッシュメモリ、ＮＶＲＡＭ、任意の他のメモリチップ又はカートリッジ及びこれらのネットワーク化されたバージョンが含まれる。

[335] 上記の記載は、本開示で提供される例示的実施形態に過ぎないことが認識される。本開示に一致して、当業者は、本開示の原理から逸脱することなく、実際の実施において変形形態及び変更形態を取り入れることができる。このような変形形態及び変更形態は、全て本開示の保護範囲に入るものとする。

Claims (47)

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. 前記複数のオブジェクトは、ネットワークデバイス及びタスクの少なくとも一方を含む、請求項２５に記載の方法。
27. 前記複数のオブジェクトは、ネットワークデバイスを含み、及び前記複数のオブジェクトを処理するために前記例外処理機能を前記呼び出すことは、
    予め設定された対応表から、前記ネットワークデバイスで現在実行しているタスクを取得することと、
    前記取得されたタスクの記述情報を含む確認信号を生成することと、
    ハートビートリクエストを前記ネットワークデバイスから受信することに応答して、前記確認信号を前記ネットワークデバイスに送信することと
    をさらに含む、請求項２５に記載の方法。
28. 前記複数のオブジェクトは、タスクを含み、及び前記複数のオブジェクトを処理するために前記例外処理機能を前記呼び出すことは、
    前記タスクが異常であると決定されることに応答して、前記タスクの二状態レコードにおける実際の状態を異常状態に設定することであって、前記二状態レコードは、前記タスクの前記実際の状態及び期待される状態を含む、設定すること
    をさらに含む、請求項２５又は２７に記載の方法。
29. タスクスケジューリング装置であって、
    命令の組を保存するメモリと、
    前記命令の組を実行して、前記タスクスケジューリング装置に、
    ターゲットデバイスに対してデプロイされるターゲットタスクを取得することと、
    前記ターゲットタスクに応じて確認信号を生成することであって、前記確認信号は、前記ターゲットタスクのタスク内容を示す、生成することと、
    ハートビートリクエストが前記ターゲットデバイスから受信されることに応答して、前記確認信号を前記ターゲットデバイスに送信することと
    を行わせるように構成されたプロセッサと
    を含むタスクスケジューリング装置。
30. ネットワーク装置であって、
    命令の組を保存するメモリと、
    前記命令の組を実行して、前記ネットワーク装置に、
    ハートビートリクエストをスケジューリングデバイスに送信することと、
    前記スケジューリングデバイスから、前記ハートビートリクエストに対応する確認信号を受信することであって、前記確認信号は、ターゲットタスクのタスク内容を示す、受信することと、
    前記タスク内容に応じて前記ターゲットタスクを実行することと
    を行わせるように構成されたプロセッサと
    を含むネットワーク装置。
31. タスクスケジューリング装置であって、
    命令の組を保存するメモリと、
    前記命令の組を実行して、前記タスクスケジューリング装置に、
    スキャンスレッドを開始することと、
    複数のオブジェクトをスキャンするために、前記スキャンスレッドのスキャン論理機能を呼び出すことと、
    前記複数のオブジェクトが１つ又は複数の異常なオブジェクトを含むか否かを決定することと、
    決定された異常なオブジェクトの数が、予め設定された閾値以上であることに応答して、前記複数のオブジェクトを処理するために例外処理機能を呼び出すことと
    を行わせるように構成されたプロセッサと
    を含むタスクスケジューリング装置。
32. 請求項２９に記載のタスク処理装置を含むタスク処理システム。
33. プログラムに含まれる命令を実行するように構成されたプロセッサであって、前記命令が実行されると、前記プログラムは、前記プロセッサにタスク処理方法を行わせ、前記方法は、
    ターゲットデバイスに対してデプロイされるターゲットタスクを取得することと、
    前記ターゲットタスクに応じて確認信号を生成することであって、前記確認信号は、前記ターゲットタスクのタスク内容を示す、生成することと、
    ハートビートリクエストが前記ターゲットデバイスから受信されることに応答して、前記確認信号を前記ターゲットデバイスに送信することと
    を含む、プロセッサ。
34. コンピュータの少なくとも１つのプロセッサによって実行可能である、前記コンピュータにタスク処理方法を行わせる命令の組を格納する非一時的コンピュータ可読媒体であって、前記方法は、
    ターゲットデバイスに対してデプロイされるターゲットタスクを取得することと、
    前記ターゲットタスクに応じて確認信号を生成することであって、前記確認信号は、前記ターゲットタスクのタスク内容を示す、生成することと、
    ハートビートリクエストが前記ターゲットデバイスから受信されることに応答して、前記確認信号を前記ターゲットデバイスに送信することと
    を含む、非一時的コンピュータ可読媒体。
35. 前記コンピュータの前記少なくとも１つのプロセッサによって実行可能な前記命令の組は、前記コンピュータに、
    前記ターゲットタスクに対応する二状態レコードを生成することであって、前記二状態レコードは、前記ターゲットタスクの期待される状態及び実際の状態を含む、生成することと、
    前記ターゲットデバイスによって送信されたタスク同期リクエストを受信することであって、前記タスク同期リクエストは、前記ターゲットタスクの実行ステータスを示す、受信することと、
    前記ターゲットタスクの前記実行ステータスに応じて前記二状態レコードを更新することと
    をさらに行わせる、請求項３４に記載の非一時的コンピュータ可読媒体。
36. 前記コンピュータの前記少なくとも１つのプロセッサによって実行可能な前記命令の組は、前記コンピュータに、
    前記二状態レコードをスキャンすることにより、前記ターゲットタスクが異常であるか否かを決定すること
    をさらに行わせる、請求項３５に記載の非一時的コンピュータ可読媒体。
37. 前記コンピュータの前記少なくとも１つのプロセッサによって実行可能な前記命令の組は、前記コンピュータに、
    前記期待される状態が前記実際の状態と同じであるか否かを決定し、且つ予め設定された期間にわたり、前記期待される状態が前記実際の状態と異なることに応答して、例外処理機構をトリガすること、又は
    前記実際の状態が異常状態を示すか否かを決定し、且つ前記実際の状態が異常状態を示すことに応答して、前記例外処理機構をトリガすること
    をさらに行わせる、請求項３６に記載の非一時的コンピュータ可読媒体。
38. 前記ターゲットタスクを前記取得することは、
    コンソールによって送信された第１のタスクを受信することであって、前記第１のタスクは、スケジューリングポリシー、デプロイメントアドレス及び前記第１のタスクの内容を含み、前記デプロイメントアドレスは、前記ターゲットデバイスを指す、受信することと、
    前記デプロイメントアドレスをパージングし、且つ前記デプロイメントアドレスに基づいて前記ターゲットデバイスの状態を決定することと、
    前記ターゲットデバイスが正常状態であることに応答して、前記スケジューリングポリシー及び前記第１のタスクの前記内容に応じて前記ターゲットタスクを生成することと
    を含む、請求項３４〜３７の何れか一項に記載の非一時的コンピュータ可読媒体。
39. 前記ターゲットタスクを前記取得することの前に、前記コンピュータの前記少なくとも１つのプロセッサによって実行可能な前記命令の組は、前記コンピュータに、
    前記ターゲットデバイスによって送信されたデバイス情報を受信することと、
    前記デバイス情報に基づいて、前記ターゲットデバイスに対応するランタイム環境識別子を生成することと、
    前記ランタイム環境識別子を前記ターゲットデバイスに送信することと
    をさらに行わせる、請求項３４〜３８の何れか一項に記載の非一時的コンピュータ可読媒体。
40. 前記ターゲットタスクに応じて前記確認信号を前記生成することは、
    前記ターゲットタスク及び前記デバイス情報に応じて前記確認信号を生成すること
    を含む、請求項３９に記載の非一時的コンピュータ可読媒体。
41. 前記デバイス情報は、中央処理装置（ＣＰＵ）、メモリサイズ、ディスクサイズ、ネットワークリンク、ソフトウェア開発キット（ＳＤＫ）バージョン番号、実行エンジン、アドレス、同期時間間隔及び構成の少なくとも１つの情報を含む、請求項３９又は４０に記載の非一時的コンピュータ可読媒体。
42. 前記コンピュータの前記少なくとも１つのプロセッサによって実行可能な前記命令の組は、前記コンピュータに、
    前記ターゲットデバイスによって送信された前記ハートビートリクエストをモニタリングすることにより、前記ターゲットデバイスが異常であるか否かを決定すること
    をさらに行わせる、請求項３４〜４１の何れか一項に記載の非一時的コンピュータ可読媒体。
43. 前記コンピュータの前記少なくとも１つのプロセッサによって実行可能な前記命令の組は、前記コンピュータに、
    予め設定された期間にわたり、前記ハートビートリクエストが受信されていないことに応答して、前記ターゲットデバイスの接続が切断されていると決定することと、
    予め設定された対応表から、前記ターゲットデバイスで現在実行している第１のタスクを取得することと、
    前記第１のタスクの記述情報を前記確認信号に格納することと、
    次のハートビートリクエストが前記ターゲットデバイスから受信されることに応答して、前記確認信号を前記ターゲットデバイスに送信することと
    をさらに行わせる、請求項４２に記載の非一時的コンピュータ可読媒体。
44. 前記確認信号は、応答内容フィールドを含み、及び前記ターゲットタスクに応じて前記確認信号を前記生成することは、
    前記タスク内容を前記応答内容フィールドに加えること
    を含む、請求項３４〜４３の何れか一項に記載の非一時的コンピュータ可読媒体。
45. 前記確認信号を前記ターゲットデバイスに前記送信することは、
    前記確認信号をハートビート応答のデータフィールドに加えることと、
    前記確認信号を含む前記ハートビート応答を前記ターゲットデバイスに送信することと
    を含む、請求項３４〜４４の何れか一項に記載の非一時的コンピュータ可読媒体。
46. 前記コンピュータの前記少なくとも１つのプロセッサによって実行可能な前記命令の組は、前記コンピュータに、
    前記ターゲットデバイスによって実行される１つ又は複数のタスクに関するタスクステータス較正リクエストを前記ターゲットデバイスから受信することであって、前記タスクステータス較正リクエストは、前記ターゲットデバイスが異常状態から再起動又は回復した後の前記１つ又は複数のタスクの実行ステータスを示す、受信することと、
    前記タスクステータス較正リクエストに応じて前記１つ又は複数のタスクの前記実行ステータスを較正することと
    をさらに行わせる、請求項３４〜４５の何れか一項に記載の非一時的コンピュータ可読媒体。
47. 前記ハートビートリクエストは、ＣＰＵ使用状況、メモリ使用状況、ディスク使用状況及び前記ターゲットデバイスによって実行される１つ又は複数のタスクの実行ステータスの少なくとも１つの情報を含む、請求項３４〜４６の何れか一項に記載の非一時的コンピュータ可読媒体。

Images