JP5687882B2 - 情報管理方法および情報処理装置 - Google Patents

Description

本発明は、情報管理方法および情報処理装置の技術に関する。

自動車製造工程管理システムなどでは、生産の効率化のため、同一の自動車製造ライン（以下、適宜ラインと称する）で複数車種が製造されている。車両毎に作業指示は異なっており、正確な作業指示を行うためには、ラインにおける車両の所在位置を正確に把握しておく必要がある。また、自動車製造ラインは一般的に溶接工程や、塗装工程や、組立工程などからなっており、各工程で発生する車両通過に対し、リアルタイムで車両の所在位置情報の更新を実現するためには、高い処理スピードを持つシステムが求められる。
また一方で、製造管理者が車両の所在状況を確認するため、所在位置情報をクライアント端末の画面などにリアルタイム表示する必要がある。ここで、車両通過による所在位置情報更新処理の際には、データの整合性を保つため排他がかけられている。つまり、所在位置情報の更新処理中はクライアント端末からサーバが管理しているデータにアクセスできなくなる。

例えば、ある車両ａが、工程Ａから工程Ｂへライン上を移動した場合、工程Ａと工程Ｂとの間に設置されているセンサ読取装置などによって車両（どの車両かはわからない）が１台、工程Ａから工程Ｂへ送られたことが検知されるとする。サーバは、車両の所在位置情報として、どの車両がどの工程に所在しているのかを管理している。ここで、工程Ａから工程Ｂへ車両が移動したことを検知したサーバは、工程Ａの先頭に所在していた車両ａが工程Ａから工程Ｂへ移動したと判定し、車両ａの所在位置情報を工程Ａから工程Ｂへ移すことで所在位置情報の更新を行う。しかし、このとき、クライアント端末から車両ａの所在位置情報を操作する処理が行われると、車両ａの所在位置情報の整合性がなくなってしまうおそれがある。従って、サーバは、所在位置情報を更新する際、クライアント端末からのアクセスを停止し、排他処理を行うことによって所在位置の整合性を維持する。

センサではなく、移動する車両が特定できるＲＦＩＤ（Radio Frequency Identification）リーダなどを用いても、このような整合性の問題が生じ得る。

ラインにおける車両の移動は随時発生しているため、車両の所在位置情報の更新は頻繁に行われている。そのため、クライアント端末からのアクセスが排他による制限も頻繁に生じ、車両の所在位置情報をクライアント端末画面にリアルタイム表示することは困難である。

そこで、従来では、車両の所在位置情報を、サーバが各クライアント端末へ配信することで、クライアン０ト端末からサーバヘアクセスする必要をなくしつつ、クライアント端末の画面表示のリアルタイム性を確保している。

なお、特許文献１には、配電系統や、配電設備などの工事に伴い、ユーザがデータを修正するときに、ホストに接続しているクライアントにデータを送信し、データを一致させる際に、常時クライアントに送信してデータを一致化を行うのではなく、クライアント立ち上げ時に一致化を行う配電自動化システムのデータ一致化方式が開示されている。

特開２０００−２９９９３５号公報

前記したようなクライアント端末に車両の所在位置を配信する技術では、ラインにおける車両の移動により車両の所在位置情報が更新される度にサーバから各クライアント端末へ最新の所在位置情報を配信しているため、ネットワーク負荷が高くなってしまうという問題がある。また、サーバと各クライアント端末でデータを保持しているため、各クライアント端末とサーバでデータの整合性を確保しなければならない。この点において、クライアント端末を追加すると、その分サーバ−クライアント端末間で整合性を確保しなければならず、クライアント端末の数が増加すると不整合が発生する確率も増加するため、容易にクライアント端末を増設できないという制約がある。
このような問題は、自動車製造工程管理システム以外の製造システムなどでも生じている問題である。

このような背景に鑑みて本発明がなされたのであり、本発明は、排他性を維持しつつ、工程の進捗閲覧のリアルタイム性を確保するとともに、情報処理装置と、クライアント端末間の通信負荷の低減も実現することを目的とする。

前記課題を解決するため、本発明は、システムの制御に関するデータである制御データと、前記制御データとは、別のデータであるとともに、前記制御データとは別の構成を有しており、かつ、前記制御データの内容をクライアント端末によって閲覧させることに適した構成を有する管理データと、を記憶部に格納している情報処理装置の情報管理方法であって、前記情報処理装置は、前記制御データが更新されると、前記更新の内容を前記管理データに反映し、前記管理データは、前記クライアント端末による閲覧が可能であるが、前記クライアント端末による内容の操作が不可能であることを特徴とする。
その他の解決手段については実施形態中で適宜説明する。

