特表 2024-528763 デバイス機能低下型故障を早期に警報するための産業用モノのインターネット、方法及び媒体

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-08-01

(54)【発明の名称】デバイス機能低下型故障を早期に警報するための産業用モノのインターネット、方法及び媒体

(51)【国際特許分類】

   G06Q 50/04 20120101AFI20240725BHJP

【ＦＩ】

G06Q50/04

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023547530

(86)(22)【出願日】2022-07-15

(85)【翻訳文提出日】2023-08-04

(86)【国際出願番号】 CN2022106031

(87)【国際公開番号】W WO2024011601

(87)【国際公開日】2024-01-18

(81)【指定国・地域】

(71)【出願人】

【識別番号】519031575

【氏名又は名称】成都秦川物聯網科技股▲ふん▼有限公司

【氏名又は名称原語表記】ＣＨＥＮＧＤＵ ＱＩＮＣＨＵＡＮ ＩＯＴ ＴＥＣＨＮＯＬＯＧＹ ＣＯ．， ＬＴＤ．

【住所又は居所原語表記】Ｎｏ．９３１， Ｎａｎｓｉ Ｒｏａｄ， Ｅｃｏｎｏｍｉｃ Ｄｅｖｅｌｏｐｍｅｎｔ Ｚｏｎｅ， Ｌｏｎｇｑｕａｎｙｉ Ｄｉｓｔｒｉｃｔ， Ｃｈｅｎｇｄｕ， Ｓｉｃｈｕａｎ， ６１０１００ Ｃｈｉｎａ

(74)【代理人】

【識別番号】110002262

【氏名又は名称】ＴＲＹ国際弁理士法人

(72)【発明者】

【氏名】邵 澤華

(72)【発明者】

【氏名】権 亜強

(72)【発明者】

【氏名】呉 岳飛

(72)【発明者】

【氏名】陳 于浩

(72)【発明者】

【氏名】周 ▲じゅん▼▲いぇん▼

【テーマコード（参考）】

5L050

【Ｆターム（参考）】

5L050CC03

(57)【要約】

本明細書の実施例はデバイス機能低下型故障を早期に警報するための産業用モノのインターネットを提供し、該産業用モノのインターネットは管理プラットフォームを備え、前記管理プラットフォームは、デバイスが所定時間帯に実行する少なくとも１つの生産タスクの実行状況を取得すること、前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断すること、前記デバイスに前記機能低下型故障があることに応答して、早期警報を出して前記デバイスに対して対応修復を行うこと、を実行するように構成される。

【特許請求の範囲】

【請求項1】

デバイス機能低下型故障を早期に警報するための産業用モノのインターネットであって、
管理プラットフォームを備え、前記管理プラットフォームは、
デバイスが所定時間帯に実行する少なくとも１つの生産タスクの実行状況を取得すること、
前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断すること、
前記デバイスに前記機能低下型故障があることに応答して、早期警報を出して前記デバイスに対して対応修復を行うこと、を実行するように構成されることを特徴とするデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項2】

ユーザープラットフォーム、サービスプラットフォーム、センシングネットワークプラットフォーム及びオブジェクトプラットフォームを更に備え、前記ユーザープラットフォーム、前記サービスプラットフォーム、前記管理プラットフォーム、前記センシングネットワークプラットフォーム及び前記オブジェクトプラットフォームが上から下まで順次対話し、
前記サービスプラットフォームと管理プラットフォームがいずれもフロントサブプラットフォーム型配置を用い、前記センシングネットワークプラットフォームが独立型配置を用い、前記フロントサブプラットフォーム型配置とは、対応するプラットフォームに１つのメインプラットフォーム及び複数のサブプラットフォームが設置され、複数のサブプラットフォームがそれぞれ下位層プラットフォームから送信された異なるタイプ又は異なる受信対象のデータを記憶して処理し、１つのメインプラットフォームが複数のサブプラットフォームのデータをまとめて記憶して処理して、データを上位層プラットフォームに伝送することを意味し、前記独立型配置とは、センシングネットワークプラットフォームが異なるオブジェクトプラットフォームのデータに対して異なるサブプラットフォームによりデータ記憶、データ処理及び／又はデータ伝送を行うことを意味し、前記オブジェクトプラットフォームがスマート製造された製造装置として設定され、
製造装置は製造を実行するとき、単品製造パラメータデータを対応するセンシングネットワークプラットフォームのサブプラットフォームにアップロードし、単品製造パラメータデータが該製造装置による単品製造時の総消費時間データを少なくとも含み、
センシングネットワークプラットフォームのサブプラットフォームは単品製造パラメータデータを管理プラットフォームの識別可能なデータファイルに変換して対応する管理プラットフォームのサブプラットフォームに送信し、
管理プラットフォームのサブプラットフォームはデータファイルを受信して総消費時間データを抽出し、総消費時間データに基づいて単品製造時間の順序に従って隣接する２つの総消費時間データの時間差を順次計算し、すべての時間差を単品製造時間の順序に従って順に順序付けて時間差データセットを形成し、且つデータファイル、時間差データセットを記憶して管理プラットフォームのメインプラットフォームに送信し、
管理プラットフォームのメインプラットフォームは、時間差データセットを受信した後に時間差データセットに基づいてデバイス機能低下型故障分析を行い、且つ、
分析結果が正常である場合、管理プラットフォームのメインプラットフォームが時間差データセットを削除して、改めてアップロードした時間差データセットの分析を待ち、
又は、分析結果が異常である場合、データファイル、異常結果データ及び時間差データセットを分析データにマージして対応するサービスプラットフォームのサブプラットフォームにアップロードすること、を分析結果に基づいて実行し、
サービスプラットフォームのサブプラットフォームは分析データを受信してデータファイルに基づいて異常時間ノードを取得し、異常時間ノード、異常結果データ及び時間差データセットをパケット化データとしてサービスプラットフォームのメインプラットフォームに送信し、
サービスプラットフォームのメインプラットフォームはパケット化データを受信して記憶し、パケット化データにおける異常結果データに基づいて故障等級分けを行って、等級分けされた対応する等級情報をユーザープラットフォームに送信することを特徴とする請求項１に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項3】

