JPWO2021059460A1 - エンジニアリングツール、学習装置、およびデータ収集システム - Google Patents

Abstract

エンジニアリングツール（１０）が、ユーザからの指示に基づいて、第１の装置から収集される第１の収集データの第１の装置用データタイプと、第１のアプリケーションが解釈可能な第１の基準データの第１の基準データタイプとの対応関係を示す対応関係情報を編集する装置モデル編集部（１１）と、第１の対応関係情報の編集結果に基づいて、第１の基準データタイプから第１の装置用データタイプへの変換のルールである変換ルールを学習し、第２のアプリケーションが解釈可能な第２の基準データの第２の基準データタイプに対する、第２の装置から収集される第２の収集データの第２の装置用データタイプへの変換候補を、変換ルールを用いて推定する変換候補提供部（１２）と、を備える。

Description

本発明は、データの収集に用いられるエンジニアリングツール、学習装置、およびデータ収集システムに関する。

近年、生産現場に配置されている産業機器からＩｏＴ（Internet of Things）技術を活用して収集データを収集し、収集データの分析結果を生産現場にフィードバックすることで生産現場における生産性の向上が図られている。

生産現場では、異なるベンダから供給される産業機器などの装置を組み合わせたマルチベンダ環境で生産が行われることが一般的である。また、各装置が用いる通信プロトコルは、ベンダ毎に異なる場合が多い。このため、装置または通信プロトコルに依存せずＩｏＴプラットフォームで収集した収集データを統合的に利活用するには、装置毎に外部出力可能なデータ定義に差異があっても、収集データを分析等するアプリケーションに対しては一意のデータ定義となるようにデータ収集する必要がある。

このため、アプリケーションが解釈可能な基準データのデータ定義と、産業機器が解釈可能な収集データのデータ定義とを対応付けたうえで、装置から収集データが収集される必要がある。

特許文献１に記載のコンピュータ処理装置は、入力データと、電子データの概念との間の対応関係を示すマッピングルールを用いて、入力データに対応する電子データの概念を選択し、選択した概念で入力データの構造を捕捉している。特許文献１における入力データは、アプリケーションが解釈可能な基準データに対応するデータであり、電子データの概念は、収集データに対応するデータである。

特開２００６−１７８９８２号公報

しかしながら、上記特許文献１の技術では、予め入力データと電子データの概念とが対応付けされている入力データに対しては、入力データに対応する電子データの概念を提供することはできるが、電子データの概念に対応付けされていない入力データに対しては、電子データの概念を提供できないという問題があった。上述したように、上記特許文献１の技術を、装置から収集データを収集してアプリケーションに提供するデータ収集システムに適用した場合、入力データは、アプリケーションが解釈可能な基準データとなり、電子データの概念は、収集データとなる。したがって、上記特許文献１の技術をデータ収集システムに適用した場合、アプリケーションが解釈可能な基準データのデータタイプと、装置から収集される収集データのデータタイプとの間の変換ルールが予め規定されていなければ、基準データのデータタイプに対応する収集データのデータタイプを提供することができないという問題があった。

本発明は、上記に鑑みてなされたものであって、アプリケーションが解釈可能な基準データのデータタイプが収集データのデータタイプに対応付けされていない場合であっても、基準データのデータタイプに対応する収集データのデータタイプ候補を提供することができるエンジニアリングツールを得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明のエンジニアリングツールは、第１のユーザからの指示に基づいて、第１の装置から収集される第１の収集データのデータタイプである第１の装置用データタイプと、第１のアプリケーションが解釈可能な第１の基準データのデータタイプである第１の基準データタイプとの対応関係を示す第１の対応関係情報を編集する編集部を備える。また、本発明のエンジニアリングツールは、第１の対応関係情報の編集結果に基づいて、第１の基準データタイプから第１の装置用データタイプへの変換のルールである変換ルールを学習し、第２のアプリケーションが解釈可能な第２の基準データのデータタイプである第２の基準データタイプに対する、第２の装置から収集される第２の収集データのデータタイプである第２の装置用データタイプへの変換候補を、変換ルールを用いて推定する変換候補提供部を備える。

本発明にかかるエンジニアリングツールは、アプリケーションが解釈可能な基準データのデータタイプが収集データのデータタイプに対応付けされていない場合であっても、基準データのデータタイプに対応する収集データのデータタイプ候補を提供することができるという効果を奏する。

実施の形態にかかるデータ収集システムの構成を示す図 実施の形態にかかるエンジニアリングツールが備える変換候補提供部の構成を示す図 実施の形態にかかるエンジニアリングツールが備える変換ルール学習部の構成を示す図 実施の形態にかかるエンジニアリングツールが用いるニューラルネットワークの構成を示す図 実施の形態にかかるエンジニアリングツールによる機械学習時の動作手順を示すフローチャート 実施の形態にかかるエンジニアリングツールによるデータ推定時の動作手順を示すフローチャート 実施の形態にかかるエンジニアリングツールを動作させるコンピュータを実現するハードウェア構成の第１例を示す図 実施の形態にかかるエンジニアリングツールを動作させるコンピュータを実現するハードウェア構成の第２例を示す図

以下に、本発明の実施の形態にかかるエンジニアリングツール、学習装置、およびデータ収集システムを図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

実施の形態．
図１は、実施の形態にかかるデータ収集システムの構成を示す図である。データ収集システム１は、エンジニアリングツール１０と、アプリケーション２０と、プラットフォーム３０と、通信サーバ４０と、装置５０と、ネットワーク回線６０とを備えている。

データ収集システム１は、種々の機器から装置データを収集し、装置データから生成された収集データをアプリケーション２０に提供するシステムである。機器の例は、生産現場に据え付けられている工作機械、工作機械の周辺装置等である。本実施の形態では、装置データが収集される機器が装置５０である場合について説明する。装置データおよび収集データの例は、装置５０の稼働状況等を示す稼働データである。

エンジニアリングツール１０、アプリケーション２０、プラットフォーム３０、および通信サーバ４０は、それぞれ、例えば、ＰＣ（Personal Computer）等のコンピュータを用いて実現される。なお、アプリケーション２０とプラットフォーム３０とは、同一のコンピュータで実現されてもよい。また、プラットフォーム３０と通信サーバ４０とは、同一のコンピュータで実現されてもよい。

データ収集システム１では、ＩｏＴプラットフォームであるプラットフォーム３０が、通信サーバ４０を介して装置５０から収集データを取得して蓄積する。プラットフォーム３０は、装置５０毎、通信プロトコル毎に収集データを取得する。プラットフォーム３０は、アプリケーション２０からデータ収集の要求があると、収集データをアプリケーション２０に提供する。

エンジニアリングツール１０は、プラットフォーム３０におけるデータ収集設定を支援する機能を有したソフトウェアツールである。エンジニアリングツール１０は、収集データの設定情報である収集設定情報をプラットフォーム３０に送る。

収集設定情報では、プラットフォーム３０が蓄積する収集データの情報が設定されている。収集設定情報は、アプリケーション２０から要求されるデータのデータアイテムと、このデータアイテムに対応する収集データを通信サーバ４０内で特定するための情報とを含んでいる。収集データを通信サーバ４０内で特定するための情報の例は、データアイテムの識別子、データアイテムのデータタグ名、データアイテムを格納している場所のアドレス、フォルダパス、ＵＲＬ（Uniform Resource Locator）等である。また、収集設定情報には、プラットフォーム３０が蓄積する収集データのデータタイプと、アプリケーション２０が扱うデータのデータタイプとが対応付けされた情報（後述する対応関係情報）が含まれている。

