JP6676778B2 - 管理計算機、データ処理システムおよびデータ処理プログラム - Google Patents

Description

本発明は、センサデータ等のデータ処理経路、および処理方式等を制御するIoTデータ処理装置に関する。

近年、様々な機器をインターネットへ接続するInternet of Things（IoT）が注目を集おり、これら機器から収集されたデータを活用する業務が増加している。

インターネットへ接続されるIoT機器は、例えば温度や圧力、振動等の様々なセンサデータを提供でき、これらセンサデータはゲートウェイとよばれる機器を介して収集される。収集されたセンサデータは、例えば整形や不要なものを除去するクレンジングや、統計的な手法による集計や、分析等の処理を施される。そして処理結果である処理済みデータは、クラウド上で動作する業務アプリケーションによって活用されている。

本発明の背景技術として、例えば国際公開第２０１３／１２１５７２号（特許文献１）がある。特許文献１には「１つのシステム内で流通するデータを取得しデータベースに蓄積し、該データベースに対する自システム内のアプリケーションまたは他システムからのアクセスを提供する場合、データの大量発生、変換処理の高負荷等のためにデータが滞留してアプリケーションからの性能要求を達成できない、データが喪失する、等の不具合が生じ得る。(1)「受信」「解析」「変換」「送信」の階層に分けて、各階層の処理モジュールはプラグイン化可能とする。(2)データの種別、重要度、頻度等及び該当データを使用するアプリケーションの処理タイミングに基づいて優先度を決定しデータを振り分ける。(3)変換定義との不一致により変換不能となったデータを別に蓄積・管理する。アプリケーションに対しては該当データの一覧を提示する。」技術が開示されている。

国際公開第２０１３／１２１５７２号

IoT機器のデータを活用した業務のプロセスは頻繁に変化することが考えられる。例えば、工場等の機械に取り付けられたセンサデータを収集し分析することで、故障の発生を検知する業務が定常的に行われている場合を考える。この業務は、故障が発生したことを契機として、故障の原因を調査する業務や、対策を実施する業務等へ、業務プロセスが変化する。それぞれの業務でアプリケーション(アプリ)が必要とする処理済みデータや、処理済みデータの元となるセンサデータの種別、収集されたセンサデータの処理方法は異なる。

加えて、例えば地震が発生した地域の工場に設置された機器の故障をより正確に検知するため、地震発生前と比較して、当該工場内に設置されたセンサのセンサデータの重要度が増減する等、様々なデータの価値が変化する場合がある。

よって、業務プロセスの変化や業務プロセスの変化によるデータの価値が変化する環境では、前記変化に応じて、異なる複数のデータ処理方式を切り替える手段や、収集するセンサデータの種別を変える手段が必要となる。

特許文献1では、アプリがセンサデータを必要とするタイミングに合わせて、センサデータをアプリへ配信できる。しかし、業務プロセスの変化や業務プロセスの変化に対応して変化するデータ価値に応じて、異なる複数のセンサデータと、センサデータに対する処理方式等を切り替える手段は開示されていない。

従って、本発明は、業務プロセスやデータ価値の変化に応じて、異なる複数のセンサデータと、センサデータに対する処理方法を切り替え、前記処理された処理済みデータをアプリへ配信する手段を提供することである。

上記課題を解決するために、例えば本発明の１つは、複数の監視対象の業務プロセスを監視する監視手段と、ネットワークに接続し複数種別のセンサデータを処理する複数の異なる種別の外部装置の管理情報をネットワークを介して管理する管理手段とをメモリに格納し、CPUにて実行する制御部を備え、制御部は、複数の監視対象の業務プロセスが変更されたか否かを判断し、業務プロセスが変更されたと判断すると、変更される業務プロセスの実行に必要なセンサ情報の処理を変更させることを複数の異なる種別の外部装置へそれぞれ指示をする。

本発明によれば、業務プロセスの変化や業務プロセスの変化によるデータ価値の変化に応じて必要となるセンサデータの処理の変更を複数種別の複数の計算機に対して指示することで、対応するアプリへセンサデータを配信することが可能となる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の概要を示す図である。 システム全体の構成例を示したブロック図である。 管理計算機の構成例を示したブロック図である。 データ処理定義テーブルの構成例を示した図である。 Hub処理定義テーブルの構成例を示した図である。 ゲートウェイ処理定義テーブルの構成例を示した図である。 処理方式変更条件テーブルの構成例を示した図である。 処理方式定義テーブルの構成例を示した図である。 データ処理計算機管理テーブルの構成例を示した図である。 Hub計算機管理テーブルの構成例を示した図である。 ゲートウェイ計算機管理テーブルの構成例を示した図である。 センサ管理テーブルの構成例を示した図である。 監視プログラムの処理の一例を示したフローチャートである。 管理プログラムの処理方式有効化/無効化に関する処理の一例を示したフローチャートである。 管理プログラムにおけるデータ処理計算機の特定と、データ処理の有効化/無効化の処理の一例を示したフローチャートである。 管理プログラムにおける、センサデータの送信経路の変更処理の一例を示したフローチャートである。 処理方式の定義と変更条件を入力する画面の一例を示した図である。 顧客データセンタを含むシステムの構成例を示した図である。 管理プログラムによるリソース調整処理の一例を示したフローチャートである。 管理プログラムによるセンサデータの送信制御処理の一例を示したフローチャートである。

以下、本発明を実施するための形態を図面を用いて説明する。

なお以降で説明をする実施例ならびに図面は、本発明を実施するための形態の一つであって、同様の処理が可能な他の構成・形態への適用を制限するものではない。

実施例１では、ある製品を生産する工場等において、製品の生産に用いられる機械の故障検知、原因分析、対策実施の業務を例に本願を実施する形態について説明する。

前記業務では、機械に取り付けられた温度や振動等を測定するセンサを用いて故障検知業務が定常的に行われるとする。さらに、機械の故障が検知されたことを契機として、原因分析、対策実施の業務へ業務プロセスが変化するとする。

加えて、例えば地震が発生した際に、地震の影響を受けた地域の工場にある機械が故障する可能性が高まることから、迅速に故障を検知することが重要になり、前記機械に取り付けられたセンサのセンサデータの価値が高まるとする。

実施例１は、このような前記業務プロセスの変化や、業務プロセスの変化に対応して変化するセンサデータの価値に応じて、センサデータの処理方式を変えることで、業務を遂行するアプリに対し、前記アプリが必要とするデータの配信を可能にするものである。従って、例えば地震発生の影響を受けた機器の故障予兆を検知することが可能となり、故障を検知した後の原因分析や対策の実施をすることができる。

Ａ．概要
本実施例のシステムについて概念図である図１を用いて説明をする。図１は、機械の故障検知、原因分析、対策実施を含む業務5000を実施のため、機械に設置されたセンサ3400のセンサデータ5100を、データをサービス提供事業者データセンタ1000の計算機で処理し、業務を遂行するアプリへ配信する様子と、業務プロセスの変化に応じて、前記センサデータの処理方式を切り替える様子を模式的に示したものである。

フィールド3000は、例えばある製品を生産する１つまたはそれ以上の工場を示し、１つまたはそれ以上のセンサ3400と、１つまたはそれ以上のゲートウェイ計算機3200を含む。センサ3400は、センサデータ5100の発生源となるものであり、例えば工場の建屋や部屋に取り付けられた温度計や、製品を製造する機械等に取り付けられた振動計等である。

ゲートウェイ計算機3200は、例えばインターネットへ接続する機能を持たないセンサ3400のセンサデータ5100を前記センサデータ5100を処理するサービス提供事業者のデータセンタ1000等へ送信する送信手段を提供する計算機である。ゲートウェイ計算機3200が有するゲートウェイプログラムP3200は前記送信手段を提供するものであり、収集するセンサデータ5100や送信先のHub計算機の情報を含むゲートウェイ処理定義テーブルT3200を用いて、前記センサ3400からセンサデータ5100を取集し、Hub計算機2400へセンサデータ5100を送信する。

