JP4380426B2 - 生産情報の統合管理システム、そのプログラム - Google Patents

Description

本発明は、生産システムにおける情報の統合管理を行うシステム、方法、プログラム等に関する。

従来より、工場等の生産システム制御・管理に係わり、様々な技術が提案されているが、特に食品工場に係わり、例えば特許文献１記載の技術が提案されている。特許文献１記載の発明は、ＨＡＣＣＰ（危害分析・重要管理点監視）管理を、ＡＳＰ（アプリケーションサービスプロバイダ）にて管理しようとするものである。すなわち、食品製造工場内のコンピュータからの食品衛生管理に関する各種リクエスト、各種実績データ、並びに各種指図の群から選ばれる情報を、通信回線を介して、管理会社のサーバにて受け取り、管理会社のサーバから工場内のサーバへ食品衛生管理に関する各種アプリケーション、各種指図、各種処置指示の群から選ばれる情報を、上記通信回線を介して送り出すことを特徴とするものである。
特開２００２−４９６６０号公報

どの様な生産物であっても、不良品は無いに越したことはないが、食品の場合、不良品によって食中毒等が発生すると、企業の存続さえ危ぶまれる事態になる可能性もある。よって、不良品が出ないように努めるのは勿論であるが、それでも問題が生じた場合に、早期発見、原因究明が容易に行えるような仕組みが必要とされる。

特にバッチプラント型（または連続プロセス型）食品製造の製造形態の特徴として、原料投入〜加工〜製品化の過程（工程）において、原料または中間品の混合、積層、分離、配分等が発生することが挙げられる。このため、工程間、原料と製品、中間品と製品等の関係が複雑化し、真の原因特定の大きな壁となっている。

上記より、製造プロセスにおける工程、実行イベント及びその前後関係の把握と、これをキーとした製造活動情報、品質情報の収集・分析が可能な仕組み作りが大きな課題となる。

本発明の課題は、トレンドデータとイベントデータの統合データを作成管理し、この統合データをロット・バッチ別、時間別、階層別に切り分けて、あるいは集計値等を求めて、これらに識別子を与えて格納・管理し、分析支援環境を含め、可能な限り統一的な分析環境を提供する生産情報統合管理システム、そのプログラム等を提供することである。

本発明の生産情報統合管理システムは、制御装置からトレンドデータとイベントデータを収集するデータ収集手段と、該収集したトレンドデータとイベントデータ間を関連付けて格納する格納する統合データ生成・格納手段と、該統合データ生成・格納手段に格納された統合データを、各種の目的に応じて分類した各種目的別データベースを生成して格納する目的別データベース生成・格納手段と、任意の検索条件に応じて、該各種目的別データベースから、検索条件に合致するデータを取得して表示する表示制御手段とを有し、前記イベントデータは、工程を段階的に細分化し且つ階層構造に従ったデータであり、前記統合データ生成・格納手段は前記収集したイベントデータの各階層に対応する部分を前記トレンドデータから切り出して前記関連付けを行うように構成する。

トレンドデータは、時間軸に沿ったセンサデータ等であり、このままでは様々な切り口から分類・整理して表示することはできないが、例えばロット・バッチで管理されるイベントデータとの関連付けを行うことで可能となる。更に、目的別に分類・整理したデータベースを作成しておくことで、検索が容易になる。

上記階層構造は例えばＳ８８に準拠したものであり、これによって特定の階層構造に従ってデータを分類・格納しておくことができ、見たい部分だけを迅速に検索・表示させることができる。

例えば、前記切り出しは、各階層の開始時間と終了時間の間のトレンドデータを切り出すものであり、前記統合データ生成・格納手段は、前記切り出したトレンドデータの合計・最大・最小・平均を求めて、これも前記関連付けを行うようにしてもよい。

例えば、前記表示制御手段は、前記取得したデータを、表、又はグラフ、又はガントチャート、あるいは相関図として表示するようにしてもよい。
例えば、前記目的別データベースは、前記統合データをロット・バッチ別に分類して、各ロット・バッチ毎に識別子を割り当てたもの、又は前記統合データから集計値を求めてロット・バッチ別に分類して、各集計値を求めたロット・バッチ毎に識別子を割り当てたもの、あるいは前記統合データを時分割に集計して、各集計値群毎に識別子を割り当てたものであり、前記表示制御手段は、ロット・バッチの識別子、または前記各集計値群毎の識別子を用いて前記検索を行うようにしてもよい。

本発明の生産情報統合管理システム等によれば、トレンドデータとイベントデータの統合データを作成管理し、この統合データをロット・バッチ別、時間別、階層別に切り分けて、あるいは集計値等を求めて、これらに識別子を与えて格納・管理し、分析支援環境を含め、可能な限り統一的な分析環境を提供することができる。

以下、図面を参照して、本発明の実施の形態について説明する。
図１は、本例の生産管理システムの概略構成図である。
図示の生産管理システムは、大別して、ＭＥＳ(Manufacturing Execution System；製造実行システム)と、ＤＣＳ／ＰＬＣ等の制御装置に分かれる。

ＭＥＳにおいて、製造計画装置１、指図展開装置３、製造指図装置５、進捗管理装置７によって、進捗管理を行いつつ、制御系Ｉ／Ｆ（インタフェース）９を介してＤＣＳ／ＰＬＣに対して製造指示を送る構成については、既存の構成であり、特に説明しない。尚、以下の説明においてＤＢはデータベースであり、ＤＣＳは分散形制御システム(Distributed Control System)、ＰＬＣはプログラマブルロジックコントローラである。