エンジニアリングツール１０は、装置５０が配置されている生産現場とは離れた場所で使用可能となっており、ネットワーク回線６０を介してプラットフォーム３０および通信サーバ４０に接続されている。ネットワーク回線６０の例は、インターネットおよびＬＡＮ（Local Area Network）である。

エンジニアリングツール１０は、収集データのスキーマを定義したスキーマ定義を、通信サーバ４０から取得する。収集データのスキーマ定義は、通信サーバ４０が扱う収集データのスキーマである装置用スキーマ（データモデル構造）を定義した情報である。以下の説明では、通信サーバ４０が扱う収集データのスキーマ定義を装置スキーマ定義という。装置スキーマ定義には、データタグ名などの識別子が含まれている。通信サーバ４０が扱う収集データは、通信サーバ４０が解釈可能なデータである。

装置用スキーマは、通信サーバ４０が扱う収集データのデータモデルを含んでいる。したがって、装置スキーマ定義は、収集データのデータモデルを定義した情報を含んでいる。収集データのデータモデルは、装置用スキーマを構成するひな形をモデル化したものである。

アプリケーション２０の例は、生産現場における生産性の改善等を目的として導入される設備稼働監視のアプリケーションである。アプリケーション２０は、生産稼働状況の見える化等を行う。アプリケーション２０は、例えば、装置５０から収集した収集データを分析し、生産現場の稼働状態等を診断する。アプリケーション２０は、アプリケーション２０が扱うデータである基準データのスキーマ定義に従ってデータ処理を行う。アプリケーション２０が扱う基準データは、アプリケーション２０が解釈可能なデータである。基準データのスキーマ定義は、アプリケーション２０が扱う基準データのスキーマである基準スキーマを定義した情報である。以下の説明では、アプリケーション２０が扱う基準データのスキーマ定義を基準スキーマ定義という。基準スキーマ定義には、データタグ名などの識別子が含まれていてもよいし、基準データのデータ内容が含まれていてもよい。

基準スキーマ定義は、アプリケーション２０が扱う基準データのデータモデルを含んでいる。したがって、基準スキーマ定義は、基準データのデータモデルを定義した情報を含んでいる。アプリケーション２０におけるデータモデルは、基準スキーマを構成するひな形をモデル化したものである。

通信サーバ４０は、装置５０から装置データを取得し、収集データとして蓄積する。通信サーバ４０は、プラットフォーム３０から収集データの要求があると、収集データをプラットフォーム３０に送信する。通信サーバ４０の例は、ＭＴコネクト（ＭＴ Connnect）およびＯＰＣ ＵＡ（Object linking and embedding for Process Control Unified Architecture）サーバである。データ収集システム１にエッジクロス（Edgecross）が適用される場合、通信サーバ４０は、種々の通信プロトコルに対応したデータコレクタからアクセスされる。

生産現場に配置された装置５０は、稼働データ等の装置データを外部装置に出力するための装置データ出力部５１を有している。稼働データは、アプリケーション２０が装置５０の稼働状態を判定可能な状態監視データである。稼働データの例は、装置５０の運転状態、装置５０の運転モード、被加工物の加工状態、アラーム発生の有無を示すデータ等である。

通信サーバ４０は、装置モデル管理部４１と、収集データ生成部４２とを有している。装置モデル管理部４１は、装置スキーマ定義を管理する。装置モデル管理部４１は、装置スキーマ定義を管理するため、例えばＸＭＬ（Extensible Markup Language：エクステンシブル マークアップ ランゲージ）文書等を管理する。ＸＭＬ文書では、１行毎にデータアイテムが記載されている。このデータアイテムには、装置スキーマを特徴付けるデータタイプが付与されている。

データタイプは、収集データの内容を示す情報である。すなわち、データタイプは、収集データのカテゴリ、分類、または内容を定義した情報である。換言すると、データタイプは、収集データの定義名である。データタイプの例は、座標、ワークカウント数、プログラム名等である。

装置モデル管理部４１は、ＸＭＬ文書で記載された装置スキーマ定義を記憶しており、エンジニアリングツール１０からの要求に応じて、装置スキーマ定義をエンジニアリングツール１０に提供する。

収集データ生成部４２は、装置モデル管理部４１が記憶している装置スキーマ定義に基づいて、装置５０から装置データを収集する。収集データ生成部４２は、装置スキーマ定義に基づいて、装置データから収集データを生成する。具体的には、収集データ生成部４２は、装置データ出力部５１から装置データを受信すると、装置５０の装置スキーマ定義に基づいて、装置データを通信プロトコルに応じた出力フォーマットの収集データに成型する。ここでの通信プロトコルは、プラットフォーム３０と通信サーバ４０との間で用いられる通信プロトコルである。収集データ生成部４２は、成型によって生成した収集データを、プラットフォーム３０からの要求に応じてプラットフォーム３０に出力する。なお、収集データ生成部４２は、生成した収集データを、アプリケーション２０からの要求に応じてアプリケーション２０に出力してもよい。

一般的に産業用途の通信装置で用いられるデータのデータモデルは、装置５０の装置種別、装置５０のベンダである装置ベンダ、および通信プロトコルによって概ね決まる。これらのデータモデルは、通信サーバ４０が有する装置スキーマ定義で規定されている。装置スキーマ定義では、通信プロトコルで定められたデータモデルのメタ構造に従い、ＸＭＬ文書等によって各装置５０に適合したデータモデルが構造定義されている。具体的には、装置スキーマ定義では、収集すべきデータアイテム毎に、タグ名またはデータ識別子（ＩＤ（Identification）情報）と、データタイプと、サブタイプと、データ型と、単位等とを基本属性情報として、データモデルが構造定義されている。サブタイプは、データタイプをさらに分類する場合に用いられる。データタイプが座標である場合、サブタイプの例は、ワーク座標、および機械座標である。データ型は、収集データのプログラム言語の型であり、データ型の例は、文字列、整数、および日付である。

なお、１つの装置用スキーマ内では複数のデータモデル（装置モデル）が定義されることもあるが、各データモデルに含まれるデータアイテム毎のデータ識別子は基本的に重複しない必要がある。データ識別子等の基本属性情報は、通信プロトコルにてセマンティクス定義されているものの、データモデルの解釈および実製品におけるアプリケーションレベルの接続性は、ベンダの実装に依存することが多い。このため、データタイプまたはサブタイプにどのような装置データを紐付けるかの厳密な正解は一般的に無いものとされている。アプリケーションレベルの接続性は、データ内容を維持したデータ通信の接続が可能であるか否かを示している。

ベンダ毎に装置スキーマ定義に差異が生じる情報の例としては、工作機械における自動運転プログラムの実行行の情報があげられる。工作機械の自動運転プログラムは、数値制御（ＮＣ：Numerical Control）装置のベンダに依らず自動運転プログラムの内容を特定する情報が、プログラム名、シーケンス番号、ブロック番号等で表される。これらの情報は、ＮＣ装置においては自動運転の開始位置または編集行サーチ等の情報として活用される。シーケンス番号とブロック番号とは共にプログラム行を特定可能な情報である。