サービス提供業者データセンタ1000は、例えばクラウドコンピューティングのサービスを提供する業者が保有するデータセンタである。

Hub計算機2400は、ゲートウェイ計算機とデータ処理計算機の間で前記センサデータの送受信を仲介する（中継する）手段を提供する計算機である。Hub計算機2400により、例えばゲートウェイ計算機やデータ処理計算機は、互いのInternet Protocol (IP)アドレス等の仕様変更を意識する必要がなくなる。Hub計算機2400が有するHubプログラムP2400は、受信するセンサデータ5100やデータ処理計算機の情報等を含むHub処理定義テーブルT2400を参照し、1つまたは複数のデータ処理計算機2200へ送信する。

データ処理計算機2200は、受信したセンサデータ5100に対し、後述のアプリP1200が求める形式への変換や分析等の処理を実施する計算機である。データ処理計算機2200が有するデータ処理プログラムP2200は、データ処理定義テーブルT2200に格納された処理定義情報に基づき、Hub計算機2400から受信した１つまたは複数のセンサデータ5100を処理し、前記処理された処理済データ5200をデータ提供計算機1200へ送信する。

なお前記処理は形式変換処理のほか、不要なデータを除去するクレンジング処理、集計処理、機器故障の検知処理、機器故障の原因分析処理等であってもそれ以外であってもよい。また、前記処理を行うタイミングは、リアルタイムに処理を実施するストリーム方式であっても定期的に処理を実施するバッチ処理であってもよい。また、データ処理計算機2200a、2200bはデータ処理計算機2200と同等のものであればよく、説明は省略する。

データ提供計算機1300は、データ処理計算機2200から受信した処理済データ5200を前記データレイクP1310へ一次的に格納し、該処理済データ5200をアプリ計算機が有する１つまたは複数のアプリP1200が取得できるよう、Application Programming Interface (API)等を提供する手段を有する。アプリ計算機1200は、前記業務を行うアプリP1200を備える。

管理計算機1400は、業務プロセスの変化に応じて、業務を遂行するアプリへデータを配信できるようセンサデータの処理方式を制御する計算機である。監視プログラムP1400は、処理方式変更条件テーブルT1400に格納された処理方式変更条件情報に基づき業務プロセスやデータ価値の変化を監視するプログラムであり、前記変化を契機として管理プログラムP1410へセンサデータの処理方式の変更等の制御を指示する。なお、処理方式変更条件情報は、例えば業務プロセスの変化を示すアプリP1200の稼働状況、処理結果等や地震発生の警報等、データ価値の変化を示す情報等であり詳細は後述する。
管理プログラムP1410は、ゲートウェイ計算機3200、Hub計算機2400やデータ処理計算機2200の処理方式に対し、変更等の制御を行うプログラムである。前記処理方式の制御は、前記監視プログラムP1400が検知した業務プロセスやデータ価値の変化に応じて処理方式定義テーブルT1420に格納された処理方式定義情報を基にゲートウェイ計算機3200、Hub計算機2400やデータ処理計算機2200が有する処理定義テーブル(T3200、T2400、T2200)に格納された情報を変更することで行う。

ここで、機械の故障が検知された場合に、業務5000が機器故障の原因分析、さらに対策実施へと業務プロセスを変化させた場合、前記監視プログラムP1400と管理プログラムP1410によってセンサデータ5100の処理方式を切り替える例について説明する。

まず、機械の故障検知業務は定常定期に実施されている業務であり、センサ1のセンサデータ5100を利用するものとする。従って、前記センサデータ5100は、ゲートウェイ計算機3200、Hub計算機2400、データ処理計算機2200、データ提供計算機1300を介し、アプリAへ配信される。

機械の故障原因分析業務は、センサ1、2のセンサデータ5100を利用するものとする。従って、前記センサデータ5100は、ゲートウェイ計算機3200、Hub計算機2400、データ処理計算機2200a、データ提供計算機1300を介し、アプリBへ配信されるものとする。なお、前記アプリAにて機械の故障が検知された場合、故障原因分析のためにアプリAはアプリBを起動するとする。

対策実施業務は、センサ3のセンサデータ5100を利用するものとする。従って、前記センサデータ5100は、ゲートウェイ計算機3200、Hub計算機2400、データ処理計算機2200b、データ提供計算機1300を介し、アプリCへ配信されるものとする。なお、前記アプリBにて機械の故障原因が特定された場合、アプリBはアプリCを起動する。

監視プログラムP1400は、アプリBの稼動開始を検知した際、故障原因の分析業務が開始されたと判断し、管理プログラムP1410へ通知する。

管理プログラムP1410は、処理方式定義テーブルT1420を参照し、故障原因分析業務に必要なセンサ2のセンサデータ5100がアプリBへ配信されるようシステム内の処理方式を変更する。

具体的には、まずゲートウェイ処理定義テーブルT3200を変更することで、センサ1に加えてセンサ2のセンサデータを収集し、データ処理計算機2200aが有するデータ処理プログラムP2200aで前記センサデータが処理されるよう、Hub処理定義テーブルを変更する。さらに、アプリBの使用要件に合致するように前記センサデータが処理されるよう、データ処理定義テーブルT2200を変更する。

機器の故障原因分析業務から対策実施業務へ業務が変化した際は、業務監視プログラムP1400がアプリCの稼働を検知し、センサ3のセンサデータ5100がデータ処理計算機2200bを介してアプリCへ配信されるよう、管理プログラムP1410がゲートウェイ処理定義テーブルT3200、Hub処理定義テーブルT2400、データ処理定義テーブルT2200を書き換える。

以上より、本実施例では上記する一連の処理を行うことで、業務プロセスやデータ価値の変化に応じて、センサデータの収集と、センサデータに対する処理を実施し、各アプリへ処理済みデータを配信することが可能となる。従って、例えば地震発生の影響を受けた機器の故障予兆を検知することが可能となり、さらに、故障を検知した後の原因分析や対策を実施することができる。本実施例についての詳細は以下にて説明を実施する。

Ｂ．各装置構成
以下、本実施例におけるシステムを構成する各装置について図２〜図３を用いて説明をする。図２はシステム全体の構成例を示したブロック図である。

本願が対象とするシステムは、図１に示す記載のフィールド3000と、サービス提供事業者データセンタ1000内に設置された各種計算機と、ネットワーク4200と、ネットワーク機器4000とから構成される。

フィールド3000は、センサ3400とゲートウェイ計算機3200を有する。ゲートウェイ計算機3200は、メモリ3210と、CPU3220と、入出力インターフェース(I/F)3230と、記憶装置3240と、ネットワークインターフェース(NW I/F)3250を備え、これらは内部バス2260で接続されている。メモリ3210は、ゲートウェイプログラムP3200とゲートウェイ処理定義テーブルT3200を備え、CPU3220により実行される。センサ3400とゲートウェイ計算機3200は、ネットワーク3500とネットワーク機器3600で接続される。またネットワーク機器3600はネットワーク4200とネットワーク機器4000に接続されている。

サービス提供事業者データセンタ1000は、Hub計算機2400と、データ処理計算機2200と、データ提供計算機1300と、アプリ計算機1200と、管理計算機1400と、を含み、これらネットワーク1500とネットワーク機器1600を介して互いに接続される。また、ネットワーク機器1600は、ネットワーク4200とネットワーク機器4000に接続されている。

Hub計算機2400は、メモリ2410と、CPU2420と、入出力I/F2430と、記憶装置2440と、NW I/F2450と、を備え、これらは内部バス2460で接続されている。Hub計算機2400は、ゲートウェイ計算機3200から送信されたセンサデータをNW I/F2450を介して受信して、記憶装置2440へ蓄積し、1つまたはそれ以上のデータ処理計算機2200へ送信する。メモリ2410は、HubプログラムP2400と、Hub処理定義テーブルT2400を備え、CPU2420により実行される。