本例の生産管理システムの特徴は、生産情報統合管理システム１０にある。生産情報統合管理システム１０は、ＤＢ一元管理装置１１と汎用実績分析装置１５とから成る。ＤＢ一元管理装置１１は、制御系Ｉ／Ｆ９を介してＤＣＳ／ＰＬＣからトレンドデータ、イベントデータを読み出し、これらを関連付けて製造実績ＤＢ（統合ＤＢ）１２に格納する。更に、製造実績ＤＢ（統合ＤＢ）１２に格納されたデータを目的別に分類・整理して、目的別ＤＢ１３に格納する。汎用実績分析装置１５は、目的別ＤＢ１３に格納されているデータを用いて、汎用／専用グラフ表示、実績分析、総合進捗管理等を行う。

上記生産情報統合管理システム１０の機能は、概略的には、以下の通りである。
１．統合データベース
（１）トレンドデータ、イベントデータ等の複数種類のデータを統合格納・管理する。

システム管理機能：ログイン認証（セキュリティ）管理機能、データベース管理機能、ロギング管理機能。
（２）バッチ（時間帯ロットも含む）／ロット／時間／日／週／月／年レベルでデータ収集・編集可能。それを、工程／設備／品目単位で抽出可能。

制御系Ｉ／Ｆ９を介して収集したトレンドデータ、イベントデータ等の各種データを、統合ＤＢ１２に格納する際、データアイテムＩＤという識別符号を割り当ててこれに対応付けて格納・管理する。このデータアイテムＩＤは、目的別ＤＢ作成、実績分析処理において、共通の情報として管理される。

・ロットバッチ別：ロット・バッチに紐づく、イベント実績、トレンド実績、トレンド集計データ
・定期ロットバッチ別：時間締め（例えば一日単位）でロット・バッチ実績を集計した実績データ、又は時間単位でロット・バッチ実績を輪切りにした実績（時間帯ロット等）
・定周期：時間締めで集計した実績（ロット・バッチとは紐づかないデータを想定）

２．分析・表示機能
（１）トレンドデータ、イベントデータ等の複数種類のデータを紐づけた表示を可能とし、ユーザにとって、より分かり易い分析・表示環境を提供する。
（２）分析支援環境を含め、可能な限り統一的な分析環境を提供する。

以上が、生産情報統合管理システム１０の概略の機能である。
尚、上記制御系Ｉ／Ｆ９は、例えばＤＣＳマルチベンダー対応、ＯＰＣ標準インタフェースを持ち、柔軟な連携を可能としている。また、尚、上記進捗管理装置７は、製造指図機能と連携した、イベント実績収集・工程間インターロック管理・進捗管理機能を持ち、ＭＥＳの中枢的な指揮機能を実現する。

以下、まず、上述してある「制御系Ｉ／Ｆ９を介してＤＣＳ／ＰＬＣからトレンドデータ、イベントデータを読み出し、これらを関連付けて製造実績ＤＢ（統合ＤＢ）１２に格納する」処理について説明する。

その前に、まず、本例におけるイベントデータに係わるイベント実績モデルの考え方について、図２を参照して説明する。
図２に示すように、本例のイベントデータは、イベント実績のモデルはISA（国際計測制御学会）により規定されたバッチ制御のモデルと用語の国際標準規格であるＳ８８に準拠し、以下の４階層にて管理する。
・プロシジャ；Ｓ８８の最上位階層実績モデルを識別するデータである。Ｓ８８では品目を意味する場合が多い。
・ユニット；Ｓ８８の第２層実績モデルを識別するデータである。Ｓ８８では装置（設備）を意味する場合が多い。
・オペレーション；Ｓ８８の第３層実績モデルを識別するデータである。Ｓ８８では工程を意味する場合が多い。
・フェーズ；Ｓ８８の第４層実績モデルを識別するデータである。Ｓ８８では小工程を意味する場合が多い。

図２に示す例では、プロシジャ階層は、仕込装置→調合へ→調合装置→貯蔵への移送→貯蔵装置というプロセスとなっている。この中の仕込装置を例にして、ユニット階層では、原料処理装置→仕込装置→ろ過装置→煮沸装置というプロセスになっている。この中の原料処理装置を例にして、オペレーション階層は、オペレーション１，２より成り、更にフェーズ階層において、オペレーション１はバルブ開、加熱オンから成り、オペレーション２は攪拌オン、冷却オンから成る。これらユニット階層、オペレーション階層、フェーズ階層の各プロセスにおいて、イベント実績データが収集される。

図３は、イベントデータとトレンドデータの関連付け処理を説明する為の概念図である。
図４は、イベントデータとトレンドデータの関連付け処理の流れを示す図である。

まず、通常は、イベントデータは、開始時間、終了時間、工程名（設備）、値等から成り、トレンドデータは収集時刻、データ種別（設備名・センサ名等）、値（生データ）等から成るが、本例では例えば図３に示すように、イベントデータは、開始時刻、終了時刻、ロットＩＤ、バッチＩＤ、及び上記Ｓ８８階層ＩＤ（プロシジャＩＤ、ユニットＩＤ、オペレーションＩＤ、フェーズＩＤ）より成る。一方、トレンドデータは上記通常のものであり、図示の例では、データ種別（設備名・センサ名等）が原料処理装置温度であるデータが示される。つまり、原料処理装置に設置された温度センサから収集したデータである。この例のように、トレンドデータは、時系列的に連続するデータに過ぎず、どの部分がどのイベントに対応するデータであるのかは分からない。

よって、図３に示すように、イベントデータとトレンドデータとを関連付けた階層別実績データを作成する。作成方法は、イベントデータの開始時刻、終了時刻を用いて、この開始−終了時刻間のトレンドデータ（生データ）を切り出す。そして、例えば、この切り出したトレンドデータ（生データ）をそのままイベントデータに対応付けてもよいし、あるいはこの生データから最大値、最小値、平均値等を求めて、これらをイベントデータに対応付けてもよい。これより、階層別実績データは、図示の通り、実績発生時刻（上記開始時刻、終了時刻）、ロットＩＤ、バッチＩＤ、及び上記Ｓ８８階層ＩＤ（プロシジャＩＤ、ユニットＩＤ、オペレーションＩＤ、フェーズＩＤ）と、生データ又は最大値・最小値・平均値等から成る。