ある通信プロトコルにおいて行番号を表すデータタイプに、プログラム名またはプログラム行しか存在しない場合がある。この場合、基準スキーマにおいて、プログラム行がブロック番号として定義されていたとしても、あるベンダ（ベンダＡ）においては、プログラム行のデータタイプをシーケンス番号として定義したいかもしれない。また、あるベンダ（ベンダＢ）においては、プログラム行のデータタイプを拡張データタイプとして定義したいかもしれない。そのため、通信サーバ４０が扱う装置スキーマ定義では同一のデータタイプで定義されていたとしても、装置５０毎に内容が異なる収集データが収集される場合がある。すなわち、アプリケーション２０が基準スキーマ定義で定義するデータの内容と、各ベンダが装置スキーマ定義で定義するデータの内容とは異なる場合がある。

また、通信プロトコルで定義されている標準的なデータタイプでは無く、装置ベンダの専用仕様といえる拡張定義が適用される場合もある。これらのような場合、同じプログラム行を意図するデータタイプであったとしても、一方（ベンダＡの装置）は、データタイプがブロック番号を表したデータアイテムであり、他方（ベンダＢの装置）はシーケンス番号を表したデータアイテムとなっている場合がある。すなわち、データタイプと、データの内容（データの意味）との対応関係は、種々設定されるものである。このため、アプリケーション２０は、データタイプを手掛かりに、ベンダＡの装置データとベンダＢの装置データとを同一のデータとして取り扱うことは不可能である。

プラットフォーム３０は、収集データ設定部３１と、収集データ蓄積部３２とを有している。収集データ設定部３１は、蓄積すべき収集データの収集設定情報をエンジニアリングツール１０から受信し、受信した収集設定情報を管理する。収集設定情報では、基準スキーマのデータタイプ（以下、基準データタイプという）に対応する装置用スキーマのデータタイプ（以下、装置用データタイプという）が設定されている。すなわち、収集設定情報では、基準データのデータアイテムに付与されている基準データタイプと、装置用データのデータアイテムに付与されている装置用データタイプとが対応付けされている。具体的には、収集設定情報では、基準データタイプに対応するデータアイテムの識別子と、装置用データタイプに対応するデータアイテムの識別子とが対応付けされている。なお、収集設定情報では、基準データタイプのデータアイテムと、装置用データタイプに対応するデータアイテムの識別子とが対応付けされていてもよい。

収集データ蓄積部３２は、アプリケーション２０によって特定の基準データタイプが収集対象として指定されると、指定された基準データタイプに対応する装置データタイプを、収集設定情報から抽出する。収集データ蓄積部３２は、抽出した装置データタイプの収集データを、通信サーバ４０の収集データ生成部４２に対して要求する。例えば、収集データ蓄積部３２は、装置データタイプのデータアイテムの識別子を収集データ生成部４２に送信することで、識別子に対応する収集データを収集データ生成部４２に要求する。このように、収集データ蓄積部３２は、収集設定情報に従って、収集データ生成部４２に収集データを要求する。

収集データ蓄積部３２は、収集データ生成部４２から送られてくる収集データを受信して蓄積する。収集データ蓄積部３２は、蓄積した収集データを、アプリケーション２０からの要求に応じてアプリケーション２０に送出する。収集データ蓄積部３２が送出する収集データのデータタイプは、基本的にはアプリケーション２０が扱えるデータタイプまたはサブタイプの定義に適合している。収集データ蓄積部３２は、汎用の通信プロトコルを用いてアプリケーション２０に収集データを送信する。

エンジニアリングツール１０は、装置モデル編集部１１と、変換候補提供部１２と、装置プロファイル出力部１３とを有している。装置モデル編集部１１は、通信サーバ４０の装置モデル管理部４１から装置用データタイプを含んだ装置スキーマ定義を取得する。装置用データタイプは、装置用データタイプと、基準データタイプとの間の対応関係を示す対応関係情報を編集する際に用いられる。

装置モデル編集部１１は、装置スキーマ定義内の装置用データタイプを編集することによって、対応関係情報を編集する。対応関係情報は、ユーザが装置モデル編集部１１に編集指示を入力することによって装置モデル編集部１１で編集される。ユーザは、後述するシステム情報（装置５０の情報、アプリケーション種別および通信プロトコル種別）を参照しながら対応関係情報を編集する。

対応関係情報は、基準スキーマにおいて変換が必要となるデータアイテムの識別子に対し、装置用スキーマ内の何れのデータアイテムの識別子を通信サーバ４０から収集すべきであるかを表す情報である。換言すると、対応関係情報は、基準スキーマ定義と装置スキーマ定義との対応関係を示す情報、すなわちスキーマ定義の対応関係を示す情報である。

装置モデル編集部１１は、ユーザによる操作に基づいて、装置スキーマ定義に含まれる装置モデル等の編集を行うことで、対応関係情報の編集を行う。ここで、プラットフォーム３０は、基準スキーマ定義で定義された各データアイテムのデータタイプに適合する収集データを装置５０から収集する必要がある。

ところが、一般的にアプリケーションが必要とする基準データは、前述したように基準スキーマおよび装置用スキーマの間で、類似または同一の意味を成すデータでありながら、データタイプ定義が一致しない場合がある。このような場合、アプリケーションを改修しない前提においては、基準スキーマ定義および装置スキーマ定義の双方の仕様を良く知るシステムインテグレータによって、通信サーバで用いられる装置スキーマ定義およびプラットフォームで用いられる収集設定情報を変更する必要があった。具体的には、アプリケーションが必要とするデータタイプに適合した収集データが装置から収集されるように、システムインテグレータ等が、通信サーバに対して装置スキーマ定義を変更し、プラットフォームに対し収集設定情報を変更する必要があった。

本実施の形態では、基準スキーマと装置用スキーマとの間で変換が必要となるデータアイテムのデータタイプまたはサブタイプ等を参考に、ユーザが、装置モデル編集部１１を用いて対応関係情報の編集を行う。このとき、ユーザは、対応関係情報の編集結果から学習された情報を参照しながら、基準スキーマ定義に対応する装置スキーマ定義（装置モデル等）を編集することで、対応関係情報の編集を行う。

基準スキーマ定義は、装置モデル編集部１１に対してユーザ入力されてもよいし、装置モデル編集部１１がアプリケーション２０等の外部装置から取得してもよい。前述したように、対応関係情報は、データタイプの対応関係を示す情報である。このため、工作機械における自動運転プログラムの例では、ベンダＡの装置データを収集する必要がある場合には、装置モデル編集部１１は、基準スキーマにおけるプログラム行に対しては、シーケンス番号のデータアイテムではなくブロック番号を表すデータアイテムのデータ識別子をマッピング定義しなければならない。

装置モデル編集部１１は、対応関係情報の編集内容を含んだ編集結果を、変換候補提供部１２に送る。変換候補提供部１２は、基準データタイプに対して収集データのデータアイテム毎に装置用データタイプをマッピングさせた対応関係情報を装置プロファイル出力部１３に送信する。

また、変換候補提供部１２は、対応関係情報の編集に用いた情報、および対応関係情報の編集結果を用いて、変換ルールを学習する。換言すると、変換候補提供部１２は、ユーザによる対応関係情報の編集履歴に基づいて、変換ルールを学習する。変換ルールは、基準データタイプから装置用データタイプへの変換のルールである。すなわち、変換ルールは、基準データタイプと装置用データタイプとを対応付けするためのルールである。したがって、変換ルールを学習することは、基準データタイプに対応する装置用データタイプの候補（後述する変換候補）を学習することに対応している。