本発明によれば、排他性を維持しつつ、工程の進捗閲覧のリアルタイム性を確保するとともに、情報処理装置と、クライアント端末間の通信負荷の低減も実現する。

本実施形態に係る製造管理システムの構成例を示す図である。 本実施形態に係る制御データ（スペック管理用）の例を示す図である。 本実施形態に係る制御データ（組立工程１用）の例を示す図である。 本実施形態に係る制御データ（組立工程２用）の例を示す図である。 本実施形態に係る管理データ（Ｔ−ＳＰＥＣテーブルデータ）の例を示す図である。 本実施形態に係る管理データ（Ｔ−ＳＥＱテーブルデータ）の例を示す図である。 本実施形態に係る対応マスタデータの例を示す図である。 本実施形態に係る製造管理システムのサーバにおける処理の手順を示すフローチャートである。

次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。

（システム構成図）
図１は、本実施形態に係る製造管理システムの構成例を示す図である。なお、本実施形態では、自動車製造工程に生産管理システムを適用した例を示すが、その他の製造工程に適用してもよい。
システムである製造管理システム５は、情報の処理を行う情報処理装置としてのサーバ１と、ユーザが車両の所在位置情報を閲覧して、確認するためのクライアント端末２と、複数の作業指示デバイス３を有する。
自動車製造工程は複数の作業工程（溶接工程１、溶接工程２、塗装工程１、・・・）からなり、各工程間にはＲＦＩＤリーダや、センサ読取装置などの検知装置４が設置されており、車両の通過を検知している。各工程には、プリンタや、コンピュータである作業指示デバイス３が設置されている。

サーバ１は、所在位置追従処理部１１、データ更新処理部１２、データ変換・更新処理部１３、データ修正処理部１４および作業指示処理部１５を有しており、データとして、制御データ１６、管理データ１７および対応マスタデータ１８が記憶部１９に格納されている。
各部１１〜１５は、図示しないＲＯＭ（Read Only Memory）や、ＨＤＤ（Hard Disk Drive）に格納されたプログラムが、ＲＡＭ（Random Access Memory）に展開され、ＣＰＵ（Central Processing Unit）によって実行されることによって具現化する。

車両の通過が検知装置４によって検知されると、検知された情報は、サーバ１の所在位置追従処理部１１へ送信される。所在位置追従処理部１１は、検知された情報を基に、通過した車両のＩＤや、通過先の工程を判別し、車両の所在位置情報を更新するため、判別結果をデータ更新処理部１２へ渡す。データ更新処理部１２は、制御データ１６を更新する。
データ変換・更新処理部１３は、対応マスタデータ１８を参照して、制御データ１６の変更を管理データ１７に反映して管理データ１７を更新する。制御データ１６、管理データ１７および対応マスタデータ１８は、図２Ａ〜図４を参照して後記する。
作業指示処理部１５は、制御データ１６を参照して、作業指示デバイス３ヘ作業指示を実施する。

クライアント端末２が所在位置情報を閲覧したいときには、管理データ１７を閲覧することになる。このとき、クライアント端末２は管理データ１７を操作することはできない。クライアント端末２による所在位置情報（制御データ１６）の変更を行うときは、クライアント端末２はサーバ１のデータ修正処理部１４へアクセス・変更要求を行い、データ修正処理部１４がデータ更新処理部１２を介して制御データ１６の変更を行う。なお、クライアント端末２による所在位置情報の変更を行うときは、排他処理が行われる。つまり、サーバ１のデータ更新処理部１２が制御データ１６にアクセスしているときは、クライアント端末２による所在位置情報（制御データ１６）の変更を行うことはできない。なお、クライアント端末２による所在位置情報（制御データ１６）の変更も、データ変換・更新処理部１３によって管理データ１７に反映される。

（制御データ）
図２Ａ〜図２Ｃは、本実施形態に係る制御データの例を示す図である。
制御データ１６は、作業指示デバイス３に作業指示を与える際に参照するためのデータであり、サーバ１は、図２Ａのようなスペック管理用の制御データ１６や、図２Ｂのような組立工程１用の制御データ１６や、図２Ｃのような組立工程２用の制御データ１６などを有している。この他にも、エンジンタイプ用の制御データ１６や、プランニングナンバ用の制御データ１６なども有している。

図２Ａに示すように、スペック管理用の制御データ１６には、車両毎に色、車両タイプ、ルーフタイプ、ミラータイプなどの各タイプに関する情報が格納されている。また、図２Ｂに示す組立工程１用の制御データ１６には、組立工程１に所在している車両の順番（「０００１」や、「０００２」など）が格納されている。図２Ｂに示す制御データ１６の例では、車両「Ｂ１」が１番目（「０００１」）であり、車両「Ｂ２」が２番目（「０００２」）である。空欄の車両は、組立工程１に所在していないことを示す。