管理プラットフォームのメインプラットフォームが時間差データセットを受信した後、時間差データセットに基づいてデバイス機能低下型故障分析を行うことは、具体的に、
管理プラットフォームのメインプラットフォームが時間差データセットを受信した後、単品製造時間の順序に従って隣接する２つの時間差の絶対値の差分を順次計算するように選択することと、
差分に負値が現れ、且つ差分に負値が連続的に現れる回数が管理プラットフォームのメインプラットフォームに設定された閾値よりも大きい場合、デバイス機能低下型故障があると判定し、分析結果が異常であることを決定し、そうではない場合、デバイス機能低下型故障がないと判定し、分析結果が正常であることを決定することと、を含むことを特徴とする請求項２に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項4】

前記管理プラットフォームのメインプラットフォームに閾値テーブルが記憶され、各管理プラットフォームのサブプラットフォームがいずれも閾値テーブルにおける唯一の閾値に対応し、
デバイス機能低下型故障分析を行うとき、管理プラットフォームのメインプラットフォームが各管理プラットフォームのサブプラットフォームの時間差データセットを分析し、閾値テーブルにおける対応閾値及び差分に負値が連続的に現れる回数を呼び出して差分計算を行うことを特徴とする請求項３に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項5】

サービスプラットフォームのサブプラットフォームが分析データを受信してデータファイルに基づいて異常時間ノードを取得し、異常時間ノード、異常結果データ及び時間差データセットをパケット化データとしてサービスプラットフォームのメインプラットフォームに送信することは、具体的に、
前記単品製造パラメータデータが製造装置による単品製造時の製造開始時刻を更に含み、製造装置が単品製造パラメータデータをアップロードするとき、単品製造時の製造開始時刻と総消費時間データを関連付けて併せてアップロードすることと、
サービスプラットフォームのサブプラットフォームが分析データを受信してからデータファイルを抽出し、時間差データセットにおける負値が現れる差分に対応する時間差を抽出し、且つ該時間差に基づいて対応する複数の総消費時間データを取得することと、
複数の総消費時間データに基づいて、複数の総消費時間データに対応する複数の製造開始時刻を取得することと、
単品製造時間の順序に従って複数の製造開始時刻を順に順序付けて前記異常時間ノードを形成することと、を含むことを特徴とする請求項３に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項6】

前記ユーザープラットフォームが等級情報を取得した後、等級情報に基づいて、前記ユーザープラットフォームは点検修理命令をサービスプラットフォームのメインプラットフォームに送信し、点検修理命令が１つの自己修復サブ命令を少なくとも含み、
サービスプラットフォームのメインプラットフォームは点検修理命令を受信して点検修理命令に基づいて命令解析を行って、少なくとも１つの自己修復サブ命令を取得し、少なくとも１つの自己修復サブ命令を対応するサービスプラットフォームのサブプラットフォームに送信し、
サービスプラットフォームのサブプラットフォームは自己修復サブ命令を受信して自己修復サブ命令を管理プラットフォームのメインプラットフォームに送信し、
管理プラットフォームのメインプラットフォームは自己修復サブ命令を受信し、且つ対応する命令コードパケットを取得し、命令コードパケットと自己修復サブ命令を関連付けてから管理プラットフォームのサブプラットフォームに併せて送信し、前記命令コードパケットが管理プラットフォームのメインプラットフォームに予め記憶され、
管理プラットフォームのサブプラットフォームは命令コードパケット及び自己修復サブ命令を受信してから対応するセンシングネットワークプラットフォームのサブプラットフォームに送信し、
センシングネットワークプラットフォームのサブプラットフォームは命令コードパケット及び自己修復サブ命令をオブジェクトプラットフォームの識別可能なコンフィギュレーションファイルに変換してから対応するオブジェクトプラットフォームに送信し、前記オブジェクトプラットフォームが自己修復サブ命令に基づいて命令コードパケットにおける命令コードデータを呼び出して自己修復を実行することを特徴とする請求項２に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項7】

点検修理命令が異なる実行時刻に対応する場合、サービスプラットフォームのメインプラットフォームが解析後に実行時刻を対応する自己修復サブ命令に書き込み、
前記オブジェクトプラットフォームが自己修復サブ命令に基づいて命令コードパケットにおける命令コードデータを呼び出した後、対応する実行時刻で自己修復を実行することを特徴とする請求項６に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項8】

前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することは、
前記デバイスが各生産タスクを実行する実際の消費時間を取得することと、
前記各生産タスクを実行する前記実際の消費時間及び対応する標準消費時間に基づいて、複数の消費時間差を決定することと、
前記複数の消費時間差に基づいて、前記デバイスに前記機能低下型故障があるかどうかを決定することと、を含むことを特徴とする請求項１に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項9】

前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することは、
前記少なくとも１つの生産タスクの前記産出製品における合格製品の比率に基づいて前記少なくとも１つの生産タスクのうちの各生産タスクの実際の合格率を決定することと、
前記各生産タスクの前記実際の合格率及び対応する標準合格率に基づいて前記デバイスの複数の合格度を決定することと、
前記複数の合格度に基づいて、前記デバイスに機能低下型故障があるかどうかを決定することと、を含むことを特徴とする請求項１に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項10】

前記複数の合格度に基づいて、前記デバイスに機能低下型故障があるかどうかを決定することは、
故障確率予測モデルにより故障確率を予測し、前記故障確率予測モデルが機械学習モデルであり、前記故障確率予測モデルがパラメータ拡張層及び確率予測層を含み、前記パラメータ拡張層が前記複数の合格度に基づいて前記デバイスの第１特徴ベクトルを決定するためのものであり、前記確率予測層が前記第１特徴ベクトル及び前記デバイスのデバイス情報に基づいて前記デバイスの前記故障確率を予測するためのものであることと、
前記故障確率が確率閾値よりも大きいことに応答して、前記デバイスに前記機能低下型故障があることを決定することと、を含むことを特徴とする請求項９に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項11】

デバイス機能低下型故障を早期に警報するための産業用モノのインターネットの制御方法であって、
デバイス機能低下型故障を早期に警報するための産業用モノのインターネットの管理プラットフォームにより実現され、
前記制御方法は、
デバイスが所定時間帯に実行する少なくとも１つの生産タスクの実行状況を取得することと、
前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することと、
前記デバイスに前記機能低下型故障があることに応答して、早期警報を出して前記デバイスに対して対応修復を行うことと、を含むことを特徴とするデバイス機能低下型故障を早期に警報するための産業用モノのインターネットの制御方法。