以下の説明では、対応関係情報の編集に用いた情報をシステム情報という。システム情報には、装置５０の情報である「装置情報」と、アプリケーション２０の種別である「アプリケーション種別」と、通信サーバ４０とプラットフォーム３０との間の通信プロトコルの種別である「通信プロトコル種別」との少なくとも１つが含まれている。「装置情報」には、装置５０を製造した装置メーカの種別である「装置メーカ種別」と、装置５０の種別である「装置種別」と、装置５０の構成である「装置構成」との少なくとも１つが含まれている。対応関係情報の編集結果は、基準データタイプと、装置用データタイプとの対応付けの結果である。

「装置情報」、「通信プロトコル種別」および「アプリケーション種別」は、例えば、ユーザによって変換候補提供部１２に入力される。なお、変換候補提供部１２は、「装置情報」および「通信プロトコル種別」の少なくとも一方を装置スキーマ定義から抽出してもよい。また、変換候補提供部１２は、「アプリケーション種別」をアプリケーション２０から取得してもよい。

変換候補提供部１２は、システム情報および基準データタイプを状態変数として観測する。また、アプリケーション２０は、教師データを取得する。そして、変換候補提供部１２は、状態変数および教師データの組み合せに基づいて作成されるデータセットに従って、変換ルールを学習する。教師データは、ユーザによって基準データタイプに対応付けされた装置用データタイプである。以下の説明では、ユーザによって基準データタイプに対応付けされた装置用データタイプを「変換後データタイプ」という。教師データとしての「変換後データタイプ」は、基準データタイプに対応するよう、実際にユーザによって設定された装置用データタイプ（データタイプ変換結果）である。

装置モデル編集部１１は、装置モデルを編集するので、対応関係情報は編集後の装置モデル（編集後モデル）を含んでいる。変換候補提供部１２は、基準データタイプの内容と装置用データタイプの内容とが一致または類似する装置用データタイプを出力することができる変換ルール、すなわち変換候補を学習する。

変換候補提供部１２は、装置５０毎に、または通信サーバ４０とプラットフォーム３０との間の通信プロトコル毎に、またはアプリケーション２０毎に状態変数を観測する。変換候補提供部１２は、装置モデル管理部４１から取得した装置スキーマ定義等と、装置モデル編集部１１における編集内容とから状態変数を観測する。すなわち、変換候補提供部１２は、例えば、システム情報である、「装置情報」、「アプリケーション種別」、および「通信プロトコル種別」を状態変数として観測する。

また、変換候補提供部１２は、対応関係情報に設定された基準データタイプを状態変数として観測する。すなわち、変換候補提供部１２は、装置モデル編集部１１でのデータタイプの変換結果（マッピング結果）である対応関係情報のうちの基準データタイプを状態変数として観測する。

変換候補提供部１２は、学習の結果得られた変換ルールを用いて、基準データタイプに対応させる装置用データタイプの候補（以下、変換候補という）を算出する。換言すると、本実施の形態の変換候補提供部１２は、対応関係情報の編集結果の履歴に基づいて、対応関係情報に設定される、装置用データタイプの候補（変換候補）を算出する。基準データタイプにマッピングされた装置データタイプを含む対応関係情報は、アプリケーション２０がデータアイテム毎に各収集データを特定可能なデータタグ名などの識別子を含んでいる。対応関係情報では、通信サーバ４０が扱う収集データのデータアイテムの識別子と、アプリケーション２０が扱うデータのデータアイテムの識別子とが対応付けされている。対応関係情報に含まれる識別子のうち、通信サーバ４０が扱うデータアイテムの識別子は装置用スキーマに含まれていた識別子であり、アプリケーション２０が扱うデータアイテムの識別子は基準スキーマに含まれていた識別子である。

変換候補提供部１２は、マッピングさせる基準データタイプがユーザによって指定された場合、指定された基準データタイプに対応する変換候補を推定する。変換候補提供部１２は、学習した変換ルールに基づいて、変換候補を推定する。変換候補は、基準データタイプに対して変換候補となる装置用データタイプである。換言すると、変換候補は、基準スキーマに対応付けされる装置用スキーマのデータタイプの変換候補である。変換候補提供部１２は、変換候補を装置モデル編集部１１に送る。

また、変換候補提供部１２は、装置モデル編集部１１から出力用の対応関係情報が送られてきた場合には、この対応関係情報を装置プロファイル出力部１３に出力する。

装置プロファイル出力部１３は、対応関係情報を用いて収集設定情報を生成する。装置プロファイル出力部１３は、収集設定情報を必要に応じてプロトコル変換し、プラットフォーム３０の収集データ設定部３１に送る。

エンジニアリングツール１０は、液晶モニタといった表示装置（図示せず）に、装置スキーマ定義、装置用データタイプ、システム情報、基準スキーマ定義、基準データタイプ、変換ルール、対応関係情報の編集結果、変換候補等を表示させる。

ユーザは、表示装置に表示された変換候補を参照しながら、対応関係情報を編集する。データ収集システム１では、ユーザによる対応関係情報の編集と、エンジニアリングツール１０による変換ルールの学習とが繰り返される。

このような構成により、エンジニアリングツール１０は、基準データタイプと装置用データタイプとの両方の知見が不足しているユーザに対しても、基準データタイプに対応する変換候補を提供することができる。

つぎに、変換候補提供部１２の詳細な構成について説明する。図２は、実施の形態にかかるエンジニアリングツールが備える変換候補提供部の構成を示す図である。変換候補提供部１２は、データ選択部１２１と、変換ルール学習部１２２と、変換候補推定部１２３と、装置モデル補正部１２４とを具備している。

データ選択部１２１、変換ルール学習部１２２、変換候補推定部１２３、および装置モデル補正部１２４は、装置モデル編集部１１に接続されている。また、変換候補推定部１２３は、データ選択部１２１、変換ルール学習部１２２、および装置モデル補正部１２４に接続されている。また、装置モデル補正部１２４は、装置プロファイル出力部１３に接続されている。

装置モデル編集部１１は、ユーザによって対応関係情報が編集された際には、対応関係情報を装置モデル補正部１２４に送る。また、装置モデル編集部１１は、変換候補提供部１２が変換ルール（変換候補）を学習する際には、編集結果を示す対応関係情報を、変換ルール学習部１２２に送る。また、装置モデル編集部１１は、変換候補提供部１２が、変換候補を推定する際には、編集中の対応関係情報を、データ選択部１２１に送る。また、装置モデル編集部１１は、変換候補提供部１２から変換候補（図２では、「変換候補」と図示）を取得する。

変換ルール学習部１２２は、機械学習装置であり、システム情報および基準データタイプを状態変数として観測し、状態変数および変換後データタイプに基づいて学習用モデルである変換ルールを学習する。変換ルール学習部１２２は、基準スキーマに対する装置用スキーマのデータタイプの変換結果を用いることで、装置５０に応じたデータタイプの変換ルールを学習する。変換ルール学習部１２２は、学習した変換ルールを変換候補推定部１２３に出力する。

データ選択部１２１は、変換候補推定部１２３が基準データタイプに対応する変換候補を推定する際に、装置モデル編集部１１での編集状態を示す編集情報を、装置モデル編集部１１から取得する。

データ選択部１２１が装置モデル編集部１１から取得する編集情報は、基準スキーマに対して編集中の基準データタイプと、システム情報とを含んでいる。データ選択部１２１は、編集情報から、装置用データタイプにマッピングさせる基準データタイプを選択して抽出する。装置用データタイプにマッピングさせる基準データタイプは、装置用データタイプと基準データタイプとでデータタイプの内容またはデータタグ名が異なる基準データタイプである。