同様に、図２Ｃに示す組立工程２用の制御データには、組立工程２に所在している車両の順番（「０００１」や、「０００２」など）が格納されている。図２Ｃに示す制御データ１６の例では、車両「Ａ１」が１番目（「０００１」）であり、車両「Ａ２」が２番目（「０００２」）である。空欄の車両は、組立工程２に所在していないことを示す。

（管理データ）
図３Ａおよび図３Ｂは、本実施形態に係る管理データの例を示す図である。
管理データ１７は、クライアント端末２が所在位置情報などを閲覧するためのデータであり、制御データ１６を基に閲覧しやすいようテーブルの形式にまとめられたデータである。
図３Ａは、スペックテーブルデータ（「Ｔ−ＳＰＥＣテーブルデータ」）の例であり、各車両における色、車両タイプ、ルーフタイプ、ミラータイプなどの各スペックデータ（「ＳＰＥＣ−ＤＡＴＡ」）が格納されている。車両名のフィールドには、対象となる車両名が格納されている。スペックＩＤ（「ＳＰＥＣ−ＩＤ」）は、該当するデータがどのスペックに対応するかを示すＩＤであり、例えば「１」は色を示し、「２」は車両タイプを示している。ＳＰＥＣ−ＩＤについては、図４の対応マスタデータ１８の説明で後記する。データフィールドには、実際のデータが格納されている。

つまり、図３Ａの例では、車両Ａ１の色（「ＳＰＥＣ−ＩＤ＝１」）は「赤」であり、車両タイプ（「ＳＰＥＣ−ＩＤ＝２」）は「Ｔ１」であることを示している。

図３Ｂは、所在位置テーブルデータとしてのＴ−ＳＥＱテーブルデータの例であり、各車両の所在位置に関する情報が格納されている。
Ｔ−ＳＥＱテーブルデータにおいて、車両名フィールドには対象となる車両名が格納され、工程ＩＤフィールドとしてのＰＲＯＣ−ＩＤフィールドには、図４で後記する工程ＩＤに該当する「ＰＲＯＣ−ＩＤ」が格納され、順番を示すＳＥＱフィールドには、該当する工程における車両の順番が格納されている。
例えば、図３Ｂを参照すると、ＰＲＯＣ−ＩＤ「ＰＲ２」（ここでは、組立工程２に該当するＩＤ）の１番目（順番）に車両Ａ１が格納され、同じ工程の２番目に車両Ａ２が格納されている。同様に、ＰＲＯＣ−ＩＤ「ＰＲ１」（ここでは、組立工程１に該当するＩＤ）の１番目（順番）に車両Ｂ１が格納され、同じ工程の２番目に車両Ｂ２が格納されている。
なお、本実施形態において、主に使用するのは図３ＢのＴ−ＳＥＱテーブルデータである。

（対応マスタデータ）
図４は、本実施形態に係る対応マスタデータの例を示す図である。
対応マスタデータ１８は、制御データ１６と、管理データ１７を対応付けるものであり、データ変換・更新処理部１３が、制御データ１６の変更内容を管理データ１７に反映する際に使用するものである。
対応マスタデータ１８は、制御データ項目と、管理データ項目とを有している。制御データ項目は、図２Ａ〜図２Ｃで示した制御データ１６における項目が格納されている。

管理データ項目は、テーブルデータ名、データ項目名および格納条件が格納されている。
例えば、スペック管理用の制御データ１６の制御データ項目「色」に該当する管理データ１７は、データテーブル名が「Ｔ−ＳＰＥＣ」であり、この「Ｔ−ＳＰＥＣ」テーブルデータの「ＳＰＥＣ−ＩＤ」が「１」となっている「ＳＰＥＣ−ＤＡＴＡ」フィールドが該当していることになる。つまり、制御データ１６において車両Ａのボディの色が「赤」から「青」に変更されたとき、データ変換・更新処理部１３は、車両Ａにおける「Ｔ−ＳＰＥＣ」テーブルデータの「ＳＰＥＣ−ＩＤ］が「１」のレコードにおける「ＳＰＥＣ−ＤＡＴＡ」フィールドの該当する欄を「赤」から「青」に更新する。