以上の様にすることで、各イベントに対応付けたトレンドデータを格納しておくことができる。例えば、図示の例では、「オペレーション１」のイベントに紐付けたトレンドデータや、フェーズ階層の「バルブ開」のイベントに紐付けたトレンドデータ等を生成・格納しておくことができ、後に例えば「オペレーション１」や「バルブ開」の原料処理装置温度を表示させたい場合に、容易に迅速に該当するトレンドデータを検索・取得して表示することができる。

上記図３に示した関連付けは、例えば図４に示す処理の流れで実現する。
まず、制御系Ｉ／Ｆ９を介してＤＣＳ／ＰＬＣから渡されたイベントデータ３１を一時的にハードディスク等の記憶部に記憶し（ＤＢコピー又はファイルコピー）、これに基づいて締め条件に合致するか否かを判定する（ステップＳ１）。締め条件に合致する場合には、階層毎に締め状態を管理しつつ（ステップＳ２）、上述した階層別実績データを作成する処理（トレンド連携処理とも言うものとする）を実行する（ステップＳ３）。これより、まず、トレンドデータが生データのままである階層別実績データ３４が作成される。更に、この階層別実績データ３４に基づいて、生データから、その合計値、最大値、最小値、平均値等を算出する集計処理を実行することで（ステップＳ４）、階層別集計データ３５を作成する。

その際、「合計値、最大値、最小値、平均値等」に対して（生データに対してでもよいが、ここでは省略して説明する）、任意のデータアイテムＩＤを割り当てる。生データが複数種類ある場合には、それぞれにデータアイテムＩＤを割り当てる。例えば、原料処理装置温度として、Ａ点温度、Ｂ点温度の２種類あった場合、Ａ点温度の「合計値、最大値、最小値、平均値等」に対してデータアイテムＩＤ＝‘Ａ１’を割り当て、Ｂ点温度の「合計値、最大値、最小値、平均値等」に対してデータアイテムＩＤ＝‘Ａ２’を割り当てる、等とする。これによって、データアイテムＩＤを用いれば、容易に、所望のデータの「合計値、最大値、最小値、平均値等」を取得して、表示等させることができる。

上記ステップＳ２の処理では、受信したイベントデータ３１がイベント発生時のものである場合には、これを集計単位毎の締め状態を格納する為の締め管理テーブル３３に記憶する。この場合、イベントデータ３１のデータ項目の開始時刻のデータは有るが終了時刻のデータが無い。そして、同一イベントのイベント終了時のイベントデータ３１（終了時刻のデータが有る）を受信すると、締め管理テーブル３３に格納したイベントデータを更新する（終了時刻のデータを追加する）。例えば図３の例においてフェーズ「バルブ開」のイベントの発生時のイベントデータを受信し、その後にイベント終了時のイベントデータを受信することで、これが締め条件に合致するものであれば、ステップＳ３の処理を実行させることで、「バルブ開」のイベントに紐付けたトレンドデータとしての階層別実績データやその集計データが作成されることになる。尚、締め条件とは「階層構造において、下の階層の開始・終了が終わって（締めて）から上の階層が締められる」というものである。例えば、「バルブ開」が終わっても「オペレーション１」は締められないが、続いて「加熱オン」が終わったら、「オペレーション１」は締められる。同様に、「オペレーション１」更に「オペレーション２」が締められた段階で、「原料処理装置」が締められる。

尚、上記ステップＳ２の階層管理は、階層管理マスタを参照して行う。階層管理マスタは、プロシジャマスタ、ユニットマスタ、オペレーションマスタ、フェーズマスタ、イベントマスタ、ＴＡＧマスタ、装置マスタ等である。プロシジャマスタには各プロシジャを識別する為の識別子（ＩＤ）であるプロシジャＩＤが格納される。ユニットマスタには各ユニットＩＤ毎にそれが属する上位階層（プロシジャＩＤ）が格納される。オペレーションマスタには各オペレーションＩＤ毎にそれが属する上位階層（プロシジャＩＤ及びユニットＩＤ）が格納される。フェーズマスタには各フェーズＩＤ毎にそれが属する上位階層（プロシジャＩＤ、ユニットＩＤ、及びオペレーションＩＤ）が格納される。ＴＡＧマスタには、イベントＴＡＧとデータＴＡＧが格納される。イベントＴＡＧは状変（状態変化）データを取得する為のＤＣＳアドレスである。データＴＡＧは現在値を取得する為のＤＣＳアドレスである。

図５に、イベントデータとトレンドデータの結合イメージを示す。
図示の例では、図上右側に示すような、ある時のある設備における加熱処理時の温度変化を表示したいものとする。ここでは、イベントＴＡＧの開始時刻と終了時刻の間にあるトレンドデータを、イベントＴＡＧとトレンドＴＡＧで紐付けする様子を示してある。尚、トレンドＴＡＧとは上記データアイテムＩＤのことであり、イベントＴＡＧとは後述するイベントＩＤのことである。

次に、上記統合ＤＢに格納したデータを、各種の目的別に分類・整理した目的別ＤＢの作成及び表示制御処理について、図６を参照して説明する。尚、これは後に説明する実績分析（各種表示）を支援する環境を構築するものであるともいえる。

図６において、統合ＤＢ５０は、上記イベントデータとトレンドデータとを紐付けた状態のイベント実績ＤＢ５１、トレンド実績ＤＢ５２等である。これらとデータアイテム定義６２に基づいて、目的別ＤＢ格納処理部６４が、目的別ＤＢ４０を作成する。