データ選択部１２１が装置モデル編集部１１から取得する基準データタイプおよびシステム情報は、後述する状態観測部が観測する状態変数と同様の情報である。以下、データ選択部１２１が抽出した基準データタイプ、およびシステム情報を推定用データという。データ選択部１２１は、推定用データを変換候補推定部１２３に出力する。

変換候補推定部１２３は、変換ルール学習部１２２から出力された学習モデルである変換ルールおよびデータ選択部１２１から出力された推定用データに基づいて、装置５０から収集すべき変換候補を推定する。変換候補推定部１２３は、変換ルールの学習に用いた装置５０とは異なる装置に対して、変換候補を推定してもよい。また、変換候補推定部１２３は、変換ルールの学習に用いたアプリケーション２０とは異なるアプリケーションに対して、変換候補を推定してもよい。変換候補推定部１２３は、推定した変換候補を装置モデル編集部１１および装置モデル補正部１２４に出力する。

装置モデル補正部１２４は、変換候補推定部１２３から送られてきた変換候補と、装置モデル編集部１１から送られてきた対応関係情報とに基づいて、装置モデル編集部１１で編集漏れ等の不備があったか否かを判定する。装置モデル補正部１２４は、装置モデル編集部１１で編集の不備があった場合、対応関係情報の自動修正を行い、自動修正した対応関係情報を装置プロファイル出力部１３に出力する。編集の不備の例は、対応関係情報において、装置データタイプが記載されていない等である。

本実施の形態における装置スキーマ定義の内容は、収集可能な収集データを特定するための、装置５０の種別と、活用する収集データを特定するためのアプリケーション２０の種別と、装置５０のベンダと、アプリケーション２０のベンダと、通信プロトコルの種別との組み合せによって概ね定まる。

元々、装置用スキーマのデータアイテムと基準スキーマのデータアイテムとの間にはマッピングが必要である。本実施の形態では、エンジニアリングツール１０が、装置用スキーマを特徴付けるための、「装置メーカ種別」、「装置種別」、「装置構成」等の「装置情報」、基準スキーマを特徴付けるための「アプリケーション種別」、および装置用スキーマを特定するための「通信プロトコル種別」等を状態変数として観測している。これにより、エンジニアリングツール１０は、変換候補の推定処理に用いられる変換ルールの学習精度を上げることができるので、装置用データタイプの適切な変換候補をユーザに教示することが可能となる。

変換ルールが学習される前に対応関係情報を編集するのが、ユーザのうちの第１のユーザであり、推定された変換候補に基づいて対応関係情報を編集するのが、ユーザのうちの第２のユーザである。

また、変換ルールの学習対象とされる装置５０が、装置のうちの第１の装置であり、変換候補の推定対象となる装置５０が、装置のうちの第２の装置である。また、第１の装置から収集されるデータが第１の収集データであり、第２の装置から収集されるデータが第２の収集データである。

また、変換ルールの学習対象とされるアプリケーション２０が、アプリケーションのうちの第１のアプリケーションであり、変換候補の推定対象となるアプリケーション２０が、アプリケーションのうちの第２のアプリケーションである。また、第１のアプリケーションが解釈可能な基準データが、第１の基準データであり、第２のアプリケーションが解釈可能な基準データが、第２の基準データである。

また、第１のユーザによって編集される対応関係情報が第１の対応関係情報であり、第２のユーザによって編集される対応関係情報が第２の対応関係情報である。第１の対応関係情報では、第１の装置用データタイプと第１の基準データタイプとが対応付けされ、第２の対応関係情報では、第２の装置用データタイプと第２の基準データタイプとが対応付けされる。

また、第１の対応関係情報の編集に用いられるシステム情報が第１のシステム情報であり、第２の対応関係情報の編集に用いられるシステム情報が第２のシステム情報である。また、第１のシステム情報に含まれる情報が、第１の装置情報、第１のアプリケーションの種別、および第１の通信プロトコルの種別である。また、第２のシステム情報に含まれる情報が、第２の装置情報、第２のアプリケーションの種別、および第２の通信プロトコルの種別である。

なお、第１のユーザと第２のユーザは、異なるユーザであってもよいし、同じユーザであってもよい。また、第１の装置と第２の装置とは、異なる装置であってもよいし、同じ装置であってもよい。また、第１のアプリケーションと第２のアプリケーションは、異なるアプリケーショであってもよいし、同じアプリケーションであってもよい。

図３は、実施の形態にかかるエンジニアリングツールが備える変換ルール学習部の構成を示す図である。図４は、実施の形態にかかるエンジニアリングツールが用いるニューラルネットワークの構成を示す図である。

変換ルール学習部１２２は、データ取得部７１と、状態観測部７２と、学習部７３とを有している。データ取得部７１は、装置モデル編集部１１から教師データを取得する。教師データは、編集された対応関係情報（対応関係情報の編集結果）に含まれている装置用データタイプ、すなわち変換後データタイプである。データ取得部７１は、教師データを学習部７３に送信する。

状態観測部７２は、システム情報を装置モデル編集部１１から取得するとともに、編集された対応関係情報から基準データタイプを抽出する。状態観測部７２は、システム情報および基準データタイプを状態変数として観測する。状態観測部７２は、システム情報および基準データタイプを学習部７３に送信する。

学習部７３は、状態観測部７２から出力されるシステム情報および基準データタイプと、教師データである変換後データタイプとの組み合せに基づいて作成されるデータセットに基づいて、変換候補（学習内容）を導出するための変換ルールを学習する。ここで、データセットは、状態変数および教師データを互いに関連付けたデータである。

なお、変換ルール学習部１２２は、エンジニアリングツール１０に設けられるものに限られない。変換ルール学習部１２２は、エンジニアリングツール１０の外部の装置に設けられてもよい。変換ルール学習部１２２は、ネットワーク回線６０を介してエンジニアリングツール１０に接続可能な装置に設けられてもよい。すなわち、変換ルール学習部１２２は、ネットワーク回線６０を介してエンジニアリングツール１０に接続された別個のコンポーネントであってもよい。また、変換ルール学習部１２２は、クラウドサーバ上に存在していてもよい。

変換ルール学習部１２２は、例えばニューラルネットワークモデルに従って、いわゆる教師あり学習により、通信サーバ４０から収集した装置スキーマ定義に含まれる装置モデルのデータタイプ（装置データタイプ）に基づいて変換候補を学習する。ここで、教師あり学習とは、ある入力と結果（ラベル）のデータとの組を大量に機械学習装置に与えることで、それらのデータセットから得られる特徴を学習し入力から結果を推定するモデルをいう。

ニューラルネットワークは、複数のニューロンからなる入力層Ｘ１〜Ｘｐ（ｐは自然数）、複数のニューロンからなる中間層（隠れ層）Ｙ１〜Ｙｑ（ｑは自然数）、および複数のニューロンからなる出力層Ｚ１〜Ｚｒ（ｒは自然数）で構成される。中間層Ｙ１〜Ｙｑは、１層、または２層以上でもよい。入力層Ｘ１〜Ｘｐは、中間層Ｙ１〜Ｙｑに接続され、中間層Ｙ１〜Ｙｑは出力層Ｚ１〜Ｚｒに接続されている。なお、図４に示す入力層Ｘ１〜Ｘｐと中間層Ｙ１〜Ｙｑとの接続は一例であり、各入力層Ｘ１〜Ｘｐは、何れの中間層Ｙ１〜Ｙｑに接続されてもよい。また、図４に示す中間層Ｙ１〜Ｙｑと出力層Ｚ１〜Ｚｒとの接続は一例であり、各中間層Ｙ１〜Ｙｑは何れの出力層Ｚ１〜Ｚｒに接続されてもよい。

