情報管理方法および情報処理装置
【課題】排他性を保ちつつ、工程の進捗閲覧のリアルタイム性を確保するとともに、情報処理装置と、クライアント端末間の通信負荷の低減を実現させる。
【解決手段】製造管理システム5における進捗情報に関するデータである制御データ16と、制御データ16の内容をクライアント端末2に閲覧させるための管理データ17と、を記憶部19に格納しているサーバ1の情報管理方法であり、サーバ1は、制御データ16が更新されると、更新の内容を管理データ17に反映する。
【解決手段】製造管理システム5における進捗情報に関するデータである制御データ16と、制御データ16の内容をクライアント端末2に閲覧させるための管理データ17と、を記憶部19に格納しているサーバ1の情報管理方法であり、サーバ1は、制御データ16が更新されると、更新の内容を管理データ17に反映する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報管理方法および情報処理装置の技術に関する。
【背景技術】
【0002】
自動車製造工程管理システムなどでは、生産の効率化のため、同一の自動車製造ライン(以下、適宜ラインと称する)で複数車種が製造されている。車両毎に作業指示は異なっており、正確な作業指示を行うためには、ラインにおける車両の所在位置を正確に把握しておく必要がある。また、自動車製造ラインは一般的に溶接工程や、塗装工程や、組立工程などからなっており、各工程で発生する車両通過に対し、リアルタイムで車両の所在位置情報の更新を実現するためには、高い処理スピードを持つシステムが求められる。
また一方で、製造管理者が車両の所在状況を確認するため、所在位置情報をクライアント端末の画面などにリアルタイム表示する必要がある。ここで、車両通過による所在位置情報更新処理の際には、データの整合性を保つため排他がかけられている。つまり、所在位置情報の更新処理中はクライアント端末からサーバが管理しているデータにアクセスできなくなる。
【0003】
例えば、ある車両aが、工程Aから工程Bへライン上を移動した場合、工程Aと工程Bとの間に設置されているセンサ読取装置などによって車両(どの車両かはわからない)が1台、工程Aから工程Bへ送られたことが検知されるとする。サーバは、車両の所在位置情報として、どの車両がどの工程に所在しているのかを管理している。ここで、工程Aから工程Bへ車両が移動したことを検知したサーバは、工程Aの先頭に所在していた車両aが工程Aから工程Bへ移動したと判定し、車両aの所在位置情報を工程Aから工程Bへ移すことで所在位置情報の更新を行う。しかし、このとき、クライアント端末から車両aの所在位置情報を操作する処理が行われると、車両aの所在位置情報の整合性がなくなってしまうおそれがある。従って、サーバは、所在位置情報を更新する際、クライアント端末からのアクセスを停止し、排他処理を行うことによって所在位置の整合性を維持する。
【0004】
センサではなく、移動する車両が特定できるRFID(Radio Frequency Identification)リーダなどを用いても、このような整合性の問題が生じ得る。
【0005】
ラインにおける車両の移動は随時発生しているため、車両の所在位置情報の更新は頻繁に行われている。そのため、クライアント端末からのアクセスが排他による制限も頻繁に生じ、車両の所在位置情報をクライアント端末画面にリアルタイム表示することは困難である。
【0006】
そこで、従来では、車両の所在位置情報を、サーバが各クライアント端末へ配信することで、クライアン0ト端末からサーバヘアクセスする必要をなくしつつ、クライアント端末の画面表示のリアルタイム性を確保している。
【0007】
なお、特許文献1には、配電系統や、配電設備などの工事に伴い、ユーザがデータを修正するときに、ホストに接続しているクライアントにデータを送信し、データを一致させる際に、常時クライアントに送信してデータを一致化を行うのではなく、クライアント立ち上げ時に一致化を行う配電自動化システムのデータ一致化方式が開示されている。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2000−299935号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
前記したようなクライアント端末に車両の所在位置を配信する技術では、ラインにおける車両の移動により車両の所在位置情報が更新される度にサーバから各クライアント端末へ最新の所在位置情報を配信しているため、ネットワーク負荷が高くなってしまうという問題がある。また、サーバと各クライアント端末でデータを保持しているため、各クライアント端末とサーバでデータの整合性を確保しなければならない。この点において、クライアント端末を追加すると、その分サーバ−クライアント端末間で整合性を確保しなければならず、クライアント端末の数が増加すると不整合が発生する確率も増加するため、容易にクライアント端末を増設できないという制約がある。
このような問題は、自動車製造工程管理システム以外の製造システムなどでも生じている問題である。
【0010】
このような背景に鑑みて本発明がなされたのであり、本発明は、排他性を維持しつつ、工程の進捗閲覧のリアルタイム性を確保するとともに、情報処理装置と、クライアント端末間の通信負荷の低減も実現することを目的とする。
【課題を解決するための手段】
【0011】
前記課題を解決するため、本発明は、システムの制御に関するデータである制御データと、前記制御データの内容をクライアント端末に閲覧させるための管理データと、を記憶部に格納している情報処理装置の情報管理方法であって、前記情報処理装置は、前記制御データが更新されると、前記更新の内容を前記管理データに反映することを特徴とする。
その他の解決手段については実施形態中で適宜説明する。
【発明の効果】
【0012】
本発明によれば、排他性を維持しつつ、工程の進捗閲覧のリアルタイム性を確保するとともに、情報処理装置と、クライアント端末間の通信負荷の低減も実現する。
【図面の簡単な説明】
【0013】
【図1】本実施形態に係る製造管理システムの構成例を示す図である。
【図2A】本実施形態に係る制御データ(スペック管理用)の例を示す図である。
【図2B】本実施形態に係る制御データ(組立工程1用)の例を示す図である。
【図2C】本実施形態に係る制御データ(組立工程2用)の例を示す図である。
【図3A】本実施形態に係る管理データ(T−SPECテーブルデータ)の例を示す図である。
【図3B】本実施形態に係る管理データ(T−SEQテーブルデータ)の例を示す図である。
【図4】本実施形態に係る対応マスタデータの例を示す図である。
【図5】本実施形態に係る製造管理システムのサーバにおける処理の手順を示すフローチャートである。
【発明を実施するための形態】
【0014】
次に、本発明を実施するための形態(「実施形態」という)について、適宜図面を参照しながら詳細に説明する。
【0015】
(システム構成図)
図1は、本実施形態に係る製造管理システムの構成例を示す図である。なお、本実施形態では、自動車製造工程に生産管理システムを適用した例を示すが、その他の製造工程に適用してもよい。
システムである製造管理システム5は、情報の処理を行う情報処理装置としてのサーバ1と、ユーザが車両の所在位置情報を閲覧して、確認するためのクライアント端末2と、複数の作業指示デバイス3を有する。
自動車製造工程は複数の作業工程(溶接工程1、溶接工程2、塗装工程1、・・・)からなり、各工程間にはRFIDリーダや、センサ読取装置などの検知装置4が設置されており、車両の通過を検知している。各工程には、プリンタや、コンピュータである作業指示デバイス3が設置されている。
【0016】
サーバ1は、所在位置追従処理部11、データ更新処理部12、データ変換・更新処理部13、データ修正処理部14および作業指示処理部15を有しており、データとして、制御データ16、管理データ17および対応マスタデータ18が記憶部19に格納されている。
各部11〜15は、図示しないROM(Read Only Memory)や、HDD(Hard Disk Drive)に格納されたプログラムが、RAM(Random Access Memory)に展開され、CPU(Central Processing Unit)によって実行されることによって具現化する。
【0017】
車両の通過が検知装置4によって検知されると、検知された情報は、サーバ1の所在位置追従処理部11へ送信される。所在位置追従処理部11は、検知された情報を基に、通過した車両のIDや、通過先の工程を判別し、車両の所在位置情報を更新するため、判別結果をデータ更新処理部12へ渡す。データ更新処理部12は、制御データ16を更新する。
データ変換・更新処理部13は、対応マスタデータ18を参照して、制御データ16の変更を管理データ17に反映して管理データ17を更新する。制御データ16、管理データ17および対応マスタデータ18は、図2A〜図4を参照して後記する。
作業指示処理部15は、制御データ16を参照して、作業指示デバイス3ヘ作業指示を実施する。
【0018】
クライアント端末2が所在位置情報を閲覧したいときには、管理データ17を閲覧することになる。このとき、クライアント端末2は管理データ17を操作することはできない。クライアント端末2による所在位置情報(制御データ16)の変更を行うときは、クライアント端末2はサーバ1のデータ修正処理部14へアクセス・変更要求を行い、データ修正処理部14がデータ更新処理部12を介して制御データ16の変更を行う。なお、クライアント端末2による所在位置情報の変更を行うときは、排他処理が行われる。つまり、サーバ1のデータ更新処理部12が制御データ16にアクセスしているときは、クライアント端末2による所在位置情報(制御データ16)の変更を行うことはできない。なお、クライアント端末2による所在位置情報(制御データ16)の変更も、データ変換・更新処理部13によって管理データ17に反映される。
【0019】
(制御データ)
図2A〜図2Cは、本実施形態に係る制御データの例を示す図である。
制御データ16は、作業指示デバイス3に作業指示を与える際に参照するためのデータであり、サーバ1は、図2Aのようなスペック管理用の制御データ16や、図2Bのような組立工程1用の制御データ16や、図2Cのような組立工程2用の制御データ16などを有している。この他にも、エンジンタイプ用の制御データ16や、プランニングナンバ用の制御データ16なども有している。
【0020】
図2Aに示すように、スペック管理用の制御データ16には、車両毎に色、車両タイプ、ルーフタイプ、ミラータイプなどの各タイプに関する情報が格納されている。また、図2Bに示す組立工程1用の制御データ16には、組立工程1に所在している車両の順番(「0001」や、「0002」など)が格納されている。図2Bに示す制御データ16の例では、車両「B1」が1番目(「0001」)であり、車両「B2」が2番目(「0002」)である。空欄の車両は、組立工程1に所在していないことを示す。
【0021】
同様に、図2Cに示す組立工程2用の制御データには、組立工程2に所在している車両の順番(「0001」や、「0002」など)が格納されている。図2Cに示す制御データ16の例では、車両「A1」が1番目(「0001」)であり、車両「A2」が2番目(「0002」)である。空欄の車両は、組立工程2に所在していないことを示す。
【0022】
(管理データ)
図3Aおよび図3Bは、本実施形態に係る管理データの例を示す図である。
管理データ17は、クライアント端末2が所在位置情報などを閲覧するためのデータであり、制御データ16を基に閲覧しやすいようテーブルの形式にまとめられたデータである。
図3Aは、スペックテーブルデータ(「T−SPECテーブルデータ」)の例であり、各車両における色、車両タイプ、ルーフタイプ、ミラータイプなどの各スペックデータ(「SPEC−DATA」)が格納されている。車両名のフィールドには、対象となる車両名が格納されている。スペックID(「SPEC−ID」)は、該当するデータがどのスペックに対応するかを示すIDであり、例えば「1」は色を示し、「2」は車両タイプを示している。SPEC−IDについては、図4の対応マスタデータ18の説明で後記する。データフィールドには、実際のデータが格納されている。
【0023】
つまり、図3Aの例では、車両A1の色(「SPEC−ID=1」)は「赤」であり、車両タイプ(「SPEC−ID=2」)は「T1」であることを示している。
【0024】
図3Bは、所在位置テーブルデータとしてのT−SEQテーブルデータの例であり、各車両の所在位置に関する情報が格納されている。
T−SEQテーブルデータにおいて、車両名フィールドには対象となる車両名が格納され、工程IDフィールドとしてのPROC−IDフィールドには、図4で後記する工程IDに該当する「PROC−ID」が格納され、順番を示すSEQフィールドには、該当する工程における車両の順番が格納されている。
例えば、図3Bを参照すると、PROC−ID「PR2」(ここでは、組立工程2に該当するID)の1番目(順番)に車両A1が格納され、同じ工程の2番目に車両A2が格納されている。同様に、PROC−ID「PR1」(ここでは、組立工程1に該当するID)の1番目(順番)に車両B1が格納され、同じ工程の2番目に車両B2が格納されている。
なお、本実施形態において、主に使用するのは図3BのT−SEQテーブルデータである。
【0025】
(対応マスタデータ)
図4は、本実施形態に係る対応マスタデータの例を示す図である。
対応マスタデータ18は、制御データ16と、管理データ17を対応付けるものであり、データ変換・更新処理部13が、制御データ16の変更内容を管理データ17に反映する際に使用するものである。
対応マスタデータ18は、制御データ項目と、管理データ項目とを有している。制御データ項目は、図2A〜図2Cで示した制御データ16における項目が格納されている。
【0026】
管理データ項目は、テーブルデータ名、データ項目名および格納条件が格納されている。
例えば、スペック管理用の制御データ16の制御データ項目「色」に該当する管理データ17は、データテーブル名が「T−SPEC」であり、この「T−SPEC」テーブルデータの「SPEC−ID」が「1」となっている「SPEC−DATA」フィールドが該当していることになる。つまり、制御データ16において車両Aのボディの色が「赤」から「青」に変更されたとき、データ変換・更新処理部13は、車両Aにおける「T−SPEC」テーブルデータの「SPEC−ID]が「1」のレコードにおける「SPEC−DATA」フィールドの該当する欄を「赤」から「青」に更新する。
【0027】
次に、車両の移動に伴う制御データ16および管理データ17の更新手順について記述する。
なお、本実施形態では、組立工程1→組立工程2の順に進むものとする。すなわち、車両B1,B2が組立工程1を終了すると、車両B1、車両B2の順に組立工程2へ進む。
「組立工程1」の車両B1が「組立工程2」へ移動して、その移動が「組立工程1」、「組立工程2」間の検出装置4によって検知されると、データ更新処理部12は、図2Bに示す組立工程1用の制御データ16において、順番の数値が「0001」である車両(ここでは、「車両B1」)の欄を空欄にし、順番の数値が「0002」である車両(ここでは、車両B2の順番の数値を「0001」とし、以下、各車両の順番の数値を繰り上げる。
【0028】
続いて、データ更新処理部12は、更新前に組立工程1用の制御データ16において、順番の数値が「0001」であった車両名(ここでは、車両B1)を記憶しておき、組立工程1の次の工程である組立工程2用の制御データ16において、車両B1の欄に順番の数値として「N+1」を格納する。ここで、「N」は、現在組立工程2に所在している車両数である。
【0029】
次に、制御データ16の更新を検知したデータ変換・更新処理部13は、制御データ16にて更新のあった箇所(組立工程1、組立工程2、車両B1)を特定し、対応マスタデータ18を参照して、更新のあった箇所に関するデータを取得する。
具体的には、データ変換・更新処理部13は、組立工程1に関するデータであるテーブルデータ名「T−SEQ」、データ項目名「SEQ」、格納条件「PROC−ID=PR1」を取得するとともに、組立工程2に関するデータであるテーブルデータ名「T−SEQ」、データ項目名「SEQ」、格納条件「PROC−ID=PR2」を取得する。
【0030】
そして、データ変換・更新処理部13は、取得したデータを基に、管理データ17を更新するためのSQL(Structured Query Language)を生成する。
このSQLによって、データ変換・更新処理部13は、図3Bに示すT−SEQテーブルデータの「PROC−ID」フィールドの車両B1(「B1」)に該当する欄を「PR1」から「PR2」に更新し、「SEQ」において該当する欄を「N+1」に更新する。Nの算出は、「PROC−ID=PR1」となっている車両数をカウントすることによって行われてもよい。
続いて、データ変換・更新処理部13は、T−SEQテーブルデータの「SEQ」フィールドにおいて、「PROC−ID」フィールドが「PR1」に該当する欄に格納されている順番の数値を順次繰り上げるためのSQLを生成する。そして、データ変換・更新処理部13は、このSQLを基に、「PROC−ID」フィールドが「PR1」に該当する欄に格納されている順番の数値を順次繰り上げる。
【0031】
(フローチャート)
図5は、本実施形態に係る製造管理システムのサーバにおける処理の手順を示すフローチャートである。
まず、所在位置追従処理部11が、センサ読取装置からの検知情報に基づいて車両の通過を検知する(S101)。
すると、データ更新処理部12が、どの検知装置4から検知情報が取得されたかによって制御データ16における更新箇所を特定し、制御データ16の該当箇所を更新する(S102)。制御データ16の更新方法は、前記したため、ここでの説明は省略する。
【0032】
データ更新処理部12は、制御データ16を格納している記憶部19からの応答などを受信したか否かを判定することによって、制御データ16の更新が成功したか否かを判定する(S103)。
ステップS103の結果、例えば一定時間、応答が返信されないなど、制御データ16の更新に失敗したと判定された場合(S103→No)、データ更新処理部12は制御データ更新失敗の旨をサーバ1の図示しない表示部に表示したり、管理者が使用しているクライアント端末2の表示部に表示させるなどして、制御データ更新失敗のエラー通知を行い(S104)、処理を終了する。この場合、管理者がデータ修正処理部14およびデータ更新処理部12を介して、手動にて制御データ16を更新する。
【0033】
ステップS103の結果、制御データ16の更新が成功した場合(S103→Yes)、データ変換・更新処理部13が対応マスタを参照して、管理データ更新のためのSQLを生成する(S105)。SQLの生成方法は、前記して説明したため、ここでの説明を省略する。
そして、データ変換・更新処理部13が、作成したSQLに従って管理データ17を更新する(S106)。ステップS105のSQL生成、ステップS106の管理データ17の更新については、前記して説明してあるので、ここでの説明を省略する。
次に、データ変換・更新処理部13は、管理データ17を格納している記憶部19からの応答を受信したか否かを判定することによって、管理データ17の更新が成功したか否かを判定する(S107)。
【0034】
ステップS107の結果、例えば一定時間、応答が返信されないなど、管理データ17の更新に失敗したと判定された場合(S107→No)、管理データ更新失敗の旨をサーバ1の図示しない表示部に表示したり、管理者が使用しているクライアント端末2の表示部に表示させるなどして、管理データ更新失敗のエラー通知を行い(S108)、処理を終了する。この場合、管理者がデータ修正処理部14、データ更新処理部12およびデータ変換・更新処理部13を介して、手動にて管理データ17を更新する。
【0035】
ステップS107の結果、管理データ17の更新が成功した場合(S107→Yes)、データ変換・更新処理部13は処理を終了する。
クライアント端末2は、管理データ17を閲覧することとなる。
【0036】
なお、本実施形態では、SQLを生成した後、このSQLに基づいて管理データ17の更新を行ったが、その他のデータベース言語を用いてもよい。また、SQLを用いずに、対応マスタデータ18のデータを基に、データ変換・更新処理部13が直接管理データ17を更新してもよい。
あるいは、対応マスタデータ18も設定せずに、データ変換・更新処理部13が、制御データ16の更新箇所を検出し、管理データ17において、その検出箇所に該当する箇所を検出して、管理データ17の更新を行ってもよい。
【0037】
(まとめ)
本実施形態によれば、クライアント端末2による閲覧専用の管理データ17を有し、制御データ16の更新をこの管理データ17に反映することによって、制御データ16への排他性を維持しつつ、クライアント端末2による工程の進捗の閲覧のリアルタイム性を確保することができる。
また、本実施形態によれば、クライアント端末2が制御データ16の内容を反映された管理データ17を閲覧することによって、リアルタイム性を保ちつつ、制御データ16の配信を行わないことから通信負荷の低減も可能となる。
さらに、管理データ17におけるIDなどを管理する対応マスタデータ18を有することにより、これらのIDを使用したSQLを生成することが可能となり、管理データ17の更新が容易となる。
【符号の説明】
【0038】
1 サーバ(情報処理装置)
2 クライアント端末
3 作業指示デバイス
4 検知装置
5 製造管理システム(システム)
11 所在位置追従処理部
12 データ更新処理部
13 データ変換・更新処理部
14 データ修正処理部
15 作業指示処理部
16 制御データ
17 管理データ
18 対応マスタデータ
19 記憶部
【技術分野】
【0001】
本発明は、情報管理方法および情報処理装置の技術に関する。
【背景技術】
【0002】
自動車製造工程管理システムなどでは、生産の効率化のため、同一の自動車製造ライン(以下、適宜ラインと称する)で複数車種が製造されている。車両毎に作業指示は異なっており、正確な作業指示を行うためには、ラインにおける車両の所在位置を正確に把握しておく必要がある。また、自動車製造ラインは一般的に溶接工程や、塗装工程や、組立工程などからなっており、各工程で発生する車両通過に対し、リアルタイムで車両の所在位置情報の更新を実現するためには、高い処理スピードを持つシステムが求められる。
また一方で、製造管理者が車両の所在状況を確認するため、所在位置情報をクライアント端末の画面などにリアルタイム表示する必要がある。ここで、車両通過による所在位置情報更新処理の際には、データの整合性を保つため排他がかけられている。つまり、所在位置情報の更新処理中はクライアント端末からサーバが管理しているデータにアクセスできなくなる。
【0003】
例えば、ある車両aが、工程Aから工程Bへライン上を移動した場合、工程Aと工程Bとの間に設置されているセンサ読取装置などによって車両(どの車両かはわからない)が1台、工程Aから工程Bへ送られたことが検知されるとする。サーバは、車両の所在位置情報として、どの車両がどの工程に所在しているのかを管理している。ここで、工程Aから工程Bへ車両が移動したことを検知したサーバは、工程Aの先頭に所在していた車両aが工程Aから工程Bへ移動したと判定し、車両aの所在位置情報を工程Aから工程Bへ移すことで所在位置情報の更新を行う。しかし、このとき、クライアント端末から車両aの所在位置情報を操作する処理が行われると、車両aの所在位置情報の整合性がなくなってしまうおそれがある。従って、サーバは、所在位置情報を更新する際、クライアント端末からのアクセスを停止し、排他処理を行うことによって所在位置の整合性を維持する。
【0004】
センサではなく、移動する車両が特定できるRFID(Radio Frequency Identification)リーダなどを用いても、このような整合性の問題が生じ得る。
【0005】
ラインにおける車両の移動は随時発生しているため、車両の所在位置情報の更新は頻繁に行われている。そのため、クライアント端末からのアクセスが排他による制限も頻繁に生じ、車両の所在位置情報をクライアント端末画面にリアルタイム表示することは困難である。
【0006】
そこで、従来では、車両の所在位置情報を、サーバが各クライアント端末へ配信することで、クライアン0ト端末からサーバヘアクセスする必要をなくしつつ、クライアント端末の画面表示のリアルタイム性を確保している。
【0007】
なお、特許文献1には、配電系統や、配電設備などの工事に伴い、ユーザがデータを修正するときに、ホストに接続しているクライアントにデータを送信し、データを一致させる際に、常時クライアントに送信してデータを一致化を行うのではなく、クライアント立ち上げ時に一致化を行う配電自動化システムのデータ一致化方式が開示されている。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2000−299935号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
前記したようなクライアント端末に車両の所在位置を配信する技術では、ラインにおける車両の移動により車両の所在位置情報が更新される度にサーバから各クライアント端末へ最新の所在位置情報を配信しているため、ネットワーク負荷が高くなってしまうという問題がある。また、サーバと各クライアント端末でデータを保持しているため、各クライアント端末とサーバでデータの整合性を確保しなければならない。この点において、クライアント端末を追加すると、その分サーバ−クライアント端末間で整合性を確保しなければならず、クライアント端末の数が増加すると不整合が発生する確率も増加するため、容易にクライアント端末を増設できないという制約がある。
このような問題は、自動車製造工程管理システム以外の製造システムなどでも生じている問題である。
【0010】
このような背景に鑑みて本発明がなされたのであり、本発明は、排他性を維持しつつ、工程の進捗閲覧のリアルタイム性を確保するとともに、情報処理装置と、クライアント端末間の通信負荷の低減も実現することを目的とする。
【課題を解決するための手段】
【0011】
前記課題を解決するため、本発明は、システムの制御に関するデータである制御データと、前記制御データの内容をクライアント端末に閲覧させるための管理データと、を記憶部に格納している情報処理装置の情報管理方法であって、前記情報処理装置は、前記制御データが更新されると、前記更新の内容を前記管理データに反映することを特徴とする。
その他の解決手段については実施形態中で適宜説明する。
【発明の効果】
【0012】
本発明によれば、排他性を維持しつつ、工程の進捗閲覧のリアルタイム性を確保するとともに、情報処理装置と、クライアント端末間の通信負荷の低減も実現する。
【図面の簡単な説明】
【0013】
【図1】本実施形態に係る製造管理システムの構成例を示す図である。
【図2A】本実施形態に係る制御データ(スペック管理用)の例を示す図である。
【図2B】本実施形態に係る制御データ(組立工程1用)の例を示す図である。
【図2C】本実施形態に係る制御データ(組立工程2用)の例を示す図である。
【図3A】本実施形態に係る管理データ(T−SPECテーブルデータ)の例を示す図である。
【図3B】本実施形態に係る管理データ(T−SEQテーブルデータ)の例を示す図である。
【図4】本実施形態に係る対応マスタデータの例を示す図である。
【図5】本実施形態に係る製造管理システムのサーバにおける処理の手順を示すフローチャートである。
【発明を実施するための形態】
【0014】
次に、本発明を実施するための形態(「実施形態」という)について、適宜図面を参照しながら詳細に説明する。
【0015】
(システム構成図)
図1は、本実施形態に係る製造管理システムの構成例を示す図である。なお、本実施形態では、自動車製造工程に生産管理システムを適用した例を示すが、その他の製造工程に適用してもよい。
システムである製造管理システム5は、情報の処理を行う情報処理装置としてのサーバ1と、ユーザが車両の所在位置情報を閲覧して、確認するためのクライアント端末2と、複数の作業指示デバイス3を有する。
自動車製造工程は複数の作業工程(溶接工程1、溶接工程2、塗装工程1、・・・)からなり、各工程間にはRFIDリーダや、センサ読取装置などの検知装置4が設置されており、車両の通過を検知している。各工程には、プリンタや、コンピュータである作業指示デバイス3が設置されている。
【0016】
サーバ1は、所在位置追従処理部11、データ更新処理部12、データ変換・更新処理部13、データ修正処理部14および作業指示処理部15を有しており、データとして、制御データ16、管理データ17および対応マスタデータ18が記憶部19に格納されている。
各部11〜15は、図示しないROM(Read Only Memory)や、HDD(Hard Disk Drive)に格納されたプログラムが、RAM(Random Access Memory)に展開され、CPU(Central Processing Unit)によって実行されることによって具現化する。
【0017】
車両の通過が検知装置4によって検知されると、検知された情報は、サーバ1の所在位置追従処理部11へ送信される。所在位置追従処理部11は、検知された情報を基に、通過した車両のIDや、通過先の工程を判別し、車両の所在位置情報を更新するため、判別結果をデータ更新処理部12へ渡す。データ更新処理部12は、制御データ16を更新する。
データ変換・更新処理部13は、対応マスタデータ18を参照して、制御データ16の変更を管理データ17に反映して管理データ17を更新する。制御データ16、管理データ17および対応マスタデータ18は、図2A〜図4を参照して後記する。
作業指示処理部15は、制御データ16を参照して、作業指示デバイス3ヘ作業指示を実施する。
【0018】
クライアント端末2が所在位置情報を閲覧したいときには、管理データ17を閲覧することになる。このとき、クライアント端末2は管理データ17を操作することはできない。クライアント端末2による所在位置情報(制御データ16)の変更を行うときは、クライアント端末2はサーバ1のデータ修正処理部14へアクセス・変更要求を行い、データ修正処理部14がデータ更新処理部12を介して制御データ16の変更を行う。なお、クライアント端末2による所在位置情報の変更を行うときは、排他処理が行われる。つまり、サーバ1のデータ更新処理部12が制御データ16にアクセスしているときは、クライアント端末2による所在位置情報(制御データ16)の変更を行うことはできない。なお、クライアント端末2による所在位置情報(制御データ16)の変更も、データ変換・更新処理部13によって管理データ17に反映される。
【0019】
(制御データ)
図2A〜図2Cは、本実施形態に係る制御データの例を示す図である。
制御データ16は、作業指示デバイス3に作業指示を与える際に参照するためのデータであり、サーバ1は、図2Aのようなスペック管理用の制御データ16や、図2Bのような組立工程1用の制御データ16や、図2Cのような組立工程2用の制御データ16などを有している。この他にも、エンジンタイプ用の制御データ16や、プランニングナンバ用の制御データ16なども有している。
【0020】
図2Aに示すように、スペック管理用の制御データ16には、車両毎に色、車両タイプ、ルーフタイプ、ミラータイプなどの各タイプに関する情報が格納されている。また、図2Bに示す組立工程1用の制御データ16には、組立工程1に所在している車両の順番(「0001」や、「0002」など)が格納されている。図2Bに示す制御データ16の例では、車両「B1」が1番目(「0001」)であり、車両「B2」が2番目(「0002」)である。空欄の車両は、組立工程1に所在していないことを示す。
【0021】
同様に、図2Cに示す組立工程2用の制御データには、組立工程2に所在している車両の順番(「0001」や、「0002」など)が格納されている。図2Cに示す制御データ16の例では、車両「A1」が1番目(「0001」)であり、車両「A2」が2番目(「0002」)である。空欄の車両は、組立工程2に所在していないことを示す。
【0022】
(管理データ)
図3Aおよび図3Bは、本実施形態に係る管理データの例を示す図である。
管理データ17は、クライアント端末2が所在位置情報などを閲覧するためのデータであり、制御データ16を基に閲覧しやすいようテーブルの形式にまとめられたデータである。
図3Aは、スペックテーブルデータ(「T−SPECテーブルデータ」)の例であり、各車両における色、車両タイプ、ルーフタイプ、ミラータイプなどの各スペックデータ(「SPEC−DATA」)が格納されている。車両名のフィールドには、対象となる車両名が格納されている。スペックID(「SPEC−ID」)は、該当するデータがどのスペックに対応するかを示すIDであり、例えば「1」は色を示し、「2」は車両タイプを示している。SPEC−IDについては、図4の対応マスタデータ18の説明で後記する。データフィールドには、実際のデータが格納されている。
【0023】
つまり、図3Aの例では、車両A1の色(「SPEC−ID=1」)は「赤」であり、車両タイプ(「SPEC−ID=2」)は「T1」であることを示している。
【0024】
図3Bは、所在位置テーブルデータとしてのT−SEQテーブルデータの例であり、各車両の所在位置に関する情報が格納されている。
T−SEQテーブルデータにおいて、車両名フィールドには対象となる車両名が格納され、工程IDフィールドとしてのPROC−IDフィールドには、図4で後記する工程IDに該当する「PROC−ID」が格納され、順番を示すSEQフィールドには、該当する工程における車両の順番が格納されている。
例えば、図3Bを参照すると、PROC−ID「PR2」(ここでは、組立工程2に該当するID)の1番目(順番)に車両A1が格納され、同じ工程の2番目に車両A2が格納されている。同様に、PROC−ID「PR1」(ここでは、組立工程1に該当するID)の1番目(順番)に車両B1が格納され、同じ工程の2番目に車両B2が格納されている。
なお、本実施形態において、主に使用するのは図3BのT−SEQテーブルデータである。
【0025】
(対応マスタデータ)
図4は、本実施形態に係る対応マスタデータの例を示す図である。
対応マスタデータ18は、制御データ16と、管理データ17を対応付けるものであり、データ変換・更新処理部13が、制御データ16の変更内容を管理データ17に反映する際に使用するものである。
対応マスタデータ18は、制御データ項目と、管理データ項目とを有している。制御データ項目は、図2A〜図2Cで示した制御データ16における項目が格納されている。
【0026】
管理データ項目は、テーブルデータ名、データ項目名および格納条件が格納されている。
例えば、スペック管理用の制御データ16の制御データ項目「色」に該当する管理データ17は、データテーブル名が「T−SPEC」であり、この「T−SPEC」テーブルデータの「SPEC−ID」が「1」となっている「SPEC−DATA」フィールドが該当していることになる。つまり、制御データ16において車両Aのボディの色が「赤」から「青」に変更されたとき、データ変換・更新処理部13は、車両Aにおける「T−SPEC」テーブルデータの「SPEC−ID]が「1」のレコードにおける「SPEC−DATA」フィールドの該当する欄を「赤」から「青」に更新する。
【0027】
次に、車両の移動に伴う制御データ16および管理データ17の更新手順について記述する。
なお、本実施形態では、組立工程1→組立工程2の順に進むものとする。すなわち、車両B1,B2が組立工程1を終了すると、車両B1、車両B2の順に組立工程2へ進む。
「組立工程1」の車両B1が「組立工程2」へ移動して、その移動が「組立工程1」、「組立工程2」間の検出装置4によって検知されると、データ更新処理部12は、図2Bに示す組立工程1用の制御データ16において、順番の数値が「0001」である車両(ここでは、「車両B1」)の欄を空欄にし、順番の数値が「0002」である車両(ここでは、車両B2の順番の数値を「0001」とし、以下、各車両の順番の数値を繰り上げる。
【0028】
続いて、データ更新処理部12は、更新前に組立工程1用の制御データ16において、順番の数値が「0001」であった車両名(ここでは、車両B1)を記憶しておき、組立工程1の次の工程である組立工程2用の制御データ16において、車両B1の欄に順番の数値として「N+1」を格納する。ここで、「N」は、現在組立工程2に所在している車両数である。
【0029】
次に、制御データ16の更新を検知したデータ変換・更新処理部13は、制御データ16にて更新のあった箇所(組立工程1、組立工程2、車両B1)を特定し、対応マスタデータ18を参照して、更新のあった箇所に関するデータを取得する。
具体的には、データ変換・更新処理部13は、組立工程1に関するデータであるテーブルデータ名「T−SEQ」、データ項目名「SEQ」、格納条件「PROC−ID=PR1」を取得するとともに、組立工程2に関するデータであるテーブルデータ名「T−SEQ」、データ項目名「SEQ」、格納条件「PROC−ID=PR2」を取得する。
【0030】
そして、データ変換・更新処理部13は、取得したデータを基に、管理データ17を更新するためのSQL(Structured Query Language)を生成する。
このSQLによって、データ変換・更新処理部13は、図3Bに示すT−SEQテーブルデータの「PROC−ID」フィールドの車両B1(「B1」)に該当する欄を「PR1」から「PR2」に更新し、「SEQ」において該当する欄を「N+1」に更新する。Nの算出は、「PROC−ID=PR1」となっている車両数をカウントすることによって行われてもよい。
続いて、データ変換・更新処理部13は、T−SEQテーブルデータの「SEQ」フィールドにおいて、「PROC−ID」フィールドが「PR1」に該当する欄に格納されている順番の数値を順次繰り上げるためのSQLを生成する。そして、データ変換・更新処理部13は、このSQLを基に、「PROC−ID」フィールドが「PR1」に該当する欄に格納されている順番の数値を順次繰り上げる。
【0031】
(フローチャート)
図5は、本実施形態に係る製造管理システムのサーバにおける処理の手順を示すフローチャートである。
まず、所在位置追従処理部11が、センサ読取装置からの検知情報に基づいて車両の通過を検知する(S101)。
すると、データ更新処理部12が、どの検知装置4から検知情報が取得されたかによって制御データ16における更新箇所を特定し、制御データ16の該当箇所を更新する(S102)。制御データ16の更新方法は、前記したため、ここでの説明は省略する。
【0032】
データ更新処理部12は、制御データ16を格納している記憶部19からの応答などを受信したか否かを判定することによって、制御データ16の更新が成功したか否かを判定する(S103)。
ステップS103の結果、例えば一定時間、応答が返信されないなど、制御データ16の更新に失敗したと判定された場合(S103→No)、データ更新処理部12は制御データ更新失敗の旨をサーバ1の図示しない表示部に表示したり、管理者が使用しているクライアント端末2の表示部に表示させるなどして、制御データ更新失敗のエラー通知を行い(S104)、処理を終了する。この場合、管理者がデータ修正処理部14およびデータ更新処理部12を介して、手動にて制御データ16を更新する。
【0033】
ステップS103の結果、制御データ16の更新が成功した場合(S103→Yes)、データ変換・更新処理部13が対応マスタを参照して、管理データ更新のためのSQLを生成する(S105)。SQLの生成方法は、前記して説明したため、ここでの説明を省略する。
そして、データ変換・更新処理部13が、作成したSQLに従って管理データ17を更新する(S106)。ステップS105のSQL生成、ステップS106の管理データ17の更新については、前記して説明してあるので、ここでの説明を省略する。
次に、データ変換・更新処理部13は、管理データ17を格納している記憶部19からの応答を受信したか否かを判定することによって、管理データ17の更新が成功したか否かを判定する(S107)。
【0034】
ステップS107の結果、例えば一定時間、応答が返信されないなど、管理データ17の更新に失敗したと判定された場合(S107→No)、管理データ更新失敗の旨をサーバ1の図示しない表示部に表示したり、管理者が使用しているクライアント端末2の表示部に表示させるなどして、管理データ更新失敗のエラー通知を行い(S108)、処理を終了する。この場合、管理者がデータ修正処理部14、データ更新処理部12およびデータ変換・更新処理部13を介して、手動にて管理データ17を更新する。
【0035】
ステップS107の結果、管理データ17の更新が成功した場合(S107→Yes)、データ変換・更新処理部13は処理を終了する。
クライアント端末2は、管理データ17を閲覧することとなる。
【0036】
なお、本実施形態では、SQLを生成した後、このSQLに基づいて管理データ17の更新を行ったが、その他のデータベース言語を用いてもよい。また、SQLを用いずに、対応マスタデータ18のデータを基に、データ変換・更新処理部13が直接管理データ17を更新してもよい。
あるいは、対応マスタデータ18も設定せずに、データ変換・更新処理部13が、制御データ16の更新箇所を検出し、管理データ17において、その検出箇所に該当する箇所を検出して、管理データ17の更新を行ってもよい。
【0037】
(まとめ)
本実施形態によれば、クライアント端末2による閲覧専用の管理データ17を有し、制御データ16の更新をこの管理データ17に反映することによって、制御データ16への排他性を維持しつつ、クライアント端末2による工程の進捗の閲覧のリアルタイム性を確保することができる。
また、本実施形態によれば、クライアント端末2が制御データ16の内容を反映された管理データ17を閲覧することによって、リアルタイム性を保ちつつ、制御データ16の配信を行わないことから通信負荷の低減も可能となる。
さらに、管理データ17におけるIDなどを管理する対応マスタデータ18を有することにより、これらのIDを使用したSQLを生成することが可能となり、管理データ17の更新が容易となる。
【符号の説明】
【0038】
1 サーバ(情報処理装置)
2 クライアント端末
3 作業指示デバイス
4 検知装置
5 製造管理システム(システム)
11 所在位置追従処理部
12 データ更新処理部
13 データ変換・更新処理部
14 データ修正処理部
15 作業指示処理部
16 制御データ
17 管理データ
18 対応マスタデータ
19 記憶部
【特許請求の範囲】
【請求項1】
システムの制御に関するデータである制御データと、
前記制御データの内容をクライアント端末に閲覧させるための管理データと、
を記憶部に格納している情報処理装置の情報管理方法であって、
前記情報処理装置は、
前記制御データが更新されると、前記更新の内容を前記管理データに反映する
ことを特徴とする情報管理方法。
【請求項2】
前記情報処理装置は、
前記制御データの内容と、前記管理データの内容と、を対応付ける情報を格納している対応マスタデータを有し、
前記制御データが更新されると、前記対応マスタデータを参照し、管理データにおける更新箇所を特定して、前記更新の内容を前記管理データに反映する
ことを特徴とする請求項1に記載の情報管理方法。
【請求項3】
システムの制御に関するデータである制御データと、
前記制御データの内容をクライアント端末に閲覧させるための管理データと、
を記憶部に格納している情報処理装置であって、
前記制御データが更新されると、前記更新の内容を前記管理データに反映するデータ変換・更新処理部を有する
ことを特徴とする情報処理装置。
【請求項1】
システムの制御に関するデータである制御データと、
前記制御データの内容をクライアント端末に閲覧させるための管理データと、
を記憶部に格納している情報処理装置の情報管理方法であって、
前記情報処理装置は、
前記制御データが更新されると、前記更新の内容を前記管理データに反映する
ことを特徴とする情報管理方法。
【請求項2】
前記情報処理装置は、
前記制御データの内容と、前記管理データの内容と、を対応付ける情報を格納している対応マスタデータを有し、
前記制御データが更新されると、前記対応マスタデータを参照し、管理データにおける更新箇所を特定して、前記更新の内容を前記管理データに反映する
ことを特徴とする請求項1に記載の情報管理方法。
【請求項3】
システムの制御に関するデータである制御データと、
前記制御データの内容をクライアント端末に閲覧させるための管理データと、
を記憶部に格納している情報処理装置であって、
前記制御データが更新されると、前記更新の内容を前記管理データに反映するデータ変換・更新処理部を有する
ことを特徴とする情報処理装置。
【図1】
【図2A】
【図2B】
【図2C】
【図3A】
【図3B】
【図4】
【図5】
【図2A】
【図2B】
【図2C】
【図3A】
【図3B】
【図4】
【図5】
【公開番号】特開2012−108781(P2012−108781A)
【公開日】平成24年6月7日(2012.6.7)
【国際特許分類】
【出願番号】特願2010−257954(P2010−257954)
【出願日】平成22年11月18日(2010.11.18)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
【公開日】平成24年6月7日(2012.6.7)
【国際特許分類】
【出願日】平成22年11月18日(2010.11.18)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
[ Back to top ]