尚、図示の例では、統合ＤＢ５０には、更に、離散ＤＢ５３が存在する。
離散ＤＢ５３には、定周期離散データと不定周期離散データが格納される。定周期離散データの例としては、例えば、原料、包装材料の入荷量（定期的に入荷する場合）、品質チェックデータ（濃度、密度、粒度）（定期的にチェックする場合）、原料、包材の在庫量（定期的に在庫チェックする場合）、製品の出荷量（定期的に出荷する場合）等である。不定周期離散データの例としては、例えば、原料、包装材料の入荷量（不定期的に入荷する場合）、品質チェックデータ（濃度、密度、粒度）（不定期的にチェックする場合）、原料、包材の在庫量（不定期的に在庫チェックする場合）、製品の出荷量（不定期的に出荷する場合）等である。

目的別ＤＢ４０は、図示の例では各目的別に４種類作成される。つまり、ロット・バッチ別ＤＢ４１、定期ロット・バッチ別ＤＢ４２、定周期収集・期間別ＤＢ４３、及び進捗ＤＢ４４である。

まず、ロット・バッチ別ＤＢ４１作成に関しては、目的別ＤＢ格納処理部７２は、特定の（例えばユーザから指定された）ロット・バッチに関連するイベントデータ、トレンドデータを、統合ＤＢ５０を検索して収集し、ロット・バッチ別ＤＢ４１に格納する。但し、イベントデータは、元々、上記のようにロット・バッチ別に分類・管理されているので問題ないが、トレンドデータにはロット・バッチに関する情報はないので、そのままでは該当するデータを検索できない。それ故に図６には示していないが、実際には上述した階層別実績データ３４又は階層別集計データ３５を検索して、該当するデータを求めることになる。但し、上述した階層別実績データ３４では、ロットＩＤ、バッチＩＤだけでなく更にＳ８８階層ＩＤによって分類・管理していたが、この例に限らず、ロットＩＤとバッチＩＤで分類・管理するようにしてもよく、この場合、上記のように、指定されたロットＩＤとバッチＩＤによってデータ検索することになる。

次に、定期ロット・バッチ別ＤＢ４２に関しては、目的別ＤＢ格納処理部７２は、以下の２通りのデータ収集処理を行う。
（Ａ）各ロット・バッチ毎に、更に時分割のデータ切り出しを行って、定期ロット・バッチ別ＤＢ４２に格納する。
（Ｂ）所定期間毎（例えば１時間毎、１日毎、１週間毎）の出来高、回数等の集計を行う。

（Ａ）の場合には、進捗データ等から、指定されたロットＩＤ、バッチＩＤに紐付く設備ＩＤを取得する。そして、イベントＩＤと設備ＩＤとから収集項目を検索し、トレンド実績を収集・集計する。収集したトレンドデータに対して、ロット・バッチの情報を紐付ける。ロット・バッチに関連し、時分割したトレンドデータを、ロット・バッチをキーにして検索・参照することが可能になる。時間帯ロット等の、ロット・バッチ内で時間帯毎に管理する実績データも対象とする。

（Ｂ）の場合には、イベント実績ＤＢ５１から時間指定でロット・バッチを検索し、該当する実績データを収集し、更に集計する。例えば、１日／１週間／一ヶ月単位での製造に関連する各種データを集計する（総生産量、原料・包材の総使用量等）。集計結果は表示等する。尚、収集対象は、既に終了したロット・バッチ・イベントのデータとする。

次に、定周期収集・期間別ＤＢ４３に関しては、日、週、月、年等の所定の時間単位でデータを収集し、主にトレンド実績データを対象として、収集したデータに対して時間指定で集計を行い、これに設備ＩＤをキー項目として付して格納・管理する。

進捗ＤＢ４４には進捗データ等を格納する。
上記ロット・バッチ別ＤＢ４１、定期ロット・バッチ別ＤＢ４２、定周期収集・期間別ＤＢ４３、及び進捗ＤＢ４４の各々に係わる目的別ＤＢ４０、統合ＤＢ５０、データアイテム定義マスター６２のデータ構成例を、図７〜図１０に示す。

図７には、ロット・バッチ別ＤＢ４１、及びこれの作成に係わる統合ＤＢ５０、データアイテム定義マスター６２のデータ構成例を示す。
まず、統合ＤＢ５０に関して、イベント実績データにおけるイベント実績ヘッダは、イベントＮｏ．をキー項目として、プロシジャＩＤ、装置ＩＤ、イベントＩＤ、開始時刻、終了時刻、締め状態、ロットＩＤ、バッチＩＤ等より成る。そして、イベントＮｏ．に紐付いて、イベント実績データやイベント実績トレンドデータがある。これらは、イベントＮｏ．とデータアイテムＩＤに応じて、実績値や各集計値が格納されている。

目的別ＤＢ格納処理部６４は、上記イベント実績データより、データアイテム定義マスタ６２のロット・バッチ別収集定義マスタ、目的別データアイテムマスタを参照して、ロット・バッチイベントヘッダ、ロット・バッチ別イベントデータ、ロット・バッチ別イベントデータ集計、ロット・バッチ別イベントトレンドデータを作成して、ロット・バッチ別ＤＢ４１に格納する。

ロット・バッチ別収集定義マスタは、データアイテムＩＤ、プロシジャＩＤ、イベントＩＤに対して、装置ＩＤ等が格納される。目的別データアイテムマスタは、データアイテムＩＤ、収集種別に対して、単位、収集先、収集データアイテムＩＤ、収集周期、バッチレベル等が格納される。ロット・バッチイベントヘッダは、プロシジャＩＤ、ロットＩＤ、バッチＩＤ、イベントＩＤ、開始時刻に対して、装置ＩＤ、終了時刻、締め状態が格納される。ロット・バッチ別イベントデータは、データアイテムＩＤ、ロットＩＤ、バッチＩＤ、プロシジャＩＤ、イベントＩＤ、開始時刻に対して、装置ＩＤ、実績値が格納される。ロット・バッチ別イベントデータ集計は、データアイテムＩＤ、ロットＩＤ、バッチＩＤ、プロシジャＩＤ、イベントＩＤに対して、装置ＩＤと各集計値とイベント数が格納され、ロット・バッチ別イベントトレンドデータでは更に有効トレンドデータ数が格納される。