例えば、図４に示すような３層のニューラルネットワークであれば、複数の入力が入力層Ｘ１〜Ｘｐに入力されると、その値に重みＡ１〜Ａａ（ａは自然数）が掛けられて中間層Ｙ１〜Ｙｑに入力される。中間層Ｙ１〜Ｙｑに入力された値は、さらに重みＢ１〜Ｂｂ（ｂは自然数）が掛けられて出力層Ｚ１〜Ｚｒに入力され、出力層Ｚ１〜Ｚｒから出力される。ここでの出力結果は、変換候補Ｔ１〜Ｔ３として図示している。この出力結果は、重みＡ１〜ＡａとＢ１〜Ｂｂの値によって変わる。

本実施の形態のニューラルネットワークは、状態観測部７２によって観測されるシステム情報および基準データタイプと、データ取得部７１によって取得される変換後データタイプとの組み合せに基づいて作成されるデータセットに従って、いわゆる教師あり学習により、変換ルールを学習する。

すなわち、ニューラルネットワークは、入力層Ｘ１〜Ｘｐにシステム情報および基準データタイプを入力して出力層Ｚ１〜Ｚｒから出力された結果が、変換後データタイプに近づくように重みＡ１〜ＡａとＢ１〜Ｂｂを調整することで学習する。

入力層Ｘ１〜Ｘｐに入力される情報は、例えば、「通信プロトコル種別」、「アプリケーション種別」、「基準データタイプｎ」（ｎは自然数）、「装置メーカ種別」、「装置種別」、および「装置構成」である。

「アプリケーション種別」の例は、稼働監視のアプリケーション、工程管理のアプリケーション、品質管理のアプリケーション、保全のアプリケーション等である。「装置種別」の例は、マシニングセンタ、複合加工機、レーザ加工機、放電加工機等である。「装置構成」の例は、系統数、軸情報、周辺機器等である。「変換候補」は、「基準データタイプ」に対応付けされる可能性が高い「装置データタイプ」である。

変換候補提供部１２は、新たなシステム情報および新たな基準データタイプを受付けた場合には、学習済みの変換ルール（図４に示したニューラルネットワーク等）を用いて変換候補を算出する。

図５は、実施の形態にかかるエンジニアリングツールによる機械学習時の動作手順を示すフローチャートである。変換ルール学習部１２２は、学習用データを取得する。具体的には、変換ルール学習部１２２は、装置モデル編集部１１から、基準スキーマ定義、装置スキーマ定義、およびユーザによる対応関係情報の編集結果を、学習用データとして取得する（ステップＳ１０１）。

変換ルール学習部１２２は、学習用データから、変換前後のデータタイプの関係を学習し、変換ルールである学習モデルを生成する（ステップＳ１０２）。変換前後のデータタイプの関係は、基準データタイプと装置用データタイプとの対応関係を示す対応関係情報である。変換ルール学習部１２２が学習する変換ルールは、アプリケーション２０が解釈可能な基準データタイプに対し、装置５０から収集可能な変換候補を推定することができる学習モデルである。変換ルール学習部１２２は、例えば、教師あり学習によって、学習用データを元に変換ルールを学習する。

また、ニューラルネットワークは、いわゆる教師なし学習によって、変換候補を学習することもできる。教師なし学習とは、入力データのみを大量に機械学習装置に与えることで、入力データがどのような分布をしているかを学習し、対応する教師データ（出力データ）を与えなくても、入力データに対して圧縮、分類、整形等を行い学習する手法である。教師なし学習では、データセットにある特徴を似たもの同士にクラスタリングすること等ができる。教師なし学習では、このクラスタリングの結果を使って、何らかの基準を設けて、この基準を最適にするような出力の割り当てを行うことで、出力の予測を実現することができる。また、教師なし学習と教師あり学習との中間的な問題設定として、半教師あり学習と呼ばれるものもある。半教師あり学習は、一部のみ入力と出力のデータの組が存在し、それ以外は入力のみのデータである場合の学習である。

また、学習部７３は、特徴量そのものの抽出を学習する深層学習（Deep Learning）を学習アルゴリズムとして用いることもできる。また、学習部７３は、他の公知の方法、例えば遺伝的プログラミング、機能論理プログラミング、サポートベクターマシンなどに従って機械学習を実行してもよい。

つぎに、エンジニアリングツール１０が、変換ルールを用いて変換候補を算出する際の処理について説明する。図６は、実施の形態にかかるエンジニアリングツールによるデータ推定時の動作手順を示すフローチャートである。

データ選択部１２１は、装置モデル編集部１１にて編集中の基準データタイプと、システム情報とを、推定用データとして装置モデル編集部１１から取得する（ステップＳ２０１）。編集中の基準データタイプは、装置用データタイプに対応付けされる前（変換前）の基準データタイプである。データ選択部１２１は、推定用データを変換候補推定部１２３に出力する。

変換候補推定部１２３は、データ選択部１２１から出力された推定用データを受け付ける。また、変換候補推定部１２３は、変換ルール学習部１２２から出力された学習モデルである変換ルールを受け付ける。

変換候補推定部１２３は、推定用データおよび学習モデルを用いて、装置用データタイプの変換候補を推定する（ステップＳ２０２）。学習モデルの例は、図４に示したニューラルネットワークであり、推定用データは、ニューラルネットワークの入力層Ｘ１〜Ｘｐに入力される。すなわち、通信プロトコル種別、アプリケーション種別といったシステム情報が、ニューラルネットワークの入力層Ｘ１〜Ｘｐに入力される。ニューラルネットワークの出力層Ｚ１〜Ｚｒから出力されるデータが、変換候補である。

変換候補推定部１２３は、基準データタイプの編集中である装置モデル編集部１１に対して、変換候補を教示する（ステップＳ２０３）。すなわち、変換候補推定部１２３は、基準データタイプに適合させるべき装置用データタイプ（装置５０のデータモデル）を編集中の装置モデル編集部１１に対して、装置５０から収集可能なデータである変換候補を教示する。具体的には、変換候補推定部１２３は、推定した変換候補を装置モデル編集部１１に送る。ユーザは、変換候補の中から所望の装置用データタイプを選択する選択指示を装置モデル編集部１１に入力する。装置モデル編集部１１は、選択指示に従って、装置用データタイプと、編集中の基準データタイプとを対応付けする。これにより、装置モデル編集部１１は、対応関係情報を編集する。

このように、変換候補が複数教示された場合、装置モデル編集部１１にてユーザの選択操作が反映される。変換ルール学習部１２２は、ユーザによって選択された変換候補にはプラスの評価を行うもしくは選択されなかった候補にはマイナスの評価を行うなどのいわゆる強化学習を行う。すなわち、変換ルール学習部１２２は、ユーザによって選択された装置用データタイプを用いて変換ルールを再学習する。これにより、変換ルール学習部１２２は、装置用データタイプの実際の使用頻度に即した変換ルールを提供することが可能となる。

装置モデル編集部１１は、ユーザに編集された対応関係情報を装置モデル補正部１２４に送る。また、変換候補推定部１２３は、変換候補を装置モデル補正部１２４に送る。