次に、車両の移動に伴う制御データ１６および管理データ１７の更新手順について記述する。
なお、本実施形態では、組立工程１→組立工程２の順に進むものとする。すなわち、車両Ｂ１，Ｂ２が組立工程１を終了すると、車両Ｂ１、車両Ｂ２の順に組立工程２へ進む。
「組立工程１」の車両Ｂ１が「組立工程２」へ移動して、その移動が「組立工程１」、「組立工程２」間の検出装置４によって検知されると、データ更新処理部１２は、図２Ｂに示す組立工程１用の制御データ１６において、順番の数値が「０００１」である車両（ここでは、「車両Ｂ１」）の欄を空欄にし、順番の数値が「０００２」である車両（ここでは、車両Ｂ２の順番の数値を「０００１」とし、以下、各車両の順番の数値を繰り上げる。

続いて、データ更新処理部１２は、更新前に組立工程１用の制御データ１６において、順番の数値が「０００１」であった車両名（ここでは、車両Ｂ１）を記憶しておき、組立工程１の次の工程である組立工程２用の制御データ１６において、車両Ｂ１の欄に順番の数値として「Ｎ＋１」を格納する。ここで、「Ｎ」は、現在組立工程２に所在している車両数である。

次に、制御データ１６の更新を検知したデータ変換・更新処理部１３は、制御データ１６にて更新のあった箇所（組立工程１、組立工程２、車両Ｂ１）を特定し、対応マスタデータ１８を参照して、更新のあった箇所に関するデータを取得する。
具体的には、データ変換・更新処理部１３は、組立工程１に関するデータであるテーブルデータ名「Ｔ−ＳＥＱ」、データ項目名「ＳＥＱ」、格納条件「ＰＲＯＣ−ＩＤ＝ＰＲ１」を取得するとともに、組立工程２に関するデータであるテーブルデータ名「Ｔ−ＳＥＱ」、データ項目名「ＳＥＱ」、格納条件「ＰＲＯＣ−ＩＤ＝ＰＲ２」を取得する。

そして、データ変換・更新処理部１３は、取得したデータを基に、管理データ１７を更新するためのＳＱＬ（Structured Query Language）を生成する。
このＳＱＬによって、データ変換・更新処理部１３は、図３Ｂに示すＴ−ＳＥＱテーブルデータの「ＰＲＯＣ−ＩＤ」フィールドの車両Ｂ１（「Ｂ１」）に該当する欄を「ＰＲ１」から「ＰＲ２」に更新し、「ＳＥＱ」において該当する欄を「Ｎ＋１」に更新する。Ｎの算出は、「ＰＲＯＣ−ＩＤ＝ＰＲ１」となっている車両数をカウントすることによって行われてもよい。
続いて、データ変換・更新処理部１３は、Ｔ−ＳＥＱテーブルデータの「ＳＥＱ」フィールドにおいて、「ＰＲＯＣ−ＩＤ」フィールドが「ＰＲ１」に該当する欄に格納されている順番の数値を順次繰り上げるためのＳＱＬを生成する。そして、データ変換・更新処理部１３は、このＳＱＬを基に、「ＰＲＯＣ−ＩＤ」フィールドが「ＰＲ１」に該当する欄に格納されている順番の数値を順次繰り上げる。

（フローチャート）
図５は、本実施形態に係る製造管理システムのサーバにおける処理の手順を示すフローチャートである。
まず、所在位置追従処理部１１が、センサ読取装置からの検知情報に基づいて車両の通過を検知する（Ｓ１０１）。
すると、データ更新処理部１２が、どの検知装置４から検知情報が取得されたかによって制御データ１６における更新箇所を特定し、制御データ１６の該当箇所を更新する（Ｓ１０２）。制御データ１６の更新方法は、前記したため、ここでの説明は省略する。

データ更新処理部１２は、制御データ１６を格納している記憶部１９からの応答などを受信したか否かを判定することによって、制御データ１６の更新が成功したか否かを判定する（Ｓ１０３）。
ステップＳ１０３の結果、例えば一定時間、応答が返信されないなど、制御データ１６の更新に失敗したと判定された場合（Ｓ１０３→Ｎｏ）、データ更新処理部１２は制御データ更新失敗の旨をサーバ１の図示しない表示部に表示したり、管理者が使用しているクライアント端末２の表示部に表示させるなどして、制御データ更新失敗のエラー通知を行い（Ｓ１０４）、処理を終了する。この場合、管理者がデータ修正処理部１４およびデータ更新処理部１２を介して、手動にて制御データ１６を更新する。