【請求項12】

前記デバイス機能低下型故障を早期に警報するための産業用モノのインターネットは上から下まで順次対話するユーザープラットフォーム、サービスプラットフォーム、管理プラットフォーム、センシングネットワークプラットフォーム及びオブジェクトプラットフォームを備え、
前記サービスプラットフォームと管理プラットフォームがいずれもフロントサブプラットフォーム型配置を用い、前記センシングネットワークプラットフォームが独立型配置を用い、前記フロントサブプラットフォーム型配置とは、対応するプラットフォームに１つのメインプラットフォーム及び複数のサブプラットフォームが設置され、複数のサブプラットフォームがそれぞれ下位層プラットフォームから送信された異なるタイプ又は異なる受信対象のデータを記憶して処理し、１つのメインプラットフォームが複数のサブプラットフォームのデータをまとめて記憶して処理して、データを上位層プラットフォームに伝送することを意味し、前記独立型配置とは、センシングネットワークプラットフォームが異なるオブジェクトプラットフォームのデータに対して異なるサブプラットフォームによりデータ記憶、データ処理及び／又はデータ伝送を行うことを意味し、前記オブジェクトプラットフォームがスマート製造された製造装置として設定され、
前記制御方法は、
製造装置は製造を実行するとき、単品製造パラメータデータを対応するセンシングネットワークプラットフォームのサブプラットフォームにアップロードし、単品製造パラメータデータが該製造装置による単品製造時の総消費時間データを少なくとも含むことと、
センシングネットワークプラットフォームのサブプラットフォームは単品製造パラメータデータを管理プラットフォームの識別可能なデータファイルに変換して対応する管理プラットフォームのサブプラットフォームに送信することと、
管理プラットフォームのサブプラットフォームはデータファイルを受信して総消費時間データを抽出し、総消費時間データに基づいて単品製造時間の順序に従って隣接する２つの総消費時間データの時間差を順次計算し、すべての時間差を単品製造時間の順序に従って順に順序付けて時間差データセットを形成し、且つデータファイル、時間差データセットを記憶して管理プラットフォームのメインプラットフォームに送信することと、
管理プラットフォームのメインプラットフォームは、時間差データセットを受信した後に時間差データセットに基づいてデバイス機能低下型故障分析を行い、且つ、
分析結果が正常である場合、管理プラットフォームのメインプラットフォームが時間差データセットを削除して、改めてアップロードした時間差データセットの分析を待ち、
又は、分析結果が異常である場合、データファイル、異常結果データ及び時間差データセットを分析データにマージして対応するサービスプラットフォームのサブプラットフォームにアップロードすること、を分析結果に基づいて実行することと、
サービスプラットフォームのサブプラットフォームは分析データを受信してデータファイルに基づいて異常時間ノードを取得し、異常時間ノード、異常結果データ及び時間差データセットをパケット化データとしてサービスプラットフォームのメインプラットフォームに送信することと、
サービスプラットフォームのメインプラットフォームはパケット化データを受信して記憶し、パケット化データにおける異常結果データに基づいて故障等級分けを行って、等級分けされた対応する等級情報をユーザープラットフォームに送信することと、を含むことを特徴とする請求項１１に記載の制御方法。

【請求項13】

管理プラットフォームのメインプラットフォームが時間差データセットを受信した後、時間差データセットに基づいてデバイス機能低下型故障分析を行うことは、具体的に、
管理プラットフォームのメインプラットフォームが時間差データセットを受信した後、単品製造時間の順序に従って隣接する２つの時間差の絶対値の差分を順次計算するように選択することと、
差分に負値が現れ、且つ差分に負値が連続的に現れる回数が管理プラットフォームのメインプラットフォームに設定された閾値よりも大きい場合、デバイス機能低下型故障があると判定し、分析結果が異常であることを決定し、そうではない場合、デバイス機能低下型故障がないと判定し、分析結果が正常であることを決定することと、を含むことを特徴とする請求項１２に記載の制御方法。

【請求項14】

前記故障等級分けは具体的に、
負値が連続的に現れる対応差分のうちの、絶対値が最も大きな差分をＴ１とし、絶対値が最も小さな差分をＴ２とし、負値が連続的に現れる具体的な回数をＮとし、且つ等級分け基準をＦとすると、等級分け基準Ｆは、
Ｆ＝（Ｔ１－Ｔ２）／Ｎ （１）を満足し、
対応する製造装置による総消費時間データのうちの、絶対値が最も大きな許容差分をＴ１′とし、負値が連続的に現れる許容回数をＮ′とすると、許容される等級分け標準はＦ′であり、且つＦ′は、
Ｆ′＝Ｔ１′／Ｎ′ （２）を満足し、
公式（１）を公式（２）で割って等級分け基数Ｑを取得し、
Ｑ＝Ｆ／Ｆ′
０＜Ｑ≦０．２の場合、前記故障等級が普通型Ｄ級であり、
０．２＜Ｑ≦０．６の場合、前記故障等級が一般型Ｃ級であり、
０．６＜Ｑ≦０．８の場合、前記故障等級が深刻型Ｂ級であり、
０．８＜Ｑの場合、前記故障等級が重大型Ａ級であることを特徴とする請求項１３に記載の制御方法。

【請求項15】

前記故障等級が深刻型Ｂ級又は重大型Ａ級である場合、サービスプラットフォームのメインプラットフォームは、等級分けされた対応する等級情報をユーザープラットフォームに送信し、それと同時に、
サービスプラットフォームのメインプラットフォームが故障等級に基づいて早期警報命令を対応するサービスプラットフォームのサブプラットフォーム、管理プラットフォームのメインプラットフォームに送信すること、
管理プラットフォームのメインプラットフォームが早期警報命令を受信し、且つ早期警報命令に基づいて早期警報命令パケットを呼び出して、早期警報命令、早期警報命令パケットを対応する管理プラットフォームのサブプラットフォーム、センシングネットワークプラットフォームのサブプラットフォームに併せて送信し、前記早期警報命令パケットが管理プラットフォームのメインプラットフォームに記憶されること、
センシングネットワークプラットフォームのサブプラットフォームが早期警報命令、早期警報命令パケットをオブジェクトプラットフォームの識別可能なコンフィギュレーションファイルに変換して対応するオブジェクトプラットフォームに送信すること、
オブジェクトプラットフォームがコンフィギュレーションファイルに基づいて早期警報操作を実行すること、を実行することを特徴とする請求項１４に記載の制御方法。