データ処理計算機2200は、メモリ2220と、CPU2230と、入出力I/F2240と、記憶装置2250と、NW I/F2260と、を備え、これらは内部バス2260で接続されている。データ処理計算機2200が有するメモリ2200は、データ処理プログラムP2200とデータ処理定義テーブルT2200を備え、CPU2230により実行される。なお、データ処理プログラムP2200は、例えば、機器故障の検知処理を実施するデータ処理プログラムと、機器故障の原因分析処理プログラムのような種別の異なるものを１つのデータ処理計算機2200が備えてもよいし、異なる複数のデータ処理計算機2200が備えてもよい。

データ提供計算機1300は、メモリ1310と、CPU1320と、入出力I/F1330と、記憶装置1340と、NW I/F1350と、を備え、これらは内部バス1360で接続されている。メモリ1310は、データ提供プログラムP1300と、データレイクプログラムP1310を備え、CPU1320により実行される。なお、データ提供プログラムP1300によって送信された処理済データ5200は、データレイクプログラムP1310により受信され、メモリ1310または記憶装置1340へ格納される。

アプリ計算機1200は、メモリ1210と、CPU1220と、入出力I/F1230と、記憶装置1240と、NW I/F1250と、を備え、これらは内部バス1360で接続されている。アプリ計算機1200は、データ処理計算機1300から送信されたデータをNW I/F1250を介して受信する。アプリ計算機が有するメモリ1210は、記憶装置1240からロードされた１つまたは複数のアプリプログラムP1200を含む。

なお、アプリP1200は１つであっても複数であってもよく、処理済データ5200の他に、他のアプリの出力を入力としてもよいし、本願で述べた以外のシステムから収集した情報を入力としてもよい。加えて、データ提供計算機1300が、データ処理計算機2200から受信した処理済データ5200をデータレイクP1310へ格納せず、アプリプログラムP1200へ即時送信してもよい。また、サービス提供業者がSaaS(Software as a Service)を提供している場合にはアプリP1200を使用しているものはサービス提供業者とは別の者である場合がある。

管理計算機1400は、メモリ1410と、CPU1420と、入出力I/F1430と、記憶装置1440と、NW I/F1450と、を備え、これらは内部バス1260で接続されている。なお、管理計算機1300の詳細な構成は図３を用いて後述する。

ネットワーク機器4000は、1つまたはそれ以上のネットワーク機器で構成され、フィールド3000、サービス提供事業者データセンタ1000内の計算機と、センサ3400と、その他の機器を接続する。ネットワーク4200の一例はインターネットであり、Virtual Private Network(VPN)であってもよいし、その他のネットワークであってもよい。

上記するすべての計算機は、物理的な計算機であっても、物理的な計算機上で動作する仮想的な計算機であってもよい。また、各計算機の記憶装置は必須要素ではなく、例えば外部ストレージ装置であってもよい。各計算機が備えるNW I/Fの一例としては、Network Interface Card (NIC)が挙げられるが、NICに限定せずその他のI/Fであってもよい。

また、ディスプレイ等の出力装置やキーボード・マウスといった入出力I/Fを備えてもよいし、Secure Shell（SSH）といった手段によりネットワーク経由で当該計算機が遠隔管理される場合には、入力I/Fは必須の要素ではない。上記の各計算機に含まれるプログラムとテープルは、各計算機が備える記憶装置に含まれていてもよい。本願で記載の以外の物理機器や、機器同士を接続する配線等があってもよい。

図３は管理計算機1400の構成の詳細を示したブロック図である。なお、管理計算機1400のCPU1420等の構成は上記にて説明したため省略する。

管理計算機1400が備えるメモリ1410は、業務プロセスやデータ価値の変化を監視する監視プログラム1411と、センサデータや処理済みデータの処理方式を制御する管理プログラム1412と、前記監視プログラム1411が監視に用いる情報を含む処理方式変更条件テーブルT1400と、前記管理プログラムが処理方式の制御に用いる情報を含む処理方式定義テーブルT1420と、受付け可能な処理やIPアドレス等のデータ処理計算機の情報を含むデータ処理計算機管理テーブルT1430と、センサデータを転送可能なデータ処理計算機やIPアドレス等のHub計算機に関する情報を含むHub計算機管理テーブルT1440と、収集可能なセンサデータやIPアドレス等のゲートウェイ計算機の情報を含むゲートウェイ計算機管理テーブルT1450と、センサの種別等のセンサ情報を含むセンサ管理テーブルT1460を備える。前記プログラムは記憶装置1440からメモリ1411上に読み込まれ、CPU1420によって実行される。

各テーブルの詳細については、図４〜図１２を用いて後述する。また、各プログラムの動作については、図１３〜図１６を用いて説明をする。

Ｃ．テーブル
図４〜図１２に示す各テーブルについて詳細を説明する。なお、本実施例では「abcテーブル」のようにテーブルとして説明をしているがテーブルに限らず、例えばリストの形式をとしてもよい。また、「abcテーブル」の各要素を「レコード」と呼ぶこともできる。また、「abcテーブル」を「abc情報」と言い替えることもできる。

図４は、データ処理定義テーブルT2200の構成例を示した図である。データ処理定義テーブルT2200は、データ処理プログラムP2200によって参照され、Hub計算機から送信されたセンサデータを、どのように処理するかを定義したテーブルである。前記データ処理定義テーブルT2200は、処理定義ID T2201、センサデータID T2202、処理T2203を含み、管理プログラムP1410によって更新される。

処理定義ID T2200は、各レコードに対して与えられた、該テーブル内で一意なIDである。センサデータID T2202は、データ処理プログラムP2200の入力となるセンサデータのIDを示す。なお、前記センサデータは複数指定可能であってもよい。処理T2203は、入力された前記センサデータをどのように処理するかを示したものでありる。例えばセンサデータをリアルタイムに分析し故障イベントを出力する処理や、あるいは、センサデータを日次で統計的に分析し正常なセンサデータの値の範囲を結果として出力する処理（バッチ処理とも言う）等が記載される。

パラメータT2204は、前記処理T2203を実行する際のパラメータである。例えばリアルタイム処理に分類される処理であればWindowサイズ、バッチ処理に分類される処理であれば実行タイミングの日時等を示す。処理済データ送信先T2205は、前記処理された処理済データ5200を、どのデータ提供計算機へ送信するかを示したものである。参照カウントT2206は、後述の処理方式定義テーブルのレコードのうち、対応する個数を示しているものであり、管理プログラムP1410によって増減される。なお、データ処理プログラムは、参照カウントT2206が1以上のレコードの内容に従いセンサデータに対する処理を実行する。

図5は、Hub処理定義テーブルT2400の構成例を示した図である。Hub処理定義テーブルT2400は、HubプログラムP2400によって参照され、ゲートウェイプログラムP3200から送信されたセンサデータ5100を、どのデータ処理計算機2200へ送信するかが定義されたテーブルである。前記Hub処理定義テーブルT2400は、Hub処理定義ID T2401、センサデータID T2402、送信元ゲートウェイ計算機T2403、参照カウントT2405を含み、管理プログラムP1410によって更新される。

Hub処理定義ID T2401は、各レコードに対して与えられた該テーブル内で一意なIDである。センサデータID T2402は、ゲートウェイプログラムP3200から受信するセンサデータ5100を特定するためのIDを示す。送信元ゲートウェイ計算機T2403は、前記センサデータの送信元となるゲートウェイ計算機を示す。送信先データ処理計算機T2403は、前記受信したセンサデータをどのデータ処理計算機2200へ送信するかを示したものである。参照カウントT2405は、後述の処理方式定義テーブルT1400のレコードのうち、対応する個数を示しているものであり、管理プログラムP1410によって増減される。なお、HubプログラムP2400は、参照カウントT2206が1以上のレコードの内容に従いセンサデータの受信と送信を実行する。

図６は、ゲートウェイ処理定義テーブルT3200の構成例を示した図である。前記ゲートウェイ処理定義テーブルT3200は、ゲートウェイプログラムP3200によって参照され、どのセンサからセンサデータ5100を収集し、収集されたセンサデータをどのHub計算機2400へ送信するかを定義したテーブルである。

