データ処理方法、プログラムおよびシステム
【課題】管理データベース設計レスおよび管理システム設計レスが可能なデータ処理方法、プログラムおよびシステムを提供することを目的とする。
【解決手段】端末１０や、サーバ１１や、ＲＦＩＤタグ１４や、カメラ１３などを有するシステム１によるデータ処理方法であって、端末１０や、サーバ１１が、ＲＦＩＤタグ１４や、カメラ１３などから取得したデータなどを基に、当該データが格納されているメッセージ２０を生成し、システム１内のメッセージ２０を送信し、メッセージ２０を受信した端末１０や、サーバ１１が、メッセージ２０内のデータを処理することを特徴とする。
【解決手段】端末１０や、サーバ１１や、ＲＦＩＤタグ１４や、カメラ１３などを有するシステム１によるデータ処理方法であって、端末１０や、サーバ１１が、ＲＦＩＤタグ１４や、カメラ１３などから取得したデータなどを基に、当該データが格納されているメッセージ２０を生成し、システム１内のメッセージ２０を送信し、メッセージ２０を受信した端末１０や、サーバ１１が、メッセージ２０内のデータを処理することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理方法、プログラムおよびシステムの技術に関する。
【背景技術】
【０００２】
従来は、図６に示すように、一般的な大規模システム１ａでは、リーダ１２を介してサーバ１１に収集されたＲＦＩＤ（Radio Frequency Identification）タグ１４のデータや、サーバ１１に収集されたカメラ１３のデータ、あるいは端末１０から入力されたデータは、管理サーバ５２によって管理データベース５１に集中的に収集される。そして、ユーザが各端末１０を使用して、必要なデータを管理データベース５１から抽出・取得し、加工などをし、場合によってはデータベース１５にデータを格納することによって、システム運用が行われる。
【０００３】
このような、大規模なシステムを構築する際には、いわゆる、ＰＤＣＡ（plan-do-check-action）サイクルを用いたシステム構築が、しばしば実施される。このようなシステム構築の際には、図７に示すように、現場ヒアリング（Ｓ３０１）→管理データベース５１の設計（Ｓ３０２）→管理データベース５１の構築（Ｓ３０３）→管理システム（管理サーバ５２）設計（Ｓ３０４）→管理システム構築（Ｓ３０５）→システム１ａの運用（Ｓ３０６）→システム１ａの改善（Ｓ３０７）→現場ヒアリング（Ｓ３０１）→・・・を繰り返すことによりシステムの構築（完成形に至る）を行う。
【０００４】
例えば、特許文献１には、運用作業項目、運用要件、サービスレベルを格納する運用要件ＤＢ（Data Base）を有し、運用要件ＤＢの内容を画面表示し、設計項目を入力することによって、入力した設計項目を基に、コストの算出、設計ドキュメントの作成を行う運用設計支援システム、その方法およびプログラムが開示されている。特許文献１に記載の技術によれば、過去の運用設計のノウハウや、ドキュメントテンプレート、実際の運用において気付いたポイントなどを登録・蓄積することができるため、ＰＤＣＡサイクルを形成でき、運用の品質を向上することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−７５９６１号公報（請求項１，段落００２４）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、図７に示すようなサイクルを用いてシステムを構築するとき、管理データベース５１の設計（Ｓ３０２）〜管理システム構築（Ｓ３０５）に時間がかかることが多く、人員・予算などで開発が待たされ、結果としてビジネスの機会を損失することが多々ある。このため、リアルタイム性に欠け、進歩するデータ加工技術や、現場の情報への追従が遅れたり、現場へのすばやいフィードバックも困難となるといった問題がある。
このような問題の１つの解決方法として、管理データベース５１や、管理サーバ５２などの管理システムを使用しないで構築することが考えられる。
【０００７】
このような背景に鑑みて本発明がなされたのであり、本発明は、管理データベース設計レスおよび管理システム設計レスが可能なデータ処理方法、プログラムおよびシステムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するため、本発明は、複数の処理装置および複数の機器を有するシステムによるデータ処理方法であって、前記処理装置が、前記システム内の機器から取得したデータ、前記処理装置自身の記憶部に格納しているデータ、前記処理装置の入力部から入力されたデータ、および前記処理装置で処理されたデータのうち、少なくとも１つを基に、当該データが格納されているメッセージを生成し、一方の前記処理装置から、他方の前記処理装置へ、前記メッセージを送信し、前記メッセージを受信した前記処理装置が、前記メッセージ内のデータを処理することを特徴とする。
その他の解決手段については、実施形態中で適宜説明する。
【発明の効果】
【０００９】
本発明によれば、管理データベース設計レスおよび管理システム設計レスが可能なデータ処理方法、プログラムおよびシステムを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態に係るシステムの構成例を示す図である。
【図２】本実施形態に係る処理装置の構成例を示す図である。
【図３】本実施形態に係るメッセージの構成例を示す図である。
【図４】本実施形態に係るシステムの処理手順を示すフローチャートであり、（ａ）はメッセージ送信時の処理手順を示し、（ｂ）はメッセージ受信時の処理手順を示している。
【図５】本実施形態に係るメッセージを用いた応用例を示す図である。
【図６】従来の大規模システムの例を示す図である。
【図７】システム構築に係るＰＤＣＡサイクルの例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
【００１２】
（システム構成）
図１は、本実施形態に係るシステムの構成例を示す図である。
システム１は、機器である複数の端末１０、サーバ１１、ＲＦＩＤタグ１４からの信号を受信するリーダ１２や、カメラ１３や、データベース１５などによって構成されている。このうち、端末１０や、サーバ１１や、データベース１５などは互いに接続されている。また、図１の例ではリーダ１２や、カメラ１３はサーバ１１と接続されている。本実施形態において、特徴的な構成は、これらの端末１０や、サーバ１１間の通信手段として、詳細を後記するメッセージ２０が用いられる点である。本実施形態に係るシステム１では、メッセージ２０を受信した端末１０や、サーバ１１などが処理することにより、図６における管理データベース５１や、管理サーバ５２の構築を不要とすることを特徴とするものである。
【００１３】
なお、図１に示すシステム１は一例であり、図６に示す、管理データベース５１や、管理サーバ５２を備えるか否かにかかわらず、システム１内の機器間をメッセージ２０によって、情報を送受信する構成であればよい。
【００１４】
（処理装置構成）
図２は、本実施形態に係る処理装置の構成例を示す図である。
なお、図２に示す処理装置１００は、図１に示す端末１０や、サーバ１１などに相当する装置である。
処理装置１００は、外部の装置へデータを送信する送信部１２１、外部の装置からデータを受信する受信部１２２、キーボードや、マウスなどの入力部１２３、ディスプレイなどの表示部１２４、データを処理する処理部１１０、データを保存する記憶部１２５を有している。
【００１５】
また、処理部１１０は、データ取得部１１１、メッセージ生成部１１２、データ抽出部１１３、データ処理部１１４を有している。データ取得部１１１は、受信部１２２が受信したカメラ１３や、リーダ１２からのデータを取得したり、記憶部１２５からデータを取得したりする機能を有する。メッセージ生成部１１２は、データ取得部１１１が取得したデータを基にメッセージ２０を生成する機能を有する。データ抽出部１１３は、受信部１２２が受信したメッセージ２０からデータを抽出する機能を有する。データ処理部１１４は、入力部１２３などからの指示に従って、データ抽出部１１３が抽出したデータを加工するなど、各種のデータ処理を行う機能を有する。
【００１６】
なお、各１１０〜１１４は、図示しないＲＯＭ（Read Only Memory）や、図示しないＨＤ（Hard Disk）に格納されたプログラムが、図示しないＲＡＭ（Random Access Memory）に展開され、図示しないＣＰＵ（Central Processing Unit）によって実行されることによって具現化する。
【００１７】
（メッセージ構成）
図３は、本実施形態に係るメッセージの構成例を示す図である。
メッセージ２０は、発信元情報、データ数値、宛先情報、単位名、生成日時、閾値１、閾値２、プロセス条件、加工装置情報、作業者名などの各種データが格納されている。なお、図３に示すメッセージ２０の構成は一例であり、格納されるデータは図３のものに限らないし、格納される順序も図３の順序に限らない。
なお、メッセージ２０に格納されるデータの先頭には、例えば、先頭以降何バイト分のデータが、何のデータであるかなどを表すヘッダ情報が付いていてもよい。あるいは、メッセージ２０の一番頭に格納されているデータの順序や、構成などをまとめて記したヘッダ情報が付いていてもよい。
なお、メッセージのデータ形式は文字列であることが望ましいが、ＸＭＬ（Extensible Markup Language）などで記述されていてもよい。
【００１８】
（フローチャート）
図４は、本実施形態に係るシステムの処理手順を示すフローチャートであり、（ａ）はメッセージ送信時の処理手順を示し、（ｂ）はメッセージ受信時の処理手順を示している。
まず、図４（ａ）を参照して、メッセージ送信時の処理手順を説明する（適宜、図１〜図３参照）と、データ取得部１１１が、リーダ１２や、カメラ１３で収集したデータを受信部１２２から取得したり、記憶部１２５から必要なデータを取得する（Ｓ１０１）。
次に、メッセージ生成部１１２が、ステップＳ１０１で取得したデータを基に、図３に示すようなメッセージ２０を生成する（Ｓ１０２）。このとき、メッセージ２０には、ステップＳ１０１で取得したデータのすべて、あるいは可能な限り（少なくとも１つ）のデータが格納される。
そして、送信部１２１がステップＳ１０２で生成したメッセージ２０を送信する（Ｓ１０３）。メッセージ２０の送信は、システム１内の端末１０や、サーバ１１に対するブロードキャスト送信が望ましいが、必要に応じてマルチキャストで送信したり、ユニキャストで送信してもよい。なお、メッセージ２０は、メールなどと異なり、カメラ１３や、ＲＦＩＤタグ１４からデータを取得したサーバ１１や、端末１０が、自動的にメッセージ２０の生成・送信を行ってもよい。
【００１９】
次に、図４（ｂ）を参照して、メッセージ受信時の処理手順を説明すると、まず、受信部１２２がメッセージ２０を受信する（Ｓ２０１）。なお、この段階でメッセージ２０が処理装置１００内の記憶部１２５に一次保存されてもよい。
次に、データ抽出部１１３が、受信したメッセージ２０からデータを抽出する（Ｓ２０２）。
そして、ユーザが、入力部１２３を介して、ステップＳ２０２で抽出したデータから必要なデータを選択、加工、保存、あるいは破棄などの指示を入力し、データ処理部１１４が入力された指示に基づいて、ステップＳ２０２で抽出したデータを処理する（Ｓ２０３）。
【００２０】
このように、データ発生源（ＲＦＩＤタグ１４や、カメラ１３など）に接続しているサーバ１１や、端末１０などからデータをメッセージ２０の形式にして直接システム１内の端末１０などに送信し、メッセージ２０の処理を受信した端末１０や、サーバ１１側に任せることで、図６に示す管理サーバ５２や、管理データベース５１を不要とすることができる。さらに、管理サーバ５２や、管理データベース５１を不要とすることにより、図７に示す管理データベース５１の設計（Ｓ３０２）〜管理システム構築（Ｓ３０５）も不要となるため、システム１の構築期間を短縮することができる。特に、ＰＤＣＡサイクルを用いたシステム１の構築においては、システム１の構築期間の大幅な短縮を可能とすることができる。これにより、システムの構築から運用までのリアルタイム性を確保することができ、進歩するデータ加工技術や、早い現場の情報への追従や、現場へのすばやいフィードバックを可能とすることができる。
【００２１】
（応用例）
図５は、本実施形態に係るメッセージを用いた応用例を示す図である。
図５は、内部に端末１０や、サーバ１１や、カメラ１３や、ＲＦＩＤタグ１４や、リーダ１２や、データベース１５などを有する独立したシステムＡ〜Ｃが存在する大規模システムを示す。
これらのシステムＡ〜Ｃは、ＷＡＮ（Wide Area Network）などのネットワークで接続されている。一般的には、システムＡ〜Ｃは、それぞれ閉じていることが多く、データ処理は、それぞれのシステムＡ〜Ｃ内で完結し、外部のシステム１に存在する端末１０からは処理の結果を見ることしかできないことが多い。
【００２２】
本実施形態に係るメッセージ２０−１を用いることにより、例えば、リーダ１２に接続しているサーバ１１が、ＲＦＩＤタグ１４から取得したデータをメッセージ２０−１の形式にしてシステムＡ内の端末１０に送信すると同時に、システムＢ，Ｃ内の端末１０や、サーバ１１にもブロードキャスト送信する。メッセージ２０−１を受信した端末１０や、サーバ１１では、必要に応じてメッセージ２０−１内のデータの加工、保存、破棄などの処理を行う。さらに、加工したデータをメッセージ２０−２の形式にして、システムＡ〜Ｃ内の端末１０や、サーバ１１に送信し、このメッセージ２０−２を受信した端末１０や、サーバ１１では、メッセージ２０−２内のデータの加工、保存、破棄などの処理を行う。図５の例では、システムＢ内の端末１０ａがメッセージ２０−２の生成を行い、同じシステムＢ内の他の端末１０へメッセージ２０−２を送信するとともに、システムＡおよびシステムＣ内の端末１０や、サーバ１１へメッセージ２０−２を送信している。
これにより、すなわち、各端末１０、サーバ１１間をピア・トゥ・ピアの方式でメッセージを送受信することにより、システムＡ〜Ｃを、あたかも１つのシステム１のように使用することができる。
【００２３】
なお、図１に示すシステム１に辞書サーバを設け、メッセージ２０（図１）内の用語のチェックを行わせてもよい。
【符号の説明】
【００２４】
１ システム
１０ 端末（処理装置）
１１ サーバ（処理装置）
１２ リーダ（機器）
１３ カメラ（機器）
１４ ＲＦＩＤタグ
１５ データベース
２０ メッセージ
１００ 処理装置
１１０ 処理部
１１１ データ取得部
１１２ メッセージ生成部
１１３ データ抽出部
１１４ データ処理部
【技術分野】
【０００１】
本発明は、データ処理方法、プログラムおよびシステムの技術に関する。
【背景技術】
【０００２】
従来は、図６に示すように、一般的な大規模システム１ａでは、リーダ１２を介してサーバ１１に収集されたＲＦＩＤ（Radio Frequency Identification）タグ１４のデータや、サーバ１１に収集されたカメラ１３のデータ、あるいは端末１０から入力されたデータは、管理サーバ５２によって管理データベース５１に集中的に収集される。そして、ユーザが各端末１０を使用して、必要なデータを管理データベース５１から抽出・取得し、加工などをし、場合によってはデータベース１５にデータを格納することによって、システム運用が行われる。
【０００３】
このような、大規模なシステムを構築する際には、いわゆる、ＰＤＣＡ（plan-do-check-action）サイクルを用いたシステム構築が、しばしば実施される。このようなシステム構築の際には、図７に示すように、現場ヒアリング（Ｓ３０１）→管理データベース５１の設計（Ｓ３０２）→管理データベース５１の構築（Ｓ３０３）→管理システム（管理サーバ５２）設計（Ｓ３０４）→管理システム構築（Ｓ３０５）→システム１ａの運用（Ｓ３０６）→システム１ａの改善（Ｓ３０７）→現場ヒアリング（Ｓ３０１）→・・・を繰り返すことによりシステムの構築（完成形に至る）を行う。
【０００４】
例えば、特許文献１には、運用作業項目、運用要件、サービスレベルを格納する運用要件ＤＢ（Data Base）を有し、運用要件ＤＢの内容を画面表示し、設計項目を入力することによって、入力した設計項目を基に、コストの算出、設計ドキュメントの作成を行う運用設計支援システム、その方法およびプログラムが開示されている。特許文献１に記載の技術によれば、過去の運用設計のノウハウや、ドキュメントテンプレート、実際の運用において気付いたポイントなどを登録・蓄積することができるため、ＰＤＣＡサイクルを形成でき、運用の品質を向上することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−７５９６１号公報（請求項１，段落００２４）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、図７に示すようなサイクルを用いてシステムを構築するとき、管理データベース５１の設計（Ｓ３０２）〜管理システム構築（Ｓ３０５）に時間がかかることが多く、人員・予算などで開発が待たされ、結果としてビジネスの機会を損失することが多々ある。このため、リアルタイム性に欠け、進歩するデータ加工技術や、現場の情報への追従が遅れたり、現場へのすばやいフィードバックも困難となるといった問題がある。
このような問題の１つの解決方法として、管理データベース５１や、管理サーバ５２などの管理システムを使用しないで構築することが考えられる。
【０００７】
このような背景に鑑みて本発明がなされたのであり、本発明は、管理データベース設計レスおよび管理システム設計レスが可能なデータ処理方法、プログラムおよびシステムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するため、本発明は、複数の処理装置および複数の機器を有するシステムによるデータ処理方法であって、前記処理装置が、前記システム内の機器から取得したデータ、前記処理装置自身の記憶部に格納しているデータ、前記処理装置の入力部から入力されたデータ、および前記処理装置で処理されたデータのうち、少なくとも１つを基に、当該データが格納されているメッセージを生成し、一方の前記処理装置から、他方の前記処理装置へ、前記メッセージを送信し、前記メッセージを受信した前記処理装置が、前記メッセージ内のデータを処理することを特徴とする。
その他の解決手段については、実施形態中で適宜説明する。
【発明の効果】
【０００９】
本発明によれば、管理データベース設計レスおよび管理システム設計レスが可能なデータ処理方法、プログラムおよびシステムを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態に係るシステムの構成例を示す図である。
【図２】本実施形態に係る処理装置の構成例を示す図である。
【図３】本実施形態に係るメッセージの構成例を示す図である。
【図４】本実施形態に係るシステムの処理手順を示すフローチャートであり、（ａ）はメッセージ送信時の処理手順を示し、（ｂ）はメッセージ受信時の処理手順を示している。
【図５】本実施形態に係るメッセージを用いた応用例を示す図である。
【図６】従来の大規模システムの例を示す図である。
【図７】システム構築に係るＰＤＣＡサイクルの例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
【００１２】
（システム構成）
図１は、本実施形態に係るシステムの構成例を示す図である。
システム１は、機器である複数の端末１０、サーバ１１、ＲＦＩＤタグ１４からの信号を受信するリーダ１２や、カメラ１３や、データベース１５などによって構成されている。このうち、端末１０や、サーバ１１や、データベース１５などは互いに接続されている。また、図１の例ではリーダ１２や、カメラ１３はサーバ１１と接続されている。本実施形態において、特徴的な構成は、これらの端末１０や、サーバ１１間の通信手段として、詳細を後記するメッセージ２０が用いられる点である。本実施形態に係るシステム１では、メッセージ２０を受信した端末１０や、サーバ１１などが処理することにより、図６における管理データベース５１や、管理サーバ５２の構築を不要とすることを特徴とするものである。
【００１３】
なお、図１に示すシステム１は一例であり、図６に示す、管理データベース５１や、管理サーバ５２を備えるか否かにかかわらず、システム１内の機器間をメッセージ２０によって、情報を送受信する構成であればよい。
【００１４】
（処理装置構成）
図２は、本実施形態に係る処理装置の構成例を示す図である。
なお、図２に示す処理装置１００は、図１に示す端末１０や、サーバ１１などに相当する装置である。
処理装置１００は、外部の装置へデータを送信する送信部１２１、外部の装置からデータを受信する受信部１２２、キーボードや、マウスなどの入力部１２３、ディスプレイなどの表示部１２４、データを処理する処理部１１０、データを保存する記憶部１２５を有している。
【００１５】
また、処理部１１０は、データ取得部１１１、メッセージ生成部１１２、データ抽出部１１３、データ処理部１１４を有している。データ取得部１１１は、受信部１２２が受信したカメラ１３や、リーダ１２からのデータを取得したり、記憶部１２５からデータを取得したりする機能を有する。メッセージ生成部１１２は、データ取得部１１１が取得したデータを基にメッセージ２０を生成する機能を有する。データ抽出部１１３は、受信部１２２が受信したメッセージ２０からデータを抽出する機能を有する。データ処理部１１４は、入力部１２３などからの指示に従って、データ抽出部１１３が抽出したデータを加工するなど、各種のデータ処理を行う機能を有する。
【００１６】
なお、各１１０〜１１４は、図示しないＲＯＭ（Read Only Memory）や、図示しないＨＤ（Hard Disk）に格納されたプログラムが、図示しないＲＡＭ（Random Access Memory）に展開され、図示しないＣＰＵ（Central Processing Unit）によって実行されることによって具現化する。
【００１７】
（メッセージ構成）
図３は、本実施形態に係るメッセージの構成例を示す図である。
メッセージ２０は、発信元情報、データ数値、宛先情報、単位名、生成日時、閾値１、閾値２、プロセス条件、加工装置情報、作業者名などの各種データが格納されている。なお、図３に示すメッセージ２０の構成は一例であり、格納されるデータは図３のものに限らないし、格納される順序も図３の順序に限らない。
なお、メッセージ２０に格納されるデータの先頭には、例えば、先頭以降何バイト分のデータが、何のデータであるかなどを表すヘッダ情報が付いていてもよい。あるいは、メッセージ２０の一番頭に格納されているデータの順序や、構成などをまとめて記したヘッダ情報が付いていてもよい。
なお、メッセージのデータ形式は文字列であることが望ましいが、ＸＭＬ（Extensible Markup Language）などで記述されていてもよい。
【００１８】
（フローチャート）
図４は、本実施形態に係るシステムの処理手順を示すフローチャートであり、（ａ）はメッセージ送信時の処理手順を示し、（ｂ）はメッセージ受信時の処理手順を示している。
まず、図４（ａ）を参照して、メッセージ送信時の処理手順を説明する（適宜、図１〜図３参照）と、データ取得部１１１が、リーダ１２や、カメラ１３で収集したデータを受信部１２２から取得したり、記憶部１２５から必要なデータを取得する（Ｓ１０１）。
次に、メッセージ生成部１１２が、ステップＳ１０１で取得したデータを基に、図３に示すようなメッセージ２０を生成する（Ｓ１０２）。このとき、メッセージ２０には、ステップＳ１０１で取得したデータのすべて、あるいは可能な限り（少なくとも１つ）のデータが格納される。
そして、送信部１２１がステップＳ１０２で生成したメッセージ２０を送信する（Ｓ１０３）。メッセージ２０の送信は、システム１内の端末１０や、サーバ１１に対するブロードキャスト送信が望ましいが、必要に応じてマルチキャストで送信したり、ユニキャストで送信してもよい。なお、メッセージ２０は、メールなどと異なり、カメラ１３や、ＲＦＩＤタグ１４からデータを取得したサーバ１１や、端末１０が、自動的にメッセージ２０の生成・送信を行ってもよい。
【００１９】
次に、図４（ｂ）を参照して、メッセージ受信時の処理手順を説明すると、まず、受信部１２２がメッセージ２０を受信する（Ｓ２０１）。なお、この段階でメッセージ２０が処理装置１００内の記憶部１２５に一次保存されてもよい。
次に、データ抽出部１１３が、受信したメッセージ２０からデータを抽出する（Ｓ２０２）。
そして、ユーザが、入力部１２３を介して、ステップＳ２０２で抽出したデータから必要なデータを選択、加工、保存、あるいは破棄などの指示を入力し、データ処理部１１４が入力された指示に基づいて、ステップＳ２０２で抽出したデータを処理する（Ｓ２０３）。
【００２０】
このように、データ発生源（ＲＦＩＤタグ１４や、カメラ１３など）に接続しているサーバ１１や、端末１０などからデータをメッセージ２０の形式にして直接システム１内の端末１０などに送信し、メッセージ２０の処理を受信した端末１０や、サーバ１１側に任せることで、図６に示す管理サーバ５２や、管理データベース５１を不要とすることができる。さらに、管理サーバ５２や、管理データベース５１を不要とすることにより、図７に示す管理データベース５１の設計（Ｓ３０２）〜管理システム構築（Ｓ３０５）も不要となるため、システム１の構築期間を短縮することができる。特に、ＰＤＣＡサイクルを用いたシステム１の構築においては、システム１の構築期間の大幅な短縮を可能とすることができる。これにより、システムの構築から運用までのリアルタイム性を確保することができ、進歩するデータ加工技術や、早い現場の情報への追従や、現場へのすばやいフィードバックを可能とすることができる。
【００２１】
（応用例）
図５は、本実施形態に係るメッセージを用いた応用例を示す図である。
図５は、内部に端末１０や、サーバ１１や、カメラ１３や、ＲＦＩＤタグ１４や、リーダ１２や、データベース１５などを有する独立したシステムＡ〜Ｃが存在する大規模システムを示す。
これらのシステムＡ〜Ｃは、ＷＡＮ（Wide Area Network）などのネットワークで接続されている。一般的には、システムＡ〜Ｃは、それぞれ閉じていることが多く、データ処理は、それぞれのシステムＡ〜Ｃ内で完結し、外部のシステム１に存在する端末１０からは処理の結果を見ることしかできないことが多い。
【００２２】
本実施形態に係るメッセージ２０−１を用いることにより、例えば、リーダ１２に接続しているサーバ１１が、ＲＦＩＤタグ１４から取得したデータをメッセージ２０−１の形式にしてシステムＡ内の端末１０に送信すると同時に、システムＢ，Ｃ内の端末１０や、サーバ１１にもブロードキャスト送信する。メッセージ２０−１を受信した端末１０や、サーバ１１では、必要に応じてメッセージ２０−１内のデータの加工、保存、破棄などの処理を行う。さらに、加工したデータをメッセージ２０−２の形式にして、システムＡ〜Ｃ内の端末１０や、サーバ１１に送信し、このメッセージ２０−２を受信した端末１０や、サーバ１１では、メッセージ２０−２内のデータの加工、保存、破棄などの処理を行う。図５の例では、システムＢ内の端末１０ａがメッセージ２０−２の生成を行い、同じシステムＢ内の他の端末１０へメッセージ２０−２を送信するとともに、システムＡおよびシステムＣ内の端末１０や、サーバ１１へメッセージ２０−２を送信している。
これにより、すなわち、各端末１０、サーバ１１間をピア・トゥ・ピアの方式でメッセージを送受信することにより、システムＡ〜Ｃを、あたかも１つのシステム１のように使用することができる。
【００２３】
なお、図１に示すシステム１に辞書サーバを設け、メッセージ２０（図１）内の用語のチェックを行わせてもよい。
【符号の説明】
【００２４】
１ システム
１０ 端末（処理装置）
１１ サーバ（処理装置）
１２ リーダ（機器）
１３ カメラ（機器）
１４ ＲＦＩＤタグ
１５ データベース
２０ メッセージ
１００ 処理装置
１１０ 処理部
１１１ データ取得部
１１２ メッセージ生成部
１１３ データ抽出部
１１４ データ処理部
【特許請求の範囲】
【請求項１】
複数の処理装置および複数の機器を有するシステムによるデータ処理方法であって、
前記処理装置が、前記システム内の機器から取得したデータ、前記処理装置自身の記憶部に格納しているデータ、前記処理装置の入力部から入力されたデータ、および前記処理装置で処理されたデータのうち、少なくとも１つを基に、当該データが格納されているメッセージを生成し、
一方の前記処理装置から、他方の前記処理装置へ、前記メッセージを送信し、
前記メッセージを受信した前記処理装置が、前記メッセージ内のデータを処理する
ことを特徴とするデータ処理方法。
【請求項２】
前記処理装置が、
前記メッセージを前記システム内の前記処理装置へ向けてブロードキャスト送信する
ことを特徴とする請求項１に記載のデータ処理方法。
【請求項３】
前記処理装置には、前記機器としてＲＦＩＤタグリーダまたはカメラが接続されており、
前記機器から取得したデータとは、前記ＲＦＩＤタグリーダから取得したＲＦＩＤタグのデータ、または前記カメラから取得したデータである
ことを特徴とする請求項１にデータ処理方法。
【請求項４】
前記処理装置が、
前記ＲＦＩＤタグリーダまたはカメラから、データを取得するとともに、前記データを基に前記メッセージを生成する
ことを特徴とする請求項３に記載のデータ処理方法。
【請求項５】
請求項１から請求項４のいずれか一項に記載のデータ処理方法をコンピュータに実行させることを特徴とするプログラム。
【請求項６】
複数の処理装置および複数の機器を有するシステムであって、
前記処理装置は、
前記システム内の機器から取得したデータ、前記処理装置自身の記憶部に格納しているデータ、前記処理装置の入力部から入力されたデータ、および前記処理装置で処理されたデータのうち、少なくとも１つを基に、当該データが格納されているメッセージを生成し、
一方の前記処理装置から、他方の前記処理装置へ、前記メッセージを送信し、
前記メッセージを受信した前記処理装置が、前記メッセージ内のデータを処理する
ことを特徴とするシステム。
【請求項１】
複数の処理装置および複数の機器を有するシステムによるデータ処理方法であって、
前記処理装置が、前記システム内の機器から取得したデータ、前記処理装置自身の記憶部に格納しているデータ、前記処理装置の入力部から入力されたデータ、および前記処理装置で処理されたデータのうち、少なくとも１つを基に、当該データが格納されているメッセージを生成し、
一方の前記処理装置から、他方の前記処理装置へ、前記メッセージを送信し、
前記メッセージを受信した前記処理装置が、前記メッセージ内のデータを処理する
ことを特徴とするデータ処理方法。
【請求項２】
前記処理装置が、
前記メッセージを前記システム内の前記処理装置へ向けてブロードキャスト送信する
ことを特徴とする請求項１に記載のデータ処理方法。
【請求項３】
前記処理装置には、前記機器としてＲＦＩＤタグリーダまたはカメラが接続されており、
前記機器から取得したデータとは、前記ＲＦＩＤタグリーダから取得したＲＦＩＤタグのデータ、または前記カメラから取得したデータである
ことを特徴とする請求項１にデータ処理方法。
【請求項４】
前記処理装置が、
前記ＲＦＩＤタグリーダまたはカメラから、データを取得するとともに、前記データを基に前記メッセージを生成する
ことを特徴とする請求項３に記載のデータ処理方法。
【請求項５】
請求項１から請求項４のいずれか一項に記載のデータ処理方法をコンピュータに実行させることを特徴とするプログラム。
【請求項６】
複数の処理装置および複数の機器を有するシステムであって、
前記処理装置は、
前記システム内の機器から取得したデータ、前記処理装置自身の記憶部に格納しているデータ、前記処理装置の入力部から入力されたデータ、および前記処理装置で処理されたデータのうち、少なくとも１つを基に、当該データが格納されているメッセージを生成し、
一方の前記処理装置から、他方の前記処理装置へ、前記メッセージを送信し、
前記メッセージを受信した前記処理装置が、前記メッセージ内のデータを処理する
ことを特徴とするシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１０−２８２３９５（Ｐ２０１０−２８２３９５Ａ）
【公開日】平成２２年１２月１６日（２０１０．１２．１６）
【国際特許分類】
【出願番号】特願２００９−１３４８６６（Ｐ２００９−１３４８６６）
【出願日】平成２１年６月４日（２００９．６．４）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２２年１２月１６日（２０１０．１２．１６）
【国際特許分類】
【出願日】平成２１年６月４日（２００９．６．４）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]