【請求項16】

前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することは、
前記デバイスが各生産タスクを実行する実際の消費時間を取得することと、
前記各生産タスクを実行する前記実際の消費時間及び対応する標準消費時間に基づいて、複数の消費時間差を決定することと、
前記複数の消費時間差に基づいて、前記デバイスに前記機能低下型故障があるかどうかを決定することと、を含むことを特徴とする請求項１１に記載の制御方法。

【請求項17】

前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することは、
前記少なくとも１つの生産タスクの前記産出製品における合格製品の比率に基づいて前記少なくとも１つの生産タスクのうちの各生産タスクの実際の合格率を決定することと、
前記各生産タスクの前記実際の合格率及び対応する標準合格率に基づいて前記デバイスの複数の合格度を決定することと、
前記複数の合格度に基づいて、前記デバイスに機能低下型故障があるかどうかを決定することと、を含むことを特徴とする請求項１１に記載の制御方法。

【請求項18】

前記複数の合格度に基づいて、前記デバイスに機能低下型故障があるかどうかを決定することは、
故障確率予測モデルにより故障確率を予測し、前記故障確率予測モデルが機械学習モデルであり、前記故障確率予測モデルがパラメータ拡張層及び確率予測層を含み、前記パラメータ拡張層が前記複数の合格度に基づいて前記デバイスの第１特徴ベクトルを決定するためのものであり、前記確率予測層が前記第１特徴ベクトル及び前記デバイスのデバイス情報に基づいて前記デバイスの前記故障確率を予測するためのものであることと、
前記故障確率が確率閾値よりも大きいことに応答して、前記デバイスに前記機能低下型故障があることを決定することと、を含むことを特徴とする請求項１７に記載の制御方法。

【請求項19】

コンピュータ可読記憶媒体であって、
前記記憶媒体にコンピュータ命令が記憶され、前記コンピュータ命令がプロセッサにより実行されるとき、請求項１１～１８のいずれか１項に記載の方法を実現することを特徴とするコンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書はモノのインターネットの技術分野に関し、特にデバイス機能低下型故障を早期に警報するための産業用モノのインターネット、方法及び媒体に関する。

【背景技術】

【0002】

生産効率は、直接に生産コストを決める。このため、生産効率は常に企業が注目しているポイントである。スマート製造において、生産ラインは複数のスマート製造装置により工程の順序又は製造実行時間の順序に従って設置して動作するのであり、各デバイスがその生産効率を確保して向上させることができれば、生産ライン全体の生産効率が向上され、更に生産コストが削減される。しかしながら、デバイスの内部構造の相互摩擦、応力などに起因して、デバイス機能低下型障害が生じて、生産効率が低下する恐れがある。

【0003】

従って、デバイス故障状況を予め取得して故障を直ちに解決し、生産ラインにおけるデバイスの正常使用を確保して生産効率を確保するように、デバイス機能低下型故障を早期に警報するための産業用モノのインターネット及び制御方法を提供することが望まれている。

【発明の概要】

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

【0004】

本明細書の実施例の１つはデバイス機能低下型故障を早期に警報するための産業用モノのインターネットを提供し、前記産業用モノのインターネットは管理プラットフォームを備え、前記管理プラットフォームは、デバイスが所定時間帯に実行する少なくとも１つの生産タスクの実行状況を取得すること、前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断すること、前記デバイスに前記機能低下型故障があることに応答して、早期警報を出して前記デバイスに対して対応修復を行うこと、を実行するように構成される。

【0005】

本明細書の実施例の１つはデバイス機能低下型故障を早期に警報するための産業用モノのインターネットの制御方法を提供し、デバイス機能低下型故障を早期に警報するための産業用モノのインターネットの管理プラットフォームにより実現され、前記制御方法は、デバイスが所定時間帯に実行する少なくとも１つの生産タスクの実行状況を取得することと、前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することと、前記デバイスに前記機能低下型故障があることに応答して、早期警報を出して前記デバイスに対して対応修復を行うことと、を含む。

【0006】

本明細書の実施例の１つはコンピュータ可読記憶媒体を提供し、前記記憶媒体にコンピュータ命令が記憶され、前記コンピュータ命令がプロセッサにより実行されるとき、上記制御方法を実現する。

【図面の簡単な説明】

【0007】

本明細書は例示的な実施例の態様で更に説明し、これらの例示的な実施例は図面により詳しく説明される。これらの実施例は制限的なものではなく、これらの実施例において、同じ番号が同じ構造を示す。

【図1】本明細書のいくつかの実施例に係るデバイス機能低下型故障を早期に警報するための産業用モノのインターネットの応用シーンの模式図である。

【図2】本明細書のいくつかの実施例に係るデバイス機能低下型故障を早期に警報するための産業用モノのインターネットの構造の例示的な模式図である。

【図3】本明細書のいくつかの実施例に係るデバイス機能低下型故障を早期に警報するための産業用モノのインターネットの制御方法の例示的なフローチャートである。

【図4】本明細書のいくつかの実施例に係るデバイス機能低下型故障を早期に警報するための産業用モノのインターネットの制御方法の例示的なフローチャートである。

【図5】本明細書のいくつかの実施例に係る合格度に基づいてデバイス機能低下型故障を決定するプロセスの例示的なフローチャートである。

【図6】本明細書のいくつかの実施例に係る故障確率予測モデルの応用の例示的な模式図である。

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

【0008】

本明細書の実施例の技術案をより明確に説明するために、以下に実施例の記述に必要な図面を簡単に説明する。明らかに、以下に記載する図面は単に本明細書のいくつかの例又は実施例であり、当業者であれば、創造的な労力を要することなく、更にこれらの図面に基づいて本明細書を他の類似のシーンに応用することができる。言語環境から明らかになり又は別に説明しない限り、図中の同じ番号が同じ構造又は操作を代表する。