一方、統合ＤＢ５０において、トレンド実績データは、データアイテムＩＤ、収集日時、収集周期に対して、例えば時間的に連続する複数のデータが格納されるが、上記の通りイベントデータと紐付いているので、データアイテムＩＤ等により、対応するプロシジャＩＤ、ロットＩＤ、バッチＩＤ、イベントＩＤ等が分かるので、図示のようなロット・バッチ別トレンドデータ等が作成できる。

図８には、定期ロット・バッチ別ＤＢ４２、及びこれの作成に係わる統合ＤＢ５０、データアイテム定義マスター６２のデータ構成例を示す。
図８において、統合ＤＢ５０のイベント実績ヘッダ、イベント実績データは上記図７とほぼ同じである。定期ロット・バッチ別ＤＢ４１には、図示の通り、イベント実績データを所定の時間単位で集計したデータが作成・格納される。図示の例では、時、日、月単位での集計値となっている。この作成の為に、データアイテム定義マスター６２の定期ロット・バッチ別収集定義マスタ、目的別データアイテムマスタ、定期収集種別マスタを参照する。目的別データアイテムマスタは図７と同じである。定期ロット・バッチ別収集定義マスタは、データアイテムＩＤ、定期収集種別に対して装置ＩＤが格納される。定期収集種別マスタは、定期収集種別に対して定期収集日時、前回定期収集日時が格納される。

図９には、定周期収集・期間別ＤＢ４３、及びこれの作成に係わる統合ＤＢ５０、データアイテム定義マスター６２のデータ構成例を示す。
この場合、統合ＤＢ５０には、トレンド実績データを所定の時間単位で集計したデータが作成・格納される。図示の例では、時、日、月単位での集計値となっている。この作成の為に、データアイテム定義マスター６２の定期ロット・バッチ別収集定義マスタ、目的別データアイテムマスタ、定期収集種別マスタは、図８とほぼ同様であり、これより図示のように装置ＩＤが加わったデータが作成されて定周期収集・期間別ＤＢ４３に格納される。尚、マスタに関しては図８に対して更に項目間演算ＩＤとこれに応じた演算式等が格納され、これを用いて項目間演算を行うこともできる。

図１０に示す進捗データについては図示の通りである。
図１１に、グラフ作成フローを示す。
図１１において、統合ＤＢ５０、目的別ＤＢ４０は、上述した処理により作成したものである。マスターＤＢ７０は、上記図６の主に目的別ＤＢ参照マスター６１に相当するものであり、グラフ定義マスタ７１、グラフ詳細定義マスタ７２、目的別ＤＢ変換マスタ７３、品種定義マスタ７４、設備定義マスタ７５、データアイテム定義マスタ７６等より成る。

グラフ定義マスタ７１、グラフ詳細定義マスタ７２は、ここでは区別して示してあるが、以下の説明では区別することなく、グラフ詳細定義マスタ７２はグラフ定義マスタ７１に含めるものとする。

グラフ定義マスタ７１の一例を図１２に示す。
また、目的別ＤＢ変換マスタ７３のみは、目的別ＤＢ参照マスター６１ではなく、データアイテム定義マスター６２に相当するものであり、その具体例は、上記図７〜図１０に示してある。

品種定義マスタ７４、設備定義マスタ７５、ＴＡＧ定義マスタ７６の一例を、それぞれ、図１３（ａ）、（ｂ）、（ｃ）に示す。図１３（ａ）に示す品種定義マスタ７４の例は、品目ＩＤをキー項目として、品目名、品目種別、単価の各データが格納される。図１３（ｂ）に示す設備定義マスタ７５の例は、設備ＩＤをキー項目として設備名が格納される。図１３（ｃ）に示すデータアイテム定義マスタ７６は、データアイテムＩＤをキー項目として、データアイテム名、データタイプ、単位ＩＤ、データ種別、収集システムＩＤの各データが格納される。

図１１のフローの説明に戻る。図１１では、上記各種ＤＢに基づいて、上記各種目的別ＤＢ４０を作成する処理（ステップＳ１１〜Ｓ１５）と、作成した目的別ＤＢ４０に基づいて各種のグラフ表示を行う処理（ステップＳ２１〜Ｓ２８）を示してある。

まず、ステップＳ１１〜Ｓ１５の処理について説明する。
まず最初に目的別ＤＢ変換マスタ７３、設備定義マスタ７５、データアイテム定義マスタ７６に格納されているデータを読み込む（ステップＳ１１、Ｓ１２）。更に、統合ＤＢ５０のイベント実績ＤＢ５１、トレンド実績ＤＢ５２に格納されているデータを収集する（ステップＳ１３）。そして、上記取得した各種データに基づいて、所定の演算処理を実行して目的別ＤＢを作成する（ステップＳ１４、Ｓ１５）。

次にステップＳ２１〜Ｓ２８の処理について説明する。ステップＳ２１〜Ｓ２８の処理は、Ｗｅｂサーバが、Ｗｅｂクライアントからの要求や設定に応じて、マスタＤＢ７０や目的別ＤＢ４０を参照しつつ実行する処理である。

まず、Ｗｅｂクライアントにおいてユーザが所望の帳票を選択すると（ステップＳ３１）、この選択結果がＷｅｂサーバに通知され、Ｗｅｂサーバはグラフ定義マスタ７１に格納されているデータ（グラフ定義）を読み込み（ステップＳ２１）、検索画面を作成してＷｅｂクライアントのディスプレイに表示させる。この検索・表示画面の一例を図１４に示す。