ゲートウェイ処理定義テーブルT3200は、ゲートウェイ処理定義ID T3201と、収集元センサT3202と、収集間隔T3203と、送信先Hub計算機T3204と、参照カウントT3205を含み、管理プログラムP1410によって更新される。

ゲートウェイ処理定義ID T3201は、各レコードに対して与えられた、該テーブル内で一意なIDである。センサデータT3202は、ゲートウェイプログラムP3200が収集するセンサデータ5100を発生させるセンサ3400を特定するエントリである。収集間隔T3203は、前記センサデータを前記センサから収集する間隔を示したものである。なお、センサ3400がゲートウェイプログラムP3200に対して能動的にデータを送信する場合は、秒数等の時間間隔を示す値はなく、例えば「−」等を格納する。

送信先Hub計算機T3204は、収集したセンサデータを送信するHub計算機2400を示す。参照カウントT3205は、後述の処理方式定義テーブルT1400のレコードのうち、対応する個数を示しているものであり、管理プログラムP1410によって増減される。なお、ゲートウェイプログラムP3200は、参照カウントT3205が1以上のレコードの内容に従いセンサデータの収集と送信を実行する。

図７は、処理方式変更条件テーブルT1400の構成例を示した図である。処理方式変更条件テーブルT1400は、監視プログラムP1400が業務プロセスやデータ価値の変化を監視する際に参照するテーブルであり、処理方式を変更する条件の情報を含む。なお、該テーブルは、例えばサービス提供事業者の管理者や工場等の顧客の管理者が作成してもよいし、アプリP1200によるセンサデータや処理済みデータの使われ方を分析するプログラム等によって自動的に作成されるものであってもよい。

条件ID T1401は、該テーブル内で一意なIDである。処理方式変更条件T1402は、処理方式を変更する条件の情報であり、例えば業務プロセスが機械の故障検知から原因分析の業務へ変化した場合や、データの価値に変化があった場合等が記載される。処理方式IDT1403は、前記条件が成立した際に実施する処理方式を特定するためのIDである。検知済フラグT1404は、監視プログラムP1400の監視の結果、処理方式変更条件T1402に合致し、処理方式の有効化を実施済みか示すフラグである。

なお、検知済フラグT1401のTは有効化済み、Fは無効であることを示す。優先度T1405は、処理方式変更条件T1402に合致した際、関連するセンサデータに対する処理を他のものよりどれだけ優先するのかを示した項目であり、例えば高、中、低のような離散値であってもよいし、数字等で表現された連続値であってもよい。なお、優先度T1405の情報は実施例１では用いず、実施例２で使用する。

図８は処理方式定義テーブルT1420の構成例を示した図である。処理方式定義テーブルT1420は、センサデータ5100と処理済データ5200に対する処理方式を定義したテーブルであり、例えばどのセンサからセンサデータを収集するか、前記収集したセンサデータに対してどのような処理を実施するか、前記処理された処理済データ5200をどのアプリへ配信するか等を定義したものである。なお、該テーブルは、例えばサービス提供事業者の管理者や、工場等の顧客の管理者が作成してもよいし、アプリP1200によるセンサデータや処理済みデータの使われ方を分析するプログラム等によって自動的に作成してもよい。

処理方式定義ID T1421は、該テーブル内で一意に定められたIDを示す項目である。センサデータID T1422は、データ処理定義テーブルT2200のセンサデータ2202と同等であり、データ処理計算機2200へ入力するセンサデータを示す。データ処理定義T1423は、データ処理定義テーブルT2200の処理T2203と、パラメータT1424は、パラメータT2204と同等であり、前記センサデータをデータ処理計算機2200においてどのように処理するかを示した項目である。データ処理計算機T1425は、センサデータをどのデータ処理計算機2200で処理するかを示した項目である。処理済みデータ送信先T1426は、前記処理されたセンサデータをどのデータ処理計算機2200へ送信するかを示した項目である。

図９はデータ処理計算機管理テーブルT1430の構成例を示した図であり、IPアドレスや実行可能なデータ処理等の各データ処理計算機2200の情報を含む。データ処理計算機管理テーブルT1430は、例えばサービス提供事業者の管理者や、工場等の顧客の管理者が作成してもよいし、管理プログラムが情報を収集し、自動的に作成してもよい。

データ処理計算機ID T1431は、該テーブル内で一意に定められたIDを示す項目である。IP T1432は、データ処理計算機2200のIPアドレスを示す項目である。なお、データ処理計算機2200をネットワーク上で特定できるものであれば、IPアドレス以外であってもよい。

実行可能処理T1433は、センサデータに対して該データ処理計算機2200が実行可能な１つまたは複数の処理を示した項目である。例えばセンサデータの分析し故障イベントを出力する処理や、センサデータを分析し、故障原因を出力する処理等が該当する。割り当てリソースT1434は、該データ処理計算機2200へ割り当てられた計算リソースの量を示し、例えばCPUの個数やメモリ容量等である。負荷状況T1435は、該データ処理計算機の現在の計算負荷状況を示したものであり、高、中、低のような離散値であってもよいし、数字で表現された連続値であってもよい。

なお、割り当てリソースT1434と、負荷状況T1435は実施例２で説明をする。また、各データ処理計算機2200の情報には、データ処理定義デーブルT2200の情報（T2201〜T2206）も含んでもよい。

図１０はHub計算機管理テーブルT1440の構成例を示した図であり、IPアドレスやセンサデータを送信可能なデータ処理計算機2200等の各Hub計算機2400の情報を含む。Hub計算機管理テーブルT1440は、例えばサービス提供事業者の管理者や、工場等の顧客の管理者が作成してもよいし、管理プログラムが各Hub計算機2400の情報を収集し、自動的に作成してもよい。

Hub計算機ID T1441は、該テーブル内で一意に定められたIDを示す項目である。IPT1432は、Hub計算機2400のIPアドレスを示す項目である。なお、Hub計算機2400をネットワーク上で特定できるものであれば、IPアドレス以外であってもよい。転送先データ処理計算機は、ゲートウェイ計算機3200から受信したセンサデータを転送可能な１か複数のデータ処理計算機2200を示す。 割り当てリソースT1444は、該Hub計算機2400へ割り当てられた計算リソースの量を示し、例えばCPUの個数やメモリ容量等である。負荷状況T1445は、該Hub計算機の現在の計算負荷状況を示したものであり、高、中、低のような離散値であってもよいし、数字で表現された連続値であってもよい。

なお、割り当てリソースT1444と、負荷状況T1445は実施例２にて説明する。また、各Hub理計算機2400の情報には、Hub処理定義テーブルT2400の情報（T2401〜T2405）も含んでもよい。

図１１はゲートウェイ計算機管理テーブルT1450の構成例を示した図であり、IPアドレスや管理しているセンサ等の各ゲートウェイ計算機3200の情報を含む。ゲートウェイ計算機管理テーブルT1450は、例えばサービス提供事業者の管理者や、工場等の顧客の管理者が作成してもよいし、管理プログラムが各ゲートウェイ計算機3200の情報を収集し、自動的に作成してもよい。

ゲートウェイ計算機ID T1451は、該テーブル内で一意に定められたIDを示す項目である。IP T1452は、ゲートウェイ計算機3200のIPアドレスを示す項目である。なお、ゲートウェイ計算機3200をネットワーク上で特定できるものであれば、IPアドレス以外であってもよい。管理センサT1453は、該ゲートウェイ計算機が管理している１か複数のセンサを示す。
なお、各ゲートウェイ計算機3200の情報には、ゲートウェイ処理定義テーブルT3200の情報（T3201〜T3205）も含んでもよい。

図１２はセンサ管理テーブルT1460の構成例を示した図であり、センサの種別や設置場所等、各センサの情報を含む。センサ管理テーブルT1460は、例えばサービス提供事業者の管理者や、工場等の顧客の管理者が作成してもよいし、管理プログラムが各センサの情報を収集し、自動的に作成してもよい。