【0009】

理解されるように、本明細書に使用される「システム」、「装置」、「ユニット」及び／又は「モジュール」は異なるレベルの異なるアセンブリ、素子、部材、部分又は組立を区分するための方法である。ところが、他の用語が同じ目的を実現できれば、他の表現で前記用語を代替してもよい。

【0010】

本明細書及び特許請求の範囲に示されるように、文脈に例外な状況を明確に提示しない限り、「一」、「１つ」、「１種」及び／又は「該」などの用語は特に単数を指すとは限らず、複数も含んでもよい。一般的には、用語「含む」及び「包含」は明確に示されるステップ及び要素を含むように提示するだけであるが、これらのステップ及び要素が排他的な羅列を構成せず、方法又はデバイスが他のステップ又は要素を含む可能性もある。

【0011】

本明細書においてフローチャートによって本明細書の実施例に係るシステムが実行する操作を説明する。理解されるように、その前又はその後の操作は必ず順序に従って正確に実行しなければならないとは限らない。それとは逆に、逆の順序に従って各ステップを処理し、又は各ステップを同時に処理してもよい。それと同時に、他の操作をこれらの過程に追加し、又はこれらの過程からあるステップ又は複数のステップの操作を取り除いてもよい。

【0012】

図１は本明細書のいくつかの実施例に係るデバイス機能低下型故障を早期に警報するための産業用モノのインターネットの応用シーンの模式図である。

【0013】

図１に示すように、デバイス機能低下型故障を早期に警報するための産業用モノのインターネットの応用シーン１００はサーバ１１０、ネットワーク１２０、端末装置１３０、生産ライン１４０及び記憶装置１５０を備えてもよい。

【0014】

いくつかの実施例では、応用シーン１００は本明細書に開示されるデバイス機能低下型故障を早期に警報するための産業用モノのインターネット及び制御方法を実施することにより、デバイスの事前早期警報及び修復を実現してもよい。例えば、１つの代表的な応用シーンにおいて、生産ライン１４０におけるデバイスの事前早期警報及び修復を実現する必要がある場合、まず所定時間帯に実行する少なくとも１つの生産タスクの実行状況を取得してサーバ１１０に送信し、サーバ１１０が前記少なくとも１つの生産タスクの実行状況に応じて、前記生産ライン１４０におけるデバイスに機能低下型故障があるかどうかを判断し、サーバ１１０が前記生産ライン１４０におけるデバイスに前記機能低下型故障があることに応答して、早期警報を出して前記生産ライン１４０におけるデバイスに対して対応修復を行い、それにより生産装置が正常に動作することが確保され、生産効率が確保される。

【0015】

いくつかの実施例では、サーバ１１０は応用シーン１００に関連する情報及び／又はデータを処理するためのものであってもよい。例えば、サーバ１１０は少なくとも１つの生産タスクの状況に応じて、前記生産ライン１４０におけるデバイスに機能低下型障害があるかどうかを判断してもよいなどが挙げられる。いくつかの実施例では、サーバ１１０は単一サーバ又はサーバ群であってもよい。該サーバ群は集中型又は分散型のものであってもよく、専用のものであってもよく、他のデバイス又はシステムによりサービスを同時に提供してもよい。

【0016】

いくつかの実施例では、サーバ１１０はローカル又はリモートのものであってもよい。いくつかの実施例では、サーバ１１０はクラウドプラットフォームにおいて実施されてもよく、又はバーチャル方式で提供されてもよい。

【0017】

いくつかの実施例では、サーバ１１０は処理装置を備えてもよい。処理装置は他のデバイス又はシステムの構成部分から取得されたデータ及び／又は情報を処理することができる。処理装置は本願に説明される１つ又は複数の機能を実行するように、これらのデータ、情報及び／又は処理結果に基づいてプログラム命令を実行することができる。

【0018】

いくつかの実施例では、ネットワーク１２０は情報及び／又はデータの交換を促進することができる。いくつかの実施例では、応用シーン１００における１つ以上のアセンブリ（例えば、サーバ１１０、ネットワーク１２０、端末装置１３０、生産ライン１４０及び記憶装置１５０）はネットワーク１２０経由で情報及び／又はデータを応用シーン１００における他のアセンブリに送信することができる。例えば、サーバ１１０はネットワーク１２０経由で情報及び／又はデータを取得することができる。

【0019】

いくつかの実施例では、端末装置１３０はデータ処理及びデータ通信を実現するための電子機器であってもよい。例えば、携帯電話１３０－１、タブレットコンピュータ１３０－２、ノートパソコン１３０－３又は他の電子機器が挙げられ、ここで特に制限しない。いくつかの実施例では、ノートパソコン１３０－３によってサーバ１１０から取得されたデータ及び／又は情報を分析してノートパソコン１３０－３のスクリーンに表示することができる。

【0020】

いくつかの実施例では、生産ライン１４０は製品の流れライン生産を実現することができる。いくつかの実施例では、生産ライン１４０は製品を製造するための様々なスマート製造装置を備えてもよい。例えば、自動車エンジンの組立生産ラインにおけるシリンダブロックの処理装置、シリンダブロックの位置決め反転装置、カムアセンブリの取付装置、ボルトアセンブリの取付装置などが挙げられる。

【0021】

いくつかの実施例では、記憶装置１５０はデータ及び／又は命令を記憶するためのものである。いくつかの実施例では、記憶装置１５０は生産ライン１４０の関連情報を記憶することができる。例えば、生産ライン１４０におけるデバイスは少なくとも１つの生産タスクの時間などのデータを実行する。いくつかの実施例では、記憶装置１５０はサーバ１１０が本願に説明される例示的な方法を実行して完了するためのデータ及び／又は命令を記憶することができる。いくつかの実施例では、記憶装置１５０はクラウドプラットフォームにおいて実現されてもよい。

【0022】

