JP2004355506A - 通信情報変換装置およびこれを用いた生産情報システム - Google Patents
通信情報変換装置およびこれを用いた生産情報システム Download PDFInfo
- Publication number
- JP2004355506A JP2004355506A JP2003154901A JP2003154901A JP2004355506A JP 2004355506 A JP2004355506 A JP 2004355506A JP 2003154901 A JP2003154901 A JP 2003154901A JP 2003154901 A JP2003154901 A JP 2003154901A JP 2004355506 A JP2004355506 A JP 2004355506A
- Authority
- JP
- Japan
- Prior art keywords
- data
- unit
- communication
- xml
- communication information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
【課題】複数の標準化規約に柔軟に対応可能な通信情報変換装置とこれを用いた生産情報システムを得る。
【解決手段】通信情報変換装置１はデータ収集部９、収集データ指定文書１０、ＸＭＬ化部１１、ＸＭＬ変換部１２、ＸＳＬ文書１３、ＸＭＬ文書１４、通信アプリケーション部１５、全体制御部１６を備えて構成される。この通信情報変換装置１を用いた生産情報システムは、生産設備を制御する制御装置２、生産計画とその進捗の把握、企業内の資源管理を行なう上位情報系アプリケーションソフトウェア５を有する上位情報系コンピュータが備わる。通信情報変換装置１、制御装置２、上位情報系コンピュータ４は内部バス、シリアル回線、ＬＡＮ等によって接続される。
【選択図】 図１
【解決手段】通信情報変換装置１はデータ収集部９、収集データ指定文書１０、ＸＭＬ化部１１、ＸＭＬ変換部１２、ＸＳＬ文書１３、ＸＭＬ文書１４、通信アプリケーション部１５、全体制御部１６を備えて構成される。この通信情報変換装置１を用いた生産情報システムは、生産設備を制御する制御装置２、生産計画とその進捗の把握、企業内の資源管理を行なう上位情報系アプリケーションソフトウェア５を有する上位情報系コンピュータが備わる。通信情報変換装置１、制御装置２、上位情報系コンピュータ４は内部バス、シリアル回線、ＬＡＮ等によって接続される。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
この発明は、相互にネットワーク接続された生産設備用制御装置および生産情報管理装置により構成される通信情報変換装置、およびこの通信情報変換装置を用いた生産情報システムに関するものである。
【０００２】
【従来の技術】
従来の通信情報変換装置は、例えば、特許文献１の図１に示されるような構成を有していた。その動作は、図中にＮｏｄｅと記された各制御装置からデータを取り出し、通信情報変換装置で通信プロトコル変換、データフォーマットの変換、物理的なデバイス名称と情報システムとして意味づけを持つ論理名称の変換を行なうというものであった。
【０００３】
このとき、特許文献１の図３には、制御装置のネットワーク接続の物理的構造の視点から生産設備全体をモデル化したツリー構造と、それとは別の視点からモデル化したツリー構造との間で、同一の概念をあらわすツリーのノード間にリンクを張ることで、そのノードの保持するデータの値の更新が一意に行われ同一性が保たれるとしていた。また、特許文献１の図８および図９においては制御装置の動作状態を表すデータが、生産管理の観点からは異常カウントを表すことを対比付ける方法が得られるとしていた。
【０００４】
さらに、特許文献２の図３には、仮想メモリデータ管理部に制御装置類からのデータが保持され、各種アプリケーションが仮想メモリデータ管理部への共通的なアクセス方法に基づいて動作することで、制御装置、或いはデバイスごとのアクセス方法の違いが吸収され統一的にデータを送受することができるとしていた。
【０００５】
【特許文献１】
特開２００１−２５１２９８号公報
【特許文献２】
特開２００１−２５１３１８号公報
【０００６】
【発明が解決しようとする課題】
従来の通信情報変換装置は、複数のツリー構造間に静的にリンクを張る方式でデータを階層的に管理することにしていたため、制御装置の状態を表すデータもしくは制御装置の動作状態を変化させるデータを管理するツリー構造と、それとは別の構造を持つツリー構造の間にリンクを張ることはできるのであるが、それぞれのツリー構造が動的に変化する場合には対応が困難になるという問題があった。例えば制御装置が３台あり、それぞれの制御装置に生産個数を表すデータが存在するとき、生産個数を表現したツリーから３台の制御装置のデータを保持するツリーにリンクを張るが、制御装置台数が増えたときに、２つのツリー構造の間に新たなリンクを自動的には生成することができない。
【０００７】
また制御装置の動作状態を表すデータであるが、制御装置がＰＬＣ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒ）のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を８個まとめて１バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立、不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという課題があった。
【０００８】
また、生産量、異常発生回数など生産管理上の論理的な名称と、制御装置および変数の値をリンクさせる際に、生産管理上の論理名をツリー構造ではなくテーブル構造で保持しているため、ツリー構造が本来持っている動的な変化への追従能力を活かせていないという課題があった。
【０００９】
また、生産管理上の論理的な名称とリンクさせることに関しては、単に例えば「変数００１」を「生産高」とみなすのではなく、論理的な生産管理モデルと現実の生産設備で起きている事象をリンクさせることこそ、真に生産能力、採算性を改善するための様々な手法を用いるために必要となる。しかしながら、従来例は単なる名称の読み替えのみであるため、論理的な生産管理モデルを利用することができないという課題があった。
【００１０】
また、ある電気接点が閉じている時間を計測する場合、閉じ終わって開いた時刻から閉じ始めた時刻を減じることで閉じている時間を得ることができるのであるが、単なるツリー間リンクでは、この例に示すような演算処理を表現することはできないという課題があった。
【００１１】
またさらに、上記のような演算処理を行なう場合には、現在時刻を与えるタイマー、演算の途中経過或いは前回の演算結果を保持するグローバル変数が必要となる場合があるが、制御装置にそのようなタイマーと変数が存在しないと演算できないという課題があった。
【００１２】
さらに、通信情報変換装置から上位情報系の計算機にデータを送信する際、送信間隔が数秒、数百ミリ秒、数十ミリ秒といった短い間隙で送信する場合には、１回の送信データ量が増えるにしたがって、通信路のバンド幅を埋め尽くす可能性が高まる。このとき、本質的にはデータ量が増大するＸＭＬフォーマット（ｅＸｔｅｎｔｄｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いることとしているため、その可能性がより高まるという課題があった。
【００１３】
一方、アプリケーションから統一的なアクセス手法により制御装置のデータを読み出すことができるとしているのであるが、すでに開発済みのアプリケーションが存在する場合には、そのアプリケーションに手を加える必要があり、変更可能でない場合は接続ができないという課題があった。
【００１４】
この発明は、上記のような課題を解決するためになされたものであり、制御装置のデータを表すツリー構造の動的変化への追従が容易である通信情報変換装置の提供を目的とする。
【００１５】
【課題を解決するための手段】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置のデータを収集するデータ収集部と、データ収集部によって収集されたデータをＸＭＬ文書に変換するＸＭＬ化部と、ＸＭＬ化部によって得られたＸＭＬ文書を、別の形式のＸＭＬ文書に変換するＸＭＬ変換部と、ＸＭＬ変換部によって得られたＸＭＬ文書を上位情報系に伝達する通信アプリケーション部と、ＸＭＬ変換部の動作内容をＸＳＬ文書で記述するＸＳＬ記述部と、データ収集部の動作内容を、どのデータを収集すべきかを指定する収集データ指定部とを備えたものである。
【００１６】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置のデータを収集するデータ収集部と、データ収集部によって収集されたデータを格納するＸＭＬ ＤＢ部と、上位情報系からＸＭＬ ＤＢ部に格納されるデータの一部もしくは全部を取り出すための問い合わせを処理して、当該問い合わせ内容に対応するデータを返答するＱｕｅｒｙ処理部とを備えるものである。
【００１７】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置からデータを取得するプログラムを含むスクリプト言語プログラムを用いてＸＭＬ文書を生成し、もしくはＸＭＬ文書の一部に、制御装置からデータを取得するスクリプト言語プログラムを記述したＸＭＬ文書を入力とし、スクリプト言語プログラムを出力するスクリプト化部を備え、出力されたスクリプト言語プログラムを用いてＸＭＬ文書を生成し、ＸＭＬ文書を上位情報系に伝達する通信アプリケーション部とを備えるものである。
【００１８】
この発明に係る生産情報システムは、ＸＭＬ文書データを２つ以上のコンピュータ間でやりとりする際、バイナリーフォーマットで転送し、そのフォーマットに格納されるデータのデータ長、データの意味を記述したフォーマット定義ＸＭＬ文書を備えるものである。
【００１９】
この発明に係る通信情報変換装置は、収集された生データを演算処理する物理現象−論理モデル変換部と、物理現象−論理モデル変換部により演算処理されたデータのフォーマット形式を変換するデータフォーマット変換部と、データ通信を処理するためのプロトコル変換部を備え、プロトコル変換部において通信クライアントおよび通信サーバを備えるものである。
【００２０】
この発明に係る生産情報システムは、データの値が空になったツリー構造データをクライアントから受けとったサーバは、空の値を埋めたツリー構造データをクライアントに返送するものである。
【００２１】
この発明に係る生産情報システムは、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置と通信情報変換装置と上位情報系は合議制により互いのＩＰアドレス、ＩＰホスト名、マルチキャストアドレスおよびポートの割り当て、およびＬＡＮ内に存在するアプリケーションの自動設定を行うものである。
【００２２】
【発明の実施の形態】
この発明に係る通信情報変換装置および生産情報システムの実施の一形態について説明する。本発明の通信情報変換装置は、制御装置とは別の筐体で設置され、生産情報システムを構成するものとして説明するが、制御装置と通信情報変換装置は同一筐体、あるいはいわゆるバックプレーン（複数の筐体の物理的合体および電気回路の連結を同時に供する機構）で接合した形態であっても同等の効果を奏する。
【００２３】
実施の形態１．
この発明の実施の形態１について図１〜図５を参照して説明する。なお、図１は実施の形態１に係る通信情報変換装置１の構成を示す図であり、図２は実施の形態１の通信情報変換装置１を用いた生産情報システムの構成を示す図である。また、図３および図４は実施の形態１の通信情報変換装置１の動作を説明するための図であり、図５は実施の形態１の通信情報変換装置１の動作を示すフローチャートである。
【００２４】
通信情報変換装置１は図１に示すように、データ収集部９、収集データ指定文書１０、ＸＭＬ化部１１、ＸＭＬ変換部１２、ＸＳＬ文書１３、ＸＭＬ文書１４、通信アプリケーション部１５、全体制御部１６とを備えて構成される。それらの動作は後段で詳細に説明する。
【００２５】
また、通信情報変換装置１を用いた生産情報システムは、図２に示すように制御装置２Ａ，２Ｂ，２Ｃ（以下、総称して「制御装置２」と記す）、制御装置２により制御される生産設備３Ａ，３Ｂ，３Ｃ（以下、総称して「生産設備３」と記す）、生産活動を行なうにあたり、生産計画とその進捗の把握、企業内の資源管理を行なう上位情報系コンピュータ４、上位情報系コンピュータ４内に生産スケジューラーや、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、ＳＣＭ（Ｓｕｐｐｌｙ Ｃｈａｉｎ Ｍａｎａｇｅｍｅｎｔ）等の上位情報系アプリケーションソフトウェア５が備わり構成される。
【００２６】
通信情報変換装置１と制御装置２はいくつかの通信路、例えば内部バス６、ＲＳ２３２Ｃのようなシリアル回線７、或いはＬＡＮ８によって情報通信を行なうことができる。ＬＡＮ８には通信情報変換装置１、制御装置２、上位情報系コンピュータ４が接続されており、これらも相互に情報の交換を行なうことができる。なお、図２中で通信情報変換装置１を１台、制御装置２、生産設備３をそれぞれ３台、上位情報系コンピュータ４を１台で構成した例を示したが、それらの台数に限ることはない。
【００２７】
通信情報変換装置１が対象としている生産情報システムは上述のようなものであるが、つぎにその動作について説明する。
【００２８】
通信情報変換装置１のデータ収集部９はその動作を開始するとき、もしくはその動作をいったん停止して再開するときに、収集データ指定文書１０を読み込む。なお、ここでいう文書とは、コンピュータで処理可能なテキストファイルのことを指している。収集データ指定文書１０には収集する対象の制御装置と、収集するデータ、および収集するタイミングの指定、収集するタイミングの指定を記載してある。収集するタイミングとはリクエストがあるごとに一回だけ収集するのか、一定周期でログとして収集するのか、エラー発生時など指定するイベントが発生したとき収集するのか等のタイミングである。データ収集部９が動作を開始すると制御装置２から指定されたデータが読み出され、そのデータはＸＭＬ化部１１に送られる。送るときには、どの制御装置のどの変数かという名称と、実データとを組にして送ることになる。
【００２９】
この実施の形態１では共有メモリを用いた実装を説明する。図３に示すように、共有メモリには制御装置内のデータを格納しているデバイス名とその値を配列型変数領域に記録している。なお、ここでいうデバイスとは制御装置のデジタル入出力点と内部変数を総称のことである。
【００３０】
図３に示した配列型変数の左側の列には制御装置識別番号とデバイス名を組み合わせた文字列が格納され、右側の列には収集した値を表す文字列が格納されている。デバイス名で「Ｘ」とあるのは、制御装置への入力信号のうちの一つを表しており、データ長は１ビットである。「Ｍ」とあるのは制御装置の内部変数であり、「Ｙ」とあるのは制御装置の出力信号であり、データ長は１ビットである。「Ｃ」とあるのはカウンタ型の特殊な内部変数で、「Ｄ」とあるのは内部変数で、「Ｂ」とあるのは制御装置間で共有される特殊な共有変数で、データ長は８ビットである。データ収集部９は制御装置からデータ収集した後、この図３に示す配列変数を介してＸＭＬ化部１１にデータを渡すものである。
【００３１】
ここで、ＸＭＬ文書について説明する。ＸＭＬ文書はツリー構造で管理されたデータを表記するテキスト形式のデータであり、その表記方法の規約は国際標準化団体であるＷ３Ｃにより承認されたものである。その特徴は、すべてテキスト形式で記述すること、データのフィールド名をタグと呼ばれる書式で表現し（タグとは“＜”および“＞”で文字列を挟んだものである）、データの値を、自分で自由にタグを定義して、開始タグと終了タグ（開始タグのタグ名の前に“／”を付加したもの）で挟んで記述することなどである。
【００３２】
例えば、生産量が１００個であることを、＜生産量＞１００＜／生産量＞と表記する。また開始タグと終了タグを入れ子にすることでツリー構造が表現でき、例えば、工場内にラインが２つあることを、ツリー構造を用いて表現すると工場ノードの下にライン１ノードとライン２ノードがぶら下がっているように表すとよい。このときＸＭＬ文書を用いてこのツリー構造を記述すると、＜工場＞＜ライン１＞＜生産量＞１００＜／生産量＞＜／ライン１＞＜ライン２＞＜生産量＞２００＜／生産量＞＜／ライン２＞＜／工場＞とすることで、もとのツリー構造を記述できる。なお、ＸＭＬ文書は、改行位置は不問である。
【００３３】
例えば、
というように人間が読みやすいように書いても意味はまったく同じである。
【００３４】
上記のような工場の構成を考えるとき、ある工場はラインが１本だけの場合や、２本或いは３本である場合があるが、ＸＭＬ文書ではそのような場合に＜ライン＞タグを増やしたり減らしたりして、この変化に対応する。いわゆるデータベースのテーブルのように、予めラインのフィールドを１０個確保しておいて、ラインが３つだけなら、１０個のフィールドのうち３つだけ使って残り７つのフィールドは空けておくようなデータ管理とは、その点が異なっている。ＸＭＬ文書はこのような半構造化データを記述する性質を持っているのである。
【００３５】
ＸＭＬ文書は、ツリー構造によるデータ管理を行なっているので、ツリー構造を取り扱う数学理論により、ＸＭＬ文書を処理するコンピュータプログラムの自動生成、その演算処理に必要な計算機資源量の把握など、省力化と、いわゆるバグの入り込みにくいソフトウェア高品質化を実現できる可能性が高い。
【００３６】
ＸＭＬ化部１１では、図３に示す配列をもとにしてＸＭＬ文書形式のデータを生成する。このアルゴリズムは非常に単純で、デバイス指定パラメータの文字列と、それに対応する値の文字列を配列から読み出して、ＸＭＬのタグで挟んで出力するだけである。ＸＭＬのタグ名は予め定めておいたものである。図４はＸＭＬ化部１１から出力されたＸＭＬ文書形式のデータの一例を表している。図４からわかるとおり、制御装置Ａのいくつかのデバイスと、その値が、＜ｄｅｖｉｃｅ＞タグを用いて表現されている。
【００３７】
つぎに図４に示すＸＭＬ文書形式のデータはＸＭＬ変換部１２に入力される。ＸＭＬ変換部１２はＸＳＬ（ｔｈｅ ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ ｓｈｅｅｔ Ｌａｎｇｕａｇｅ）文書１３のＸＳＬデータを予め、もしくは図４に示すＸＭＬ文書形式のデータが入力された直後に読み込む動作を行なう。ＸＳＬデータとはインターネット関連技術の標準規約団体であるＷ３Ｃにてその仕様が規定されたＸＭＬ文書の変換ルールの記述方式であり、例えば、
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｓｔｙｌｅ／ＸＳＬ／
で、その仕様の詳細を知ることができる。
【００３８】
簡単には例えば次のようなルールが記述される。図４に示したようなＸＭＬ文書形式のデータの中からｄｅｖｉｃｅタグのうち、パラメータ部分にＤデバイスが記述されているタグで挟まれたデータを取り出して、それらの和をとって、＜生産量＞＜／生産量＞というタグで挟んで出力する、といったルールである。図４のＸＭＬ文書形式のデータこのルールを適用すると、ＤデバイスのタグはＤ０１、Ｄ０２、Ｄ０３の３つあり、タグで挟まれたデータはそれぞれ１２、３、８であるから、それらの和は２３となり、＜生産量＞２３＜／生産量＞というＸＭＬ文書が得られることになり、ＸＭＬ変換部１２の出力であるＸＭＬ文書１４は、＜生産量＞２３＜／生産量＞という内容を持つことになる。
【００３９】
上述した方式によれば、Ｄデバイスの数に変化があってもすべてのＤデバイスの値が取り出されて、足し算が行われる効果がある。勿論、予め、どのＤデバイスを加えるかを決めておくこともできるので、いずれか都合の良いほうを選択することになる。
【００４０】
つぎに上述したようにして作成されたＸＭＬ文書１４を読み込んだ通信アプリケーション部１５は、予め定められた通信プロトコル（通信手順）を用いて上位情報系アプリケーションソフトウェア５にＸＭＬ文書１４を送信する。通信プロトコルについては、独自のもの、標準的なものを含め、さまざまなものが利用可能である。例えば、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）、ＩＭＡＰ（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）に代表される基本的なプロトコルと、これら基本プロトコルを用いた応用プロトコルとしてＳＯＡＰ（特に略したものではない固有名詞）、或いは独自のものとしてリレーショナル・データベースで用いられるＳＱＬのリモート手順、Ｊａｖａ（登録商標）−ＲＭＩ、ＭＳ社ＤＣＯＭなどの分散オブジェクトの通信手順などが利用可能である。
【００４１】
通信相手のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の違い、通信ソフトウェアの開発言語の違いの吸収、通信路の関係からＨＴＴＰプロトコル上でＳＯＡＰを利用することが好適であり、本実施の形態１ではこのＨＴＴＰプロトコル上のＳＯＡＰを使う例で説明する。勿論、目的はＸＭＬ文書１４を上位情報系アプリケーションソフトウェア５に送り届けることであるので、これらの通信手順のどれを用いても目的は達成される。
【００４２】
通信プロトコルが決まったとしても、通信アプリケーション部１５が通信プロトコル上のクライアントとなる場合と、通信プロトコル上のサーバとなる場合のいずれをも選択できるのであるが、どちらにするか決める必要がある。本実施の形態１では、通信プロトコル上のクライアントとする場合で説明する。
【００４３】
ＳＯＡＰでは、送信したいデータをＳＯＡＰボディーと呼ばれる書式で文書として記述することになっている。今回送りたいのはＸＭＬ文書１４であり、すでに文書になっているので、そのままＳＯＡＰボディーそのものとして送ることができる。もちろん上位情報系アプリケーションソフトウェア５が所定のＳＯＡＰボディー書式を使うことにしている場合は、それに合わせて書き換えればよいのであるが、本実施の形態１ではこの書き換えはＸＭＬ変換部１２で行うことにしており、ＸＭＬ文書１４をＳＯＡＰボディーとしてそのまま送ることにする。
【００４４】
本実施の形態１においては上位情報系アプリケーションソフトウェア５と通信アプリケーション部１５はｈｔｔｐプロトコルを用いてデータ通信を行なう。その概要は上位情報系アプリケーションソフトウェア５ではＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と呼ばれる書式により、これから説明するＳＯＡＰによるデータの受け取り口を、予め定めておく。例えば、「ｐｕｔＯｕｔｐｕｔＳｕｍ」というように決めておく。また、ＬＡＮ８において、これら通信情報変換装置１や上位情報系アプリケーションソフトウェア５を実行している上位情報系コンピュータ４のＬＡＮ８上での識別名も予め定めておく。ＬＡＮ８上の識別名とは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスかホスト名のことをさしている。
【００４５】
このとき、上位情報系コンピュータ４のホスト名が、「Ｍａｓｔｅｒ」と定められていたとする。この状態で通信アプリケーション部１５は、上位情報系アプリケーションソフトウェア５に対してデータの送信を行なうとき、まずＴＣＰ（Ｔｒａｎｓｍｉｓｓｈｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ソケットとよばれる仮想的な通信チャンネルをこれら２者の間に張る。通信アプリケーション部１５におけるコンピュータプログラムはＴＣＰのソケットをオープンする。その際、「Ｍａｓｔｅｒ」の８０番ポートに向けてソケットを張る旨をパラメータとして記述する。ＴＣＰソケットが張られた後は、データを送受することができるようになるので、通信アプリケーション部１５は、つぎのようにデータを送る。
【００４６】
なお、途中の略した部分に図４のＸＭＬ文書１４のデータが送られてくる。
【００４７】
このデータ送信が成功すると、上位情報系アプリケーションソフトウェア５からＯＫという返答につづき、「ｐｕｔＯｕｔｐｕｔＳｕｍ」という生産量受け取り手順の実行が成功したことを表すデータを返す。これらの手順により、通信アプリケーション部１５から上位情報系アプリケーションソフトウェア５に対してデータの送信が完了する。
【００４８】
さて、上記の実施の形態１では生産量を合計するため、３つの整数値を加える例について説明したが、さらに複雑な別の実施の形態について述べる。生産設備で利用される制御装置２はいわゆるシーケンサと呼ばれるリレー回路を電子的に置き換えて生産設備の動きをシーケンス制御している。このシーケンサの基本的な入出力単位は１ビット（リレー回路を置き換えているので、ＯＮとＯＦＦの状態を表している）である。このような１ビットの接点を８本集めてきて、生産個数をカウントする整数値を表現することが行われている。このいわば見做し整数値を読み出したいときには、例えば図３に示すＸ０１からＸ０８までの１ビットを８本集めて整数値とみなしてワード型デバイスのＤ０１に整数値を書き込むシーケンスプログラム（ラダープログラム）を記述していたのである。
【００４９】
本実施の形態１では、ラダープログラムを記述することなく、ＸＭＬ変換部１２において、
という演算を行なうことを、ＸＳＬ文書１３に記述することで代行することができる。
【００５０】
生産設備が完成して稼動を始めた後に、上位情報系アプリケーションソフトウェア５でこのような値が必要になったとき、従来ならラダープログラミングのできるプログラマーでなければ対応できなかった。通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費と工期の面で不利であった。これに対し、ＸＳＬ文書１３を書き換える作業は、上位情報系プログラマーが簡単にすばやく作業できる効果がある。なお、従来例のように単にデバイスに向けてリンクを張るだけではこのような演算操作は行えなかった。
【００５１】
この例では１ビットを８本集めることを説明したが、これとは逆に生産設備上の要求から、生産設備の動作状態を表すビットデータを複数集めてワードデータにする場合がある。このような複数の情報がパックされたワードデータの中から、１ビットだけ読み出したいことがある。従来はこれを行なうためにラダープログラムが必要であったが、本実施の形態１によればＸＳＬ文書１３中に、いわゆるビットマスク演算を行うことを記述すれば実現できることになる。上述したようにラダープログラマーと上位情報系プログラマーを同時に稼動させ人件費と工期の面で改善され、上位情報系プログラマーのみで簡単にすばやく作業できる効果がある。従来のように単にデバイスに向けてリンクを張るだけではこのような演算操作は行えないものであった。
【００５２】
さて、以上述べてきたデータ収集部９、ＸＭＬ化部１１、ＸＭＬ変換部１２、通信アプリケーション部１５の一連の動作は、全体制御部１６が動作させる部位の順番と動作タイミングを制御して行われている。本実施の形態１では、図５に示すようなフローチャートに従っている。図中、左側（ＳＴＡＲＴ▲１▼、以下同様）が通信情報変換装置１の全体制御部１６の動きを、また右側（ＳＴＡＲＴ▲２▼、以下同様）が上位情報系アプリケーションソフトウェア５においてデータの送受信に関する部分のみの手順を現している。
【００５３】
まず上位情報系アプリケーションソフトウェア５の受信手順が開始され、受信待ちに入る（ステップＳＴ５０１）。即ち、図５の右側である。つぎに全体制御部１６は、予め定められた一定周期、例えば１時間に１回などの周期で図５の左側の手順を実行する。まずデータ収集部９を動かして、収集データ指定を読み込み（ステップＳＴ５０２）、その指定内容にしたがって、制御装置２からデータを集める（ステップＳＴ５０３）。
【００５４】
つぎにＸＭＬ化部１１を動かしＸＭＬデータを作成する（ステップＳＴ５０４）。つぎにＸＭＬ変換部１２を動かして、ＸＳＬ文書１３を読み込んで（ステップＳＴ５０５）、ＸＭＬデータを変換しＸＭＬ文書１４を作成して通信アプリケーション部１５へと出力する（ステップＳＴ５０６）。つぎに通信アプリケーション部１５を動かして、上位情報系アプリケーションソフトウェア５と通信ソケットを張り（ステップＳＴ５０７）、ＸＭＬ文書１４を読み込み（ステップＳＴ５０８）、データを送信し（ステップＳＴ５０９）、結果を受信する（ステップＳＴ５１０）。
【００５５】
一方、ステップＳＴ５０７の手順を受けて上位情報系アプリケーションソフトウェア５は、ソケットを許可し（ステップＳＴ５１１）、ステップＳＴ５０９に呼応してデータを受信し（ステップＳＴ５１２）、それが完了すると受信結果を送信する（ステップＳＴ５１３）。以上で動作が完了する。
【００５６】
なお、この実施の形態１においては、ＸＳＬ文書１３、収集データ指定文書１０を書き換えることで上位情報系アプリケーション５の指定するデータフォーマットおよび内容に対応することが可能となる。
【００５７】
以上説明したように実施の形態１によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。
【００５８】
また、制御装置の動作状態を表すデータであるが、制御装置がＰＬＣ（プログラマブルロジックコントローラー）のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を８個まとめて１バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという問題点を解決できる効果が得られる。
【００５９】
実施の形態２．
この発明の実施の形態２について図６〜図８を参照して説明する。なお、図６は実施の形態２に係る通信情報変換装置の構成を示す図であり、図７は実施の形態２の通信情報変換装置の動作を説明するための図であり、また、図８は実施の形態２の通信情報変換装置の動作を示すフローチャートである。
【００６０】
実施の形態１おいては収集データ指定文書１０により指定されたデータが収集され、図３に示すように、どのデバイスであるかを示すデバイス指定パラメータとその値の配列が作成されていた。本実施の形態２においては、図６に示すように実施の形態１の動作のように図３に示す配列が得られた後、論理名−物理名変換部１７が変換テーブル１８を読み込んで、図３に示すような配列を図７に示す配列に書き換える動作が追加されている。この場合に全体制御部１６の動作は、データ収集部９を動かした後、論理名−物理名変換部１７を動かし、その後にＸＭＬ化部１１を動かすことになる。
【００６１】
この論理名−物理名変換部１７の動作について説明すると、制御装置２のデバイスと論理名が１対１に対応する場合には、変換テーブル１８は、例えば、
ライン１の生産量＝制御装置Ａ．Ｄ０１
ライン２の生産量＝制御装置Ａ．Ｄ０２
ライン３の生産量＝制御装置Ａ．Ｄ０３
等のような対応関係を記述する。さらに、実施の形態１で説明したように複数のビットデバイスをまとめて整数値として取り扱う場合や、集計を行う場合にはそのような演算が記述される。例えば、次のような記述がなされる。
全体生産量＝制御装置Ａ．Ｄ０１＋制御装置Ａ．Ｄ０２＋制御装置Ａ．Ｄ０３
【００６２】
そして、本実施の形態２におけるＸＳＬ文書１３は、実施の形態１においてデバイス名を記述していた部分が論理名で書けばよいことになり、人間にとっては記述しやすくなり、間違いが起こりにくいという効果が得られる。
【００６３】
なお、本実施の形態２では変換テーブル１８を数式のような形態で記述する例を示したが、この変換規則をＸＭＬで記述しても同様の効果が得られる。そのＸＭＬは、例えばつぎのようなものである。
【００６４】
なお、ＸＭＬで変換規則を記述した場合に、全体制御部１６よる各部の動かし方を変更することもできる。この場合、収集データ指定文書１０は不要となる。
【００６５】
つぎにこの場合の全体制御部１６の動作について図８のフローチャートに沿って説明する。まず、論理名−物理名変換部１７を動かし、変換テーブル１８を読み込む（ステップＳＴ８０１）。ここで、制御装置からどのデバイスの値を集めればよいかがわかるので収集データ指定文書１０は不要となるのである。この、どのデータを集めるかは論理名−物理名変換部１７により抽出され、データ収集部９に送られ、収集動作が行われる（ステップＳＴ８０２）。これ以降は図５の動作と同等であるので説明は省略する。
【００６６】
なお、どのデータを集めるかの抽出は、変換テーブル１８の中からデバイスを指定する文字列を切り出す方法を用いることができる。さらに別の方法として、Ｘｐａｔｈ、Ｘｌｉｎｋと呼ばれる規約に従った記述を変換テーブル１８にて行っておき、論理名−物理名変換部１７において、Ｘｐａｔｈの記述を処理して、データを取り出すべきデバイスがわかるたびに、データ収集部９を動かしてデータを収集する方法を用いることもできる。この場合、収集データ指定文書１０は不要である。
【００６７】
この実施の形態２においては、ＸＳＬ文書１３、変換テーブル１８、収集データ指定文書１０を書き換えることで上位情報系アプリケーションソフトウェア５の指定するデータフォーマットおよび内容に対応することが可能となる。
【００６８】
以上説明したように実施の形態２によれば、デバイス名を記述していた部分が論理名で書けばよいことになり、人間にとってはわかりやすいので記述しやすくなり、間違いが起こりにくいという効果が得られる。
【００６９】
実施の形態３．
この発明の実施の形態３について図９〜図１１を参照して説明する。なお、図９は本発明の実施の形態３に係る通信情報変換装置の構成を示す図であり、図１０は実施の形態３の通信情報変換装置の動作を説明するためのスクリプトプログラムであり、また、図１１は実施の形態３の通信情報変換装置の動作を示すフローチャートである。
【００７０】
実施の形態３に係る通信情報変換装置は図９に示す構成であって、スクリプト処理部１９はスクリプトプログラム２０を読み込んで、このプログラムに基づく動作を行なうよう構成されている。ここでいうスクリプト処理部は、Ｐｅｒｌ、Ｒｕｂｙ、ｂｓｈ、ＥＣＭＡ Ｓｃｒｉｐｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ（ＪＳｃｒｉｐｔ）、ＶＢｓｃｒｉｐｔ、Ｗｉｎｄｏｗｓ（登録商標） Ｓｃｒｉｐｔｉｎｇ Ｈｏｓｔ、ａｗｋ、或いは三菱電機株式会社製のグラフィックオペレーションターミナルＧＯＴシリーズにおけるＧＯＴスクリプト、ＭＳ−ＤＯＳのバッチコマンドなど、簡単なロジックとシーケンスを記述して処理を実現できるようにした簡易プログラミング言語の処理系のことを指している。
【００７１】
ただし、
（１）制御装置２のデバイスを指定し、その値を取得できる書式もしくは組み込み関数もしくは外部手続きの呼び出しする機能
（２）ファイルもしくはメモリ上もしくは標準出力などのファイルストリームに文字列を出力する機能
の２つの機能を最低限装備しておく必要がある。
【００７２】
このとき、本実施の形態の通信情報変換装置１は、例えば図１０に示すスクリプトプログラム２０に従って次のように動作する。図１０中、「ｐｒｉｎｔｆ」というのは標準出力ストリームに文字列を、書式付きで出力する命令文を示している。また、「制御装置（２）．ｄ（０１）」というのは制御装置２のデバイスを指定し、その値を取得できる組み込み関数である。
【００７３】
図１０に示したスクリプトプログラムは各行が順番に実行される。まず１行目ではＸＭＬ文書の開始を表す文言が出力される。次の行では「＜生産量＞」というＸＭＬの開始タグが出力される。次の行では２という制御装置の、０１というｄデバイスから値が読み出され、同様に０２というｄデバイス、０３というｄデバイスから値が読み出され、読み出された３つの値の和が求められ、その値が整数値として文字列で出力される。デバイスから値が読み出される際にはデータ収集部９を動作させることにより、制御装置２からデータが収集され、その値を読み出すことができる。
【００７４】
その次の行では、「＜／生産量＞」という終了タグが出力されている。なお、各行の「￥ｎ」とは改行文字をあらわしている。結局、図１０に示したスクリプトプログラムの実行結果は次のようなＸＭＬ文書が生成される。これが図９におけるＸＭＬ文書１４である。
【００７５】
＜？ＸＭＬ ｖｅｒｓｉｏｎ＝“１．０” ？＞
＜生産量＞
１２３
＜／生産量＞
【００７６】
このようにして、制御装置２のデバイスのデータの値を含んで生成されたＸＭＬ文書１４は、通信アプリケーション部１５を用いて、上位情報系アプリケーションソフトウェア５に送信される。詳細な説明は実施の形態１と同様であるので省略する。
【００７７】
これら一連の手順の制御は全体制御部１６により行われる。この手順は図１１に示すように、まず全体制御部１６はスクリプト処理部１９を動作させる。スクリプト処理部１９はスクリプトプログラム２０を読み込み（ステップＳＴ１１０１）、このスクリプトプログラム２０に記述された内容を解釈して実行し（ステップＳＴ１１０２）、ＸＭＬ文書１４が生成される（ステップＳＴ１１０３）。このときデータ収集部９は必要になったときに用いられる（ステップＳＴ１１０４）。つぎに全体制御部１６は通信アプリケーション部１５を動かしてＸＭＬ文書１４を上位情報系アプリケーションソフトウェア５に送出する（ステップＳＴ１１０５〜ステップＳＴ１１８）。
【００７８】
以上説明したように実施の形態３によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。さらに、制御装置の動作状態を表すデータは、制御装置がＰＬＣ（プログラマブルロジックコントローラー）のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を８個まとめて１バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという従来の問題点を解決できる効果が得られる。
【００７９】
実施の形態４．
この発明の実施の形態４について図１２および図１３を参照して説明する。なお、図１２は本発明の実施の形態４に係る通信情報変換装置の構成を示す図であり、図１３は実施の形態４の他の通信情報変換装置の構成を示す図である。
【００８０】
図１２に示すよう実施の形態４は、上述した実施の形態１〜３と同様に各部の動きは全体制御部１６により制御されている。そして、スクリプト処理部１９を用いてスクリプトプログラム２０に記載された内容を実行してＸＭＬ文書１４を生成し、通信アプリケーション部１５を用いて上位情報系アプリケーションソフトウェア５にＸＭＬ文書１４を送る動作を行なう。
【００８１】
このとき、データ収集部９を用いて制御装置２からデバイスのデータを集めると同時に、時計部２１、グローバル変数部２２を動かすことにより、制御装置２のデバイスの値を読み出すことのみでは得られない情報を作ることができる。例えば、あるデバイスがＯＦＦ状態からＯＮ状態に変化した時刻、或いはあるデバイスがＯＦＦ状態からＯＮ状態に変化した瞬間から、再びＯＦＦ状態に変化するまでの時間の長さである。
【００８２】
これらが必要になるのは本発明の主題である上位情報系アプリケーションソフトウェア５において生産状態の管理を行なうための情報を生産ラインから抽出するときである。上記ではその情報はデバイスの値を読むだけでは得ることができないとしていた。従来例にあるようなツリー間リンクでは得ることはできないので、制御装置においてプログラミングして作り出しているのである。このとき、従来の方式であればラダープログラミングのできるプログラマーでなければ対応できないが、通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費や工期が増大するものであった。
【００８３】
本実施の形態４では、このように上位情報系アプリケーションソフトウェアで生産管理、品質管理、稼動管理を行なう際に必要となるデータであって、従来はラダープログラミングすることで生成していたデータを、ラダープログラミング不要で生成するための機能部を設けることを特徴としている。
【００８４】
まず時計部２１の動きについて説明する。時計部の機能は２つある。ひとつはタイムスタンプ機能である。もうひとつはストップウォッチ機能である。タイムスタンプ機能はスクリプト処理部１９にてこの機能を呼び出した瞬間の時刻を返答する機能である。スクリプト処理部１９ではこれにより、次のようなときにその瞬間の時刻情報を得ることができ、その時刻情報を上位情報系アプリケーションソフトウェア５に送ることができる。第一に上位情報系アプリケーションソフトウェア５に送るＸＭＬ文書１４を生成した時刻であり、第二に制御装置２のあるデバイスの状態が変化した瞬間の時刻である（ただしスクリプト処理部１９はあるデバイスの変化を監視するタスクもしくはプロセスもしくはスレッドを実行しているものとする）。
【００８５】
さらにストップウォッチ機能であるが、ストップウォッチによる計測を開始する、停止する、ラップする（一時停止）、リセットする、計時時間を読み出すといった手続きを有している。ストップウォッチ機能は複数のストップウォッチを同時に独立して動かすことができる。このストップウォッチ機能により、制御装置２のあるデバイスがＯＮに変化した瞬間にストップウォッチを計時開始し、ＯＦＦに変化した瞬間に計時停止することで、あるデバイスがＯＮしていた時間の長さを計測することができ、それを読み出す手続きを経ることで上位情報系アプリケーションソフトウェア５に送るＸＭＬ文書１４にこの時間長さを含めることができる。
【００８６】
つぎにグローバル変数部２２について説明する。これは主として制御装置２のデバイスの値の変化を積算もしくは微分計算、移動平均、算術平均などの演算処理を実現する目的で設けられている。例えば生産ラインで処理したワークの個数を数えるのに、ワークを１個処理したときに変化するデバイスの変化回数を積算するために利用する。スクリプトプログラム２０の処理が終了し、その後スクリプトプログラム２０の処理が再び開始されたときにも前回の結果を残しておくことにも利用できる。
【００８７】
これらの処理は予め制御装置２においてラダープログラミングしておけば生成することはできるのであるが、あとからそのような情報がほしいことがわかったときにラダープログラミングのできるプログラマーでなければ対応できない。通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費と工期が増大するものであった。
【００８８】
またグローバル変数部２２には、状態遷移モデル機能或いは階層的エラー状態モデルを含めることも可能であり、これを含めた場合の動作を説明する。
まず状態遷移モデルであるが、例えば米国の電子産業業界団体のＩＰＣ（ｈｔｔｐ：／／ｗｗｗ．ｉｐｃ．ｏｒｇ／）が定めた製造現場の組み立て機器間の通信メッセージの規約ＩＰＣ−２５４１における装置の状態遷移モデルのことを指している。
【００８９】
例えば製造装置が電源停止状態から準備状態に移行し、ワークが流れてこないので止まっている、下流工程が詰まっているので止まっている、ワークを加工している、障害が発生している、などの各状態間を遷移していくというモデルである。ＩＰＣ−２５４１の規約ではこのような状態遷移モデルの標準仕様を定めている。このような標準的なモデルをたてる目的は、メーカーや目的、作業内容の異なる現場機器を統一的に上位情報系で扱って、管理手法の比較、最適化などを行なうことにある。
【００９０】
この発明においてはグローバル変数部２２にこのＩＰＣ−２５４１の状態遷移の各状態を製造装置ごとに保持する。そして、この標準化モデルの各状態と、実際の制御装置における複数のデバイスの値の組み合わせを関連付けておき、実際の制御装置２の複数のデバイスの値の組み合わせが変化したとき、標準化モデルの状態も遷移するように構成する。しかるのち、スクリプト処理部１９から現在の標準化モデルの遷移の状態を読み出してＸＭＬ文書１４に含めたり、或いは遷移が起きたときにＸＭＬ文書１４の生成を開始することが可能となる。
【００９１】
つぎに階層的エラーモデルであるが、品質管理、稼動管理の目的で、生産設備のエラー状態を細かく分類し障害要因を複雑な階層型に分類することが一般的になりつつある。このような複雑な階層型に分類された障害要因モデルと、実際の制御装置の複数のデバイスの値とを関連付けておき、複数のデバイスの値が一致したときにひとつの障害が発生したことにする。しかるのち、スクリプト処理部１９から現在の障害要因モデルの状態を読み出してＸＭＬ文書１４に含めたり、或いは障害が起きたときにＸＭＬ文書１４の生成を開始することが可能となる。
【００９２】
なお、システム変数部２３を設けることもできる。この場合は、上位情報系アプリケーションソフトウェア５との通信にＳＯＡＰの手順を用いる際の上位側からのリクエストメッセージに含まれるリクエストヘッダと呼ばれる文字列、とりわけメッセージＩＤを格納したり、通信情報変換装置のホスト名、リクエストを発行したホスト名、メッセージ番号（読み出すごとに自動生成される）、その他通信情報変換装置ごとに異なる固有情報を読み出すことが可能な変数が複数格納されており、それを読み出して、ＸＭＬ文書１４に含めるような動作を行なうことが可能となる。
【００９３】
実施の形態４の他の実施の形態について説明する。図１３に示すように、この実施の形態はＸＳＬ文書１３によりＸＭＬ変換を行なってＸＭＬ文書１４を生成している。この場合は先の例でスクリプト処理部１９が行なうこととしていた処理、例えばストップウォッチによる計時を開始したり停止したりする処理を行なうためのデータ１次処理部２４を設けている。
【００９４】
この実施の形態４によれば、従来であればラダープログラミングの必要な場面であってもラダープログラミングすることなく、上位情報系アプリケーションソフトウェアで必要な情報を収集し生成することが可能となるので、情報システム構築の工数、費用、期間が短縮される効果がある。また、従来では上位情報系から制御装置に対し、いわゆるポーリングを実行することでデバイスの変化している時間を計ることも可能ではあるが、ポーリング時間間隔以上の時間制度が得られず、この発明によればポーリング不要で時間精度も向上する効果がある。
【００９５】
実施の形態５．
この発明の実施の形態５について図１４〜図１６を参照して説明する。なお、図１４は本発明の実施の形態５に係る通信情報変換装置の構成を示す図であり、図１５は実施の形態５の通信情報変換装置の動作を説明するための図であり、図１６は実施の形態５の他の通信情報変換装置の構成を示す図である。
【００９６】
図１４に示すようにこの実施の形態５の通信情報変換装置には、スクリプト埋め込みＸＭＬ文書２６が用意される。用意するとはプログラマーがテキストエディターなどを用いてこのスクリプト埋め込みＸＭＬ文書を記述し、記述完了した後、通信情報変換装置に組み込んでおくという意味である。
【００９７】
このスクリプト埋め込みＸＭＬ文書２６は図１５に示すように、全体的にはＸＭＬ文書である。そしてその一部（「＜％」 と 「％＞」で囲まれた部分）に実施の形態３で述べたようなスクリプトの文が記述されていることがわかる。プログラマーの視点からは、通信情報変換装置１にて最終的に生成したいＸＭＬ文書１４のなかで、制御装置２から直接得たデバイスの値、或いはデバイスから得た値を演算して得られるデータ、或いは実施の形態４で説明したデータを含めたい部分について、そのデータを取得もしくは生成するためのスクリプトを埋め込むことができるとみなすことができるものである。
【００９８】
さて、スクリプト埋め込みＸＭＬ文書２６はスクリプト化部２７に読み込まれて処理が行われる。ＸＭＬ文書として書かれている部分は、その文字列を出力するためのスクリプトプログラムに書き換えられる。例えば、「＜生産量＞」というタグの部分は、「ｐｒｉｎｔｆ（“＜生産量＞”）；」というように書き換えられる。「＜％」と「％＞」で囲まれた部分はなんら処理されない。以上の結果、スクリプト化部２７からの出力は、図１０で示したスクリプトプログラムと同一のものになる。これ以降の動作は実施の形態３と同じであるので省略する。
【００９９】
また、図１６に示すように、時計部２１、グローバル変数部２２、システム変数部２３を設けることで、制御装置のデバイスの値を読み出すことのみでは得られない情報を作ることができる。これらの部分の動作は実施の形態４と同一のものであるので省略する。
【０１００】
以上説明したように実施の形態５によれば、プログラミングをスクリプト埋め込みＸＭＬ文書２６を記述することで情報変換を行なうことができる。これは上位情報系アプリケーションソフトウェア５が要求するＸＭＬ文書の形式のうち、実データで置き換える部分についてスクリプトプログラミングすればよいということである。したがって、プログラミング効率が向上する効果が得られる。時計部２１、グローバル変数部２２、システム変数部２３を設けた場合は、予めデータを生成する機能が用意されており、それについてはプログラミング不要であるので、さらにプログラミング効率が向上する効果が得られる。
【０１０１】
実施の形態６．
この発明の実施の形態６について図１７および図１８を参照して説明する。なお、図１７および図１８はこの本発明の実施の形態６に係る通信情報変換装置の動作を説明するための図である。
【０１０２】
図１に示すように通信情報変換装置１から上位情報系コンピュータ４にＸＭＬ文書１４を送ることを考えると、図１７に示す実施の形態６においては、送り側７０における元データ２８が、送られて、受け取り側７１における元データ２９になることをあらわしている。このとき、送信中の通信路、例えばＬＡＮ８上でのデータフォーマットとしてバイナリーＸＭＬ３０を用いることをこの実施の形態６は特徴としている。
【０１０３】
つぎに、元データ２８、２９が２つの整数と１つの浮動少数の値を含んでいる例について説明する。このとき、例えば元データ２８、２９は、
＜生産番号＞１２３＜／生産番号＞
＜加工結果測定値＞２３４．５６７＜／加工結果測定値＞
＜累積生産個数＞２３４５６＜／累積生産個数＞
であるとする。
【０１０４】
ここで、このようなＸＭＬ文書の元データ２８に対し、この発明を適用しバイナリーＸＭＬを用いる例について説明する。バイナリーＸＭＬ３０としては、図１７に示すように、４バイト、８バイト、４バイトの、合計１６バイトのデータ並びとして表現することにしてみる。もちろんデータのバイト長さは、取り扱うデータの変動範囲を十分に表せるように選択することはいうまでもない。
【０１０５】
このとき先頭から４バイトが整数値で、ＸＭＬのタグは「＜生産番号＞」であること、そのつぎの８バイトが不動小数点の値で、ＸＭＬのタグは「＜加工測定結果＞」であること、そのつぎの４バイトが整数値でＸＭＬのタグは「＜累積生産個数＞」であること、バイト並びのいわゆるエンディアンの大小を記述したフォーマット定義ＸＭＬ文書３１が用意しておく。これにより、バイナリーＸＭＬ３０と元データ２８および２９は、エンコード部３２およびデコード部３３により一意に相互変換可能となる。
【０１０６】
このときのフォーマット定義ＸＭＬ文書３１を図１８に示す。図中「＜ｄａｔａ＞」と記述された部分が３つあり、それぞれが上記の３つのデータの名称、バイト長さ、エンディアン、変数型を定義していることがわかる。
【０１０７】
なお、上記実施例では送信側の元データ２８のＸＭＬ文書からエンコード部３２を介してバイナリーＸＭＬ３０をエンコードすることにしているが、送り側でＸＭＬ文書の元データ２８を作ることなく直接バイナリーＸＭＬ３０を生成して送信することも可能である。この場合は送り出し側にＸＭＬ生成機能を搭載せず、直接制御装置のメモリマップの一部を送出すれば良いということになる。その際、そのメモリマップの中身をフォーマット定義ＸＭＬ文書にて記述すればよい。
【０１０８】
以上説明したように実施の形態６によれば、通信情報変換装置から上位情報系の計算機にデータを送信する際、数秒、数百ミリ秒、数十ミリ秒といった短い間隙で送信する場合には、１回の送信データ量が増えるにしたがって、通信路のバンド幅を埋め尽くす可能性に対して、これを減らすことができる効果がある。また、ＣＰＵ能力、メモリ容量に対して制限の多い制御装置においてテキスト型のＸＭＬ文書を生成しなくても自身のメモリマップの該当する箇所をそのまま切り出して送ればよいのでＣＰＵ、メモリに負荷をかけずに目的を果たせる効果がある。
【０１０９】
実施の形態７．
この発明の実施の形態７について図１９および図２０を参照して説明する。なお、図１９はこの発明の実施の形態７に係る通信情報変換装置の構成を示す図であり、図２０は実施の形態７の通信情報変換装置の動作を説明するための図である。
【０１１０】
図１９において全体制御部１６が各部を順次作動させる。まずデータ収集部９を用いて制御装置２からデータが収集される。つぎに通信アプリケーション部１５が用いられ、上位情報系アプリケーションソフトウェア５へのデータ送信が試みられる。このときこの実施の形態７においては通信アプリケーション部１５の構成として送信キューイング部３４と送信キュー部３５を備えたことを特徴とする。
【０１１１】
図２０に示すフローチャートに沿って実施の形態７に係る通信情報変換装置の動きを説明する。図２０中、２つのシーケンスからなることが示されているが、まず左側のシーケンス（ＳＴＡＲＴ▲３▼）を説明する。データ収集部９がデータを集め（ステップＳＴ２００１）、送信キューイング部３４が上位情報系アプリケーションソフトウェア５へデータを送信する（ステップＳＴ２００２）、このとき、送信が完了したかどうかの判定が行われ（ステップＳＴ２００３）、送信が完了しておれば、シーケンスは完了する。
【０１１２】
一方、完了していない場合は、送信キュー部３５に送ることができなかったデータが格納される（ステップＳＴ２００４）。完了していない場合とは、途中の通信路、この実施の形態７ではＬＡＮ８であるが、この通信路に障害が発生して、データ通信できなくなっている場合か、或いは上位情報系アプリケーションソフトウェア５自体か、またはこれを実行している上位情報系コンピュータ４に障害が発生しておりデータを受け取れない場合等がある。
【０１１３】
つぎに図２０の右側のシーケンス（ＳＴＡＲＴ▲４▼）について説明する。まず送信キューイング部３４を用いて送信キュー部３５に蓄えられているデータをひとつ取り出す（ステップＳＴ２００５）。ここで取り出せたかどうかの判定を行なう（ステップＳＴ２００６）。もし、なにもデータが蓄えられておらず、取り出すことができない場合は終了する。ひとつ取り出すことに成功した場合はデータ送信を行なう（ステップＳＴ２００７）。そして送信が完了したかどうかを判定し（ステップＳＴ２００８）、完了した場合は、そのデータを送信キュー部３５から削除する（ステップＳＴ２００９）。その後、再び最初に戻る。送信に失敗した場合はそのデータを再格納して（ステップＳＴ２０１０）、ステップＳＴ２００５に戻る。
【０１１４】
送信キュー部３５に格納するデータは、この例ではデータそのものを格納している。これは送信先の上位情報系アプリケーションソフトウェア５がひとつだけであるからである。上位情報系アプリケーションソフトウェアが複数あるときには、その送信先とデータとを組み合わせたものを送信キュー部３５に格納すれば対応できる。
【０１１５】
図２０におけるシーケンスは２つあることを説明したが、これら２つは全体制御部１６により、その開始が決定されている。左側のシーケンスは、一定周期或いは上位情報系アプリケーションソフトウェア５からリクエストがあったとき、制御装置２で予め定めておいたイベントが発生したとき（往々にして障害が発生したときに報告したいことがある）に実行される。右側のシーケンスは一定周期で実行開始される。
【０１１６】
以上説明したように実施の形態７によれば、上位情報系アプリケーションソフトウェア５或いはＬＡＮ８に障害が発生したときに、送信を後回しにすることが可能となるのでデータが遺失しない通信情報変換装置が得られる効果がある。
【０１１７】
実施の形態８．
この発明の実施の形態８について図２１を参照して説明する。なお、図２１はこの発明の実施の形態８に係る通信情報変換装置の構成を示す図である。
【０１１８】
実施の形態８に係る通信情報変換装置は、プロトコル変換部３６と、データフォーマット変換部３７、物理現象−論理モデル変換部３８の３つの部分から構成されることを特徴としている。さらにこれらの３つの部分はそれぞれより具体的な構成部品を備える。なおこのような概要構成から各部詳細化にむかう設計手法はオブジェクト指向プログラミングにより、実際にソフトウェア開発可能である。
【０１１９】
３つの部分を順に説明する。まず、プロトコル変換部３６の目的は他システム５５、すなわち上位情報系アプリケーションソフトウェア５および制御装置２と、この発明の通信情報変換装置の間で行われるデータ通信を処理するための部分である。
【０１２０】
上位情報系アプリケーションソフトウェア５および制御装置２の種類は数多く存在し、それと同時に、これら他システム５５とデータ通信するための手段が数多く必要となる。このときプロトコル変換部３６は、シリアル入出力部３９、ソケット入出力部４０、ＳＱＬクライアント４１、ＳＱＬサーバ４２、ＳＯＡＰサーバ４３、ｈｔｔｐクライアント４４、ｈｔｔｐサーバ４５、ｆｔｐクライアント４６、ｆｔｐサーバ４７、ＳＯＡＰクライアント４８、ＰＯＰ／ＩＭＡＰサーバ４９、制御装置入出力ライブラリ５０、制御装置クライアント５１、ｓｍｔｐクライアント５２といった通信クライアント機能および通信サーバ機能を持った詳細構成部を備えている。
【０１２１】
図２１においてはこれらのうち、ｈｔｔｐサーバ４５で上位情報系アプリケーションソフトウェア５と通信し、シリアル入出力部３９および制御装置入出力ライブラリ５０および制御装置クライアント５１で制御装置をデータ通信している。
データフォーマット変換部３７は、実施の形態１において説明したようなＸＭＬ文書１４の形式変換を行なう。
【０１２２】
物理現象−論理モデル変換部３８は実施の形態４で説明したように、制御装置２のデバイスがＯＮ状態にある時間を計ったり、複数のデバイスの値を集計するなどの演算を施したりする部分である。この実施の形態８では制御装置２から集められた生データ５３を直接およびデータ１次処理部５４にて上記のような演算処理を施した結果をデータフォーマット変換部３７に渡している。
【０１２３】
以上説明したように実施の形態８によれば、複数の種類の上位情報系アプリケーションソフトウェア５および制御装置２と通信可能で、かつデータのフォーマットも送り側のものから受け取り側が理解できる形式へ変換して通信できるとともに単なるデバイスのＯＮとＯＦＦなどで計測される物理現象を、上位情報系アプリケーションソフトウェア５で即刻用いることが可能な論理モデルにもとづくデータに変換することが可能な通信情報変換装置が得られる効果がある。
【０１２４】
さらに、通信プロトコルの変換、データフォーマットの変換、物理現象の論理モデルへのマッピングをそれぞれ独立してソフトウェアプログラミングできるので、通信相手の追加、利用したい論理モデルの変更、処理したいデータ追加などの機能の追加変更が容易に行えるという効果が得られる。
【０１２５】
実施の形態９．
この発明に係る実施の形態９について図２２を参照して説明する。なお、図２２は実施の形態９に係る通信情報変換装置の構成を示す図である。
【０１２６】
この実施の形態９の目的は制御装置２から例えば製造している製品の品質に関するデータ、具体的には各ワークごとの品質検査結果データなどを入出力するシリアル入出力部３９、制御装置入出力ライブラリ５０、制御装置クライアント５１を介して回収し、得られた生データ５３をそのまま、或いはデータ１次処理部５４を用いた処理の後、典型的な上位情報系アプリケーションソフトウェア５であるＲＤＢ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａ Ｂａｓｅ）システムに格納することにある。
【０１２７】
なおＲＤＢとは、全てのデータは関係演算と集合演算で扱うように設計されていて、データは２次元の表として考えられ、互いの表の関連をキーによって擬似的に結合することによって表現される。また、夫々の表はキーによって結ばれ、データの重複を省き効率的にデータ管理ができ、また、データ構造の変更に柔軟に対応することができるデータベースである。
【０１２８】
まず上位情報系アプリケーションソフトウェア５は、ＳＯＡＰサーバ４３により、通信情報変換装置１からのデータ登録を待っている。通信プロトコルはＳＯＡＰを利用することにする。ＳＯＡＰではいわゆるリモートプロシージャーコール、即ちネットワーク越しに通信相手のソフトウェアの機能を呼び出すことができるのであるが、この実施の形態９においてはＳＯＡＰを用いて上位情報系アプリケーションソフトウェア５におけるＯＤＢＣクライアント５６のデータ登録機能をリモートコンピュータから呼び出すことにしている。ここでのリモートコンピュータとは通信情報変換装置１のことである。通信情報変換装置１中のプロトコル変換部３６は、このためＳＯＡＰクライアント４８を備えている。
【０１２９】
ＳＯＡＰクライアント４８ではＳＯＡＰメッセージをＳＯＡＰサーバに送りつけて、その処理結果を受け取る動作を行なう。データフォーマット変換部３７では、生データをＲＤＢ部６１に登録するためのＳＯＡＰメッセージの生成が行われる。ここでの動作は実施の形態１で説明した動作であり、ＸＳＬ文書１３を用いて生データをＸＭＬ文書１４に変換する。ここでのＸＭＬ文書１４とはＳＯＡＰメッセージのことである。
【０１３０】
以上説明したように実施の形態９によれば、従来パソコンなどでいわゆるＳＣＡＤＡシステムを構成して制御装置２をポーリングすることでデータを回収し、上位情報系アプリケーションソフトウェア５にデータを送っていたが、実施の形態９では制御装置２と密結合した通信情報変換装置１を用いてデータを直送することができるため、上記ポーリング周期以上の頻度でデータ改修することできる効果がある。
【０１３１】
実施の形態１０．
この発明に実施の形態１０について図２３〜図２６を参照して説明する。なお、図２３は実施の形態１０に係る通信情報変換装置の構成を示す図であり、図２４は実施の形態１０に係る通信情報変換装置の他の構成を示す図である。また、図２５および図２６は実施の形態１０に係る通信情報変換装置の動作を説明するための図である。
【０１３２】
実施の形態１０では図２３に示すように、ＩＰＣ２５４Ｘモデル部５７を備えている。ＩＰＣ２５４Ｘとは、米国の電子産業業界団体のＩＰＣ（ｈｔｔｐ：／／ｗｗｗ．ｉｐｃ．ｏｒｇ／）が定めた製造現場の組み立て機器間の通信メッセージの規約のことを指しており、実施の形態４で説明している。
【０１３３】
図２５はＩＰＣ−２５４１が規定する製造装置の状態遷移の様子を表している。図２５からわかるように、製造装置は、Ｏｆｆ、Ｓｅｔｕｐ、Ｂｌｏｃｋｅｄ、Ｓｔａｒｖｅｄ、Ａｃｔｉｖｅ、Ｅｘｅｃｕｔｉｎｇ、Ｄｏｗｎという７つの状態を持つとしている。したがって、自分の製造装置もしくはその製造装置を制御している制御装置の状態をあらわすデータとして４ビット以上の値を観測すれば、論理モデルにおけるこれら７つの状態のいずれかに自分の製造設備の状態をマッピングできることになる。
【０１３４】
この実施の形態１０において、ＩＰＣ２５４Ｘモデル部５７は上記７つの状態のいずれにあるのかを保持しており、データ１次処理部５４が生データ５３のうちの上記４ビットに相当するデータを観測して、ＩＰＣ２５４Ｘモデル部５７の保持する状態を変更するよう構成されている。
【０１３５】
一方、図２４に示すようにデータ１次処理部５４と連携したＳＣＭモデル部５８が設けられている。ＳＣＭとはＳｕｐｐｌｙ Ｃｈａｉｎ Ｍａｎａｇｅｍｅｎｔの略であり、生産管理手法のひとつである。この実施の形態１０はＳＣＭを工場内の生産ラインに限定して適用するためのものである。すなわち生産ライン内のどの工程がボトルネックとなって生産速度を律速しているかを発見するために用いる。
【０１３６】
図２６はある製品の製造工程表であり、加工、組み立て、検査工程が表されている。図２６中、○印は部品または製品であり、□印は加工組み立て工程、▽印は検査工程である。図２６においては、この製品は３つの部品が別々に加工されて、その後ひとつに組み立てられ、検査されて完成している様子を表している。このとき各工程はその処理速度が監視される。また、各工程の前後の矢印の部分は次の工程での処理待ちとなっているワークの個数などが監視される。
【０１３７】
実施の形態１０におけるＳＣＭモデルは図２６に示したようなものであり、これは製造ラインごとに異なるものである。このとき、制御装置２から集めたデータをもとに各工程の処理速度、および工程前後の滞留数を１次処理により計算することができる。
【０１３８】
以上説明したように実施の形態１０によれば、生産ラインのトータルの処理能力を向上させるためにはボトルネックを発見する必要があるが、滞留数の一覧表を、図１に示す上位情報系コンピュータ４の画面に表示するなどして、このボトルネックを発見することが可能な生産情報システムを構成することができる効果がある。
【０１３９】
実施の形態１１．
この発明に係る実施の形態１１について図２７を参照して説明する。なお、図２７は実施の形態１１に係る通信情報変換装置の動作を説明するための図である。
【０１４０】
上述した実施の形態１および実施の形態の形態８における通信情報変換装置１の全体制御部１６において、リクエスト応答型タスク、周期起動型タスク、ストップウォッチ型タスク、イベント駆動型タスクの各タスクを複数登録しておき、各タスクの起動条件が満たされたときにそれぞれのタスクが起動して処理内容が実行されることを特徴としている。夫々のタスクとその処理内容は図２７に示すとおりである。
【０１４１】
以上説明したように実施の形態１１によれば、タスクを登録しなおすことでさまざまな動作を行わせることができる通信情報変換装置が得られる効果がある。
【０１４２】
実施の形態１２．
この発明の実施の形態１２について説明する。なお、ここでは図１を参照することとする。
図１に示すようなＬＡＮ８で相互接続されたシステムにおいては、近年Ｅｔｈｅｒｎｅｔ（登録商標）上でＴＣＰ／ＩＰ通信を行うことが一般的となった。しかしながら、ＴＣＰ／ＩＰのネットワークを設営するためにはネットワーク設計作業が必要となる。この作業にはネットワークの専門知識が必要である。本発明の通信情報変換装置、制御装置、上位情報系コンピュータはつぎのような機能を備えることで上記専門知識を持った作業員を不要としている。
【０１４３】
（１）ＩＰアドレスの合議制割り当て
（２）ＩＰホスト名の合議制割り当て
（３）マルチキャストアドレス、ポートの合議制割り当て
（４）ＲＤＢシステムとそのクライアントなどＬＡＮ内に存在するアプリケーションの自動設定
ここで合議制とはたとえば制御装置間でその都度もうし合わせて、お互いのＩＰアドレスの割り当てを自動的に決定するようなことをさしている。
【０１４４】
以上説明したように実施の形態１２によれば、ネットワークの専門知識を持った設営作業員の存在を不要とする効果が得られる。
【０１４５】
実施の形態１３．
この発明に係る実施の形態１３について図２８を参照して説明する。なお、図２８はこの実施の形態１３に係る通信情報変換装置の動作を説明するための図である。
【０１４６】
実施の形態１３は制御装置２の保持するデータをツリー構造で管理することを特徴とする通信情報変換装置である。このとき制御装置２は次のようなツリー構造のデータ６４を管理しているとする。
【０１４７】
＜Ａ＞
＜Ｂ＞値１＜／Ｂ＞
＜Ｃ＞
＜Ｄ＞値２＜／Ｄ＞
＜Ｅ＞値３＜／Ｅ＞
＜／Ｃ＞
＜／Ａ＞
【０１４８】
値１、値２、値３の３つの値が上記のツリー構造で管理されているとする。このとき、ツリー構造に含まれる、あるデータを読み出す際の方式に関する実施の形態が図２８に示されている。
【０１４９】
例えば値２を知りたいとき、送り側７０の空ＸＭＬクライアント５９は、
＜Ａ＞
＜Ｃ＞
＜Ｄ＞＜／Ｄ＞
＜／Ｃ＞
＜／Ａ＞
というＸＭＬ文書を生成して（これを空ＸＭＬ６２と呼ぶことにする）、受け取り側７１の空ＸＭＬサーバ６０に送りつける。
【０１５０】
空ＸＭＬサーバ６０はこれを受け取って、内容を解釈し、＜Ｄ＞＜／Ｄ＞の部分に実データを書き込めばよいことを知り、受け取り側７１は下記のように値を書き込んで送り側７０の空ＸＭＬクライアント５９に返送する。
＜Ａ＞
＜Ｃ＞
＜Ｄ＞１２３．４５６＜／Ｄ＞
＜／Ｃ＞
＜／Ａ＞
これを充ＸＭＬ６３と呼ぶことにする。
【０１５１】
以上説明したように実施の形態１３によれば、ツリー構造でデータを管理する設計だけを行えば、それらの値をリモートコンピュータから取得するプロトコルとそれを扱うミドルウェアおよびそのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ：ミドルウェアを呼び出す関数名のリスト）が上記のごとく自動的に得られるので、プロトコル、ミドルウェア及びそのＡＰＩの設計が不要となる効果がある。
【０１５２】
実施の形態１４．
この発明に係る実施の形態１４について図２９を参照して説明する。なお、図２９はこの実施の形態１４に係る通信情報変換装置の構成を示す図である。
【０１５３】
図２９において、データ収集部９は、制御装置２Ａ、２Ｂ、２Ｃから指定されたデータの収集を行い、ＸＭＬ ＤＢ部７２にそのデータを格納する。「指定された」とは、図１３における収集データ指定文書１０により指定されているものである。収集データは書く制御装置の動作状態を表しており、制御パラメータであったり、生産設備におけるワークの加工状態であったり、ワークの生産個数を表している。
【０１５４】
ＸＭＬ ＤＢ部７２では、通常のＲＤＢ部においてテーブル構造でデータを管理しているのに対し、各データをツリー構造で管理している。
【０１５５】
Ｑｕｅｒｙ処理部７３は、上位情報系アプリケーションソフトウェア５からの問い合わせを処理するために存在する。ＸＭＬ ＤＢ部７２に格納されたデータの一部、もしくは全部についての問い合わせが処理される。この問い合わせは、例えば実施の形態１３の図２８に示された空ＸＭＬによることができる。また、Ｑｕｅｒｙと呼ばれる標準化問い合わせ言語によることができる。
【０１５６】
実施の形態１４の通信情報変換装置は、次に述べるような生産情報システムを構築する際に有益である。つまり、生産情報システム内に実施の形態１４の通信情報変換装置が複数個配置され、それぞれ別々の制御装置郡からデータ収集を実行する。生産情報システム内には上位情報系アプリケーションソフトウェアとしてリレーショナルデータベースを配置する。このリレーショナルデータベース内に各通信情報変換装置内に格納されたデータを格納するための領域（テーブルと呼ばれる）を設け、予め定められた周期で、各通信情報変換装置が収集し保持している複数のデータの内容を上位情報系アプリケーションソフトウェアとしてのリレーショナルデータベース内の前記領域にコピーする動作をリレーショナルデータベースに設定する。
【０１５７】
これにより、生産情報システム内で収集されたデータはすべて上位情報系アプリケーションソフトウェアであるリレーショナルデータベースに集められる。この結果、リレーショナルデータベース一箇所に集まったデータテーブルに対し、生産管理、品質管理、稼動管理を目的とする演算処理を施すことが可能となる。
【０１５８】
各通信情報変換装置からリレーショナルデータベースへデータをコピーする動作は、レプリケーションと呼ばれるソフトウェア、もしくはデータテーブルのエクスポーネントおよびインポートにより実現可能である。通信情報変換装置が集めたデータはすべてもしくはその一部が取り出されてリレーショナルデータベース内のテーブルにコピーされる。
【０１５９】
以上説明したように実施の形態１４によれば、制御装置の動きを記録しておき、後からその動きを確認する必要が生じた際に、必要な部分を取り出すことができる通信情報変換装置が得られる効果がある。
【０１６０】
【発明の効果】
以上のように、この発明によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。
【０１６１】
この発明によれば、制御装置の動作状態を表すデータは、制御装置がＰＬＣ（プログラマブルロジックコントローラー）のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を８個まとめて１バイトと見立て、これを整数値データとして扱うことがある。一方、これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという課題を解決できる効果が得られる。
【図面の簡単な説明】
【図１】この発明の実施の形態１に係る通信情報変換装置の構成を示す図である。
【図２】実施の形態１の通信情報変換装置を用いた生産情報システムの構成を示す図である。
【図３】実施の形態１の通信情報変換装置の動作を説明するための図である。
【図４】実施の形態１の通信情報変換装置の動作を説明するための図である。
【図５】実施の形態１の通信情報変換装置の動作を示すフローチャートである。
【図６】この発明の実施の形態２に係る通信情報変換装置の構成を示す図である。
【図７】実施の形態２の通信情報変換装置の動作を説明するための図である。
【図８】実施の形態２の通信情報変換装置の動作を示すフローチャートである。
【図９】この発明の実施の形態３に係る通信情報変換装置の構成を示す図である。
【図１０】実施の形態３の通信情報変換装置の動作を説明するためのスクリプトプログラムである。
【図１１】実施の形態３の通信情報変換装置の動作を示すフローチャートである。
【図１２】この発明の実施の形態４に係る通信情報変換装置の構成を示す図である。
【図１３】実施の形態４の他の通信情報変換装置の構成を示す図である。
【図１４】この発明の実施の形態５に係る通信情報変換装置の構成を示す図である。
【図１５】実施の形態５の通信情報変換装置の動作を説明するための図である。
【図１６】実施の形態５の通信情報変換装置の、他の構成例を示す図である。
【図１７】この発明の実施の形態６に係る通信情報変換装置の動作を説明するための図である。
【図１８】実施の形態６に係る通信情報変換装置の動作を説明するための図である。
【図１９】この発明の実施の形態７に係る通信情報変換装置の構成を示す図である。
【図２０】実施の形態７の通信情報変換装置の動作を説明するための図である。
【図２１】この発明の実施の形態８に係る通信情報変換装置の構成を示す図である。
【図２２】この発明の実施の形態９に係る通信情報変換装置の構成を示す図である。
【図２３】この発明の実施の形態１０に係る通信情報変換装置の構成を示す図である。
【図２４】実施の形態１０に係る通信情報変換装置の、他の構成例を示す図である。
【図２５】実施の形態１０に係る通信情報変換装置の動作を説明するための図である。
【図２６】実施の形態１０に係る通信情報変換装置の動作を説明するための図である。
【図２７】この発明の実施の形態１１に係る通信情報変換装置の動作を説明するための図である。
【図２８】この発明の実施の形態１３に係る通信情報変換装置の動作を説明するための図である。
【図２９】この発明の実施の形態１４に係る通信情報変換装置の構成を示す図である。
【符号の説明】
１ 通信情報変換装置、２，２Ａ，２Ｂ，２Ｃ 制御装置、３，３Ａ，３Ｂ，３Ｃ 生産設備、４ 上位情報系コンピュータ、５ 上位情報系アプリケーションソフトウェア、６ 内部バス、７ シリアル回線、８ ＬＡＮ、９ データ収集部（データ収集手段）、１０ 収集データ指定文書、１１ ＸＭＬ化部（ＸＭＬ化手段）、１２ ＸＭＬ変換部（ＸＭＬ変換手段）、１３ ＸＳＬ文書、１４ＸＭＬ文書、１５ 通信アプリケーション部（通信アプリケーション手段）、１６ 全体制御部、１７ 論理名−物理名変換部（論理名−物理名変換手段）、１８ 変換テーブル、１９ スクリプト処理部、２０ スクリプトプログラム、２１ 時計部（計時手段）、２２ グローバル変数部、２３ システム変数部、２４ データ１次処理部、２５ １次処理方法指定文書、２６ スクリプト埋め込みＸＭＬ文書、２７ スクリプト化部、２８ 元データ、２９ 元データ、３０ バイナリーＸＭＬ、３１ フォーマット定義ＸＭＬ文書、３２ エンコード部、３３ デコード部、３４ 送信キューイング部、３５ 送信キュー部、３６プロトコル変換部（プロトコル変換手段）、３７ データフォーマット変換部（データフォーマット変換手段）、３８ 物理現象−論理モデル変換部（物理現象―論理モデル変換手段）、３９ シリアル入出力部、４０ ソケット入出力部、４１ ＳＱＬクライアント、４２ ＳＱＬサーバ、４３ ＳＯＡＰサーバ、４４ ｈｔｔｐクライアント、４５ ｈｔｔｐサーバ、４６ ｆｔｐクライアント、４７ ｆｔｐサーバ、４８ ＳＯＡＰクライアント、４９ ＰＯＰ／ＩＭＡＰサーバ、５０ 制御装置入出力ライブラリ、５１ 制御装置クライアント、５２ｓｍｔｐクライアント、５３ 生データ、５４ データ１次処理部（データ１次処理手段）、５５ 他システム、５６ ＯＤＢＣクライアント、５７ ＩＰＣ２５４Ｘモデル部、５８ ＳＣＭモデル部、５９ 空ＸＭＬクライアント、６０空ＸＭＬサーバ、６１ ＲＤＢ部、６２ 空ＸＭＬ、６３ 充ＸＭＬ、６４ ツリー構造のデータ、７０ 送り側、７１ 受け取り側、７２ ＸＭＬ ＤＢ部、７３ Ｑｕｅｒｙ処理部。
【発明の属する技術分野】
この発明は、相互にネットワーク接続された生産設備用制御装置および生産情報管理装置により構成される通信情報変換装置、およびこの通信情報変換装置を用いた生産情報システムに関するものである。
【０００２】
【従来の技術】
従来の通信情報変換装置は、例えば、特許文献１の図１に示されるような構成を有していた。その動作は、図中にＮｏｄｅと記された各制御装置からデータを取り出し、通信情報変換装置で通信プロトコル変換、データフォーマットの変換、物理的なデバイス名称と情報システムとして意味づけを持つ論理名称の変換を行なうというものであった。
【０００３】
このとき、特許文献１の図３には、制御装置のネットワーク接続の物理的構造の視点から生産設備全体をモデル化したツリー構造と、それとは別の視点からモデル化したツリー構造との間で、同一の概念をあらわすツリーのノード間にリンクを張ることで、そのノードの保持するデータの値の更新が一意に行われ同一性が保たれるとしていた。また、特許文献１の図８および図９においては制御装置の動作状態を表すデータが、生産管理の観点からは異常カウントを表すことを対比付ける方法が得られるとしていた。
【０００４】
さらに、特許文献２の図３には、仮想メモリデータ管理部に制御装置類からのデータが保持され、各種アプリケーションが仮想メモリデータ管理部への共通的なアクセス方法に基づいて動作することで、制御装置、或いはデバイスごとのアクセス方法の違いが吸収され統一的にデータを送受することができるとしていた。
【０００５】
【特許文献１】
特開２００１−２５１２９８号公報
【特許文献２】
特開２００１−２５１３１８号公報
【０００６】
【発明が解決しようとする課題】
従来の通信情報変換装置は、複数のツリー構造間に静的にリンクを張る方式でデータを階層的に管理することにしていたため、制御装置の状態を表すデータもしくは制御装置の動作状態を変化させるデータを管理するツリー構造と、それとは別の構造を持つツリー構造の間にリンクを張ることはできるのであるが、それぞれのツリー構造が動的に変化する場合には対応が困難になるという問題があった。例えば制御装置が３台あり、それぞれの制御装置に生産個数を表すデータが存在するとき、生産個数を表現したツリーから３台の制御装置のデータを保持するツリーにリンクを張るが、制御装置台数が増えたときに、２つのツリー構造の間に新たなリンクを自動的には生成することができない。
【０００７】
また制御装置の動作状態を表すデータであるが、制御装置がＰＬＣ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒ）のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を８個まとめて１バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立、不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという課題があった。
【０００８】
また、生産量、異常発生回数など生産管理上の論理的な名称と、制御装置および変数の値をリンクさせる際に、生産管理上の論理名をツリー構造ではなくテーブル構造で保持しているため、ツリー構造が本来持っている動的な変化への追従能力を活かせていないという課題があった。
【０００９】
また、生産管理上の論理的な名称とリンクさせることに関しては、単に例えば「変数００１」を「生産高」とみなすのではなく、論理的な生産管理モデルと現実の生産設備で起きている事象をリンクさせることこそ、真に生産能力、採算性を改善するための様々な手法を用いるために必要となる。しかしながら、従来例は単なる名称の読み替えのみであるため、論理的な生産管理モデルを利用することができないという課題があった。
【００１０】
また、ある電気接点が閉じている時間を計測する場合、閉じ終わって開いた時刻から閉じ始めた時刻を減じることで閉じている時間を得ることができるのであるが、単なるツリー間リンクでは、この例に示すような演算処理を表現することはできないという課題があった。
【００１１】
またさらに、上記のような演算処理を行なう場合には、現在時刻を与えるタイマー、演算の途中経過或いは前回の演算結果を保持するグローバル変数が必要となる場合があるが、制御装置にそのようなタイマーと変数が存在しないと演算できないという課題があった。
【００１２】
さらに、通信情報変換装置から上位情報系の計算機にデータを送信する際、送信間隔が数秒、数百ミリ秒、数十ミリ秒といった短い間隙で送信する場合には、１回の送信データ量が増えるにしたがって、通信路のバンド幅を埋め尽くす可能性が高まる。このとき、本質的にはデータ量が増大するＸＭＬフォーマット（ｅＸｔｅｎｔｄｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いることとしているため、その可能性がより高まるという課題があった。
【００１３】
一方、アプリケーションから統一的なアクセス手法により制御装置のデータを読み出すことができるとしているのであるが、すでに開発済みのアプリケーションが存在する場合には、そのアプリケーションに手を加える必要があり、変更可能でない場合は接続ができないという課題があった。
【００１４】
この発明は、上記のような課題を解決するためになされたものであり、制御装置のデータを表すツリー構造の動的変化への追従が容易である通信情報変換装置の提供を目的とする。
【００１５】
【課題を解決するための手段】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置のデータを収集するデータ収集部と、データ収集部によって収集されたデータをＸＭＬ文書に変換するＸＭＬ化部と、ＸＭＬ化部によって得られたＸＭＬ文書を、別の形式のＸＭＬ文書に変換するＸＭＬ変換部と、ＸＭＬ変換部によって得られたＸＭＬ文書を上位情報系に伝達する通信アプリケーション部と、ＸＭＬ変換部の動作内容をＸＳＬ文書で記述するＸＳＬ記述部と、データ収集部の動作内容を、どのデータを収集すべきかを指定する収集データ指定部とを備えたものである。
【００１６】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置のデータを収集するデータ収集部と、データ収集部によって収集されたデータを格納するＸＭＬ ＤＢ部と、上位情報系からＸＭＬ ＤＢ部に格納されるデータの一部もしくは全部を取り出すための問い合わせを処理して、当該問い合わせ内容に対応するデータを返答するＱｕｅｒｙ処理部とを備えるものである。
【００１７】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置からデータを取得するプログラムを含むスクリプト言語プログラムを用いてＸＭＬ文書を生成し、もしくはＸＭＬ文書の一部に、制御装置からデータを取得するスクリプト言語プログラムを記述したＸＭＬ文書を入力とし、スクリプト言語プログラムを出力するスクリプト化部を備え、出力されたスクリプト言語プログラムを用いてＸＭＬ文書を生成し、ＸＭＬ文書を上位情報系に伝達する通信アプリケーション部とを備えるものである。
【００１８】
この発明に係る生産情報システムは、ＸＭＬ文書データを２つ以上のコンピュータ間でやりとりする際、バイナリーフォーマットで転送し、そのフォーマットに格納されるデータのデータ長、データの意味を記述したフォーマット定義ＸＭＬ文書を備えるものである。
【００１９】
この発明に係る通信情報変換装置は、収集された生データを演算処理する物理現象−論理モデル変換部と、物理現象−論理モデル変換部により演算処理されたデータのフォーマット形式を変換するデータフォーマット変換部と、データ通信を処理するためのプロトコル変換部を備え、プロトコル変換部において通信クライアントおよび通信サーバを備えるものである。
【００２０】
この発明に係る生産情報システムは、データの値が空になったツリー構造データをクライアントから受けとったサーバは、空の値を埋めたツリー構造データをクライアントに返送するものである。
【００２１】
この発明に係る生産情報システムは、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置と通信情報変換装置と上位情報系は合議制により互いのＩＰアドレス、ＩＰホスト名、マルチキャストアドレスおよびポートの割り当て、およびＬＡＮ内に存在するアプリケーションの自動設定を行うものである。
【００２２】
【発明の実施の形態】
この発明に係る通信情報変換装置および生産情報システムの実施の一形態について説明する。本発明の通信情報変換装置は、制御装置とは別の筐体で設置され、生産情報システムを構成するものとして説明するが、制御装置と通信情報変換装置は同一筐体、あるいはいわゆるバックプレーン（複数の筐体の物理的合体および電気回路の連結を同時に供する機構）で接合した形態であっても同等の効果を奏する。
【００２３】
実施の形態１．
この発明の実施の形態１について図１〜図５を参照して説明する。なお、図１は実施の形態１に係る通信情報変換装置１の構成を示す図であり、図２は実施の形態１の通信情報変換装置１を用いた生産情報システムの構成を示す図である。また、図３および図４は実施の形態１の通信情報変換装置１の動作を説明するための図であり、図５は実施の形態１の通信情報変換装置１の動作を示すフローチャートである。
【００２４】
通信情報変換装置１は図１に示すように、データ収集部９、収集データ指定文書１０、ＸＭＬ化部１１、ＸＭＬ変換部１２、ＸＳＬ文書１３、ＸＭＬ文書１４、通信アプリケーション部１５、全体制御部１６とを備えて構成される。それらの動作は後段で詳細に説明する。
【００２５】
また、通信情報変換装置１を用いた生産情報システムは、図２に示すように制御装置２Ａ，２Ｂ，２Ｃ（以下、総称して「制御装置２」と記す）、制御装置２により制御される生産設備３Ａ，３Ｂ，３Ｃ（以下、総称して「生産設備３」と記す）、生産活動を行なうにあたり、生産計画とその進捗の把握、企業内の資源管理を行なう上位情報系コンピュータ４、上位情報系コンピュータ４内に生産スケジューラーや、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、ＳＣＭ（Ｓｕｐｐｌｙ Ｃｈａｉｎ Ｍａｎａｇｅｍｅｎｔ）等の上位情報系アプリケーションソフトウェア５が備わり構成される。
【００２６】
通信情報変換装置１と制御装置２はいくつかの通信路、例えば内部バス６、ＲＳ２３２Ｃのようなシリアル回線７、或いはＬＡＮ８によって情報通信を行なうことができる。ＬＡＮ８には通信情報変換装置１、制御装置２、上位情報系コンピュータ４が接続されており、これらも相互に情報の交換を行なうことができる。なお、図２中で通信情報変換装置１を１台、制御装置２、生産設備３をそれぞれ３台、上位情報系コンピュータ４を１台で構成した例を示したが、それらの台数に限ることはない。
【００２７】
通信情報変換装置１が対象としている生産情報システムは上述のようなものであるが、つぎにその動作について説明する。
【００２８】
通信情報変換装置１のデータ収集部９はその動作を開始するとき、もしくはその動作をいったん停止して再開するときに、収集データ指定文書１０を読み込む。なお、ここでいう文書とは、コンピュータで処理可能なテキストファイルのことを指している。収集データ指定文書１０には収集する対象の制御装置と、収集するデータ、および収集するタイミングの指定、収集するタイミングの指定を記載してある。収集するタイミングとはリクエストがあるごとに一回だけ収集するのか、一定周期でログとして収集するのか、エラー発生時など指定するイベントが発生したとき収集するのか等のタイミングである。データ収集部９が動作を開始すると制御装置２から指定されたデータが読み出され、そのデータはＸＭＬ化部１１に送られる。送るときには、どの制御装置のどの変数かという名称と、実データとを組にして送ることになる。
【００２９】
この実施の形態１では共有メモリを用いた実装を説明する。図３に示すように、共有メモリには制御装置内のデータを格納しているデバイス名とその値を配列型変数領域に記録している。なお、ここでいうデバイスとは制御装置のデジタル入出力点と内部変数を総称のことである。
【００３０】
図３に示した配列型変数の左側の列には制御装置識別番号とデバイス名を組み合わせた文字列が格納され、右側の列には収集した値を表す文字列が格納されている。デバイス名で「Ｘ」とあるのは、制御装置への入力信号のうちの一つを表しており、データ長は１ビットである。「Ｍ」とあるのは制御装置の内部変数であり、「Ｙ」とあるのは制御装置の出力信号であり、データ長は１ビットである。「Ｃ」とあるのはカウンタ型の特殊な内部変数で、「Ｄ」とあるのは内部変数で、「Ｂ」とあるのは制御装置間で共有される特殊な共有変数で、データ長は８ビットである。データ収集部９は制御装置からデータ収集した後、この図３に示す配列変数を介してＸＭＬ化部１１にデータを渡すものである。
【００３１】
ここで、ＸＭＬ文書について説明する。ＸＭＬ文書はツリー構造で管理されたデータを表記するテキスト形式のデータであり、その表記方法の規約は国際標準化団体であるＷ３Ｃにより承認されたものである。その特徴は、すべてテキスト形式で記述すること、データのフィールド名をタグと呼ばれる書式で表現し（タグとは“＜”および“＞”で文字列を挟んだものである）、データの値を、自分で自由にタグを定義して、開始タグと終了タグ（開始タグのタグ名の前に“／”を付加したもの）で挟んで記述することなどである。
【００３２】
例えば、生産量が１００個であることを、＜生産量＞１００＜／生産量＞と表記する。また開始タグと終了タグを入れ子にすることでツリー構造が表現でき、例えば、工場内にラインが２つあることを、ツリー構造を用いて表現すると工場ノードの下にライン１ノードとライン２ノードがぶら下がっているように表すとよい。このときＸＭＬ文書を用いてこのツリー構造を記述すると、＜工場＞＜ライン１＞＜生産量＞１００＜／生産量＞＜／ライン１＞＜ライン２＞＜生産量＞２００＜／生産量＞＜／ライン２＞＜／工場＞とすることで、もとのツリー構造を記述できる。なお、ＸＭＬ文書は、改行位置は不問である。
【００３３】
例えば、
【００３４】
上記のような工場の構成を考えるとき、ある工場はラインが１本だけの場合や、２本或いは３本である場合があるが、ＸＭＬ文書ではそのような場合に＜ライン＞タグを増やしたり減らしたりして、この変化に対応する。いわゆるデータベースのテーブルのように、予めラインのフィールドを１０個確保しておいて、ラインが３つだけなら、１０個のフィールドのうち３つだけ使って残り７つのフィールドは空けておくようなデータ管理とは、その点が異なっている。ＸＭＬ文書はこのような半構造化データを記述する性質を持っているのである。
【００３５】
ＸＭＬ文書は、ツリー構造によるデータ管理を行なっているので、ツリー構造を取り扱う数学理論により、ＸＭＬ文書を処理するコンピュータプログラムの自動生成、その演算処理に必要な計算機資源量の把握など、省力化と、いわゆるバグの入り込みにくいソフトウェア高品質化を実現できる可能性が高い。
【００３６】
ＸＭＬ化部１１では、図３に示す配列をもとにしてＸＭＬ文書形式のデータを生成する。このアルゴリズムは非常に単純で、デバイス指定パラメータの文字列と、それに対応する値の文字列を配列から読み出して、ＸＭＬのタグで挟んで出力するだけである。ＸＭＬのタグ名は予め定めておいたものである。図４はＸＭＬ化部１１から出力されたＸＭＬ文書形式のデータの一例を表している。図４からわかるとおり、制御装置Ａのいくつかのデバイスと、その値が、＜ｄｅｖｉｃｅ＞タグを用いて表現されている。
【００３７】
つぎに図４に示すＸＭＬ文書形式のデータはＸＭＬ変換部１２に入力される。ＸＭＬ変換部１２はＸＳＬ（ｔｈｅ ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ ｓｈｅｅｔ Ｌａｎｇｕａｇｅ）文書１３のＸＳＬデータを予め、もしくは図４に示すＸＭＬ文書形式のデータが入力された直後に読み込む動作を行なう。ＸＳＬデータとはインターネット関連技術の標準規約団体であるＷ３Ｃにてその仕様が規定されたＸＭＬ文書の変換ルールの記述方式であり、例えば、
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｓｔｙｌｅ／ＸＳＬ／
で、その仕様の詳細を知ることができる。
【００３８】
簡単には例えば次のようなルールが記述される。図４に示したようなＸＭＬ文書形式のデータの中からｄｅｖｉｃｅタグのうち、パラメータ部分にＤデバイスが記述されているタグで挟まれたデータを取り出して、それらの和をとって、＜生産量＞＜／生産量＞というタグで挟んで出力する、といったルールである。図４のＸＭＬ文書形式のデータこのルールを適用すると、ＤデバイスのタグはＤ０１、Ｄ０２、Ｄ０３の３つあり、タグで挟まれたデータはそれぞれ１２、３、８であるから、それらの和は２３となり、＜生産量＞２３＜／生産量＞というＸＭＬ文書が得られることになり、ＸＭＬ変換部１２の出力であるＸＭＬ文書１４は、＜生産量＞２３＜／生産量＞という内容を持つことになる。
【００３９】
上述した方式によれば、Ｄデバイスの数に変化があってもすべてのＤデバイスの値が取り出されて、足し算が行われる効果がある。勿論、予め、どのＤデバイスを加えるかを決めておくこともできるので、いずれか都合の良いほうを選択することになる。
【００４０】
つぎに上述したようにして作成されたＸＭＬ文書１４を読み込んだ通信アプリケーション部１５は、予め定められた通信プロトコル（通信手順）を用いて上位情報系アプリケーションソフトウェア５にＸＭＬ文書１４を送信する。通信プロトコルについては、独自のもの、標準的なものを含め、さまざまなものが利用可能である。例えば、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）、ＩＭＡＰ（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）に代表される基本的なプロトコルと、これら基本プロトコルを用いた応用プロトコルとしてＳＯＡＰ（特に略したものではない固有名詞）、或いは独自のものとしてリレーショナル・データベースで用いられるＳＱＬのリモート手順、Ｊａｖａ（登録商標）−ＲＭＩ、ＭＳ社ＤＣＯＭなどの分散オブジェクトの通信手順などが利用可能である。
【００４１】
通信相手のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の違い、通信ソフトウェアの開発言語の違いの吸収、通信路の関係からＨＴＴＰプロトコル上でＳＯＡＰを利用することが好適であり、本実施の形態１ではこのＨＴＴＰプロトコル上のＳＯＡＰを使う例で説明する。勿論、目的はＸＭＬ文書１４を上位情報系アプリケーションソフトウェア５に送り届けることであるので、これらの通信手順のどれを用いても目的は達成される。
【００４２】
通信プロトコルが決まったとしても、通信アプリケーション部１５が通信プロトコル上のクライアントとなる場合と、通信プロトコル上のサーバとなる場合のいずれをも選択できるのであるが、どちらにするか決める必要がある。本実施の形態１では、通信プロトコル上のクライアントとする場合で説明する。
【００４３】
ＳＯＡＰでは、送信したいデータをＳＯＡＰボディーと呼ばれる書式で文書として記述することになっている。今回送りたいのはＸＭＬ文書１４であり、すでに文書になっているので、そのままＳＯＡＰボディーそのものとして送ることができる。もちろん上位情報系アプリケーションソフトウェア５が所定のＳＯＡＰボディー書式を使うことにしている場合は、それに合わせて書き換えればよいのであるが、本実施の形態１ではこの書き換えはＸＭＬ変換部１２で行うことにしており、ＸＭＬ文書１４をＳＯＡＰボディーとしてそのまま送ることにする。
【００４４】
本実施の形態１においては上位情報系アプリケーションソフトウェア５と通信アプリケーション部１５はｈｔｔｐプロトコルを用いてデータ通信を行なう。その概要は上位情報系アプリケーションソフトウェア５ではＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と呼ばれる書式により、これから説明するＳＯＡＰによるデータの受け取り口を、予め定めておく。例えば、「ｐｕｔＯｕｔｐｕｔＳｕｍ」というように決めておく。また、ＬＡＮ８において、これら通信情報変換装置１や上位情報系アプリケーションソフトウェア５を実行している上位情報系コンピュータ４のＬＡＮ８上での識別名も予め定めておく。ＬＡＮ８上の識別名とは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスかホスト名のことをさしている。
【００４５】
このとき、上位情報系コンピュータ４のホスト名が、「Ｍａｓｔｅｒ」と定められていたとする。この状態で通信アプリケーション部１５は、上位情報系アプリケーションソフトウェア５に対してデータの送信を行なうとき、まずＴＣＰ（Ｔｒａｎｓｍｉｓｓｈｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ソケットとよばれる仮想的な通信チャンネルをこれら２者の間に張る。通信アプリケーション部１５におけるコンピュータプログラムはＴＣＰのソケットをオープンする。その際、「Ｍａｓｔｅｒ」の８０番ポートに向けてソケットを張る旨をパラメータとして記述する。ＴＣＰソケットが張られた後は、データを送受することができるようになるので、通信アプリケーション部１５は、つぎのようにデータを送る。
【００４６】
【００４７】
このデータ送信が成功すると、上位情報系アプリケーションソフトウェア５からＯＫという返答につづき、「ｐｕｔＯｕｔｐｕｔＳｕｍ」という生産量受け取り手順の実行が成功したことを表すデータを返す。これらの手順により、通信アプリケーション部１５から上位情報系アプリケーションソフトウェア５に対してデータの送信が完了する。
【００４８】
さて、上記の実施の形態１では生産量を合計するため、３つの整数値を加える例について説明したが、さらに複雑な別の実施の形態について述べる。生産設備で利用される制御装置２はいわゆるシーケンサと呼ばれるリレー回路を電子的に置き換えて生産設備の動きをシーケンス制御している。このシーケンサの基本的な入出力単位は１ビット（リレー回路を置き換えているので、ＯＮとＯＦＦの状態を表している）である。このような１ビットの接点を８本集めてきて、生産個数をカウントする整数値を表現することが行われている。このいわば見做し整数値を読み出したいときには、例えば図３に示すＸ０１からＸ０８までの１ビットを８本集めて整数値とみなしてワード型デバイスのＤ０１に整数値を書き込むシーケンスプログラム（ラダープログラム）を記述していたのである。
【００４９】
本実施の形態１では、ラダープログラムを記述することなく、ＸＭＬ変換部１２において、
【００５０】
生産設備が完成して稼動を始めた後に、上位情報系アプリケーションソフトウェア５でこのような値が必要になったとき、従来ならラダープログラミングのできるプログラマーでなければ対応できなかった。通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費と工期の面で不利であった。これに対し、ＸＳＬ文書１３を書き換える作業は、上位情報系プログラマーが簡単にすばやく作業できる効果がある。なお、従来例のように単にデバイスに向けてリンクを張るだけではこのような演算操作は行えなかった。
【００５１】
この例では１ビットを８本集めることを説明したが、これとは逆に生産設備上の要求から、生産設備の動作状態を表すビットデータを複数集めてワードデータにする場合がある。このような複数の情報がパックされたワードデータの中から、１ビットだけ読み出したいことがある。従来はこれを行なうためにラダープログラムが必要であったが、本実施の形態１によればＸＳＬ文書１３中に、いわゆるビットマスク演算を行うことを記述すれば実現できることになる。上述したようにラダープログラマーと上位情報系プログラマーを同時に稼動させ人件費と工期の面で改善され、上位情報系プログラマーのみで簡単にすばやく作業できる効果がある。従来のように単にデバイスに向けてリンクを張るだけではこのような演算操作は行えないものであった。
【００５２】
さて、以上述べてきたデータ収集部９、ＸＭＬ化部１１、ＸＭＬ変換部１２、通信アプリケーション部１５の一連の動作は、全体制御部１６が動作させる部位の順番と動作タイミングを制御して行われている。本実施の形態１では、図５に示すようなフローチャートに従っている。図中、左側（ＳＴＡＲＴ▲１▼、以下同様）が通信情報変換装置１の全体制御部１６の動きを、また右側（ＳＴＡＲＴ▲２▼、以下同様）が上位情報系アプリケーションソフトウェア５においてデータの送受信に関する部分のみの手順を現している。
【００５３】
まず上位情報系アプリケーションソフトウェア５の受信手順が開始され、受信待ちに入る（ステップＳＴ５０１）。即ち、図５の右側である。つぎに全体制御部１６は、予め定められた一定周期、例えば１時間に１回などの周期で図５の左側の手順を実行する。まずデータ収集部９を動かして、収集データ指定を読み込み（ステップＳＴ５０２）、その指定内容にしたがって、制御装置２からデータを集める（ステップＳＴ５０３）。
【００５４】
つぎにＸＭＬ化部１１を動かしＸＭＬデータを作成する（ステップＳＴ５０４）。つぎにＸＭＬ変換部１２を動かして、ＸＳＬ文書１３を読み込んで（ステップＳＴ５０５）、ＸＭＬデータを変換しＸＭＬ文書１４を作成して通信アプリケーション部１５へと出力する（ステップＳＴ５０６）。つぎに通信アプリケーション部１５を動かして、上位情報系アプリケーションソフトウェア５と通信ソケットを張り（ステップＳＴ５０７）、ＸＭＬ文書１４を読み込み（ステップＳＴ５０８）、データを送信し（ステップＳＴ５０９）、結果を受信する（ステップＳＴ５１０）。
【００５５】
一方、ステップＳＴ５０７の手順を受けて上位情報系アプリケーションソフトウェア５は、ソケットを許可し（ステップＳＴ５１１）、ステップＳＴ５０９に呼応してデータを受信し（ステップＳＴ５１２）、それが完了すると受信結果を送信する（ステップＳＴ５１３）。以上で動作が完了する。
【００５６】
なお、この実施の形態１においては、ＸＳＬ文書１３、収集データ指定文書１０を書き換えることで上位情報系アプリケーション５の指定するデータフォーマットおよび内容に対応することが可能となる。
【００５７】
以上説明したように実施の形態１によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。
【００５８】
また、制御装置の動作状態を表すデータであるが、制御装置がＰＬＣ（プログラマブルロジックコントローラー）のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を８個まとめて１バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという問題点を解決できる効果が得られる。
【００５９】
実施の形態２．
この発明の実施の形態２について図６〜図８を参照して説明する。なお、図６は実施の形態２に係る通信情報変換装置の構成を示す図であり、図７は実施の形態２の通信情報変換装置の動作を説明するための図であり、また、図８は実施の形態２の通信情報変換装置の動作を示すフローチャートである。
【００６０】
実施の形態１おいては収集データ指定文書１０により指定されたデータが収集され、図３に示すように、どのデバイスであるかを示すデバイス指定パラメータとその値の配列が作成されていた。本実施の形態２においては、図６に示すように実施の形態１の動作のように図３に示す配列が得られた後、論理名−物理名変換部１７が変換テーブル１８を読み込んで、図３に示すような配列を図７に示す配列に書き換える動作が追加されている。この場合に全体制御部１６の動作は、データ収集部９を動かした後、論理名−物理名変換部１７を動かし、その後にＸＭＬ化部１１を動かすことになる。
【００６１】
この論理名−物理名変換部１７の動作について説明すると、制御装置２のデバイスと論理名が１対１に対応する場合には、変換テーブル１８は、例えば、
ライン１の生産量＝制御装置Ａ．Ｄ０１
ライン２の生産量＝制御装置Ａ．Ｄ０２
ライン３の生産量＝制御装置Ａ．Ｄ０３
等のような対応関係を記述する。さらに、実施の形態１で説明したように複数のビットデバイスをまとめて整数値として取り扱う場合や、集計を行う場合にはそのような演算が記述される。例えば、次のような記述がなされる。
全体生産量＝制御装置Ａ．Ｄ０１＋制御装置Ａ．Ｄ０２＋制御装置Ａ．Ｄ０３
【００６２】
そして、本実施の形態２におけるＸＳＬ文書１３は、実施の形態１においてデバイス名を記述していた部分が論理名で書けばよいことになり、人間にとっては記述しやすくなり、間違いが起こりにくいという効果が得られる。
【００６３】
なお、本実施の形態２では変換テーブル１８を数式のような形態で記述する例を示したが、この変換規則をＸＭＬで記述しても同様の効果が得られる。そのＸＭＬは、例えばつぎのようなものである。
【００６４】
【００６５】
つぎにこの場合の全体制御部１６の動作について図８のフローチャートに沿って説明する。まず、論理名−物理名変換部１７を動かし、変換テーブル１８を読み込む（ステップＳＴ８０１）。ここで、制御装置からどのデバイスの値を集めればよいかがわかるので収集データ指定文書１０は不要となるのである。この、どのデータを集めるかは論理名−物理名変換部１７により抽出され、データ収集部９に送られ、収集動作が行われる（ステップＳＴ８０２）。これ以降は図５の動作と同等であるので説明は省略する。
【００６６】
なお、どのデータを集めるかの抽出は、変換テーブル１８の中からデバイスを指定する文字列を切り出す方法を用いることができる。さらに別の方法として、Ｘｐａｔｈ、Ｘｌｉｎｋと呼ばれる規約に従った記述を変換テーブル１８にて行っておき、論理名−物理名変換部１７において、Ｘｐａｔｈの記述を処理して、データを取り出すべきデバイスがわかるたびに、データ収集部９を動かしてデータを収集する方法を用いることもできる。この場合、収集データ指定文書１０は不要である。
【００６７】
この実施の形態２においては、ＸＳＬ文書１３、変換テーブル１８、収集データ指定文書１０を書き換えることで上位情報系アプリケーションソフトウェア５の指定するデータフォーマットおよび内容に対応することが可能となる。
【００６８】
以上説明したように実施の形態２によれば、デバイス名を記述していた部分が論理名で書けばよいことになり、人間にとってはわかりやすいので記述しやすくなり、間違いが起こりにくいという効果が得られる。
【００６９】
実施の形態３．
この発明の実施の形態３について図９〜図１１を参照して説明する。なお、図９は本発明の実施の形態３に係る通信情報変換装置の構成を示す図であり、図１０は実施の形態３の通信情報変換装置の動作を説明するためのスクリプトプログラムであり、また、図１１は実施の形態３の通信情報変換装置の動作を示すフローチャートである。
【００７０】
実施の形態３に係る通信情報変換装置は図９に示す構成であって、スクリプト処理部１９はスクリプトプログラム２０を読み込んで、このプログラムに基づく動作を行なうよう構成されている。ここでいうスクリプト処理部は、Ｐｅｒｌ、Ｒｕｂｙ、ｂｓｈ、ＥＣＭＡ Ｓｃｒｉｐｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ（ＪＳｃｒｉｐｔ）、ＶＢｓｃｒｉｐｔ、Ｗｉｎｄｏｗｓ（登録商標） Ｓｃｒｉｐｔｉｎｇ Ｈｏｓｔ、ａｗｋ、或いは三菱電機株式会社製のグラフィックオペレーションターミナルＧＯＴシリーズにおけるＧＯＴスクリプト、ＭＳ−ＤＯＳのバッチコマンドなど、簡単なロジックとシーケンスを記述して処理を実現できるようにした簡易プログラミング言語の処理系のことを指している。
【００７１】
ただし、
（１）制御装置２のデバイスを指定し、その値を取得できる書式もしくは組み込み関数もしくは外部手続きの呼び出しする機能
（２）ファイルもしくはメモリ上もしくは標準出力などのファイルストリームに文字列を出力する機能
の２つの機能を最低限装備しておく必要がある。
【００７２】
このとき、本実施の形態の通信情報変換装置１は、例えば図１０に示すスクリプトプログラム２０に従って次のように動作する。図１０中、「ｐｒｉｎｔｆ」というのは標準出力ストリームに文字列を、書式付きで出力する命令文を示している。また、「制御装置（２）．ｄ（０１）」というのは制御装置２のデバイスを指定し、その値を取得できる組み込み関数である。
【００７３】
図１０に示したスクリプトプログラムは各行が順番に実行される。まず１行目ではＸＭＬ文書の開始を表す文言が出力される。次の行では「＜生産量＞」というＸＭＬの開始タグが出力される。次の行では２という制御装置の、０１というｄデバイスから値が読み出され、同様に０２というｄデバイス、０３というｄデバイスから値が読み出され、読み出された３つの値の和が求められ、その値が整数値として文字列で出力される。デバイスから値が読み出される際にはデータ収集部９を動作させることにより、制御装置２からデータが収集され、その値を読み出すことができる。
【００７４】
その次の行では、「＜／生産量＞」という終了タグが出力されている。なお、各行の「￥ｎ」とは改行文字をあらわしている。結局、図１０に示したスクリプトプログラムの実行結果は次のようなＸＭＬ文書が生成される。これが図９におけるＸＭＬ文書１４である。
【００７５】
＜？ＸＭＬ ｖｅｒｓｉｏｎ＝“１．０” ？＞
＜生産量＞
１２３
＜／生産量＞
【００７６】
このようにして、制御装置２のデバイスのデータの値を含んで生成されたＸＭＬ文書１４は、通信アプリケーション部１５を用いて、上位情報系アプリケーションソフトウェア５に送信される。詳細な説明は実施の形態１と同様であるので省略する。
【００７７】
これら一連の手順の制御は全体制御部１６により行われる。この手順は図１１に示すように、まず全体制御部１６はスクリプト処理部１９を動作させる。スクリプト処理部１９はスクリプトプログラム２０を読み込み（ステップＳＴ１１０１）、このスクリプトプログラム２０に記述された内容を解釈して実行し（ステップＳＴ１１０２）、ＸＭＬ文書１４が生成される（ステップＳＴ１１０３）。このときデータ収集部９は必要になったときに用いられる（ステップＳＴ１１０４）。つぎに全体制御部１６は通信アプリケーション部１５を動かしてＸＭＬ文書１４を上位情報系アプリケーションソフトウェア５に送出する（ステップＳＴ１１０５〜ステップＳＴ１１８）。
【００７８】
以上説明したように実施の形態３によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。さらに、制御装置の動作状態を表すデータは、制御装置がＰＬＣ（プログラマブルロジックコントローラー）のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を８個まとめて１バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという従来の問題点を解決できる効果が得られる。
【００７９】
実施の形態４．
この発明の実施の形態４について図１２および図１３を参照して説明する。なお、図１２は本発明の実施の形態４に係る通信情報変換装置の構成を示す図であり、図１３は実施の形態４の他の通信情報変換装置の構成を示す図である。
【００８０】
図１２に示すよう実施の形態４は、上述した実施の形態１〜３と同様に各部の動きは全体制御部１６により制御されている。そして、スクリプト処理部１９を用いてスクリプトプログラム２０に記載された内容を実行してＸＭＬ文書１４を生成し、通信アプリケーション部１５を用いて上位情報系アプリケーションソフトウェア５にＸＭＬ文書１４を送る動作を行なう。
【００８１】
このとき、データ収集部９を用いて制御装置２からデバイスのデータを集めると同時に、時計部２１、グローバル変数部２２を動かすことにより、制御装置２のデバイスの値を読み出すことのみでは得られない情報を作ることができる。例えば、あるデバイスがＯＦＦ状態からＯＮ状態に変化した時刻、或いはあるデバイスがＯＦＦ状態からＯＮ状態に変化した瞬間から、再びＯＦＦ状態に変化するまでの時間の長さである。
【００８２】
これらが必要になるのは本発明の主題である上位情報系アプリケーションソフトウェア５において生産状態の管理を行なうための情報を生産ラインから抽出するときである。上記ではその情報はデバイスの値を読むだけでは得ることができないとしていた。従来例にあるようなツリー間リンクでは得ることはできないので、制御装置においてプログラミングして作り出しているのである。このとき、従来の方式であればラダープログラミングのできるプログラマーでなければ対応できないが、通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費や工期が増大するものであった。
【００８３】
本実施の形態４では、このように上位情報系アプリケーションソフトウェアで生産管理、品質管理、稼動管理を行なう際に必要となるデータであって、従来はラダープログラミングすることで生成していたデータを、ラダープログラミング不要で生成するための機能部を設けることを特徴としている。
【００８４】
まず時計部２１の動きについて説明する。時計部の機能は２つある。ひとつはタイムスタンプ機能である。もうひとつはストップウォッチ機能である。タイムスタンプ機能はスクリプト処理部１９にてこの機能を呼び出した瞬間の時刻を返答する機能である。スクリプト処理部１９ではこれにより、次のようなときにその瞬間の時刻情報を得ることができ、その時刻情報を上位情報系アプリケーションソフトウェア５に送ることができる。第一に上位情報系アプリケーションソフトウェア５に送るＸＭＬ文書１４を生成した時刻であり、第二に制御装置２のあるデバイスの状態が変化した瞬間の時刻である（ただしスクリプト処理部１９はあるデバイスの変化を監視するタスクもしくはプロセスもしくはスレッドを実行しているものとする）。
【００８５】
さらにストップウォッチ機能であるが、ストップウォッチによる計測を開始する、停止する、ラップする（一時停止）、リセットする、計時時間を読み出すといった手続きを有している。ストップウォッチ機能は複数のストップウォッチを同時に独立して動かすことができる。このストップウォッチ機能により、制御装置２のあるデバイスがＯＮに変化した瞬間にストップウォッチを計時開始し、ＯＦＦに変化した瞬間に計時停止することで、あるデバイスがＯＮしていた時間の長さを計測することができ、それを読み出す手続きを経ることで上位情報系アプリケーションソフトウェア５に送るＸＭＬ文書１４にこの時間長さを含めることができる。
【００８６】
つぎにグローバル変数部２２について説明する。これは主として制御装置２のデバイスの値の変化を積算もしくは微分計算、移動平均、算術平均などの演算処理を実現する目的で設けられている。例えば生産ラインで処理したワークの個数を数えるのに、ワークを１個処理したときに変化するデバイスの変化回数を積算するために利用する。スクリプトプログラム２０の処理が終了し、その後スクリプトプログラム２０の処理が再び開始されたときにも前回の結果を残しておくことにも利用できる。
【００８７】
これらの処理は予め制御装置２においてラダープログラミングしておけば生成することはできるのであるが、あとからそのような情報がほしいことがわかったときにラダープログラミングのできるプログラマーでなければ対応できない。通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費と工期が増大するものであった。
【００８８】
またグローバル変数部２２には、状態遷移モデル機能或いは階層的エラー状態モデルを含めることも可能であり、これを含めた場合の動作を説明する。
まず状態遷移モデルであるが、例えば米国の電子産業業界団体のＩＰＣ（ｈｔｔｐ：／／ｗｗｗ．ｉｐｃ．ｏｒｇ／）が定めた製造現場の組み立て機器間の通信メッセージの規約ＩＰＣ−２５４１における装置の状態遷移モデルのことを指している。
【００８９】
例えば製造装置が電源停止状態から準備状態に移行し、ワークが流れてこないので止まっている、下流工程が詰まっているので止まっている、ワークを加工している、障害が発生している、などの各状態間を遷移していくというモデルである。ＩＰＣ−２５４１の規約ではこのような状態遷移モデルの標準仕様を定めている。このような標準的なモデルをたてる目的は、メーカーや目的、作業内容の異なる現場機器を統一的に上位情報系で扱って、管理手法の比較、最適化などを行なうことにある。
【００９０】
この発明においてはグローバル変数部２２にこのＩＰＣ−２５４１の状態遷移の各状態を製造装置ごとに保持する。そして、この標準化モデルの各状態と、実際の制御装置における複数のデバイスの値の組み合わせを関連付けておき、実際の制御装置２の複数のデバイスの値の組み合わせが変化したとき、標準化モデルの状態も遷移するように構成する。しかるのち、スクリプト処理部１９から現在の標準化モデルの遷移の状態を読み出してＸＭＬ文書１４に含めたり、或いは遷移が起きたときにＸＭＬ文書１４の生成を開始することが可能となる。
【００９１】
つぎに階層的エラーモデルであるが、品質管理、稼動管理の目的で、生産設備のエラー状態を細かく分類し障害要因を複雑な階層型に分類することが一般的になりつつある。このような複雑な階層型に分類された障害要因モデルと、実際の制御装置の複数のデバイスの値とを関連付けておき、複数のデバイスの値が一致したときにひとつの障害が発生したことにする。しかるのち、スクリプト処理部１９から現在の障害要因モデルの状態を読み出してＸＭＬ文書１４に含めたり、或いは障害が起きたときにＸＭＬ文書１４の生成を開始することが可能となる。
【００９２】
なお、システム変数部２３を設けることもできる。この場合は、上位情報系アプリケーションソフトウェア５との通信にＳＯＡＰの手順を用いる際の上位側からのリクエストメッセージに含まれるリクエストヘッダと呼ばれる文字列、とりわけメッセージＩＤを格納したり、通信情報変換装置のホスト名、リクエストを発行したホスト名、メッセージ番号（読み出すごとに自動生成される）、その他通信情報変換装置ごとに異なる固有情報を読み出すことが可能な変数が複数格納されており、それを読み出して、ＸＭＬ文書１４に含めるような動作を行なうことが可能となる。
【００９３】
実施の形態４の他の実施の形態について説明する。図１３に示すように、この実施の形態はＸＳＬ文書１３によりＸＭＬ変換を行なってＸＭＬ文書１４を生成している。この場合は先の例でスクリプト処理部１９が行なうこととしていた処理、例えばストップウォッチによる計時を開始したり停止したりする処理を行なうためのデータ１次処理部２４を設けている。
【００９４】
この実施の形態４によれば、従来であればラダープログラミングの必要な場面であってもラダープログラミングすることなく、上位情報系アプリケーションソフトウェアで必要な情報を収集し生成することが可能となるので、情報システム構築の工数、費用、期間が短縮される効果がある。また、従来では上位情報系から制御装置に対し、いわゆるポーリングを実行することでデバイスの変化している時間を計ることも可能ではあるが、ポーリング時間間隔以上の時間制度が得られず、この発明によればポーリング不要で時間精度も向上する効果がある。
【００９５】
実施の形態５．
この発明の実施の形態５について図１４〜図１６を参照して説明する。なお、図１４は本発明の実施の形態５に係る通信情報変換装置の構成を示す図であり、図１５は実施の形態５の通信情報変換装置の動作を説明するための図であり、図１６は実施の形態５の他の通信情報変換装置の構成を示す図である。
【００９６】
図１４に示すようにこの実施の形態５の通信情報変換装置には、スクリプト埋め込みＸＭＬ文書２６が用意される。用意するとはプログラマーがテキストエディターなどを用いてこのスクリプト埋め込みＸＭＬ文書を記述し、記述完了した後、通信情報変換装置に組み込んでおくという意味である。
【００９７】
このスクリプト埋め込みＸＭＬ文書２６は図１５に示すように、全体的にはＸＭＬ文書である。そしてその一部（「＜％」 と 「％＞」で囲まれた部分）に実施の形態３で述べたようなスクリプトの文が記述されていることがわかる。プログラマーの視点からは、通信情報変換装置１にて最終的に生成したいＸＭＬ文書１４のなかで、制御装置２から直接得たデバイスの値、或いはデバイスから得た値を演算して得られるデータ、或いは実施の形態４で説明したデータを含めたい部分について、そのデータを取得もしくは生成するためのスクリプトを埋め込むことができるとみなすことができるものである。
【００９８】
さて、スクリプト埋め込みＸＭＬ文書２６はスクリプト化部２７に読み込まれて処理が行われる。ＸＭＬ文書として書かれている部分は、その文字列を出力するためのスクリプトプログラムに書き換えられる。例えば、「＜生産量＞」というタグの部分は、「ｐｒｉｎｔｆ（“＜生産量＞”）；」というように書き換えられる。「＜％」と「％＞」で囲まれた部分はなんら処理されない。以上の結果、スクリプト化部２７からの出力は、図１０で示したスクリプトプログラムと同一のものになる。これ以降の動作は実施の形態３と同じであるので省略する。
【００９９】
また、図１６に示すように、時計部２１、グローバル変数部２２、システム変数部２３を設けることで、制御装置のデバイスの値を読み出すことのみでは得られない情報を作ることができる。これらの部分の動作は実施の形態４と同一のものであるので省略する。
【０１００】
以上説明したように実施の形態５によれば、プログラミングをスクリプト埋め込みＸＭＬ文書２６を記述することで情報変換を行なうことができる。これは上位情報系アプリケーションソフトウェア５が要求するＸＭＬ文書の形式のうち、実データで置き換える部分についてスクリプトプログラミングすればよいということである。したがって、プログラミング効率が向上する効果が得られる。時計部２１、グローバル変数部２２、システム変数部２３を設けた場合は、予めデータを生成する機能が用意されており、それについてはプログラミング不要であるので、さらにプログラミング効率が向上する効果が得られる。
【０１０１】
実施の形態６．
この発明の実施の形態６について図１７および図１８を参照して説明する。なお、図１７および図１８はこの本発明の実施の形態６に係る通信情報変換装置の動作を説明するための図である。
【０１０２】
図１に示すように通信情報変換装置１から上位情報系コンピュータ４にＸＭＬ文書１４を送ることを考えると、図１７に示す実施の形態６においては、送り側７０における元データ２８が、送られて、受け取り側７１における元データ２９になることをあらわしている。このとき、送信中の通信路、例えばＬＡＮ８上でのデータフォーマットとしてバイナリーＸＭＬ３０を用いることをこの実施の形態６は特徴としている。
【０１０３】
つぎに、元データ２８、２９が２つの整数と１つの浮動少数の値を含んでいる例について説明する。このとき、例えば元データ２８、２９は、
＜生産番号＞１２３＜／生産番号＞
＜加工結果測定値＞２３４．５６７＜／加工結果測定値＞
＜累積生産個数＞２３４５６＜／累積生産個数＞
であるとする。
【０１０４】
ここで、このようなＸＭＬ文書の元データ２８に対し、この発明を適用しバイナリーＸＭＬを用いる例について説明する。バイナリーＸＭＬ３０としては、図１７に示すように、４バイト、８バイト、４バイトの、合計１６バイトのデータ並びとして表現することにしてみる。もちろんデータのバイト長さは、取り扱うデータの変動範囲を十分に表せるように選択することはいうまでもない。
【０１０５】
このとき先頭から４バイトが整数値で、ＸＭＬのタグは「＜生産番号＞」であること、そのつぎの８バイトが不動小数点の値で、ＸＭＬのタグは「＜加工測定結果＞」であること、そのつぎの４バイトが整数値でＸＭＬのタグは「＜累積生産個数＞」であること、バイト並びのいわゆるエンディアンの大小を記述したフォーマット定義ＸＭＬ文書３１が用意しておく。これにより、バイナリーＸＭＬ３０と元データ２８および２９は、エンコード部３２およびデコード部３３により一意に相互変換可能となる。
【０１０６】
このときのフォーマット定義ＸＭＬ文書３１を図１８に示す。図中「＜ｄａｔａ＞」と記述された部分が３つあり、それぞれが上記の３つのデータの名称、バイト長さ、エンディアン、変数型を定義していることがわかる。
【０１０７】
なお、上記実施例では送信側の元データ２８のＸＭＬ文書からエンコード部３２を介してバイナリーＸＭＬ３０をエンコードすることにしているが、送り側でＸＭＬ文書の元データ２８を作ることなく直接バイナリーＸＭＬ３０を生成して送信することも可能である。この場合は送り出し側にＸＭＬ生成機能を搭載せず、直接制御装置のメモリマップの一部を送出すれば良いということになる。その際、そのメモリマップの中身をフォーマット定義ＸＭＬ文書にて記述すればよい。
【０１０８】
以上説明したように実施の形態６によれば、通信情報変換装置から上位情報系の計算機にデータを送信する際、数秒、数百ミリ秒、数十ミリ秒といった短い間隙で送信する場合には、１回の送信データ量が増えるにしたがって、通信路のバンド幅を埋め尽くす可能性に対して、これを減らすことができる効果がある。また、ＣＰＵ能力、メモリ容量に対して制限の多い制御装置においてテキスト型のＸＭＬ文書を生成しなくても自身のメモリマップの該当する箇所をそのまま切り出して送ればよいのでＣＰＵ、メモリに負荷をかけずに目的を果たせる効果がある。
【０１０９】
実施の形態７．
この発明の実施の形態７について図１９および図２０を参照して説明する。なお、図１９はこの発明の実施の形態７に係る通信情報変換装置の構成を示す図であり、図２０は実施の形態７の通信情報変換装置の動作を説明するための図である。
【０１１０】
図１９において全体制御部１６が各部を順次作動させる。まずデータ収集部９を用いて制御装置２からデータが収集される。つぎに通信アプリケーション部１５が用いられ、上位情報系アプリケーションソフトウェア５へのデータ送信が試みられる。このときこの実施の形態７においては通信アプリケーション部１５の構成として送信キューイング部３４と送信キュー部３５を備えたことを特徴とする。
【０１１１】
図２０に示すフローチャートに沿って実施の形態７に係る通信情報変換装置の動きを説明する。図２０中、２つのシーケンスからなることが示されているが、まず左側のシーケンス（ＳＴＡＲＴ▲３▼）を説明する。データ収集部９がデータを集め（ステップＳＴ２００１）、送信キューイング部３４が上位情報系アプリケーションソフトウェア５へデータを送信する（ステップＳＴ２００２）、このとき、送信が完了したかどうかの判定が行われ（ステップＳＴ２００３）、送信が完了しておれば、シーケンスは完了する。
【０１１２】
一方、完了していない場合は、送信キュー部３５に送ることができなかったデータが格納される（ステップＳＴ２００４）。完了していない場合とは、途中の通信路、この実施の形態７ではＬＡＮ８であるが、この通信路に障害が発生して、データ通信できなくなっている場合か、或いは上位情報系アプリケーションソフトウェア５自体か、またはこれを実行している上位情報系コンピュータ４に障害が発生しておりデータを受け取れない場合等がある。
【０１１３】
つぎに図２０の右側のシーケンス（ＳＴＡＲＴ▲４▼）について説明する。まず送信キューイング部３４を用いて送信キュー部３５に蓄えられているデータをひとつ取り出す（ステップＳＴ２００５）。ここで取り出せたかどうかの判定を行なう（ステップＳＴ２００６）。もし、なにもデータが蓄えられておらず、取り出すことができない場合は終了する。ひとつ取り出すことに成功した場合はデータ送信を行なう（ステップＳＴ２００７）。そして送信が完了したかどうかを判定し（ステップＳＴ２００８）、完了した場合は、そのデータを送信キュー部３５から削除する（ステップＳＴ２００９）。その後、再び最初に戻る。送信に失敗した場合はそのデータを再格納して（ステップＳＴ２０１０）、ステップＳＴ２００５に戻る。
【０１１４】
送信キュー部３５に格納するデータは、この例ではデータそのものを格納している。これは送信先の上位情報系アプリケーションソフトウェア５がひとつだけであるからである。上位情報系アプリケーションソフトウェアが複数あるときには、その送信先とデータとを組み合わせたものを送信キュー部３５に格納すれば対応できる。
【０１１５】
図２０におけるシーケンスは２つあることを説明したが、これら２つは全体制御部１６により、その開始が決定されている。左側のシーケンスは、一定周期或いは上位情報系アプリケーションソフトウェア５からリクエストがあったとき、制御装置２で予め定めておいたイベントが発生したとき（往々にして障害が発生したときに報告したいことがある）に実行される。右側のシーケンスは一定周期で実行開始される。
【０１１６】
以上説明したように実施の形態７によれば、上位情報系アプリケーションソフトウェア５或いはＬＡＮ８に障害が発生したときに、送信を後回しにすることが可能となるのでデータが遺失しない通信情報変換装置が得られる効果がある。
【０１１７】
実施の形態８．
この発明の実施の形態８について図２１を参照して説明する。なお、図２１はこの発明の実施の形態８に係る通信情報変換装置の構成を示す図である。
【０１１８】
実施の形態８に係る通信情報変換装置は、プロトコル変換部３６と、データフォーマット変換部３７、物理現象−論理モデル変換部３８の３つの部分から構成されることを特徴としている。さらにこれらの３つの部分はそれぞれより具体的な構成部品を備える。なおこのような概要構成から各部詳細化にむかう設計手法はオブジェクト指向プログラミングにより、実際にソフトウェア開発可能である。
【０１１９】
３つの部分を順に説明する。まず、プロトコル変換部３６の目的は他システム５５、すなわち上位情報系アプリケーションソフトウェア５および制御装置２と、この発明の通信情報変換装置の間で行われるデータ通信を処理するための部分である。
【０１２０】
上位情報系アプリケーションソフトウェア５および制御装置２の種類は数多く存在し、それと同時に、これら他システム５５とデータ通信するための手段が数多く必要となる。このときプロトコル変換部３６は、シリアル入出力部３９、ソケット入出力部４０、ＳＱＬクライアント４１、ＳＱＬサーバ４２、ＳＯＡＰサーバ４３、ｈｔｔｐクライアント４４、ｈｔｔｐサーバ４５、ｆｔｐクライアント４６、ｆｔｐサーバ４７、ＳＯＡＰクライアント４８、ＰＯＰ／ＩＭＡＰサーバ４９、制御装置入出力ライブラリ５０、制御装置クライアント５１、ｓｍｔｐクライアント５２といった通信クライアント機能および通信サーバ機能を持った詳細構成部を備えている。
【０１２１】
図２１においてはこれらのうち、ｈｔｔｐサーバ４５で上位情報系アプリケーションソフトウェア５と通信し、シリアル入出力部３９および制御装置入出力ライブラリ５０および制御装置クライアント５１で制御装置をデータ通信している。
データフォーマット変換部３７は、実施の形態１において説明したようなＸＭＬ文書１４の形式変換を行なう。
【０１２２】
物理現象−論理モデル変換部３８は実施の形態４で説明したように、制御装置２のデバイスがＯＮ状態にある時間を計ったり、複数のデバイスの値を集計するなどの演算を施したりする部分である。この実施の形態８では制御装置２から集められた生データ５３を直接およびデータ１次処理部５４にて上記のような演算処理を施した結果をデータフォーマット変換部３７に渡している。
【０１２３】
以上説明したように実施の形態８によれば、複数の種類の上位情報系アプリケーションソフトウェア５および制御装置２と通信可能で、かつデータのフォーマットも送り側のものから受け取り側が理解できる形式へ変換して通信できるとともに単なるデバイスのＯＮとＯＦＦなどで計測される物理現象を、上位情報系アプリケーションソフトウェア５で即刻用いることが可能な論理モデルにもとづくデータに変換することが可能な通信情報変換装置が得られる効果がある。
【０１２４】
さらに、通信プロトコルの変換、データフォーマットの変換、物理現象の論理モデルへのマッピングをそれぞれ独立してソフトウェアプログラミングできるので、通信相手の追加、利用したい論理モデルの変更、処理したいデータ追加などの機能の追加変更が容易に行えるという効果が得られる。
【０１２５】
実施の形態９．
この発明に係る実施の形態９について図２２を参照して説明する。なお、図２２は実施の形態９に係る通信情報変換装置の構成を示す図である。
【０１２６】
この実施の形態９の目的は制御装置２から例えば製造している製品の品質に関するデータ、具体的には各ワークごとの品質検査結果データなどを入出力するシリアル入出力部３９、制御装置入出力ライブラリ５０、制御装置クライアント５１を介して回収し、得られた生データ５３をそのまま、或いはデータ１次処理部５４を用いた処理の後、典型的な上位情報系アプリケーションソフトウェア５であるＲＤＢ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａ Ｂａｓｅ）システムに格納することにある。
【０１２７】
なおＲＤＢとは、全てのデータは関係演算と集合演算で扱うように設計されていて、データは２次元の表として考えられ、互いの表の関連をキーによって擬似的に結合することによって表現される。また、夫々の表はキーによって結ばれ、データの重複を省き効率的にデータ管理ができ、また、データ構造の変更に柔軟に対応することができるデータベースである。
【０１２８】
まず上位情報系アプリケーションソフトウェア５は、ＳＯＡＰサーバ４３により、通信情報変換装置１からのデータ登録を待っている。通信プロトコルはＳＯＡＰを利用することにする。ＳＯＡＰではいわゆるリモートプロシージャーコール、即ちネットワーク越しに通信相手のソフトウェアの機能を呼び出すことができるのであるが、この実施の形態９においてはＳＯＡＰを用いて上位情報系アプリケーションソフトウェア５におけるＯＤＢＣクライアント５６のデータ登録機能をリモートコンピュータから呼び出すことにしている。ここでのリモートコンピュータとは通信情報変換装置１のことである。通信情報変換装置１中のプロトコル変換部３６は、このためＳＯＡＰクライアント４８を備えている。
【０１２９】
ＳＯＡＰクライアント４８ではＳＯＡＰメッセージをＳＯＡＰサーバに送りつけて、その処理結果を受け取る動作を行なう。データフォーマット変換部３７では、生データをＲＤＢ部６１に登録するためのＳＯＡＰメッセージの生成が行われる。ここでの動作は実施の形態１で説明した動作であり、ＸＳＬ文書１３を用いて生データをＸＭＬ文書１４に変換する。ここでのＸＭＬ文書１４とはＳＯＡＰメッセージのことである。
【０１３０】
以上説明したように実施の形態９によれば、従来パソコンなどでいわゆるＳＣＡＤＡシステムを構成して制御装置２をポーリングすることでデータを回収し、上位情報系アプリケーションソフトウェア５にデータを送っていたが、実施の形態９では制御装置２と密結合した通信情報変換装置１を用いてデータを直送することができるため、上記ポーリング周期以上の頻度でデータ改修することできる効果がある。
【０１３１】
実施の形態１０．
この発明に実施の形態１０について図２３〜図２６を参照して説明する。なお、図２３は実施の形態１０に係る通信情報変換装置の構成を示す図であり、図２４は実施の形態１０に係る通信情報変換装置の他の構成を示す図である。また、図２５および図２６は実施の形態１０に係る通信情報変換装置の動作を説明するための図である。
【０１３２】
実施の形態１０では図２３に示すように、ＩＰＣ２５４Ｘモデル部５７を備えている。ＩＰＣ２５４Ｘとは、米国の電子産業業界団体のＩＰＣ（ｈｔｔｐ：／／ｗｗｗ．ｉｐｃ．ｏｒｇ／）が定めた製造現場の組み立て機器間の通信メッセージの規約のことを指しており、実施の形態４で説明している。
【０１３３】
図２５はＩＰＣ−２５４１が規定する製造装置の状態遷移の様子を表している。図２５からわかるように、製造装置は、Ｏｆｆ、Ｓｅｔｕｐ、Ｂｌｏｃｋｅｄ、Ｓｔａｒｖｅｄ、Ａｃｔｉｖｅ、Ｅｘｅｃｕｔｉｎｇ、Ｄｏｗｎという７つの状態を持つとしている。したがって、自分の製造装置もしくはその製造装置を制御している制御装置の状態をあらわすデータとして４ビット以上の値を観測すれば、論理モデルにおけるこれら７つの状態のいずれかに自分の製造設備の状態をマッピングできることになる。
【０１３４】
この実施の形態１０において、ＩＰＣ２５４Ｘモデル部５７は上記７つの状態のいずれにあるのかを保持しており、データ１次処理部５４が生データ５３のうちの上記４ビットに相当するデータを観測して、ＩＰＣ２５４Ｘモデル部５７の保持する状態を変更するよう構成されている。
【０１３５】
一方、図２４に示すようにデータ１次処理部５４と連携したＳＣＭモデル部５８が設けられている。ＳＣＭとはＳｕｐｐｌｙ Ｃｈａｉｎ Ｍａｎａｇｅｍｅｎｔの略であり、生産管理手法のひとつである。この実施の形態１０はＳＣＭを工場内の生産ラインに限定して適用するためのものである。すなわち生産ライン内のどの工程がボトルネックとなって生産速度を律速しているかを発見するために用いる。
【０１３６】
図２６はある製品の製造工程表であり、加工、組み立て、検査工程が表されている。図２６中、○印は部品または製品であり、□印は加工組み立て工程、▽印は検査工程である。図２６においては、この製品は３つの部品が別々に加工されて、その後ひとつに組み立てられ、検査されて完成している様子を表している。このとき各工程はその処理速度が監視される。また、各工程の前後の矢印の部分は次の工程での処理待ちとなっているワークの個数などが監視される。
【０１３７】
実施の形態１０におけるＳＣＭモデルは図２６に示したようなものであり、これは製造ラインごとに異なるものである。このとき、制御装置２から集めたデータをもとに各工程の処理速度、および工程前後の滞留数を１次処理により計算することができる。
【０１３８】
以上説明したように実施の形態１０によれば、生産ラインのトータルの処理能力を向上させるためにはボトルネックを発見する必要があるが、滞留数の一覧表を、図１に示す上位情報系コンピュータ４の画面に表示するなどして、このボトルネックを発見することが可能な生産情報システムを構成することができる効果がある。
【０１３９】
実施の形態１１．
この発明に係る実施の形態１１について図２７を参照して説明する。なお、図２７は実施の形態１１に係る通信情報変換装置の動作を説明するための図である。
【０１４０】
上述した実施の形態１および実施の形態の形態８における通信情報変換装置１の全体制御部１６において、リクエスト応答型タスク、周期起動型タスク、ストップウォッチ型タスク、イベント駆動型タスクの各タスクを複数登録しておき、各タスクの起動条件が満たされたときにそれぞれのタスクが起動して処理内容が実行されることを特徴としている。夫々のタスクとその処理内容は図２７に示すとおりである。
【０１４１】
以上説明したように実施の形態１１によれば、タスクを登録しなおすことでさまざまな動作を行わせることができる通信情報変換装置が得られる効果がある。
【０１４２】
実施の形態１２．
この発明の実施の形態１２について説明する。なお、ここでは図１を参照することとする。
図１に示すようなＬＡＮ８で相互接続されたシステムにおいては、近年Ｅｔｈｅｒｎｅｔ（登録商標）上でＴＣＰ／ＩＰ通信を行うことが一般的となった。しかしながら、ＴＣＰ／ＩＰのネットワークを設営するためにはネットワーク設計作業が必要となる。この作業にはネットワークの専門知識が必要である。本発明の通信情報変換装置、制御装置、上位情報系コンピュータはつぎのような機能を備えることで上記専門知識を持った作業員を不要としている。
【０１４３】
（１）ＩＰアドレスの合議制割り当て
（２）ＩＰホスト名の合議制割り当て
（３）マルチキャストアドレス、ポートの合議制割り当て
（４）ＲＤＢシステムとそのクライアントなどＬＡＮ内に存在するアプリケーションの自動設定
ここで合議制とはたとえば制御装置間でその都度もうし合わせて、お互いのＩＰアドレスの割り当てを自動的に決定するようなことをさしている。
【０１４４】
以上説明したように実施の形態１２によれば、ネットワークの専門知識を持った設営作業員の存在を不要とする効果が得られる。
【０１４５】
実施の形態１３．
この発明に係る実施の形態１３について図２８を参照して説明する。なお、図２８はこの実施の形態１３に係る通信情報変換装置の動作を説明するための図である。
【０１４６】
実施の形態１３は制御装置２の保持するデータをツリー構造で管理することを特徴とする通信情報変換装置である。このとき制御装置２は次のようなツリー構造のデータ６４を管理しているとする。
【０１４７】
＜Ａ＞
＜Ｂ＞値１＜／Ｂ＞
＜Ｃ＞
＜Ｄ＞値２＜／Ｄ＞
＜Ｅ＞値３＜／Ｅ＞
＜／Ｃ＞
＜／Ａ＞
【０１４８】
値１、値２、値３の３つの値が上記のツリー構造で管理されているとする。このとき、ツリー構造に含まれる、あるデータを読み出す際の方式に関する実施の形態が図２８に示されている。
【０１４９】
例えば値２を知りたいとき、送り側７０の空ＸＭＬクライアント５９は、
＜Ａ＞
＜Ｃ＞
＜Ｄ＞＜／Ｄ＞
＜／Ｃ＞
＜／Ａ＞
というＸＭＬ文書を生成して（これを空ＸＭＬ６２と呼ぶことにする）、受け取り側７１の空ＸＭＬサーバ６０に送りつける。
【０１５０】
空ＸＭＬサーバ６０はこれを受け取って、内容を解釈し、＜Ｄ＞＜／Ｄ＞の部分に実データを書き込めばよいことを知り、受け取り側７１は下記のように値を書き込んで送り側７０の空ＸＭＬクライアント５９に返送する。
＜Ａ＞
＜Ｃ＞
＜Ｄ＞１２３．４５６＜／Ｄ＞
＜／Ｃ＞
＜／Ａ＞
これを充ＸＭＬ６３と呼ぶことにする。
【０１５１】
以上説明したように実施の形態１３によれば、ツリー構造でデータを管理する設計だけを行えば、それらの値をリモートコンピュータから取得するプロトコルとそれを扱うミドルウェアおよびそのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ：ミドルウェアを呼び出す関数名のリスト）が上記のごとく自動的に得られるので、プロトコル、ミドルウェア及びそのＡＰＩの設計が不要となる効果がある。
【０１５２】
実施の形態１４．
この発明に係る実施の形態１４について図２９を参照して説明する。なお、図２９はこの実施の形態１４に係る通信情報変換装置の構成を示す図である。
【０１５３】
図２９において、データ収集部９は、制御装置２Ａ、２Ｂ、２Ｃから指定されたデータの収集を行い、ＸＭＬ ＤＢ部７２にそのデータを格納する。「指定された」とは、図１３における収集データ指定文書１０により指定されているものである。収集データは書く制御装置の動作状態を表しており、制御パラメータであったり、生産設備におけるワークの加工状態であったり、ワークの生産個数を表している。
【０１５４】
ＸＭＬ ＤＢ部７２では、通常のＲＤＢ部においてテーブル構造でデータを管理しているのに対し、各データをツリー構造で管理している。
【０１５５】
Ｑｕｅｒｙ処理部７３は、上位情報系アプリケーションソフトウェア５からの問い合わせを処理するために存在する。ＸＭＬ ＤＢ部７２に格納されたデータの一部、もしくは全部についての問い合わせが処理される。この問い合わせは、例えば実施の形態１３の図２８に示された空ＸＭＬによることができる。また、Ｑｕｅｒｙと呼ばれる標準化問い合わせ言語によることができる。
【０１５６】
実施の形態１４の通信情報変換装置は、次に述べるような生産情報システムを構築する際に有益である。つまり、生産情報システム内に実施の形態１４の通信情報変換装置が複数個配置され、それぞれ別々の制御装置郡からデータ収集を実行する。生産情報システム内には上位情報系アプリケーションソフトウェアとしてリレーショナルデータベースを配置する。このリレーショナルデータベース内に各通信情報変換装置内に格納されたデータを格納するための領域（テーブルと呼ばれる）を設け、予め定められた周期で、各通信情報変換装置が収集し保持している複数のデータの内容を上位情報系アプリケーションソフトウェアとしてのリレーショナルデータベース内の前記領域にコピーする動作をリレーショナルデータベースに設定する。
【０１５７】
これにより、生産情報システム内で収集されたデータはすべて上位情報系アプリケーションソフトウェアであるリレーショナルデータベースに集められる。この結果、リレーショナルデータベース一箇所に集まったデータテーブルに対し、生産管理、品質管理、稼動管理を目的とする演算処理を施すことが可能となる。
【０１５８】
各通信情報変換装置からリレーショナルデータベースへデータをコピーする動作は、レプリケーションと呼ばれるソフトウェア、もしくはデータテーブルのエクスポーネントおよびインポートにより実現可能である。通信情報変換装置が集めたデータはすべてもしくはその一部が取り出されてリレーショナルデータベース内のテーブルにコピーされる。
【０１５９】
以上説明したように実施の形態１４によれば、制御装置の動きを記録しておき、後からその動きを確認する必要が生じた際に、必要な部分を取り出すことができる通信情報変換装置が得られる効果がある。
【０１６０】
【発明の効果】
以上のように、この発明によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。
【０１６１】
この発明によれば、制御装置の動作状態を表すデータは、制御装置がＰＬＣ（プログラマブルロジックコントローラー）のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を８個まとめて１バイトと見立て、これを整数値データとして扱うことがある。一方、これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという課題を解決できる効果が得られる。
【図面の簡単な説明】
【図１】この発明の実施の形態１に係る通信情報変換装置の構成を示す図である。
【図２】実施の形態１の通信情報変換装置を用いた生産情報システムの構成を示す図である。
【図３】実施の形態１の通信情報変換装置の動作を説明するための図である。
【図４】実施の形態１の通信情報変換装置の動作を説明するための図である。
【図５】実施の形態１の通信情報変換装置の動作を示すフローチャートである。
【図６】この発明の実施の形態２に係る通信情報変換装置の構成を示す図である。
【図７】実施の形態２の通信情報変換装置の動作を説明するための図である。
【図８】実施の形態２の通信情報変換装置の動作を示すフローチャートである。
【図９】この発明の実施の形態３に係る通信情報変換装置の構成を示す図である。
【図１０】実施の形態３の通信情報変換装置の動作を説明するためのスクリプトプログラムである。
【図１１】実施の形態３の通信情報変換装置の動作を示すフローチャートである。
【図１２】この発明の実施の形態４に係る通信情報変換装置の構成を示す図である。
【図１３】実施の形態４の他の通信情報変換装置の構成を示す図である。
【図１４】この発明の実施の形態５に係る通信情報変換装置の構成を示す図である。
【図１５】実施の形態５の通信情報変換装置の動作を説明するための図である。
【図１６】実施の形態５の通信情報変換装置の、他の構成例を示す図である。
【図１７】この発明の実施の形態６に係る通信情報変換装置の動作を説明するための図である。
【図１８】実施の形態６に係る通信情報変換装置の動作を説明するための図である。
【図１９】この発明の実施の形態７に係る通信情報変換装置の構成を示す図である。
【図２０】実施の形態７の通信情報変換装置の動作を説明するための図である。
【図２１】この発明の実施の形態８に係る通信情報変換装置の構成を示す図である。
【図２２】この発明の実施の形態９に係る通信情報変換装置の構成を示す図である。
【図２３】この発明の実施の形態１０に係る通信情報変換装置の構成を示す図である。
【図２４】実施の形態１０に係る通信情報変換装置の、他の構成例を示す図である。
【図２５】実施の形態１０に係る通信情報変換装置の動作を説明するための図である。
【図２６】実施の形態１０に係る通信情報変換装置の動作を説明するための図である。
【図２７】この発明の実施の形態１１に係る通信情報変換装置の動作を説明するための図である。
【図２８】この発明の実施の形態１３に係る通信情報変換装置の動作を説明するための図である。
【図２９】この発明の実施の形態１４に係る通信情報変換装置の構成を示す図である。
【符号の説明】
１ 通信情報変換装置、２，２Ａ，２Ｂ，２Ｃ 制御装置、３，３Ａ，３Ｂ，３Ｃ 生産設備、４ 上位情報系コンピュータ、５ 上位情報系アプリケーションソフトウェア、６ 内部バス、７ シリアル回線、８ ＬＡＮ、９ データ収集部（データ収集手段）、１０ 収集データ指定文書、１１ ＸＭＬ化部（ＸＭＬ化手段）、１２ ＸＭＬ変換部（ＸＭＬ変換手段）、１３ ＸＳＬ文書、１４ＸＭＬ文書、１５ 通信アプリケーション部（通信アプリケーション手段）、１６ 全体制御部、１７ 論理名−物理名変換部（論理名−物理名変換手段）、１８ 変換テーブル、１９ スクリプト処理部、２０ スクリプトプログラム、２１ 時計部（計時手段）、２２ グローバル変数部、２３ システム変数部、２４ データ１次処理部、２５ １次処理方法指定文書、２６ スクリプト埋め込みＸＭＬ文書、２７ スクリプト化部、２８ 元データ、２９ 元データ、３０ バイナリーＸＭＬ、３１ フォーマット定義ＸＭＬ文書、３２ エンコード部、３３ デコード部、３４ 送信キューイング部、３５ 送信キュー部、３６プロトコル変換部（プロトコル変換手段）、３７ データフォーマット変換部（データフォーマット変換手段）、３８ 物理現象−論理モデル変換部（物理現象―論理モデル変換手段）、３９ シリアル入出力部、４０ ソケット入出力部、４１ ＳＱＬクライアント、４２ ＳＱＬサーバ、４３ ＳＯＡＰサーバ、４４ ｈｔｔｐクライアント、４５ ｈｔｔｐサーバ、４６ ｆｔｐクライアント、４７ ｆｔｐサーバ、４８ ＳＯＡＰクライアント、４９ ＰＯＰ／ＩＭＡＰサーバ、５０ 制御装置入出力ライブラリ、５１ 制御装置クライアント、５２ｓｍｔｐクライアント、５３ 生データ、５４ データ１次処理部（データ１次処理手段）、５５ 他システム、５６ ＯＤＢＣクライアント、５７ ＩＰＣ２５４Ｘモデル部、５８ ＳＣＭモデル部、５９ 空ＸＭＬクライアント、６０空ＸＭＬサーバ、６１ ＲＤＢ部、６２ 空ＸＭＬ、６３ 充ＸＭＬ、６４ ツリー構造のデータ、７０ 送り側、７１ 受け取り側、７２ ＸＭＬ ＤＢ部、７３ Ｑｕｅｒｙ処理部。
Claims (10)
- 制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、
制御装置のデータを収集するデータ収集部と、
前記データ収集部によって収集されたデータをＸＭＬ文書に変換するＸＭＬ化部と、
前記ＸＭＬ化部によって得られた前記ＸＭＬ文書を、別の形式のＸＭＬ文書に変換するＸＭＬ変換部と、
前記ＸＭＬ変換部によって得られた前記ＸＭＬ文書を上位情報系に伝達する通信アプリケーション部と、
前記ＸＭＬ変換部の動作内容をＸＳＬ文書で記述するＸＳＬ記述部と、
前記データ収集部の動作内容を、どのデータを収集すべきかを指定する収集データ指定部と
を備えたことを特徴とする通信情報変換装置。 - 制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、
制御装置のデータを収集するデータ収集部と、
前記データ収集部によって収集されたデータを格納するＸＭＬ ＤＢ部と、
上位情報系からＸＭＬ ＤＢ部に格納されるデータの一部もしくは全部を取り出すための問い合わせを処理して、当該問い合わせ内容に対応するデータを返答するＱｕｅｒｙ処理部と
を備えたことを特徴とする通信情報変換装置。 - 制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、
制御装置からデータを取得するプログラムを含むスクリプト言語プログラムを用いてＸＭＬ文書を生成し、
もしくはＸＭＬ文書の一部に、前記制御装置からデータを取得するスクリプト言語プログラムを記述したＸＭＬ文書を入力とし、前記スクリプト言語プログラムを出力するスクリプト化部を備え、出力されたスクリプト言語プログラムを用いてＸＭＬ文書を生成し、
前記ＸＭＬ文書を上位情報系に伝達する通信アプリケーション部と
を備えたことを特徴とする通信情報変換装置。 - タイムスタンプ機能およびストップウォッチ機能を有する計時部と、
データの演算処理に供するためのグローバル変数部と、
上位情報系とのデータ通信におけるパラメータを保持するためのシステム変換部と
を備えたことを特徴とする請求項１から請求項３のうちのいずれか１項記載の通信情報変換装置。 - ＸＭＬ文書データを２つ以上のコンピュータ間でやりとりする際、バイナリーフォーマットで転送し、そのフォーマットに格納されるデータのデータ長、データの意味を記述したフォーマット定義ＸＭＬ文書を備えることを特徴とする生産情報システム。
- 収集された生データを演算処理する物理現象−論理モデル変換部と、
前記物理現象−論理モデル変換部により演算処理されたデータのフォーマット形式を変換するデータフォーマット変換部と、
データ通信を処理するためのプロトコル変換部を備え、
前記プロトコル変換部において通信クライアントおよび通信サーバを備えたこと
を特徴とする通信情報変換装置。 - 物理現象−論理モデル変換部において、生産システムの論理モデルを備えることを特徴とする請求項６記載の通信情報変換装置。
- リクエスト応答型タスク、周期起動型タスク、ストップウォッチ型タスク、イベント駆動型タスクの各タスクを複数登録しておき、前記各タスクの起動条件が満たされたときにそれぞれのタスクが起動され処理が実行されることを特徴とする請求項１、請求項２、請求項３、請求項４、請求項６、請求項７のうちのいずれか１項記載の通信情報変換装置。
- データの値が空になったツリー構造データをクライアントから受けとったサーバは、空の値を埋めた前記ツリー構造データをクライアントに返送することを特徴とする生産情報システム。
- 制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、
前記制御装置と前記通信情報変換装置と前記上位情報系は合議制により互いのＩＰアドレス、ＩＰホスト名、マルチキャストアドレスおよびポートの割り当て、およびＬＡＮ内に存在するアプリケーションの自動設定を行うことを特徴とする生産情報システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003154901A JP2004355506A (ja) | 2003-05-30 | 2003-05-30 | 通信情報変換装置およびこれを用いた生産情報システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003154901A JP2004355506A (ja) | 2003-05-30 | 2003-05-30 | 通信情報変換装置およびこれを用いた生産情報システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004355506A true JP2004355506A (ja) | 2004-12-16 |
Family
ID=34049428
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003154901A Pending JP2004355506A (ja) | 2003-05-30 | 2003-05-30 | 通信情報変換装置およびこれを用いた生産情報システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004355506A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006011498A1 (ja) * | 2004-07-28 | 2006-02-02 | Passcell Integration Co., Ltd. | 情報管理方法、情報管理プログラム、及び情報管理装置 |
| JP2009123133A (ja) * | 2007-11-19 | 2009-06-04 | Mitsubishi Electric Corp | 生産情報連携装置 |
| JP2010238084A (ja) * | 2009-03-31 | 2010-10-21 | Fuji Electric Systems Co Ltd | 生産情報管理システム及び方法 |
| JP2010238085A (ja) * | 2009-03-31 | 2010-10-21 | Fuji Electric Systems Co Ltd | 生産情報管理システム |
-
2003
- 2003-05-30 JP JP2003154901A patent/JP2004355506A/ja active Pending
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006011498A1 (ja) * | 2004-07-28 | 2006-02-02 | Passcell Integration Co., Ltd. | 情報管理方法、情報管理プログラム、及び情報管理装置 |
| JP2006065364A (ja) * | 2004-07-28 | 2006-03-09 | Passcell Integration Co Ltd | 情報管理方法、情報管理プログラム、及び情報管理装置 |
| US7941456B2 (en) | 2004-07-28 | 2011-05-10 | Passcell Integration Co., Ltd. | Information management method, information management program and information management apparatus |
| JP2009123133A (ja) * | 2007-11-19 | 2009-06-04 | Mitsubishi Electric Corp | 生産情報連携装置 |
| JP2010238084A (ja) * | 2009-03-31 | 2010-10-21 | Fuji Electric Systems Co Ltd | 生産情報管理システム及び方法 |
| JP2010238085A (ja) * | 2009-03-31 | 2010-10-21 | Fuji Electric Systems Co Ltd | 生産情報管理システム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108351636B (zh) | 工程设计工具、系统及模块 | |
| Jain et al. | Cloud to edge: distributed deployment of process-aware IoT applications | |
| Parekh et al. | Retrofitting autonomic capabilities onto legacy systems | |
| JP6624008B2 (ja) | エンジニアリングツール連携装置、エンジニアリングツール連携方法、エンジニアリングツール連携プログラム及び記録媒体 | |
| JP6663060B2 (ja) | セマンティックゲートウェイのモデリング方法及びセマンティックゲートウェイ | |
| Virta et al. | SOA-Based integration for batch process management with OPC UA and ISA-88/95 | |
| Theiss et al. | Software agents in industry: A customized framework in theory and praxis | |
| US20070198562A1 (en) | Method and Apparatus for Ensuring Business Process Integration Capability for one or more Distributed Component Systems in Communication with one or more Legacy Systems | |
| Trunzer et al. | Graphical modeling notation for data collection and analysis architectures in cyber-physical systems of systems | |
| Erazo-Garzón et al. | A domain-specific language for modeling IoT system architectures that support monitoring | |
| Lam et al. | Dynamical orchestration and configuration services in industrial iot systems: An autonomic approach | |
| Kruger et al. | Evaluation of JADE multi-agent system and Erlang holonic control implementations for a manufacturing cell | |
| US7802235B2 (en) | System and method for tracing and/or evaluating the exchange of information | |
| CN111104181A (zh) | 一种可视化编辑任务流程的网页数据填报系统 | |
| US20110289515A1 (en) | Generating service-access activities for workflow applications | |
| Liu et al. | Engineering information service infrastructure for ubiquitous computing | |
| Prist et al. | Cyber-physical manufacturing systems: An architecture for sensor integration, production line simulation and cloud services | |
| JP2004355506A (ja) | 通信情報変換装置およびこれを用いた生産情報システム | |
| CN112084178A (zh) | 一种数据清洗方法、系统、数据清洗设备和可读存储介质 | |
| Kallab et al. | Using colored Petri nets for verifying RESTful service composition | |
| Dai et al. | Automatic information model generation for industrial edge applications based on IEC 61499 and OPC UA | |
| CN115865680A (zh) | 分布式的设备接入、控制和数据传输的方法及系统、装置 | |
| CN110324280A (zh) | 工业云中的协议配置系统、装置和方法 | |
| JP2008181299A (ja) | 通信エラー情報出力プログラム、通信エラー情報出力方法および通信エラー情報出力装置 | |
| JP6793881B1 (ja) | 管理装置、管理システム、管理方法及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051107 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20071022 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20071022 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20071022 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080709 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080919 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080930 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081128 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081224 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090421 |