センサID T1461は、該テーブル内で一意に定められたIDを示す項目である。種別T1426は、例えば温度や、振動、圧力等、各センサが出力可能なセンサデータの種別を表す項目である。設置場所T1463は、例えばラインAのモータや、建屋の名称等、センサが設置された場所を示す項目である。収集方式T1464は、例えばゲートウェイ計算機3200が能動的にセンサデータを収集するPULL方式や、センサがゲートウェイ計算機3200に対して能動的にデータを送信するPUSH方式等、センサデータをゲートウェイ計算機3200が収集する際の方式を示す。収集可能間隔T1465は、各センサからセンサデータを収集可能な最小間隔を示したものである。IP T1466は、各センサのIPアドレスを示す項目である。なお、各センサをネットワーク上で特定できるものであれば、IPアドレス以外であってもよい。
Ｄ．フローチャート
図１３は、管理計算機1400が有する監視プログラムP1400が、業務プロセスの変化や業務プロセスの変化に応じたデータ価値の変化を検知し、管理プログラムP1410に対して、センサデータや処理済みデータに関する処理方式の変更を指示する処理を示したフローチャートである。なお、本実施例では、機械の故障を検知した際のセンサデータの処理について説明をする。また、説明を簡潔にするためにプログラムが主体として動作しているが、実際は管理計算機1400のCPU1420等が主体となって動作する。

ステップS1000にて監視が開始されると、ステップS1020へ進む。
ステップS1020では、業務プロセスの状態や業務プロセスの変化の応じて変わるデータ価値の状態をアプリ稼働情報や、アプリ出力情報や、図示しない外部のシステムの出力から収集し、ステップS1050へ進む。

ここでデータの価値とは、例えば、ある処理（アプリ）にしか用いなかったセンサデータが、業務プロセスが変化することにより別の処理（アプリ）にも必要となるという需要を示しており、データの価値が変わるとはその重要性が変動する事を示している。換言すると、あるセンサデータを必要とする処理（アプリ）が増えればデータの価値が上がり、処理（アプリ）が減ればデータの価値が下がることである。このデータの価値については、図示しない外部装置により予め定められた基準（閾値）により設定されてもよいし、管理装置が基準を備えてもよいし、図示しない外部装置からの情報を基に管理装置が変更するとしてもよい。また、別の例では環境の変化の違いによりデータの価値が変わるとしてもよい。具体的には、フィールド3000がある工場の周辺で地震が発生した場合、気象庁などの震度情報を取得した管理装置がフィールド3000内のセンサデータ5100のうち、発生した地震による工場（フィールド3000）への影響を把握するために必要なデータを取得しようとして優先度を上げるという処理をすることもできる。

ステップS1050では、処理方式変更条件テーブルT1400を参照し、１つレコードを取得する。

ステップS1100では、処理方式変更条件テーブルT1400を参照し、処理方式変更条件T1402に合致するかを検証する。前記条件に合致すればステップS1150へ進み、合致しなければステップS1400へ進む。 ステップS1150では、ステップS1050で取得したレコードの検知済みフラグT1404がFかを検証し、すでに未検知を示すFであればステップS1200へ、検知済みを示すTであればステップS1300へ進む。

ステップS1200では、管理プログラムP1410に対し、ステップS1050で取得した処理方式IDT1403と、処理方式を有効化する旨を送信し、ステップS1250にて、ステップS1050で取得したレコードの検知済みフラグT1404をTへ更新後、ステップS1300へ進む。なお、管理プログラムP1410の処理の詳細については後述する。

ステップS1300では、処理方式変更条件テーブルT1400を参照し、未取得のレコードがあるかを検証し、全レコードを取得済みであればステップS1350にて終了し、それ以外であればステップS1050へ戻る。

ステップS1400では、ステップS1050で取得したレコードの検知済みフラグT1404がTかを検証し、検知済みを示すTであればステップS1450へ、未検知を示すFであればステップS1300へ進む。

ステップS1450では、管理プログラムP1410に対し、ステップS1050で取得した処理方式IDT1403と、処理方式を無効化する旨を送信し、ステップS1500にて、ステップS1050で取得したレコードの検知済みフラグT1404をFへ更新後、ステップS1300へ進む。即ち、変更された処理方式に合致しないものは、不要であるとして処理を無効化する。

なお、本処理では、説明のためにステップ1350にて終了するとしたが、実際には所定のタイミングで業務プロセスを繰り返し監視している。そのため、図１で示したように、あるアプリで業務を行っている場合に装置の故障を検知し、発生した故障の原因分析のためにアプリBを起動し、その後対策実施のためにアプリCを起動した場合であってもセンサデータの処理方式を変更する事ができる。

次に図14について説明をする。図14は、管理計算機1400が有する管理プログラムP1410が、監視プログラムP1400から処理方式ID T1403と、有効化/無効化の要求を受信し、データ処理計算機2200、Hub計算機2400、ゲートウェイ計算機3200における、データの処理方式を変更する処理に関するフローチャートである。

始めに、ステップS2000にて監視プログラムP1400から処理方式ID T1403と、有効化/無効化の要求を受信し、ステップS2050へ進む。

ステップS2050では、処理方式定義テーブルT1420から、前記受信した処理方式IDが合致するレコードを特定し、ステップS2200へ進む。

ステップS2200では、特定されたレコードのデータ処理計算機T1425から、センサデータを処理するデータ処理計算機2200を特定し、データ処理方式の有効化/無効化を実施後、ステップS2250へ進む。なお、本ステップS2200の詳細について、図15の説明にて詳述する。

ステップS2250では、Hub計算機管理テーブルT1440から、特定されたデータ処理計算機2200へセンサデータを送信可能なHub計算機2400を、転送先データ処理計算機T1443欄を基に特定し、ステップS2300へ進む。

ステップS2300では、特定されたHub計算機2400が有するHub処理定義テーブルT2440を参照し、S2050で特定された処理方式定義テーブルT1420のレコードからセンサデータID T2402、送信先データ処理計算機T2404が同じ、Hub処理定義テーブルT2400のレコードを特定し、ステップS2350へ進む。本処理により、データ処理方式を有効化/無効化を実施するHub処理定義テーブルT2400のレコードを特定する。なお、レコードが特定できなかった場合は、新しいレコードとして追加処理を後述するS2500で行うため、同様にステップS2350へ進む。

次にステップS2350では、ステップS2050特定された処理方式定義テーブルT1420のレコードから、収集するセンサデータT1422を特定し、ステップS2400へ進む。

ステップS2400では、特定されたセンサデータを収集可能なゲートウェイ計算機3200を、ゲートウェイ計算機管理テーブルT1450から特定し、ステップS2450へ進む。

ステップS2450では、特定されたゲートウェイ計算機3200のゲートウェイ処理定義テーブルT3200から、ステップS2050特定されたレコードに記載されたセンサデータT3202、送信先Hub計算機T3204が同じレコードを特定する。本処理により、データ処理方式を有効化/無効化を実施するHub処理定義テーブルT2400のレコードを特定する。なお、レコードが特定できなかった場合は、新しいレコードとして追加処理を後述するS2500で行うため、同様にステップS2500へ進む。

ステップS2500では、特定されたデータ処理方式定義テーブルT1420のレコードの情報を基に、特定されたHub処理定義テーブルT2400のレコードと特定されたゲートウェイ処理定義テーブルT3200のレコードの内容を変更し、データ処理方式の有効化/無効化を実施し、ステップS2550で終了する。ステップS2550の詳細については、図16を用いて後述する。

次に図15について説明をする。図15は、管理計算機1400が有する管理プログラムP1410がデータの処理方式を変更すべきデータ処理計算機2200の特定と、データの処理方式の変更実施する際の処理を示したフローチャートである。

ステップS3000にて、データ処理方式を変更すべきデータ処理計算機の特定と、データ処理有効化/無効化の処理を開始し、ステップS3010へ進む。

ステップS3010では、ステップS2050で特定された処理方式定義テーブルT1420のレコードのデータ処理計算機欄の情報を基に、処理方式変更の対象となるデータ処理計算機と特定し、ステップS3020へ進む。