図１４には、検索・表示画面の一例（その１）を示す。
図示の検索・表示画面では、検索条件として、グラフ種別、表示単位、項目毎、品目、日付等がある。グラフ種別に関しては、時報、日報、ロット報、バッチ報、週報、月報、年報、任意期間報等がコンボボックスに選択肢として表示され、ユーザはこの中から任意に選択する。また、表示単位に関しては、選択したグラフ種別に応じた選択肢がコンボボックス内に表示され、ユーザはこの中から任意に選択する。例えば、日報が選択された場合には時、日、バッチ、ロット報が選択された場合には時、日、バッチ、ロット報がコンボボックス内に表示される。項目毎のチェックボックスは、もしチェックした場合には、検索結果として表示されるグラフは、項目毎にデータは分けて時間軸に沿って表示され、もしチェックしなかった場合には項目内で時間順に表示される。また、品目に関しては、検索結果として表示されるグラフがイベントデータである場合に、関連する品目名一覧がコンボボックス内に表示される。また、日付には、選択したグラフ種別に応じた、表示させる期間を入力させる。例えば、日報であれば、年月日を入力する。

以上の検索条件を入力して（ステップＳ３２）、「表示」ボタンを操作すると、当該入力された検索条件を含む表示要求がＷｅｂサーバに送られる。Ｗｅｂサーバは、マスターＤＢ７０からグラフ詳細定義とデータアイテム定義を読み込み（ステップＳ２３、Ｓ２４）、更に目的別ＤＢ４０から上記検索条件に合致するデータを収集する（ステップＳ２５）。そして、所定の演算処理を実行してグラフページを作成し（ステップＳ２６、Ｓ２７）、作成したグラフページをＷｅｂクライアントに返信する（ステップＳ２８）。

Ｗｅｂクライアントは、受け取ったグラフページに基づいて、グラフ作成処理を行い、例えば上記図１４に示すようなグラフを表示する。
図１４の例は、基本的なグラフ表示の例であるが、他にも以下に説明する加工グラフ表示を行うことができる。加工グラフ表示機能としては、例えば挙動解析、ロットフロー、相関解析等による表示がある。

挙動解析は、同一装置（同一工程）内でバッチ毎のトレンドデータ（生データ）の表示を行うものである。図１５に、その為の検索・表示画面を示す。Ｗｅｂサーバは、Ｗｅｂクライアントから挙動解析指令が送られてくると、予め用意されている各種画面定義情報の中から挙動解析用の画面定義情報を取得して、これをＷｅｂクライアントに返信することで、図１５の検索・表示画面が表示される。

ユーザは、この検索・表示画面上で所望の検索条件を入力する。すなわち、ユーザは、まず、コンボボックスにより、装置グループ一覧の中から所望の装置グループを選択し、選択された装置グループに属する装置名一覧の中から所望の装置名を選択する。続いて、選択された装置名の装置に関連する表示データ一覧がリストボックスに表示されるので、所望の表示データを選択する。表示データ一覧の一例としては、例えば、蒸気入口温度、蒸気出口温度、蒸気入口圧力、蒸気出口圧力等である。つまり、選択された装置に備えられておる各種センサから収集したデータのデータ名一覧が表示される。

そして、「バッチ検索」ボタンを押すことで、以上選択した条件に合致するバッチが検索され、そのバッチ名がリストボックスに一覧表示されるので、この中から所望のバッチを選択することで、選択されたバッチのトレンドデータ（生データ）が図示の様にグラフ表示される。

次に、ロットフローは、同一プロシジャにおける複数設備でのトレンドデータ表示を行うものである。ロットフローの検索・表示画面の一例を図１６に示す。
図１６に示す画面は、特に図示しない画面上で任意の複数設備（設備名；設備１〜設備４）を指定した後に表示される画面である。尚、この設備名は、図１２に示す加工グラフ設備定義と図１３（ｂ）の設備定義マスタから検索して求める。また、尚、この複数設備の指定は、全く任意であってもよいし、後述する工程間リンクを利用して互いに関連する設備を取得するようにしてもよい。

図１６において、ユーザは、まず、設備１〜設備４の各々について、グラフ表示させるべきデータ名を、コンボボックスに一覧表示された中から選択する。図示の例では、設備１についてはＡ点温度、設備２についてはＢ点温度、設備３については流量、設備４については圧力が選択されている。更に任意の追加の検索条件としてユーザは、バッチ一覧の中から所望のバッチを選択する。あるいは時間帯指定に行う。時間帯指定を行った場合には、指定された時間帯を元に該当するバッチを検索する。そして、「表示」ボタンを操作すると、上記入力されたデータ名、バッチを検索キーとして該当するデータを取得して、図示の通りグラフ表示する。

最後に、相関解析は、２つのデータ間の相関図を表示するものである。相関関係の検索・表示画面の一例を図１７に示す。図示の画面において、ユーザは、まず、所望のデータグループを選択する。つまり、まず所望の設備を選択し、更に選択した設備に係わる装置一覧の中から所望の装置を選択する。これによって、選択された装置に係わる各種表示データ名が取得され、図示の「Ｘ軸」、「Ｙ軸」のコンボボックスに一覧表示されるようになる。つまり、図示の「Ｘ軸」、「Ｙ軸」のコンボボックスには、相関図のＸ軸／Ｙ軸に表示させる表示データの候補が一覧表示されることになる。これより、ユーザは、相関図のＸ軸、Ｙ軸に表示させるべき所望の表示データ名を選択する。図示の例ではＸ軸は釜内圧力、Ｙ軸は蒸気圧力が選択されている。更に、図示の「バッチ選択」のリストボックスには、グラフ表示可能なバッチ一覧が表示され、ユーザは所望のバッチ名を選択する。そして、プロット間隔の指定や表示位置の指定を行った後、「表示」ボタンを操作すると、図示の通り、相関図がグラフ表示される。

図１８は、画面データアイテムＩＤ定義画面の一例である。この画面は、目的別ＤＢに格納されている各データアイテムの中から、画面に表示するデータアイテムを絞り込むことを目的とする。