いくつかの実施例では、記憶装置１５０は応用シーン１００における１つ以上のアセンブリ（例えば、サーバ１１０、ネットワーク１２０、端末装置１３０及び生産ライン１４０）と通信するように、ネットワーク１２０に接続されてもよい。応用シーン１００における１つ以上のアセンブリはネットワーク１２０経由で記憶装置１５０に記憶されるデータ又は命令にアクセスすることができる。いくつかの実施例では、記憶装置１５０は応用シーン１００における１つ以上のアセンブリに直接接続又は通信してもよい。いくつかの実施例では、記憶装置１５０はサーバ１１０の一部であってもよい。

【0023】

注意すべきことは、応用シーンは単に説明のために提供するものであって、本明細書の範囲を制限することを意図するものではない。当業者であれば、本明細書の説明に基づいて種々の変更又は変化を行うことができる。例えば、応用シーンは更にデータベースを含んでもよい。更に例えば、応用シーンは類似又は異なる機能を実現するように、他のデバイスにおいて実現されてもよい。ところが、変化及び変更は本明細書の範囲から逸脱することがない。

【0024】

モノのインターネットシステムはユーザープラットフォーム、サービスプラットフォーム、管理プラットフォーム、センシングネットワークプラットフォーム、オブジェクトプラットフォームのうちの一部又は全部のプラットフォームを含む情報処理システムであり、ユーザープラットフォームはモノのインターネット実行系の主導者であり、ユーザーニーズを取得するためのものであってもよい。ユーザーニーズはモノのインターネット実行系を形成する基礎及び前提であり、モノのインターネットシステムにおける各プラットフォーム間の連絡はいずれもユーザーのニーズを満足することを目的とする。

【0025】

図２は本明細書のいくつかの実施例に係るデバイス機能低下型故障を早期に警報するための産業用モノのインターネットシステムの構造の例示的な模式図である。

【0026】

図２に示すように、デバイス機能低下型故障を早期に警報するための産業用モノのインターネットシステム２００はモノのインターネットシステムにより実現されてもよい。システム２００は上から下まで順次対話するユーザープラットフォーム２１０、サービスプラットフォーム２２０、管理プラットフォーム２３０、センシングネットワークプラットフォーム２４０及びオブジェクトプラットフォーム２５０を備える。

【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】

本明細書のいくつかの実施例では、故障確率予測モデルによりデバイスの機能低下型故障を予測し、機能低下型故障がある恐れがあるデバイスを早期に警報し及び予め防止することに寄与する。

【0145】

本明細書はデバイス機能低下型故障を早期に警報するための産業用モノのインターネット及びその制御方法を提供し、５つのプラットフォームの構造に基づいて産業用モノのインターネットを構築し、且つフロントサブプラットフォーム型配置と独立型配置を組み合わせるプラットフォーム配置方法を用いることにより、データ伝送時の独立性が確保され、データの分類及び処理にも寄与する。デバイス機能低下型故障を等級分けし、且つ故障等級分け状況に応じてサービスプラットフォームのメインプラットフォームが故障処理命令を自発的に送信することにより、デバイスの故障を早期に警報することができ、生産ラインが正常に動作できることが確保され、更に生産効率を確保する目的を実現する。

【0146】

異常は基本的な概念を説明したが、明らかに、当業者にとっては、上記詳細な開示は単に例示的なものであり、本明細書を限定するものではない。ここで明確に説明しないが、当業者であれば本明細書に対して種々の変更、改良及び修正を行うことができる。このような変更、改良及び修正が本明細書に推奨されるため、このような変更、改良、修正は依然として本明細書の模範的な実施例の主旨及び範囲に属する。

【0147】

それと同時に、本明細書は特定の用語を用いて本明細書の実施例を説明する。例えば「１つの実施例」、「一実施例」及び／又は「いくつかの実施例」とは、本明細書の少なくとも１つの実施例に関連するある特徴、構造又は特性を意味する。従って、強調して注意すべきことは、本明細書において異なる位置に２回以上言及した「一実施例」又は「１つの実施例」又は「１つの代替実施例」は必ず同一実施例を指すとは限らない。また、本明細書の１つ又は複数の実施例におけるいくつかの特徴、構造又は特性は適当に組み合わせられることができる。

【0148】

また、特に特許請求の範囲に明確に説明しない限り、本明細書に記載の処理要素及び系列の順序、数字・アルファベットの使用、又は他の名称の使用は、本明細書のプロセス及び方法の順序を限定するためのものではない。上記開示において様々な例によっていくつかの現在有用であると見なされる発明実施例について検討したが、理解されるように、このような詳細は単に説明のためのものであり、添付の特許請求の範囲は開示される実施例に限らず、それとは逆に、特許請求の範囲はすべての本明細書の実施例の本質及び範囲に合致する修正及び等価組み合わせをカバーすることを意図する。例えば、以上に説明されたシステムアセンブリはハードウェアデバイスにより実現されてもよいが、ソフトウェアのソリューションだけにより実現されてもよく、例えば既存のサーバ又はモバイル機器には説明されるシステムをインストールする。

【0149】

同様に、注意すべきことは、本明細書に開示される説明を簡素化して１つ又は複数の発明実施例を理解しやすくするために、以上の本明細書の実施例の説明において、複数の特徴を１つの実施例、図面又はその説明にまとめる場合がある。しかしながら、このような開示方法は本明細書の対象に必要な特徴が特許請求の範囲に言及した特徴よりも多いことを意味しない。実際には、実施例の特徴が上記開示される単一実施例のすべての特徴よりも少ない。

【0150】

いくつかの実施例において成分、属性の数を説明する数字を用いたが、理解されるように、このような実施例の説明に用いられる数字は、いくつかの例において修飾語「約」、「近似」又は「ほぼ」で修飾される。特に説明しない限り、「約」、「近似」又は「ほぼ」は前記数字が±２０％変化することが許容されることを示す。それに対応して、いくつかの実施例では、明細書及び特許請求の範囲に使用される数値パラメータがいずれも近似値であり、該近似値が個別実施例に必要な特性に応じて変化してもよい。いくつかの実施例では、数値パラメータは規定された有効桁を考慮して一般的な桁で保存する方法を用いるべきである。本明細書のいくつかの実施例においてその範囲の広さを確認するための数値フィールド及びパラメータが近似値であるが、具体的な実施例においてこのような数値の設定を実行可能な範囲内にできる限り正確にする。

【0151】