ステップS3020では、ステップS3010で特定されたデータ処理計算機2200のデータ処理定義テーブルT2200から、センサデータT2202、処理T2203、パラメータT2204、処理済データ送信先T2205が同じレコードを特定し、ステップS3050へ進む。

ステップS3050では、監視プログラムP1400から受信した指示が処理方式の有効化であったのか、無効化であったのかを判定し、有効化であればステップS3100へ、無効化であればステップS3450へ進む。

ステップS3100では、ステップS3020でレコードが特定されたかを判定し、特定されていればS3150、特定されていなければS3350へ進む。

ステップS3150では、ステップS3020で特定されたレコードの参照カウントT2206を１増加させ、ステップ3300で終了する。

ステップS3350では、ステップS3020で特定されたレコードの情報を基に、データ処理計算機処理定義テーブルT2200へ、新たなレコードを追加し、ステップS3300で終了する。

ステップS3450では、ステップS3020で特定された差コードの参照カウントT2206を１減じ、ステップS3500へ進む。新たなレコードのセンサデータT2202、処理T2203、パラメータT2204、処理済みデータ送信先T2205は、それぞれ処理定義テーブルT1420のセンサデータT1422、データ処理定義T1423、パラメータT1424、処理済みデータ送信先T1426の情報から作成し、参照カウントT2206は1とする。

ステップS3500では、ステップS3020で特定されたレコードの参照カウントT2206が0かを判定し、0であればステップS3550で該レコードを削除し、0でなければステップS3300へ進み終了する。

次に図16について説明をする。図16は、管理計算機1400が有する管理プログラムP1410における、特定されたHub処理定義テーブルT2400のレコードと特定されたゲートウェイ処理定義テーブルT3200のレコードの内容の変更処理を示したフローチャートである。なお、当該レコードの変更処理によりセンサデータの送信経路が変更されるため、センサデータの送信経路変更処理とも呼ぶことができる。

ステップS4000にてセンサデータの送信経路の変更処理を開始し、ステップS4050へ進む。

ステップS4050では、監視プログラムP1400から受信した指示が処理方式の有効化であったのか、無効化であったのかを判定し、有効化であればステップS4100へ、無効化であればステップS4450へ進む。

ステップS4110では、ステップS2300でHub処理定義テーブルT2400のレコードが特定されたか否かを判定する。Hub処理定義テーブルT2400のレコードが特定されていれば、ステップS4150へ進み、特定されていなければステップS4350へ進む。

ステップS4150では、ステップS2300で特定されたHub処理定義テーブルT2400レコードの参照カウントT2405を１増加させ、ステップS4200へ進む。

ステップS4350では、Hub処理定義テーブルT2400へ、ステップS2300で特定されたレコードに記載された情報を基に、新しいレコードを追加し、ステップS4200へ進む。新しいレコードは、センサデータT2402、送信先データ処理計算機T2404は、それぞれ処理定義テーブルT1420のセンサデータT1422、処理済みデータ送信先T1426の情報から作成する。また、送信元ゲートウェイ計算機T2403は、センサデータT2402に記載のセンサデータを送信可能なゲートウェイ計算を、ゲートウェイ管理テーブルT1450の管理センサT1453の情報から特定したものを記載する。なお、新たしいレコードの参照カウントT2405は1とする。

ステップS4200では、ステップS2450でゲートウェイ処理定義テーブルT3200のレコードが特定されたかを判定し、ゲートウェイ処理定義テーブルT3200のレコードが特定されていればS4250、特定されていなければS4400へ進む。

ステップS4250では、ステップS2450で特定されたゲートウェイ処理定義テーブルT3200のレコードの参照カウントT3205を１増加させ、ステップS4800で終了する。

ステップS4400では、ゲートウェイ処理定義テーブルT3200へ、ステップS2450で特定されたレコードに記載された情報を基に、新しいレコードを追加し、ステップS4800で終了する。新しいレコードは、センサデータT2402、収集間隔T3203、送信先Hub計算機T3204は、それぞれ処理定義テーブルT1420のセンサデータT1422、パラメータT1424、処理済みデータ送信先T1426の情報から作成する。なお、新たしいレコードの参照カウントT3205は1とする。

一方、ステップS4450では、ステップS2300で特定されたHub処理定義テーブルT2400のレコードの参照カウントT2405を１減じ、ステップS4500へ進む。

ステップS4500では、ステップS2300で特定されたレコードの参照カウントT2405が0かを判定する。判定の結果0であれば次のステップS4550に進み、ステップS2300で特定されたレコードを削除し、ステップS4650へ進む。判定の結果が0でない場合は、ステップS4600へ進む。
ステップS4600では、ステップS2450で特定されたゲートウェイ処理定義テーブルT3200のレコードの参照カウントT3205を１減じ、ステップS4650へ進む。

ステップS4650では、ステップS2450で特定されたゲートウェイ処理定義テーブルのレコードの参照カウントT3205が0かを判定する。参照カウントT3205の値が0以外であればステップS4800へ進み。参照カウントT3205の値が0であればステップS4700にて、ステップS2450で特定されたゲートウェイ処理定義テーブルT3200のレコードを削除し、ステップS4800進み、終了する。

本処理を実施する事により、Hub処理定義テーブルT2400およびゲートウェイ処理定義テーブルT3200に新規のレコードを追加または削除をすることができ、センサデータの経路を追加または削除をすることができる。

次に図17について説明をする。図17は、管理計算機が業務プロセスやデータ価値の変化など、センサデータに対する処理方式を変更する際の条件と、条件を満たしたときに変更する処理の内容を入力する画面の例を示したものである。

画面G1000は、センサデータに対する処理方式を変更する際の条件を指定する条件フォームG1100と、条件を満たしたときに変更する処理の内容を指定する処理方式定義フォームG1200を含む。

条件フォームG1100は、例えば監視対象の種別を示すG1110や、アプリ稼動状況の条件を指定するG1121を含む。前記条件は、例えば業務プロセスの変化を検知するため、アプリAが稼動中、かつアプリBが稼動中であることを条件とすることや、データ価値の変化を検知するため、特定のアプリの処理結果がデータ提供計算機のデータレイクに格納され、前記処理結果が特定の閾値を超えていることを条件とする、等であってもよく、それ以外であってもよい。
処理方式定義フォームG1200は、センサデータをどのように処理するかを定義した処理方式入力フォームG1210や、前記処理方式入力フォームへセンサデータを追加するボタンG1220や、データ処理方式を変更するためのボタンG1230や、処理済みデータを配信するデータレイクを追加するボタンG1240が含まれても良い。

前記条件フォームG1100に入力された内容は、設定ボタンG1300が押下されたとき、管理計算機2200が有する処理方式変更条件テーブルT1410へ反映され、処理方式定義フォームG1200で入力された内容は、処理条件定義テーブルT1420へ反映される。

本実施例が対象とするシステムにおいて、以上のような一連の処理を行うことで、業務プロセスや業務プロセスの変化に応じたデータ価値の変化に応じて、センサデータの収集と、センサデータに対する処理を複数の異なる計算機に対して実施し、各アプリへ処理済みデータを配信することが可能となる。

実施例2では、実施例1にてサービス提供業者データセンタに含まれていたデータ処理計算機2200と、Hub計算機2400が、顧客データセンタ2000を顧客データセンタに含まれる場合について説明をする。

ここで顧客データセンタ2000とは、例えば工場等のフィールド3000を所有する顧客が管理するデータセンタである。このように、顧客データセンタ2000をサービス提供事業者データセンタ1000とフィールド3000の間に設けることで、例えば顧客が、サービス提供事業者に対してセンサデータを秘匿することや、センサデータに対して独自の処理を施すことや、独自にセンサデータを保存することが可能となる。

サービス提供事業者データセンタ1000は、クラウドコンピューティングのサービスを提供するためのデータセンタであり、豊富な計算リソースを持つ。しかし、顧客データセンタ2000は、金銭的なコストや計算機を設置する物理的空間の制約から、計算リソースに限りがある。そのため、膨大なセンサデータすべてを顧客データセンタが有する計算機で処理すると、計算リソースの不足が発生する場合がある。