まず、図示の「プロシジャ選択」のコンボボックスにおいて、選択したいデータのプロシジャを指定する（例えば仕込／調合／貯蔵／全てが一覧表示されるので、この中から指定する）。すると、選択されたプロシジャに関する上記Ｓ８８に準拠した階層モデルが一覧表示されるので、ユーザはこの中から任意に選択する。そして、「選択」ボタンを操作すると、上記選択結果に対応するデータアイテムが、図示の「データアイテム一覧」に表示される。ユーザが任意のデータアイテムを選択して「詳細表示」ボタンを操作すると、そのデータアイテムの詳細が図上右側に表示されるので、ユーザはその内容を確認できる。
確認したら、図示の矢印キー（↑、↓）により所望のデータアイテムを選択し、画面データアイテム定義ＤＢに登録する。

上記図１６のロットフロー検索は、工程間リンク情報に基づいて行う。これについて以下に説明する。
実績情報として記録することで、工程間リンクを実現する。

すなわち、図１９に例示されるように、本例のマスタＤＢには、工程間リンクマスタ１７１、工程間リンクデータマスタ１７２、バッチイベントマスタ１７３、および、イベント実績ヘッダ１８１、イベント実績データ１８２、工程間リンク実績ヘッダ１８３、工程間リンク実績データ１８４が設定されている。

これらの情報は、汎用データベースプログラム２２ｂにて制御されているデータセットマスタ７４、データセットアイテムマスタ７５およびデータアイテムマスタ７６等の汎用データベースの上に構築／設定されており、工程間リンク処理プログラム２２ｃおよびトレーサビリティプログラム２２ｄにて後述のように、設定／制御される。

図１９に示されるように、払い側と受け側の基本的なリンク関係を定義する工程間リンクマスタ１７１には、キー項目としての工程間リンクＩＤ１７１ａと、受けプロシジャＩＤ１７１ｂ、受け装置ＩＤ１７１ｃ、受けイベントＩＤ１７１ｄ、払いプロシジャＩＤ１７１ｅ、払い装置ＩＤ１７１ｆ、払いイベントＩＤ１７１ｇ、の各情報が設定されている。個々のリンク関係は、工程間リンクＩＤ１７１ａにて識別される。

バッチイベントの定義が格納されるバッチイベントマスタ１７３には、キー項目としてのプロシジャＩＤ１７３ａ、装置ＩＤ１７３ｂおよびイベントＩＤ１７３ｃと、データセットＩＤ１７３ｄ、項目間演算ＩＤ１７３ｅ、バッチレベル１７３ｆ、親イベントＩＤ１７３ｇ、の各情報が設定されている。

イベント実績ヘッダ１８１には、キー項目としてのイベント番号１８１ａ、プロシジャＩＤ１８１ｂ、装置ＩＤ１８１ｃ、イベントＩＤ１８１ｄ、開始時刻１８１ｅ、終了時刻１８１ｆ、締め状態１８１ｇ、ロット番号１８１ｈ、バッチ番号１８１ｉ、の各情報が設定されている。

イベント実績データ１８２には、キー項目としてのイベント番号１８２ａおよびデータアイテムＩＤ１８２ｂと、実績値１８２ｃ、等の各情報が設定されている。この実績値１８２ｃは、原料や中間製品、中間原料、最終製品等の名称、あるいは量、各種測定データの実測値、等が含まれる。

ロット、バッチの対応付け情報が設定される工程間リンク実績ヘッダ１８３には、工程間リンクＩＤ１８３ａ、受け終了時刻１８３ｂ、受けロット番号１８３ｃ、受けバッチ番号１８３ｄ、払い終了時刻１８３ｅ、払いロット番号１８３ｆ、払いバッチ番号１８３ｇ、リンク状態１８３ｈ、等の各情報が格納されている。

受け払いの実績値が格納される工程間リンク実績データ１８４には、工程間リンクＩＤ１８４ａ、受け終了時刻１８４ｂ、データアイテムＩＤ１８４ｃ、受け実績値１８４ｄ、払い実績値１８４ｅ、の各情報が格納されている。

図２０に、工程間リンク実績データの作成例を示す。先行する工程に払いイベントＡと、払いイベントＢがあり、後続の工程に受けイベントＢがある場合、払いイベントＡと受けイベントＡをリンクするケースＣ１の場合、工程間リンク定義はテーブルＴ１−１となり、実績値は、テーブルＴ１−２となる。

また、払いイベントＢと受けイベントＡをリンクするケースＣ２の場合、工程間リンク定義はテーブルＴ２−１となり、実績値は、テーブルＴ２−２となる。
尚、飲料等の食品製造工程のような連続型製造システムでは、図２１に示すように、複数の設備１〜８の間で、マルチパス、合流、繰り返し、分岐などの複雑な処理経路が構成されるため、個々の設備（プロシジャ）単位で実績データを管理したのでは、プロシジャ間にまたがる表示ができない。

図２２に、上記生産情報統合管理システム１０を実現するパソコン／サーバ等のコンピュータのハードウェア構成図を示す。
同図に示すコンピュータ１００は、ＣＰＵ１０１、メモリ１０２、入力部１０３、出力部１０４、記憶部１０５、記録媒体駆動部１０６、及びネットワーク接続部１０７を有し、これらがバス１０８に接続された構成となっている。同図に示す構成は一例であり、これに限るものではない。

ＣＰＵ１０１は、当該コンピュータ１００全体を制御する中央処理装置である。
メモリ１０２は、プログラム実行、データ更新等の際に、記憶部１０５（あるいは可搬型記録媒体１０９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１０１は、メモリ１０２に読み出したプログラム／データを用いて、上述してある各種処理を実行する。

入力部１０３は、例えば、キーボード、マウス、タッチパネル等である。出力部１０４は、例えばディスプレイ等である。
ネットワーク接続部１０７は、例えばＬＡＮやインターネット、シリアルバス等の何等かのネットワークに接続して、他の情報処理装置とのコマンド／データ送受信を行う為の構成であり、上記実施例では、例えば制御系Ｉ／Ｆ９に接続して、各ＤＣＳ／ＰＬＣとの間でコマンド／データ等の送受信を行っている。