本明細書に援用される各特許、特許出願、特許出願刊行物及び他の材料、例えば文章、書籍、明細書、出版物、ファイルなどについて、特にそのすべての内容は参照として本明細書に組み込まれている。本明細書の内容に一致せず又は本明細書の内容と衝突する出願履歴ファイルが除かれ、本明細書の特許請求の範囲の最も広い範囲が制限されるファイル（その前又はその後に本明細書に追加するもの）も除かれる。なお、本明細書の添付の材料における説明、定義、及び／又は用語の使用が本明細書に記載の内容に一致せず又は本明細書に記載の内容と衝突するところは、本明細書の説明、定義及び／又は用語の使用に準じる。

【0152】

最後に理解されるように、本明細書に記載の実施例は単に本明細書の実施例の原則を説明するためのものである。他の変形は本明細書の範囲に属する可能性もある。従って、制限ではなく例示的なものとして、本明細書の実施例の代替配置は本明細書の指導に一致すると見なされてもよい。それに対応して、本明細書の実施例は本明細書に明確に披露及び説明される実施例に限定されるものではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【手続補正書】

【提出日】2023-08-04

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

デバイス機能低下型故障を早期に警報するための産業用モノのインターネットであって、
管理プラットフォームを備え、前記管理プラットフォームは、
デバイスが所定時間帯に実行する少なくとも１つの生産タスクの実行状況を取得すること、
前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断すること、
前記デバイスに前記機能低下型故障があることに応答して、早期警報を出して前記デバイスに対して対応修復を行うこと、を実行するように構成されることを特徴とするデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項2】

ユーザープラットフォーム、サービスプラットフォーム、センシングネットワークプラットフォーム及びオブジェクトプラットフォームを更に備え、前記ユーザープラットフォーム、前記サービスプラットフォーム、前記管理プラットフォーム、前記センシングネットワークプラットフォーム及び前記オブジェクトプラットフォームが上から下まで順次対話し、
前記サービスプラットフォームと管理プラットフォームがいずれもフロントサブプラットフォーム型配置を用い、前記センシングネットワークプラットフォームが独立型配置を用い、前記フロントサブプラットフォーム型配置とは、対応するプラットフォームに１つのメインプラットフォーム及び複数のサブプラットフォームが設置され、複数のサブプラットフォームがそれぞれ下位層プラットフォームから送信された異なるタイプ又は異なる受信対象のデータを記憶して処理し、１つのメインプラットフォームが複数のサブプラットフォームのデータをまとめて記憶して処理して、データを上位層プラットフォームに伝送することを意味し、前記独立型配置とは、センシングネットワークプラットフォームが異なるオブジェクトプラットフォームのデータに対して異なるサブプラットフォームによりデータ記憶、データ処理及び／又はデータ伝送を行うことを意味し、前記オブジェクトプラットフォームがスマート製造された製造装置として設定され、
製造装置は製造を実行するとき、単品製造パラメータデータを対応するセンシングネットワークプラットフォームのサブプラットフォームにアップロードし、単品製造パラメータデータが該製造装置による単品製造時の総消費時間データを少なくとも含み、
センシングネットワークプラットフォームのサブプラットフォームは単品製造パラメータデータを管理プラットフォームの識別可能なデータファイルに変換して対応する管理プラットフォームのサブプラットフォームに送信し、
管理プラットフォームのサブプラットフォームはデータファイルを受信して総消費時間データを抽出し、総消費時間データに基づいて単品製造時間の順序に従って隣接する２つの総消費時間データの時間差を順次計算し、すべての時間差を単品製造時間の順序に従って順に順序付けて時間差データセットを形成し、且つデータファイル、時間差データセットを記憶して管理プラットフォームのメインプラットフォームに送信し、
管理プラットフォームのメインプラットフォームは、時間差データセットを受信した後に時間差データセットに基づいてデバイス機能低下型故障分析を行い、且つ、
分析結果が正常である場合、管理プラットフォームのメインプラットフォームが時間差データセットを削除して、改めてアップロードした時間差データセットの分析を待ち、
又は、分析結果が異常である場合、データファイル、異常結果データ及び時間差データセットを分析データにマージして対応するサービスプラットフォームのサブプラットフォームにアップロードすること、を分析結果に基づいて実行し、
サービスプラットフォームのサブプラットフォームは分析データを受信してデータファイルに基づいて異常時間ノードを取得し、異常時間ノード、異常結果データ及び時間差データセットをパケット化データとしてサービスプラットフォームのメインプラットフォームに送信し、
サービスプラットフォームのメインプラットフォームはパケット化データを受信して記憶し、パケット化データにおける異常結果データに基づいて故障等級分けを行って、等級分けされた対応する等級情報をユーザープラットフォームに送信することを特徴とする請求項１に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項3】

管理プラットフォームのメインプラットフォームが時間差データセットを受信した後、時間差データセットに基づいてデバイス機能低下型故障分析を行うことは、具体的に、
管理プラットフォームのメインプラットフォームが時間差データセットを受信した後、単品製造時間の順序に従って隣接する２つの時間差の絶対値の差分を順次計算するように選択することと、
差分に負値が現れ、且つ差分に負値が連続的に現れる回数が管理プラットフォームのメインプラットフォームに設定された閾値よりも大きい場合、デバイス機能低下型故障があると判定し、分析結果が異常であることを決定し、そうではない場合、デバイス機能低下型故障がないと判定し、分析結果が正常であることを決定することと、を含むことを特徴とする請求項２に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項4】

前記管理プラットフォームのメインプラットフォームに閾値テーブルが記憶され、各管理プラットフォームのサブプラットフォームがいずれも閾値テーブルにおける唯一の閾値に対応し、
デバイス機能低下型故障分析を行うとき、管理プラットフォームのメインプラットフォームが各管理プラットフォームのサブプラットフォームの時間差データセットを分析し、閾値テーブルにおける対応閾値及び差分に負値が連続的に現れる回数を呼び出して差分計算を行うことを特徴とする請求項３に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項5】