一方、業務プロセスやセンサデータの価値の状態によって、例えば数秒以内に処理され、データ提供計算機1300へ処理済データを届けるべきセンサデータや、1日に一回データ処理計算機1300へ処理済データを配信できればよい場合がある。

従って、顧客データセンタが有する計算リソースの枯渇を防ぎ、かつデータ提供計算機へ処理済みデータを送信するために特定のセンサデータに対する処理を優先的に実施する優先制御の手段が必要となる。

実施例2は、優先制御を行う一例として、業務プロセスやセンサデータの価値の状態に応じて、顧客データセンタ2000が有する計算機のリソース割当量を調整する手段を含むものである。なお、実施例2では顧客データセンタ2000を例に挙げて説明をするが、実施例1で説明した構成であっても優先制御処理を適用してもよい。

図18は、実施例2のシステムの構成を示したブロック図である。

実施例1との構成の差異は、サービス提供事象者データセンタ1000に含まれていたデータ処理計算機2200と、Hub計算機2400が、顧客データセンタ2000に含まれる点である。

顧客データセンタ2000が有する各計算機間の通信は、ネットワーク機器1600とネットワーク2500を介して行われ、 顧客データセンタ2000が有する各計算機とサービス提供事業者データセンタ1000、またはフィールド3000との通信は、ネットワーク4200とネットワーク機器4000を介して行われる。

なお、上記する顧客データセンタ2000が有するデータ処理計算機2200とHub計算機2400の他に、サービス提供事業者データセンタ1000にデータ処理計算機2200とHub計算機2400が含まれていてもよい。

次に図19について説明をする。図19は、限られた計算リソースの中でセンサデータに対する処理を実施するため、管理計算機1400が有する管理プログラムP1410が、顧客データセンタが有する１または複数のデータ処理計算機2210の計算リソース量の調整を行う処理を示したフローチャートである。前記フローチャートの処理は、図14の説明で述べたステップS2200の直後に実施されてもよいし、ステップS2500の直後に実施されてもよいし、定期的に実行されてもよい。また、上記する以外のタイミングで実行されてもよい。

ステップS6000にてリソース調整処理が開始されると、ステップS6050へ進む。

ステップS6050およびステップS6100は、リソースを割り当てるべき処理方式を特定するために、現在有効な処理方式と、処理方式毎の優先度を収集するステップである。

ステップS6050では、処理方式変更条件テーブルT1400から、検知済みフラグT1404がTのレコード群を収集し、ステップS6100へ進む。

ステップS6100では、ステップS6050で収集したレコード群に対し、優先度T1405に記載された優先度の情報を基に、優先度が高い順でソートを実施し、ステップS6150へ進む。

ステップS6150からステップS6500では、優先度の高い処理方式処理方式変更条件テーブルT1400の処理方式IDT1403に紐付く、処理方式定義テーブルT1420に記載された処理方式定義に対して、より多くのリソースが割り当てられるように調整を行う。

ステップS6150では、ステップS6100でソート済みのレコード群から、一つレコードを取得し、ステップS6200へ進む。

ステップS6200では、ステップS6200で取得したレコードの処理の情報から、データ処理計算機2200に必要なリソース量を算出し、ステップS6250へ進む。リソース量を算出する方法は、例えばセンサデータT1422に記載のセンサデータの種別から1センサデータ当たりのデータ量を求めて（例えばデータ処理定義T1423と、パラメータT1424とから求めて）もよいし、ステップS6200で取得したレコード毎に必要なリソース量を統計的な手法で求めてもよいし、それ以外の方法で求めても良い。

ステップS6250では、前記算出したリソース量の情報を基に、データ処理計算機2200のリソース量を拡張、または縮小する指示をする。具体的には、データ処理計算機2200が仮想化されている場合、データ処理計算機を管理している図示しない管理システムへ指示をする。指示をした後、拡張または縮小し割り当てたリソース量をデータ処理計算機管理テーブルT1430の割当リソースT1434に記録して、ステップS6500へ進む。

ステップS6500では、ステップS6100でソート済みの処理方式定義テーブルT1420のレコードに対し、ステップS6150で未取得のレコードがあるかを判定し、前記未取得のレコードがあればステップS6150を実行し、なければS6600で処理を終了する。

以上の処理により、処理方式条件変更テーブルT1400の優先度T1405に記載の情報と、処理方式定義テーブルT1420の情報から、データ処理計算機2200のリソース量を変更し、リソースが必要なデータ処理計算機2200にリソースを提供することができる。

次に図20について説明をする。図20は、限られた計算リソースの中でデータ処理計算機2000がセンサデータに対する処理を実施できるよう、ゲートウェイ計算機3000や、Hub計算機2400によって、センサデータの送信を保留ため、管理プログラムによってセンサデータの送信優先制御を行う処理を示したフローチャートである。

図20のフローチャートの処理は、図14の説明で述べたステップS2500の直後に実施されてもよいし、定期的に実行されてもよい、また、上記する以外のタイミングで実行されてもよい。

ステップS7000でセンサデータの送信制御処理が開始されると、ステップS7050へ進む。

ステップS7050と、ステップS7100は、センサデータの送信を抑制すべきかを判定するために、現在有効な処理方式定義と、処理方式定義毎の優先度を収集するステップである。

ステップS7050では、処理方式変更条件テーブルT1400から、検知済みフラグT1404がTのレコード群を収集し、ステップS7100へ進む。

ステップS7100では、ステップS7050で収集したレコード群に対し、優先度T1405に記載された優先度の情報を基に、優先度が高い順でソートを実施し、ステップS7150へ進む。

ステップS7150からステップS7500では、優先度の高い処理方式変更条件テーブルT1400の処理方式ID T1403に紐付く、処理方式定義テーブルT1420に記載された処理方式定義ID T1421に対して、センサデータの送信先であるデータ処理計算機2200またはHub計算機2400が処理可能なリソース量を超えているかを判定する。前記判定の結果から、リソース量を超えている場合はセンサデータの送信を一時的に保留することで、各計算機のリソース枯渇を防止する。

ステップS7150では、ステップS7100でソート済みのレコード群から、一つレコードを取得し、ステップS7200へ進む。

ステップS7200では、ステップS7200で取得したレコードの処理の情報から、データ処理計算機2200に必要なリソース量を算出する。さらに、前記算出したリソース量と、データ処理計算機管理テーブルT1430の負荷状況T1445の情報と、現在割り当てられているリソースT1434の情報から、該データ処理計算機で処理可能かを判断する。判断の結果、処理可能であればステップS7250へ、リソースが枯渇する場合はステップS7210へ進む。

ステップS7210では、データ処理計算機のリソース枯渇を避けるため、Hub計算機に対して、前記データ処理計算機へセンサデータの送信を保留するように指示する。なお該ステップは，前記リソース枯渇を避けることを目的としたものであれば，前記センサデータの送信を保留する指示ではなく，送信データの量を抑制する等，流量制御の指示等であってもよい。
ステップS7520では、ステップS7200で取得したレコードの処理の情報から、Hub計算機2400に必要なリソース量を算出し、ステップS7300へ進む。

ステップS7300では、前記算出したHub計算機に必要なリソース量と、Hub処理計算機管理テーブルT1440の負荷状況T1445の情報と、現在割り当てられているリソースT1444の情報から、該Hub処理計算機でリソース枯渇が発生するかを判断する。リソース枯渇が発生しなければステップS7350へ、リソース枯渇が発生すればS7310へ進む。

ステップS7350では、ステップS7100でソート済みの処理方式定義テーブルT1420のレコードに対し、ステップS7150で未取得のレコードがあるかを判定し、前記未取得のレコードがあればステップS7150へ、なければS7400で処理を終了する。

ステップS7310では、Hub計算機のリソース枯渇を避けるため、ゲートウェイ計算機に対してセンサデータの送信を保留するように指示する。