記憶部１０５は、例えばハードディスク等であり、上記各種処理をコンピュータ１００に実行させるためのプログラムや、このプログラム処理に用いる各種データが格納されている。

あるいは、これらプログラム／データは、可搬型記録媒体１０９に記憶されているものであってもよい。この場合、可搬型記録媒体１０９に記憶されているプログラム／データは、記録媒体駆動部１０６によって読み出される。可搬型記録媒体１０９とは、例えば、ＦＤ（フレキシブル・ディスク）１０９ａ、ＣＤ−ＲＯＭ１０９ｂ、その他、ＤＶＤ、光磁気ディスク等である。

あるいは、また、上記プログラム／データは、ネットワーク接続部１０７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。

また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。

生産管理システムの概略構成図である。 本例のイベントデータに係わるイベント実績モデルを説明する為の図である。 イベントデータとトレンドデータの関連付け処理を説明する為の概念図である。 イベントデータとトレンドデータの関連付け処理の流れを示す図である。 イベントデータとトレンドデータの結合イメージを示す。 目的別ＤＢの作成及び表示制御処理を説明する為の図である。 ロット・バッチ別ＤＢに係わる各種データ構成例である。 定期ロット・バッチ別ＤＢに係わる各種データ構成例である。 定周期収集・期間別ＤＢに係わる各種データ構成例である。 進捗ＤＢに係わる各種データ構成例である。 グラフ作成フローである。 グラフ定義マスタの一例である。 （ａ）〜（ｃ）は、品種定義マスタ、設備定義マスタ、ＴＡＧ定義マスタの一例を示す図である。 検索画面の一例を示す図（その１）である。 検索画面の一例を示す図（その２）である。 検索画面の一例を示す図（その３）である。 検索画面の一例を示す図（その４）である。 画面データアイテムＩＤ定義画面の一例である。 工程間リンクに係わるマスタの一例である。 工程間リンク実績データの作成例である。 食品製造工程のようなバッチ型製造システムにおける工程の複雑さを示す図である。 コンピュータハードウェア構成図である。

符号の説明

１ 製造計画装置
２ 製造計画制約条件
３ 指図展開装置
４ 製造レシピ
５ 製造指図装置
６ 指図予約
７ 進捗管理装置
８ 移行ルール
９ 制御系Ｉ／Ｆ
１０ 生産情報統合管理システム
１１ ＤＢ一元管理装置
１２ 製造実績ＤＢ（統合ＤＢ）
１３ 目的別ＤＢ
１５ 汎用実績分析装置
３１ イベントデータ
３２ トレンドデータ
３３ 締め管理テーブル
３４ 階層別実績データ
３５ 階層別集計データ
４０ 目的別ＤＢ
４１ ロット・バッチ別ＤＢ
４２ 定期ロット・バッチ別ＤＢ
４３ 定周期収集・期間別ＤＢ
４４ 進捗ＤＢ
５０ 統合ＤＢ
５１ イベントＤＢ
５２ トレンドＤＢ
５３ 離散ＤＢ
６１ 目的別ＤＢ参照マスター
６２ データアイテム定義マスター
６３ データ収集・演算処理部
６４ 目的別ＤＢ格納処理部
７１ グラフ定義マスタ
７２ グラフ詳細定義マスタ
７３ 目的別ＤＢ変換マスタ
７４ 品種定義マスタ
７５ 設備定義マスタ
７６ データアイテム定義マスタ
１００ コンピュータ
１０１ ＣＰＵ
１０２ メモリ
１０３ 入力部
１０４ 出力部
１０５ 記憶部
１０６ 記録媒体駆動部
１０７ ネットワーク接続部
１０８ バス
１０９ 可搬型記録媒体
１０９ａ ＦＤ（フレキシブル・ディスク）
１０９ｂ ＣＤ−ＲＯＭ

Claims (4)

1. 制御装置からトレンドデータとイベントデータを収集するデータ収集手段と、
   該収集したトレンドデータとイベントデータ間を関連付けて格納する統合データ生成・格納手段と、
   該統合データ生成・格納手段に格納された統合データを、各種の目的に応じて分類した各種目的別データベースを生成して格納する目的別データベース生成・格納手段と、
   任意の検索条件に応じて、該各種目的別データベースから、検索条件に合致するデータを取得して表示する表示制御手段と、を有し、
   前記イベントデータは、工程を段階的に細分化し且つ階層構造に従ったデータであり、前記統合データ生成・格納手段は前記収集したイベントデータの各階層に対応する部分を前記トレンドデータから切り出して前記関連付けを行うことを特徴とする生産情報統合管理システム。
2. 前記切り出しは、各階層の開始時間と終了時間の間のトレンドデータを切り出すものであり、
   前記統合データ生成・格納手段は、前記切り出したトレンドデータの合計・最大・最小・平均を求めて、これも前記関連付けを行うことを特徴とする請求項１記載の生産情報統合管理システム。
3. 前記表示制御手段は、前記取得したデータを、表、又はグラフ、又はガントチャート、あるいは相関図として表示することを特徴とする請求項１または２に記載の生産情報統合管理システム。
4. 前記目的別データベースは、前記統合データをロット・バッチ別に分類して、各ロット・バッチ毎に識別子を割り当てたもの、又は前記統合データから集計値を求めてロット・バッチ別に分類して、各集計値を求めたロット・バッチ毎に識別子を割り当てたもの、あるいは前記統合データを時分割に集計して、各集計値群毎に識別子を割り当てたものであり、
   前記表示制御手段は、前記ロット・バッチの識別子、または前記各集計値群毎の識別子を用いて前記検索を行うことを特徴とする請求項１〜３の何れかに記載の生産情報統合管理システム。