サービスプラットフォームのサブプラットフォームが分析データを受信してデータファイルに基づいて異常時間ノードを取得し、異常時間ノード、異常結果データ及び時間差データセットをパケット化データとしてサービスプラットフォームのメインプラットフォームに送信することは、具体的に、
前記単品製造パラメータデータが製造装置による単品製造時の製造開始時刻を更に含み、製造装置が単品製造パラメータデータをアップロードするとき、単品製造時の製造開始時刻と総消費時間データを関連付けて併せてアップロードすることと、
サービスプラットフォームのサブプラットフォームが分析データを受信してからデータファイルを抽出し、時間差データセットにおける負値が現れる差分に対応する時間差を抽出し、且つ該時間差に基づいて対応する複数の総消費時間データを取得することと、
複数の総消費時間データに基づいて、複数の総消費時間データに対応する複数の製造開始時刻を取得することと、
単品製造時間の順序に従って複数の製造開始時刻を順に順序付けて前記異常時間ノードを形成することと、を含むことを特徴とする請求項３又は４に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項6】

前記ユーザープラットフォームが等級情報を取得した後、等級情報に基づいて、前記ユーザープラットフォームは点検修理命令をサービスプラットフォームのメインプラットフォームに送信し、点検修理命令が１つの自己修復サブ命令を少なくとも含み、
サービスプラットフォームのメインプラットフォームは点検修理命令を受信して点検修理命令に基づいて命令解析を行って、少なくとも１つの自己修復サブ命令を取得し、少なくとも１つの自己修復サブ命令を対応するサービスプラットフォームのサブプラットフォームに送信し、
サービスプラットフォームのサブプラットフォームは自己修復サブ命令を受信して自己修復サブ命令を管理プラットフォームのメインプラットフォームに送信し、
管理プラットフォームのメインプラットフォームは自己修復サブ命令を受信し、且つ対応する命令コードパケットを取得し、命令コードパケットと自己修復サブ命令を関連付けてから管理プラットフォームのサブプラットフォームに併せて送信し、前記命令コードパケットが管理プラットフォームのメインプラットフォームに予め記憶され、
管理プラットフォームのサブプラットフォームは命令コードパケット及び自己修復サブ命令を受信してから対応するセンシングネットワークプラットフォームのサブプラットフォームに送信し、
センシングネットワークプラットフォームのサブプラットフォームは命令コードパケット及び自己修復サブ命令をオブジェクトプラットフォームの識別可能なコンフィギュレーションファイルに変換してから対応するオブジェクトプラットフォームに送信し、前記オブジェクトプラットフォームが自己修復サブ命令に基づいて命令コードパケットにおける命令コードデータを呼び出して自己修復を実行することを特徴とする請求項２～４のいずれか一項に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項7】

前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することは、
前記デバイスが各生産タスクを実行する実際の消費時間を取得することと、
前記各生産タスクを実行する前記実際の消費時間及び対応する標準消費時間に基づいて、複数の消費時間差を決定することと、
前記複数の消費時間差に基づいて、前記デバイスに前記機能低下型故障があるかどうかを決定することと、を含むことを特徴とする請求項１～４のいずれか一項に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項8】

前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することは、
前記少なくとも１つの生産タスクの前記産出製品における合格製品の比率に基づいて前記少なくとも１つの生産タスクのうちの各生産タスクの実際の合格率を決定することと、
前記各生産タスクの前記実際の合格率及び対応する標準合格率に基づいて前記デバイスの複数の合格度を決定することと、
前記複数の合格度に基づいて、前記デバイスに機能低下型故障があるかどうかを決定することと、を含むことを特徴とする請求項１～４のいずれか一項に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項9】

前記複数の合格度に基づいて、前記デバイスに機能低下型故障があるかどうかを決定することは、
故障確率予測モデルにより故障確率を予測し、前記故障確率予測モデルが機械学習モデルであり、前記故障確率予測モデルがパラメータ拡張層及び確率予測層を含み、前記パラメータ拡張層が前記複数の合格度に基づいて前記デバイスの第１特徴ベクトルを決定するためのものであり、前記確率予測層が前記第１特徴ベクトル及び前記デバイスのデバイス情報に基づいて前記デバイスの前記故障確率を予測するためのものであることと、
前記故障確率が確率閾値よりも大きいことに応答して、前記デバイスに前記機能低下型故障があることを決定することと、を含むことを特徴とする請求項８に記載のデバイス機能低下型故障を早期に警報するための産業用モノのインターネット。

【請求項10】

デバイス機能低下型故障を早期に警報するための産業用モノのインターネットの制御方法であって、
デバイス機能低下型故障を早期に警報するための産業用モノのインターネットの管理プラットフォームにより実現され、
前記制御方法は、
デバイスが所定時間帯に実行する少なくとも１つの生産タスクの実行状況を取得することと、
前記少なくとも１つの生産タスクの実行状況に応じて、前記デバイスに機能低下型故障があるかどうかを判断することと、
前記デバイスに前記機能低下型故障があることに応答して、早期警報を出して前記デバイスに対して対応修復を行うことと、を含むことを特徴とするデバイス機能低下型故障を早期に警報するための産業用モノのインターネットの制御方法。

【手続補正2】

【補正対象書類名】明細書

【補正対象項目名】０１２３

【補正方法】変更

【補正の内容】

【0123】

いくつかの実施例では、故障確率予測モデル６２０は更に第２特徴層６５０を含んでもよい。第２特徴層６５０は第２シーケンスモデル６５１及び第２重畳層６５４を含んでもよい。第２シーケンスモデル６５１は長短期記憶ネットワークモデルであってもよく、第２重畳層６５４はディープニューラルネットワークモデルであってもよい。

【手続補正3】

【補正対象書類名】明細書

【補正対象項目名】０１４０

【補正方法】変更

【補正の内容】

【0140】

それと同時に、第２特徴層６５０における処理において、消費時間差系列６１２を第２シーケンスモデル６５１に入力し、複数の将来時刻の消費時間差６５２を出力し、複数の将来時刻の消費時間差６５２及び消費時間差系列６１２を第２重畳層６５４の入力とし、第１重畳層６４３の処理にて第２特徴ベクトル６６２を取得するとともに、第２信頼度計算モジュール６５３が複数の将来時刻の消費時間差６５２及び消費時間差系列６１２に基づいて所定の計算公式により第２信頼度６６５を取得する。

【国際調査報告】