装置モデル補正部１２４は、装置モデル編集部１１の出力結果である対応関係情報に対し、教示結果である変換候補を用いて、装置スキーマ定義を修正する（ステップＳ２０４）。装置モデル補正部１２４は、例えば、装置モデル編集部１１による編集操作によって装置スキーマ定義の定義漏れなどの不備があった場合に、不備のあった装置スキーマ定義を適切な変換ルールに従った装置スキーマ定義に自動修正する。装置モデル補正部１２４は、必要に応じて装置スキーマ定義を修正した対応関係情報を、装置プロファイル出力部１３に出力する。

装置プロファイル出力部１３は、対応関係情報を含んだ収集設定情報を生成する。装置プロファイル出力部１３は、収集設定情報を必要に応じてプロトコル変換し、プラットフォーム３０の収集データ設定部３１に送る。これにより、収集データ設定部３１が収集設定情報を設定する。そして、プラットフォーム３０の収集データ蓄積部３２は、アプリケーション２０からデータ要求があった場合には、収集設定情報に従って通信サーバ４０にデータ要求を行う。具体的には、収集データ蓄積部３２は、アプリケーション２０から要求があったデータを基準データタイプのデータとし、この基準データタイプに対応する装置用データタイプのデータを通信サーバ４０に要求する。収集データ蓄積部３２は、装置用データタイプの識別子を通信サーバ４０に送信することによって、装置用データタイプのデータを通信サーバ４０から取得する。収集データ蓄積部３２は、取得した装置用データタイプのデータをアプリケーション２０に送る。

これらの仕組みにより、本実施の形態のエンジニアリングツール１０のユーザは、アプリケーション２０における基準スキーマ定義（アプリケーション２０におけるデータモデル）および装置５０における装置スキーマ定義（装置５０におけるデータモデル）の仕様を知ることなく、アプリケーション２０のデータモデルに適合したデータ収集設定をプラットフォーム３０に行うことができる。

プラットフォーム３０は、「装置情報」、「通信プロトコル種別」、または「アプリケーション種別」によって装置スキーマ定義（外部出力可能なデータの定義）に差異があっても、アプリケーション２０に対しては一意のデータ定義となるように収集データを収集することができる。これにより、アプリケーション２０は、「装置情報」、「通信プロトコル種別」、または「アプリケーション種別」等に依存せずプラットフォーム３０で収集された収集データを統合的に利活用することができる。

ところで、一般的には、ＩｏＴプラットフォームまたは通信サーバで、アプリケーションと装置との間のデータの整合を取る場合、生産現場にて装置およびアプリケーション双方のデータ仕様を考慮しながら装置毎のコンフィグレーション作業を行うことになる。この作業は、システム規模に応じた多くの工数がかかり、特にコンフィグレーションツールが普及していない通信プロトコルを扱う場合には大きな課題となる。また、ＩｏＴプラットフォームまたは通信サーバで、アプリケーションと装置との間のデータの整合を取る場合、装置およびアプリケーション双方のデータ仕様を良く知るシステムインテグレータが仲介してシステム構築作業の一環として一括してコンフィグレーションが行われる。このため、システム構築にかかるコストが高くなること、または立上げ時間が長くなることが課題となる。

一方、本実施の形態では、エンジニアリングツール１０が、変換候補を推定しているので、ユーザは、容易かつ短時間で対応関係情報を編集することができる。したがって、低いコストかつ短時間でデータ収集システム１が構築される。

なお、データ収集システム１は、製造実行システム（ＭＥＳ：Manufacturing Execution System）、企業資源計画（ＥＲＰ：Enterprise Resource Planning）といった、アプリケーション２０よりも上位のＩＴシステム層でのデータ活用に適用されてもよい。また、データ収集システム１は、生産現場近傍でのエッジコンピューティングによるデータ分析に適用されてもよく、エッジコンピューティングによる診断結果を装置５０へリアルタイムフィードバックしてもよい。これにより、データ収集システム１は、生産設備の高稼働化を実現することができる。

以上のように、実施の形態によれば、エンジニアリングツール１０が、対応関係情報の編集結果に基づいて変換ルールを学習し、アプリケーション２０が解釈可能な基準データタイプに対する装置用データタイプへの変換候補を、変換ルールを用いて推定するので、アプリケーション２０が解釈可能な基準データタイプに対応する装置用データタイプの変換候補を提供することができる。したがって、アプリケーション２０が解釈可能な基準データタイプが装置用データタイプに対応付けされていない場合であっても、基準データタイプに対応する変換候補を提供することができる。

データ収集システム１は、学習した変換ルールに基づいて、プラットフォーム３０でのデータ収集設定を自動で行うことができるので、プラットフォーム３０におけるデータ変換作業が省力化される。データ収集システム１は、新たに接続する装置、または対応すべき通信プロトコルが増えた場合であっても、アプリケーション２０での改修が不要であり、迅速な接続設定およびシステム構築が可能となる。

また、エンジニアリングツール１０は、プラットフォーム３０とは分離されているので、エンジニアリングツール１０は、装置５０からの遠隔地においても収集データの変換ルールを編集して出力することができる。したがって、データ収集システム１は、セットアップ作業におけるベンダ間の役割を柔軟に分担させることができるので、システム構築コストの低減を図ることができるとともに、システム立上げ時間の短縮を図ることができる。

また、変換ルールに対応する装置スキーマ定義は、標準的なモデリング記述言語による装置プロファイルとして出力可能であるので、様々な産業用プラットフォームに適用可能となる。

ここで、エンジニアリングツール１０を動作させるコンピュータのハードウェア構成について説明する。図７は、実施の形態にかかるエンジニアリングツールを動作させるコンピュータを実現するハードウェア構成の第１例を示す図である。図８は、実施の形態にかかるエンジニアリングツールを動作させるコンピュータを実現するハードウェア構成の第２例を示す図である。

エンジニアリングツール１０を動作させるコンピュータは、図７に示したプロセッサ５０１、メモリ５０２、およびインタフェース５０４により実現することができる。プロセッサ５０１は、ＣＰＵ（Central Processing Unit、ＦＰＧＡ（Field-Programmable Gate Array）、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサ、ＤＳＰ（Digital Signal Processor）ともいう）、システムＬＳＩ（Large Scale Integration）などである。メモリ５０２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）などである。

メモリ５０２には、エンジニアリングツール１０の機能を実行するプログラムが格納されている。プロセッサ５０１は、メモリ５０２で記憶されているプログラムを読み出して実行することによって、エンジニアリングツール１０による処理を実行する。メモリ５０２に格納されているプログラムは、エンジニアリングツール１０の手順または方法に対応する複数の命令をコンピュータに実行させるものであるともいえる。メモリ５０２は、プロセッサ５０１が各種処理を実行する際の一時メモリとしても使用される。

プロセッサ５０１が実行するプログラムは、コンピュータで実行可能な、データ処理を行うための複数の命令を含むコンピュータ読取り可能かつ非遷移的な（non-transitory）記録媒体を有するコンピュータプログラムプロダクトであってもよい。すなわち、エンジニアリングツール１０は、プログラムが記録されたコンピュータが読み取り可能な媒体で実現されてもよい。

なお、図７に示すプロセッサ５０１およびメモリ５０２は、図８に示す処理回路５０３に置き換えられてもよい。処理回路５０３は、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、又は、これらを組み合わせたものが該当する。なお、エンジニアリングツール１０の機能について、一部を専用のハードウェアで実現し、一部をソフトウェアまたはファームウェアで実現するようにしてもよい。