ステップＳ１０３の結果、制御データ１６の更新が成功した場合（Ｓ１０３→Ｙｅｓ）、データ変換・更新処理部１３が対応マスタを参照して、管理データ更新のためのＳＱＬを生成する（Ｓ１０５）。ＳＱＬの生成方法は、前記して説明したため、ここでの説明を省略する。
そして、データ変換・更新処理部１３が、作成したＳＱＬに従って管理データ１７を更新する（Ｓ１０６）。ステップＳ１０５のＳＱＬ生成、ステップＳ１０６の管理データ１７の更新については、前記して説明してあるので、ここでの説明を省略する。
次に、データ変換・更新処理部１３は、管理データ１７を格納している記憶部１９からの応答を受信したか否かを判定することによって、管理データ１７の更新が成功したか否かを判定する（Ｓ１０７）。

ステップＳ１０７の結果、例えば一定時間、応答が返信されないなど、管理データ１７の更新に失敗したと判定された場合（Ｓ１０７→Ｎｏ）、管理データ更新失敗の旨をサーバ１の図示しない表示部に表示したり、管理者が使用しているクライアント端末２の表示部に表示させるなどして、管理データ更新失敗のエラー通知を行い（Ｓ１０８）、処理を終了する。この場合、管理者がデータ修正処理部１４、データ更新処理部１２およびデータ変換・更新処理部１３を介して、手動にて管理データ１７を更新する。

ステップＳ１０７の結果、管理データ１７の更新が成功した場合（Ｓ１０７→Ｙｅｓ）、データ変換・更新処理部１３は処理を終了する。
クライアント端末２は、管理データ１７を閲覧することとなる。

なお、本実施形態では、ＳＱＬを生成した後、このＳＱＬに基づいて管理データ１７の更新を行ったが、その他のデータベース言語を用いてもよい。また、ＳＱＬを用いずに、対応マスタデータ１８のデータを基に、データ変換・更新処理部１３が直接管理データ１７を更新してもよい。
あるいは、対応マスタデータ１８も設定せずに、データ変換・更新処理部１３が、制御データ１６の更新箇所を検出し、管理データ１７において、その検出箇所に該当する箇所を検出して、管理データ１７の更新を行ってもよい。

（まとめ）
本実施形態によれば、クライアント端末２による閲覧専用の管理データ１７を有し、制御データ１６の更新をこの管理データ１７に反映することによって、制御データ１６への排他性を維持しつつ、クライアント端末２による工程の進捗の閲覧のリアルタイム性を確保することができる。
また、本実施形態によれば、クライアント端末２が制御データ１６の内容を反映された管理データ１７を閲覧することによって、リアルタイム性を保ちつつ、制御データ１６の配信を行わないことから通信負荷の低減も可能となる。
さらに、管理データ１７におけるＩＤなどを管理する対応マスタデータ１８を有することにより、これらのＩＤを使用したＳＱＬを生成することが可能となり、管理データ１７の更新が容易となる。

１ サーバ（情報処理装置）
２ クライアント端末
３ 作業指示デバイス
４ 検知装置
５ 製造管理システム（システム）
１１ 所在位置追従処理部
１２ データ更新処理部
１３ データ変換・更新処理部
１４ データ修正処理部
１５ 作業指示処理部
１６ 制御データ
１７ 管理データ
１８ 対応マスタデータ
１９ 記憶部

Claims (3)

1. システムの制御に関するデータである制御データと、
   前記制御データとは、別のデータであるとともに、前記制御データとは別の構成を有しており、かつ、前記制御データの内容をクライアント端末によって閲覧させることに適した構成を有する管理データと、
   を記憶部に格納している情報処理装置の情報管理方法であって、
   前記情報処理装置は、
   前記制御データが更新されると、前記更新の内容を前記管理データに反映し、
   前記管理データは、前記クライアント端末による閲覧が可能であるが、前記クライアント端末による内容の操作が不可能である
   ことを特徴とする情報管理方法。
2. 前記情報処理装置は、
   前記制御データの内容と、前記管理データの内容と、を対応付ける情報を格納している対応マスタデータを有し、
   前記制御データが更新されると、前記対応マスタデータを参照し、前記管理データにおける更新箇所を特定して、前記更新の内容を前記管理データに反映する
   ことを特徴とする請求項１に記載の情報管理方法。
3. システムの制御に関するデータである制御データと、
   前記制御データとは、別のデータであるとともに、前記制御データとは別の構成を有しており、かつ、前記制御データの内容をクライアント端末によって閲覧させることに適した構成を有する管理データと、
   を記憶部に格納している情報処理装置であって、
   前記制御データが更新されると、前記更新の内容を前記管理データに反映するデータ変換・更新処理部を有し、
   前記管理データは、前記クライアント端末による閲覧が可能であるが、前記クライアント端末による内容の操作が不可能である
   ことを特徴とする情報処理装置。

Images