なお、Hub計算機、またはゲートウェイ計算機においてセンサデータ送信を保留する処理は、センサデータの送信を保留する各計算機が有する記憶装置を用いてもよいし、メモリを用いても良いし、それ以外の計算機を用いて実施してもよい。センサデータの送信を保留するのではなく、実施例１で説明したようにセンサデータをリソースに余裕のある別のデータ処理装置2200へ送信し、処理をするようにしてもよい。

以上の処理により、処理方式条件変更テーブルT1400の優先度T1405に記載の情報と、処理方式定義テーブルT1420の情報から、データ処理計算機2200のリソース枯渇がないよう、Hub計算機2400と、ゲートウェイ計算機3000とで、センサデータの送信を保留する。

実施例2では上記で述べた構成を備えることにより、顧客データセンタ2000が有する計算リソースの枯渇を防ぎ、かつデータ提供計算機1300へ顧客ポリシーに則った処理済みデータを送信するための特定のセンサデータに対する処理を優先的に実施する優先制御することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるＣＰＵが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、コンピュータが備えるＣＰＵが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。

上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

1000・・・サービス提供事業者データセンタ、1200・・・アプリケーション計算機、1300・・・データ提供計算機、1400・・・管理計算機、2200・・・データ処理計算機、2400・・・Hub計算機、3000・・・フィールド、3200・・・ゲートウェイ計算機、3400・・・センサ、5000・・・業務、5100・・・センサデータ、5200・・・処理済データ、P1200・・・アプリケーション、P1300・・・データ提供プログラム、P1310・・・データレイク、P1400・・・監視プログラム、P1410・・・管理プログラム、P2200・・・データ処理プログラム、P2400・・・Hubプログラム、P3200・・・ゲートウェイプログラム、T1400・・・処理方式条件変更テーブル、T1420・・・処理方式定義テーブル、T2200・・・データ処理定義テーブル、T2400・・・Hub処理定義テーブル、T3200・・・ゲートウェイ処理定義テーブル

Claims (15)

1. 複数の監視対象の業務プロセスを監視する監視手段と、ネットワークに接続し複数種別のセンサ情報を処理する複数の異なる種別の外部装置の管理情報を前記ネットワークを介して管理する管理手段とをメモリに格納し、CPUにて実行する制御部を備え、
   前記制御部は、
   前記複数の監視対象の前記業務プロセスが変更されたか否かを判断し、
   前記業務プロセスが変更されたと判断すると、前記変更される業務プロセスの実行に必要な前記センサ情報の処理を変更させることを前記複数の異なる種別の外部装置へそれぞれ指示をすることを特徴とする管理計算機。
2. 請求項１に記載の管理計算機であって、
   前記業務プロセスが変更されたか否かを判断するために利用する処理方式変更条件情報と、前記業務プロセスの変更に対応した前記複数の異なる種別の外部装置を特定し、前記複数種別のセンサ情報の処理の変更を指示するために利用する処理方式定義情報とを記憶する記憶部をさらに備えることを特徴とする管理計算機。
3. 請求項２に記載の管理計算機であって、
   前記処理方式定義情報は予め処理の優先度を定めた優先度情報を備え、
   前記制御部は、前記処理方式定義情報に基づき特定された複数の異なる種別の外部装置の一つに対し、前記優先度情報に基づいて前記特定された一つの複数の異なる種別の外部装置の計算リソース量の増減させる指示を出力することを特徴とする管理計算機。
4. 請求項２に記載の管理計算機であって、
   前記処理方式定義情報は、前記複数の異なる種別の外部装置の負荷情報を備え、
   前記制御部は、前記負荷情報に基づいて、前記複数の異なる種別の外部装置への指示を出力することを特徴とする管理計算機。
5. 請求項４に記載の管理計算機であって、
   前記制御部は、前記複数の異なる種別の外部装置のうち前記センサ情報の送信元である第１の外部装置に対し、前記複数の異なる種別の外部装置のうち前記センサ情報の送信先である第２の外部装置の前記負荷情報に基づき、前記第１の外部装置から前記第２の外部装置へと前記センサ情報を送信させる送信指示または前記第１の外部装置から前記第２の外部装置へと前記センサ情報の送信を保留する保留指示または前記センサ情報の送信量を調節する流量制御指示を出力することを特徴とする管理計算機。
6. 請求項２に記載の管理計算機であって、
   利用者の操作を促す画面を表示する出力部と、利用者の入力を受け付ける入力部とをさらに備え、
   前記処理方式変更条件情報または前記処理方式定義情報の変更の入力を受け付ける画面を前記出力部へ出力することを特徴とする管理計算機。
7. 請求項２に記載の管理計算機であって、
   前記複数の異なる種別の外部装置への指示は、前記業務プロセスに使用する前記センサ情報の種別を変更する指示、前記センサ情報の転送経路を変更する指示、前記センサ情報の処理方法を変更する指示を含むことを特徴とする管理計算機。
8. 請求項２に記載の管理計算機であって、
   前記業務プロセスの変更は、前記センサ情報の価値の変更も含み、
   前記制御部は、外部環境の変化にともない他の外部装置から送信された外部環境情報に基づき前記処理方式変更条件情報に含まれる前記センサ情報の価値を変更することを特徴とする管理計算機。
9. センサ情報を外部装置から受信し、転送する中継計算機と、
   前記中継計算機から受信した前記センサ情報を加工処理し、転送するデータ処理計算機と、
   前記データ処理計算機から転送され加工処理された前記センサ情報を保存し、所定のタイミングでアプリケーションを実行するアプリ計算機へ転送するデータ提供計算機と、
   前記中継計算機と前記データ処理計算機とを管理し、前記アプリケーションを監視する管理計算機から構成され、
   前記管理計算機は、前記アプリケーションが変更されたと判断すると、前記中継計算機および前記データ処理計算機に、前記アプリケーションの変更に対応した前記センサ情報の処理の変更をそれぞれ指示することを特徴とするデータ処理システム。
10. 請求項９に記載のデータ処理システムであって、
    前記管理計算機は、前記アプリケーションが変更されたか否かを判断するために利用する処理方式変更条件情報と、前記アプリケーションの変更に対応した前記中継計算機および前記データ処理計算機を特定し前記センサ情報の処理の変更を指示するために利用する処理方式定義情報とを記憶することを特徴とするデータ処理システム。
11. 請求項１０に記載のデータ処理システムであって、
    前記処理方式定義情報は予め処理の優先度を定めた優先度情報を備え、
    前記管理計算機は、前記処理方式定義情報に基づき特定される前記データ処理装置のリソースを判断し、前記優先度に基づき前記リソースの増減をさせる指示を前記データ処理装置へ出力することを特徴とするデータ処理システム。
12. 請求項１０に記載のデータ処理システムであって、
    前記処理方式定義情報は、前記中継計算機および前記データ処理計算機の負荷情報を有し、
    前記管理計算機は、前記負荷情報に基づいて、前記センサ情報の送信指示または保留指示または流量制御指示を出力することを特徴とするデータ処理システム。
13. 請求項１２に記載のデータ処理システムであって、
    前記制御部は、前記センサ情報の送信元である前記中継装置に対し、前記センサ情報の送信先である前記データ処理装置の前記負荷情報に基づいた前記送信指示または前記保留指示を送信することを特徴とするデータ処理システム。
14. 請求項１０に記載のデータ処理システムであって、
    前記アプリケーションの変更は、前記センサ情報を価値の変更も含み、
    前記管理計算機は、外部環境の変化にともない他の外部装置から送信された外部環境情報に基づき前記処理方式変更条件情報に含まれる前記センサ情報の価値を変更することを特徴とするデータ処理システム。
15. ネットワークを介して接続する複数の異なる種別の外部装置を管理する管理計算機で実行されるデータ処理プログラムであって、
    複数の監視対象の業務プロセスを監視し、前記業務プロセスが変更されたか否かを検知する監視ステップと、
    前記監視ステップにより前記業務プロセスが変更されたと判断する場合、前記変更される業務プロセスの実行に必要な前記センサ情報の処理を変更させることを前記複数の異なる種別の外部装置へそれぞれ指示する指示ステップとを備えることを特徴とする前記管理計算機で実行されるデータ処理プログラム。

Images