また、アプリケーション２０、プラットフォーム３０、および通信サーバ４０の少なくとも１つを、エンジニアリングツール１０を動作させるコンピュータと同様のハードウェア構成で実現してもよい。

以上の実施の形態に示した構成は、本発明の内容の一例を示すものであり、別の公知の技術と組み合わせることも可能であるし、本発明の要旨を逸脱しない範囲で、構成の一部を省略、変更することも可能である。

１ データ収集システム、１０ エンジニアリングツール、１１ 装置モデル編集部、１２ 変換候補提供部、１３ 装置プロファイル出力部、２０ アプリケーション、３０ プラットフォーム、３１ 収集データ設定部、３２ 収集データ蓄積部、４０ 通信サーバ、４１ 装置モデル管理部、４２ 収集データ生成部、５０ 装置、５１ 装置データ出力部、６０ ネットワーク回線、７１ データ取得部、７２ 状態観測部、７３ 学習部、１２１ データ選択部、１２２ 変換ルール学習部、１２３ 変換候補推定部、１２４ 装置モデル補正部、５０１ プロセッサ、５０２ メモリ、５０３ 処理回路、５０４ インタフェース、Ｔ１〜Ｔ３ 変換候補、Ｘ１〜Ｘｐ 入力層、Ｙ１〜Ｙｑ 中間層、Ｚ１〜Ｚｒ 出力層。

Claims (9)

1. 第１のユーザからの指示に基づいて、第１の装置から収集される第１の収集データのデータタイプである第１の装置用データタイプと、第１のアプリケーションが解釈可能な第１の基準データのデータタイプである第１の基準データタイプとの対応関係を示す第１の対応関係情報を編集する編集部と、
   前記第１の対応関係情報の編集結果に基づいて、前記第１の基準データタイプから前記第１の装置用データタイプへの変換のルールである変換ルールを学習し、第２のアプリケーションが解釈可能な第２の基準データのデータタイプである第２の基準データタイプに対する、第２の装置から収集される第２の収集データのデータタイプである第２の装置用データタイプへの変換候補を、前記変換ルールを用いて推定する変換候補提供部と、
   を備えることを特徴とするエンジニアリングツール。
2. 前記編集部は、前記第１の装置の情報である第１の装置情報、前記第１の装置に対応する第１の通信プロトコルの種別、および前記第１のアプリケーションの種別の少なくとも１つを含んだ情報である第１のシステム情報に基づいて、前記第１の対応関係情報を編集し、
   前記変換候補提供部は、前記第２の装置の情報である第２の装置情報、前記第２の装置に対応する第２の通信プロトコルの種別、および前記第２のアプリケーションの種別の少なくとも１つを含んだ情報である第２のシステム情報に基づいて、前記変換候補を推定する、
   ことを特徴とする請求項１に記載のエンジニアリングツール。
3. 前記第１の装置情報には、前記第１の装置を製造した装置メーカの種別、前記第１の装置の種別と、前記第１の装置の構成との少なくとも１つが含まれ、
   前記第２の装置情報には、前記第２の装置を製造した装置メーカの種別、前記第２の装置の種別と、前記第２の装置の構成との少なくとも１つが含まれている、
   ことを特徴とする請求項２に記載のエンジニアリングツール。
4. 前記変換候補提供部は、
   前記変換ルールを学習する変換ルール学習部を有し、
   前記変換ルール学習部は、
   前記第１のシステム情報および前記第１の基準データタイプを含む状態変数を観測する状態観測部と、
   前記第１の装置用データタイプを取得するデータ取得部と、
   前記状態変数および前記第１の装置用データタイプの組み合わせに基づいて作成されるデータセットに従って、前記変換ルールを学習する学習部と、
   を具備する、
   ことを特徴とする請求項２に記載のエンジニアリングツール。
5. 第２のユーザが、前記変換候補の中から前記第２の基準データタイプに対応する前記第２の装置用データタイプを選択すると、
   前記編集部は、選択された前記第２の装置用データタイプと、前記第２の基準データタイプとの対応関係を示す第２の対応関係情報を編集し、
   前記変換候補提供部は、前記第２の対応関係情報の編集結果に基づいて、前記変換ルールを再学習する、
   ことを特徴とする請求項１から４の何れか１つに記載のエンジニアリングツール。
6. 前記第１の対応関係情報は、前記第１の収集データのスキーマ定義を示す装置スキーマ定義と、前記第１の基準データのスキーマ定義を示す基準スキーマ定義と、に対応する情報である、
   ことを特徴とする請求項１から５の何れか１つに記載のエンジニアリングツール。
7. ユーザからの指示に基づいて、装置から収集される収集データのデータタイプである装置用データタイプと、アプリケーションが解釈可能な基準データのデータタイプである基準データタイプとの対応関係を示す対応関係情報が編集されると、前記対応関係情報に含まれる前記基準データタイプと、前記対応関係情報が編集される際に参照された情報であるシステム情報と、を含む状態変数を観測する状態観測部と、
   前記対応関係情報に含まれる前記装置用データタイプを取得するデータ取得部と、
   前記状態変数および前記装置用データタイプの組み合わせに基づいて作成されるデータセットに従って、前記基準データタイプから前記装置用データタイプへの変換のルールである変換ルールを学習する学習部と、
   を備えることを特徴とする学習装置。
8. 装置から収集データを収集する通信サーバと、
   前記収集データに基づいて前記装置が配置されている設備の状態情報を算出するアプリケーションと、
   前記収集データのデータタイプである装置用データタイプと、前記アプリケーションが解釈可能な基準データのデータタイプである基準データタイプとの対応関係を示す対応関係情報に基づいて、前記アプリケーションから要求のあったデータに対応する収集データを前記通信サーバから取得して前記アプリケーションに送信するプラットフォームと、
   ユーザからの指示に基づいて、前記対応関係情報を編集するエンジニアリングツールと、
   を有し、
   前記エンジニアリングツールは、
   ユーザのうちの第１のユーザからの指示に基づいて、前記装置のうちの第１の装置から収集される第１の収集データのデータタイプである第１の装置用データタイプと、前記アプリケーションのうちの第１のアプリケーションが解釈可能な第１の基準データのデータタイプである第１の基準データタイプとの対応関係を示す対応関係情報を編集する編集部と、
   前記対応関係情報の編集結果に基づいて、前記第１の基準データタイプから前記第１の装置用データタイプへの変換のルールである変換ルールを学習し、前記アプリケーションのうちの第２のアプリケーションが解釈可能な第２の基準データのデータタイプである第２の基準データタイプに対する、前記装置のうちの第２の装置から収集される第２の収集データのデータタイプである第２の装置用データタイプへの変換候補を、前記変換ルールを用いて推定する変換候補提供部と、
   を備えることを特徴とするデータ収集システム。
9. 前記変換候補提供部は、前記変換候補を前記編集部に送り、
   ユーザのうちの第２のユーザが、前記変換候補の中から前記第２の基準データタイプに対応する前記第２の装置用データタイプを選択すると、
   前記編集部は、選択された前記第２の装置用データタイプと、前記第２の基準データタイプとの対応関係を示す第２の対応関係情報を編集し、
   前記プラットフォームは、前記編集部から送られてきた前記対応関係情報に基づいて、前記第２のアプリケーションから要求のあったデータに対応する収集データを前記通信サーバから取得して前記第２のアプリケーションに送信する、
   ことを特徴とする請求項８に記載のデータ収集システム。

Images