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
【解決手段】通信情報変換装置1はデータ収集部9、収集データ指定文書10、XML化部11、XML変換部12、XSL文書13、XML文書14、通信アプリケーション部15、全体制御部16を備えて構成される。この通信情報変換装置1を用いた生産情報システムは、生産設備を制御する制御装置2、生産計画とその進捗の把握、企業内の資源管理を行なう上位情報系アプリケーションソフトウェア5を有する上位情報系コンピュータが備わる。通信情報変換装置1、制御装置2、上位情報系コンピュータ4は内部バス、シリアル回線、LAN等によって接続される。
【選択図】 図1
Description
【発明の属する技術分野】
この発明は、相互にネットワーク接続された生産設備用制御装置および生産情報管理装置により構成される通信情報変換装置、およびこの通信情報変換装置を用いた生産情報システムに関するものである。
【0002】
【従来の技術】
従来の通信情報変換装置は、例えば、特許文献1の図1に示されるような構成を有していた。その動作は、図中にNodeと記された各制御装置からデータを取り出し、通信情報変換装置で通信プロトコル変換、データフォーマットの変換、物理的なデバイス名称と情報システムとして意味づけを持つ論理名称の変換を行なうというものであった。
【0003】
このとき、特許文献1の図3には、制御装置のネットワーク接続の物理的構造の視点から生産設備全体をモデル化したツリー構造と、それとは別の視点からモデル化したツリー構造との間で、同一の概念をあらわすツリーのノード間にリンクを張ることで、そのノードの保持するデータの値の更新が一意に行われ同一性が保たれるとしていた。また、特許文献1の図8および図9においては制御装置の動作状態を表すデータが、生産管理の観点からは異常カウントを表すことを対比付ける方法が得られるとしていた。
【0004】
さらに、特許文献2の図3には、仮想メモリデータ管理部に制御装置類からのデータが保持され、各種アプリケーションが仮想メモリデータ管理部への共通的なアクセス方法に基づいて動作することで、制御装置、或いはデバイスごとのアクセス方法の違いが吸収され統一的にデータを送受することができるとしていた。
【0005】
【特許文献1】
特開2001−251298号公報
【特許文献2】
特開2001−251318号公報
【0006】
【発明が解決しようとする課題】
従来の通信情報変換装置は、複数のツリー構造間に静的にリンクを張る方式でデータを階層的に管理することにしていたため、制御装置の状態を表すデータもしくは制御装置の動作状態を変化させるデータを管理するツリー構造と、それとは別の構造を持つツリー構造の間にリンクを張ることはできるのであるが、それぞれのツリー構造が動的に変化する場合には対応が困難になるという問題があった。例えば制御装置が3台あり、それぞれの制御装置に生産個数を表すデータが存在するとき、生産個数を表現したツリーから3台の制御装置のデータを保持するツリーにリンクを張るが、制御装置台数が増えたときに、2つのツリー構造の間に新たなリンクを自動的には生成することができない。
【0007】
また制御装置の動作状態を表すデータであるが、制御装置がPLC(Programmable Logic Controller)のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を8個まとめて1バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立、不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという課題があった。
【0008】
また、生産量、異常発生回数など生産管理上の論理的な名称と、制御装置および変数の値をリンクさせる際に、生産管理上の論理名をツリー構造ではなくテーブル構造で保持しているため、ツリー構造が本来持っている動的な変化への追従能力を活かせていないという課題があった。
【0009】
また、生産管理上の論理的な名称とリンクさせることに関しては、単に例えば「変数001」を「生産高」とみなすのではなく、論理的な生産管理モデルと現実の生産設備で起きている事象をリンクさせることこそ、真に生産能力、採算性を改善するための様々な手法を用いるために必要となる。しかしながら、従来例は単なる名称の読み替えのみであるため、論理的な生産管理モデルを利用することができないという課題があった。
【0010】
また、ある電気接点が閉じている時間を計測する場合、閉じ終わって開いた時刻から閉じ始めた時刻を減じることで閉じている時間を得ることができるのであるが、単なるツリー間リンクでは、この例に示すような演算処理を表現することはできないという課題があった。
【0011】
またさらに、上記のような演算処理を行なう場合には、現在時刻を与えるタイマー、演算の途中経過或いは前回の演算結果を保持するグローバル変数が必要となる場合があるが、制御装置にそのようなタイマーと変数が存在しないと演算できないという課題があった。
【0012】
さらに、通信情報変換装置から上位情報系の計算機にデータを送信する際、送信間隔が数秒、数百ミリ秒、数十ミリ秒といった短い間隙で送信する場合には、1回の送信データ量が増えるにしたがって、通信路のバンド幅を埋め尽くす可能性が高まる。このとき、本質的にはデータ量が増大するXMLフォーマット(eXtentded Markup Language)を用いることとしているため、その可能性がより高まるという課題があった。
【0013】
一方、アプリケーションから統一的なアクセス手法により制御装置のデータを読み出すことができるとしているのであるが、すでに開発済みのアプリケーションが存在する場合には、そのアプリケーションに手を加える必要があり、変更可能でない場合は接続ができないという課題があった。
【0014】
この発明は、上記のような課題を解決するためになされたものであり、制御装置のデータを表すツリー構造の動的変化への追従が容易である通信情報変換装置の提供を目的とする。
【0015】
【課題を解決するための手段】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置のデータを収集するデータ収集部と、データ収集部によって収集されたデータをXML文書に変換するXML化部と、XML化部によって得られたXML文書を、別の形式のXML文書に変換するXML変換部と、XML変換部によって得られたXML文書を上位情報系に伝達する通信アプリケーション部と、XML変換部の動作内容をXSL文書で記述するXSL記述部と、データ収集部の動作内容を、どのデータを収集すべきかを指定する収集データ指定部とを備えたものである。
【0016】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置のデータを収集するデータ収集部と、データ収集部によって収集されたデータを格納するXML DB部と、上位情報系からXML DB部に格納されるデータの一部もしくは全部を取り出すための問い合わせを処理して、当該問い合わせ内容に対応するデータを返答するQuery処理部とを備えるものである。
【0017】
この発明に係る通信情報変換装置は、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置からデータを取得するプログラムを含むスクリプト言語プログラムを用いてXML文書を生成し、もしくはXML文書の一部に、制御装置からデータを取得するスクリプト言語プログラムを記述したXML文書を入力とし、スクリプト言語プログラムを出力するスクリプト化部を備え、出力されたスクリプト言語プログラムを用いてXML文書を生成し、XML文書を上位情報系に伝達する通信アプリケーション部とを備えるものである。
【0018】
この発明に係る生産情報システムは、XML文書データを2つ以上のコンピュータ間でやりとりする際、バイナリーフォーマットで転送し、そのフォーマットに格納されるデータのデータ長、データの意味を記述したフォーマット定義XML文書を備えるものである。
【0019】
この発明に係る通信情報変換装置は、収集された生データを演算処理する物理現象−論理モデル変換部と、物理現象−論理モデル変換部により演算処理されたデータのフォーマット形式を変換するデータフォーマット変換部と、データ通信を処理するためのプロトコル変換部を備え、プロトコル変換部において通信クライアントおよび通信サーバを備えるものである。
【0020】
この発明に係る生産情報システムは、データの値が空になったツリー構造データをクライアントから受けとったサーバは、空の値を埋めたツリー構造データをクライアントに返送するものである。
【0021】
この発明に係る生産情報システムは、制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、制御装置と通信情報変換装置と上位情報系は合議制により互いのIPアドレス、IPホスト名、マルチキャストアドレスおよびポートの割り当て、およびLAN内に存在するアプリケーションの自動設定を行うものである。
【0022】
【発明の実施の形態】
この発明に係る通信情報変換装置および生産情報システムの実施の一形態について説明する。本発明の通信情報変換装置は、制御装置とは別の筐体で設置され、生産情報システムを構成するものとして説明するが、制御装置と通信情報変換装置は同一筐体、あるいはいわゆるバックプレーン(複数の筐体の物理的合体および電気回路の連結を同時に供する機構)で接合した形態であっても同等の効果を奏する。
【0023】
実施の形態1.
この発明の実施の形態1について図1〜図5を参照して説明する。なお、図1は実施の形態1に係る通信情報変換装置1の構成を示す図であり、図2は実施の形態1の通信情報変換装置1を用いた生産情報システムの構成を示す図である。また、図3および図4は実施の形態1の通信情報変換装置1の動作を説明するための図であり、図5は実施の形態1の通信情報変換装置1の動作を示すフローチャートである。
【0024】
通信情報変換装置1は図1に示すように、データ収集部9、収集データ指定文書10、XML化部11、XML変換部12、XSL文書13、XML文書14、通信アプリケーション部15、全体制御部16とを備えて構成される。それらの動作は後段で詳細に説明する。
【0025】
また、通信情報変換装置1を用いた生産情報システムは、図2に示すように制御装置2A,2B,2C(以下、総称して「制御装置2」と記す)、制御装置2により制御される生産設備3A,3B,3C(以下、総称して「生産設備3」と記す)、生産活動を行なうにあたり、生産計画とその進捗の把握、企業内の資源管理を行なう上位情報系コンピュータ4、上位情報系コンピュータ4内に生産スケジューラーや、ERP(Enterprise Resource Planning)、SCM(Supply Chain Management)等の上位情報系アプリケーションソフトウェア5が備わり構成される。
【0026】
通信情報変換装置1と制御装置2はいくつかの通信路、例えば内部バス6、RS232Cのようなシリアル回線7、或いはLAN8によって情報通信を行なうことができる。LAN8には通信情報変換装置1、制御装置2、上位情報系コンピュータ4が接続されており、これらも相互に情報の交換を行なうことができる。なお、図2中で通信情報変換装置1を1台、制御装置2、生産設備3をそれぞれ3台、上位情報系コンピュータ4を1台で構成した例を示したが、それらの台数に限ることはない。
【0027】
通信情報変換装置1が対象としている生産情報システムは上述のようなものであるが、つぎにその動作について説明する。
【0028】
通信情報変換装置1のデータ収集部9はその動作を開始するとき、もしくはその動作をいったん停止して再開するときに、収集データ指定文書10を読み込む。なお、ここでいう文書とは、コンピュータで処理可能なテキストファイルのことを指している。収集データ指定文書10には収集する対象の制御装置と、収集するデータ、および収集するタイミングの指定、収集するタイミングの指定を記載してある。収集するタイミングとはリクエストがあるごとに一回だけ収集するのか、一定周期でログとして収集するのか、エラー発生時など指定するイベントが発生したとき収集するのか等のタイミングである。データ収集部9が動作を開始すると制御装置2から指定されたデータが読み出され、そのデータはXML化部11に送られる。送るときには、どの制御装置のどの変数かという名称と、実データとを組にして送ることになる。
【0029】
この実施の形態1では共有メモリを用いた実装を説明する。図3に示すように、共有メモリには制御装置内のデータを格納しているデバイス名とその値を配列型変数領域に記録している。なお、ここでいうデバイスとは制御装置のデジタル入出力点と内部変数を総称のことである。
【0030】
図3に示した配列型変数の左側の列には制御装置識別番号とデバイス名を組み合わせた文字列が格納され、右側の列には収集した値を表す文字列が格納されている。デバイス名で「X」とあるのは、制御装置への入力信号のうちの一つを表しており、データ長は1ビットである。「M」とあるのは制御装置の内部変数であり、「Y」とあるのは制御装置の出力信号であり、データ長は1ビットである。「C」とあるのはカウンタ型の特殊な内部変数で、「D」とあるのは内部変数で、「B」とあるのは制御装置間で共有される特殊な共有変数で、データ長は8ビットである。データ収集部9は制御装置からデータ収集した後、この図3に示す配列変数を介してXML化部11にデータを渡すものである。
【0031】
ここで、XML文書について説明する。XML文書はツリー構造で管理されたデータを表記するテキスト形式のデータであり、その表記方法の規約は国際標準化団体であるW3Cにより承認されたものである。その特徴は、すべてテキスト形式で記述すること、データのフィールド名をタグと呼ばれる書式で表現し(タグとは“<”および“>”で文字列を挟んだものである)、データの値を、自分で自由にタグを定義して、開始タグと終了タグ(開始タグのタグ名の前に“/”を付加したもの)で挟んで記述することなどである。
【0032】
例えば、生産量が100個であることを、<生産量>100</生産量>と表記する。また開始タグと終了タグを入れ子にすることでツリー構造が表現でき、例えば、工場内にラインが2つあることを、ツリー構造を用いて表現すると工場ノードの下にライン1ノードとライン2ノードがぶら下がっているように表すとよい。このときXML文書を用いてこのツリー構造を記述すると、<工場><ライン1><生産量>100</生産量></ライン1><ライン2><生産量>200</生産量></ライン2></工場>とすることで、もとのツリー構造を記述できる。なお、XML文書は、改行位置は不問である。
【0033】
例えば、
というように人間が読みやすいように書いても意味はまったく同じである。
【0034】
上記のような工場の構成を考えるとき、ある工場はラインが1本だけの場合や、2本或いは3本である場合があるが、XML文書ではそのような場合に<ライン>タグを増やしたり減らしたりして、この変化に対応する。いわゆるデータベースのテーブルのように、予めラインのフィールドを10個確保しておいて、ラインが3つだけなら、10個のフィールドのうち3つだけ使って残り7つのフィールドは空けておくようなデータ管理とは、その点が異なっている。XML文書はこのような半構造化データを記述する性質を持っているのである。
【0035】
XML文書は、ツリー構造によるデータ管理を行なっているので、ツリー構造を取り扱う数学理論により、XML文書を処理するコンピュータプログラムの自動生成、その演算処理に必要な計算機資源量の把握など、省力化と、いわゆるバグの入り込みにくいソフトウェア高品質化を実現できる可能性が高い。
【0036】
XML化部11では、図3に示す配列をもとにしてXML文書形式のデータを生成する。このアルゴリズムは非常に単純で、デバイス指定パラメータの文字列と、それに対応する値の文字列を配列から読み出して、XMLのタグで挟んで出力するだけである。XMLのタグ名は予め定めておいたものである。図4はXML化部11から出力されたXML文書形式のデータの一例を表している。図4からわかるとおり、制御装置Aのいくつかのデバイスと、その値が、<device>タグを用いて表現されている。
【0037】
つぎに図4に示すXML文書形式のデータはXML変換部12に入力される。XML変換部12はXSL(the eXtensible Style sheet Language)文書13のXSLデータを予め、もしくは図4に示すXML文書形式のデータが入力された直後に読み込む動作を行なう。XSLデータとはインターネット関連技術の標準規約団体であるW3Cにてその仕様が規定されたXML文書の変換ルールの記述方式であり、例えば、
http://www.w3.org/Style/XSL/
で、その仕様の詳細を知ることができる。
【0038】
簡単には例えば次のようなルールが記述される。図4に示したようなXML文書形式のデータの中からdeviceタグのうち、パラメータ部分にDデバイスが記述されているタグで挟まれたデータを取り出して、それらの和をとって、<生産量></生産量>というタグで挟んで出力する、といったルールである。図4のXML文書形式のデータこのルールを適用すると、DデバイスのタグはD01、D02、D03の3つあり、タグで挟まれたデータはそれぞれ12、3、8であるから、それらの和は23となり、<生産量>23</生産量>というXML文書が得られることになり、XML変換部12の出力であるXML文書14は、<生産量>23</生産量>という内容を持つことになる。
【0039】
上述した方式によれば、Dデバイスの数に変化があってもすべてのDデバイスの値が取り出されて、足し算が行われる効果がある。勿論、予め、どのDデバイスを加えるかを決めておくこともできるので、いずれか都合の良いほうを選択することになる。
【0040】
つぎに上述したようにして作成されたXML文書14を読み込んだ通信アプリケーション部15は、予め定められた通信プロトコル(通信手順)を用いて上位情報系アプリケーションソフトウェア5にXML文書14を送信する。通信プロトコルについては、独自のもの、標準的なものを含め、さまざまなものが利用可能である。例えば、FTP(File Transfer Protocol)、HTTP(Hyper Text Transfer Protocol)、SMTP(Simple Mail Transfer Protocol)、POP(Post Office Protocol)、IMAP(Internet Message Access Protocol)に代表される基本的なプロトコルと、これら基本プロトコルを用いた応用プロトコルとしてSOAP(特に略したものではない固有名詞)、或いは独自のものとしてリレーショナル・データベースで用いられるSQLのリモート手順、Java(登録商標)−RMI、MS社DCOMなどの分散オブジェクトの通信手順などが利用可能である。
【0041】
通信相手のOS(Operating System)の違い、通信ソフトウェアの開発言語の違いの吸収、通信路の関係からHTTPプロトコル上でSOAPを利用することが好適であり、本実施の形態1ではこのHTTPプロトコル上のSOAPを使う例で説明する。勿論、目的はXML文書14を上位情報系アプリケーションソフトウェア5に送り届けることであるので、これらの通信手順のどれを用いても目的は達成される。
【0042】
通信プロトコルが決まったとしても、通信アプリケーション部15が通信プロトコル上のクライアントとなる場合と、通信プロトコル上のサーバとなる場合のいずれをも選択できるのであるが、どちらにするか決める必要がある。本実施の形態1では、通信プロトコル上のクライアントとする場合で説明する。
【0043】
SOAPでは、送信したいデータをSOAPボディーと呼ばれる書式で文書として記述することになっている。今回送りたいのはXML文書14であり、すでに文書になっているので、そのままSOAPボディーそのものとして送ることができる。もちろん上位情報系アプリケーションソフトウェア5が所定のSOAPボディー書式を使うことにしている場合は、それに合わせて書き換えればよいのであるが、本実施の形態1ではこの書き換えはXML変換部12で行うことにしており、XML文書14をSOAPボディーとしてそのまま送ることにする。
【0044】
本実施の形態1においては上位情報系アプリケーションソフトウェア5と通信アプリケーション部15はhttpプロトコルを用いてデータ通信を行なう。その概要は上位情報系アプリケーションソフトウェア5ではURL(Uniform Resource Locator)と呼ばれる書式により、これから説明するSOAPによるデータの受け取り口を、予め定めておく。例えば、「putOutputSum」というように決めておく。また、LAN8において、これら通信情報変換装置1や上位情報系アプリケーションソフトウェア5を実行している上位情報系コンピュータ4のLAN8上での識別名も予め定めておく。LAN8上の識別名とは、IP(Internet Protocol)アドレスかホスト名のことをさしている。
【0045】
このとき、上位情報系コンピュータ4のホスト名が、「Master」と定められていたとする。この状態で通信アプリケーション部15は、上位情報系アプリケーションソフトウェア5に対してデータの送信を行なうとき、まずTCP(Transmisshon Control Protocol)ソケットとよばれる仮想的な通信チャンネルをこれら2者の間に張る。通信アプリケーション部15におけるコンピュータプログラムはTCPのソケットをオープンする。その際、「Master」の80番ポートに向けてソケットを張る旨をパラメータとして記述する。TCPソケットが張られた後は、データを送受することができるようになるので、通信アプリケーション部15は、つぎのようにデータを送る。
【0046】
なお、途中の略した部分に図4のXML文書14のデータが送られてくる。
【0047】
このデータ送信が成功すると、上位情報系アプリケーションソフトウェア5からOKという返答につづき、「putOutputSum」という生産量受け取り手順の実行が成功したことを表すデータを返す。これらの手順により、通信アプリケーション部15から上位情報系アプリケーションソフトウェア5に対してデータの送信が完了する。
【0048】
さて、上記の実施の形態1では生産量を合計するため、3つの整数値を加える例について説明したが、さらに複雑な別の実施の形態について述べる。生産設備で利用される制御装置2はいわゆるシーケンサと呼ばれるリレー回路を電子的に置き換えて生産設備の動きをシーケンス制御している。このシーケンサの基本的な入出力単位は1ビット(リレー回路を置き換えているので、ONとOFFの状態を表している)である。このような1ビットの接点を8本集めてきて、生産個数をカウントする整数値を表現することが行われている。このいわば見做し整数値を読み出したいときには、例えば図3に示すX01からX08までの1ビットを8本集めて整数値とみなしてワード型デバイスのD01に整数値を書き込むシーケンスプログラム(ラダープログラム)を記述していたのである。
【0049】
本実施の形態1では、ラダープログラムを記述することなく、XML変換部12において、
という演算を行なうことを、XSL文書13に記述することで代行することができる。
【0050】
生産設備が完成して稼動を始めた後に、上位情報系アプリケーションソフトウェア5でこのような値が必要になったとき、従来ならラダープログラミングのできるプログラマーでなければ対応できなかった。通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費と工期の面で不利であった。これに対し、XSL文書13を書き換える作業は、上位情報系プログラマーが簡単にすばやく作業できる効果がある。なお、従来例のように単にデバイスに向けてリンクを張るだけではこのような演算操作は行えなかった。
【0051】
この例では1ビットを8本集めることを説明したが、これとは逆に生産設備上の要求から、生産設備の動作状態を表すビットデータを複数集めてワードデータにする場合がある。このような複数の情報がパックされたワードデータの中から、1ビットだけ読み出したいことがある。従来はこれを行なうためにラダープログラムが必要であったが、本実施の形態1によればXSL文書13中に、いわゆるビットマスク演算を行うことを記述すれば実現できることになる。上述したようにラダープログラマーと上位情報系プログラマーを同時に稼動させ人件費と工期の面で改善され、上位情報系プログラマーのみで簡単にすばやく作業できる効果がある。従来のように単にデバイスに向けてリンクを張るだけではこのような演算操作は行えないものであった。
【0052】
さて、以上述べてきたデータ収集部9、XML化部11、XML変換部12、通信アプリケーション部15の一連の動作は、全体制御部16が動作させる部位の順番と動作タイミングを制御して行われている。本実施の形態1では、図5に示すようなフローチャートに従っている。図中、左側(START▲1▼、以下同様)が通信情報変換装置1の全体制御部16の動きを、また右側(START▲2▼、以下同様)が上位情報系アプリケーションソフトウェア5においてデータの送受信に関する部分のみの手順を現している。
【0053】
まず上位情報系アプリケーションソフトウェア5の受信手順が開始され、受信待ちに入る(ステップST501)。即ち、図5の右側である。つぎに全体制御部16は、予め定められた一定周期、例えば1時間に1回などの周期で図5の左側の手順を実行する。まずデータ収集部9を動かして、収集データ指定を読み込み(ステップST502)、その指定内容にしたがって、制御装置2からデータを集める(ステップST503)。
【0054】
つぎにXML化部11を動かしXMLデータを作成する(ステップST504)。つぎにXML変換部12を動かして、XSL文書13を読み込んで(ステップST505)、XMLデータを変換しXML文書14を作成して通信アプリケーション部15へと出力する(ステップST506)。つぎに通信アプリケーション部15を動かして、上位情報系アプリケーションソフトウェア5と通信ソケットを張り(ステップST507)、XML文書14を読み込み(ステップST508)、データを送信し(ステップST509)、結果を受信する(ステップST510)。
【0055】
一方、ステップST507の手順を受けて上位情報系アプリケーションソフトウェア5は、ソケットを許可し(ステップST511)、ステップST509に呼応してデータを受信し(ステップST512)、それが完了すると受信結果を送信する(ステップST513)。以上で動作が完了する。
【0056】
なお、この実施の形態1においては、XSL文書13、収集データ指定文書10を書き換えることで上位情報系アプリケーション5の指定するデータフォーマットおよび内容に対応することが可能となる。
【0057】
以上説明したように実施の形態1によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。
【0058】
また、制御装置の動作状態を表すデータであるが、制御装置がPLC(プログラマブルロジックコントローラー)のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を8個まとめて1バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという問題点を解決できる効果が得られる。
【0059】
実施の形態2.
この発明の実施の形態2について図6〜図8を参照して説明する。なお、図6は実施の形態2に係る通信情報変換装置の構成を示す図であり、図7は実施の形態2の通信情報変換装置の動作を説明するための図であり、また、図8は実施の形態2の通信情報変換装置の動作を示すフローチャートである。
【0060】
実施の形態1おいては収集データ指定文書10により指定されたデータが収集され、図3に示すように、どのデバイスであるかを示すデバイス指定パラメータとその値の配列が作成されていた。本実施の形態2においては、図6に示すように実施の形態1の動作のように図3に示す配列が得られた後、論理名−物理名変換部17が変換テーブル18を読み込んで、図3に示すような配列を図7に示す配列に書き換える動作が追加されている。この場合に全体制御部16の動作は、データ収集部9を動かした後、論理名−物理名変換部17を動かし、その後にXML化部11を動かすことになる。
【0061】
この論理名−物理名変換部17の動作について説明すると、制御装置2のデバイスと論理名が1対1に対応する場合には、変換テーブル18は、例えば、
ライン1の生産量=制御装置A.D01
ライン2の生産量=制御装置A.D02
ライン3の生産量=制御装置A.D03
等のような対応関係を記述する。さらに、実施の形態1で説明したように複数のビットデバイスをまとめて整数値として取り扱う場合や、集計を行う場合にはそのような演算が記述される。例えば、次のような記述がなされる。
全体生産量=制御装置A.D01+制御装置A.D02+制御装置A.D03
【0062】
そして、本実施の形態2におけるXSL文書13は、実施の形態1においてデバイス名を記述していた部分が論理名で書けばよいことになり、人間にとっては記述しやすくなり、間違いが起こりにくいという効果が得られる。
【0063】
なお、本実施の形態2では変換テーブル18を数式のような形態で記述する例を示したが、この変換規則をXMLで記述しても同様の効果が得られる。そのXMLは、例えばつぎのようなものである。
【0064】
なお、XMLで変換規則を記述した場合に、全体制御部16よる各部の動かし方を変更することもできる。この場合、収集データ指定文書10は不要となる。
【0065】
つぎにこの場合の全体制御部16の動作について図8のフローチャートに沿って説明する。まず、論理名−物理名変換部17を動かし、変換テーブル18を読み込む(ステップST801)。ここで、制御装置からどのデバイスの値を集めればよいかがわかるので収集データ指定文書10は不要となるのである。この、どのデータを集めるかは論理名−物理名変換部17により抽出され、データ収集部9に送られ、収集動作が行われる(ステップST802)。これ以降は図5の動作と同等であるので説明は省略する。
【0066】
なお、どのデータを集めるかの抽出は、変換テーブル18の中からデバイスを指定する文字列を切り出す方法を用いることができる。さらに別の方法として、Xpath、Xlinkと呼ばれる規約に従った記述を変換テーブル18にて行っておき、論理名−物理名変換部17において、Xpathの記述を処理して、データを取り出すべきデバイスがわかるたびに、データ収集部9を動かしてデータを収集する方法を用いることもできる。この場合、収集データ指定文書10は不要である。
【0067】
この実施の形態2においては、XSL文書13、変換テーブル18、収集データ指定文書10を書き換えることで上位情報系アプリケーションソフトウェア5の指定するデータフォーマットおよび内容に対応することが可能となる。
【0068】
以上説明したように実施の形態2によれば、デバイス名を記述していた部分が論理名で書けばよいことになり、人間にとってはわかりやすいので記述しやすくなり、間違いが起こりにくいという効果が得られる。
【0069】
実施の形態3.
この発明の実施の形態3について図9〜図11を参照して説明する。なお、図9は本発明の実施の形態3に係る通信情報変換装置の構成を示す図であり、図10は実施の形態3の通信情報変換装置の動作を説明するためのスクリプトプログラムであり、また、図11は実施の形態3の通信情報変換装置の動作を示すフローチャートである。
【0070】
実施の形態3に係る通信情報変換装置は図9に示す構成であって、スクリプト処理部19はスクリプトプログラム20を読み込んで、このプログラムに基づく動作を行なうよう構成されている。ここでいうスクリプト処理部は、Perl、Ruby、bsh、ECMA Script、Java(登録商標)Script(JScript)、VBscript、Windows(登録商標) Scripting Host、awk、或いは三菱電機株式会社製のグラフィックオペレーションターミナルGOTシリーズにおけるGOTスクリプト、MS−DOSのバッチコマンドなど、簡単なロジックとシーケンスを記述して処理を実現できるようにした簡易プログラミング言語の処理系のことを指している。
【0071】
ただし、
(1)制御装置2のデバイスを指定し、その値を取得できる書式もしくは組み込み関数もしくは外部手続きの呼び出しする機能
(2)ファイルもしくはメモリ上もしくは標準出力などのファイルストリームに文字列を出力する機能
の2つの機能を最低限装備しておく必要がある。
【0072】
このとき、本実施の形態の通信情報変換装置1は、例えば図10に示すスクリプトプログラム20に従って次のように動作する。図10中、「printf」というのは標準出力ストリームに文字列を、書式付きで出力する命令文を示している。また、「制御装置(2).d(01)」というのは制御装置2のデバイスを指定し、その値を取得できる組み込み関数である。
【0073】
図10に示したスクリプトプログラムは各行が順番に実行される。まず1行目ではXML文書の開始を表す文言が出力される。次の行では「<生産量>」というXMLの開始タグが出力される。次の行では2という制御装置の、01というdデバイスから値が読み出され、同様に02というdデバイス、03というdデバイスから値が読み出され、読み出された3つの値の和が求められ、その値が整数値として文字列で出力される。デバイスから値が読み出される際にはデータ収集部9を動作させることにより、制御装置2からデータが収集され、その値を読み出すことができる。
【0074】
その次の行では、「</生産量>」という終了タグが出力されている。なお、各行の「¥n」とは改行文字をあらわしている。結局、図10に示したスクリプトプログラムの実行結果は次のようなXML文書が生成される。これが図9におけるXML文書14である。
【0075】
<?XML version=“1.0” ?>
<生産量>
123
</生産量>
【0076】
このようにして、制御装置2のデバイスのデータの値を含んで生成されたXML文書14は、通信アプリケーション部15を用いて、上位情報系アプリケーションソフトウェア5に送信される。詳細な説明は実施の形態1と同様であるので省略する。
【0077】
これら一連の手順の制御は全体制御部16により行われる。この手順は図11に示すように、まず全体制御部16はスクリプト処理部19を動作させる。スクリプト処理部19はスクリプトプログラム20を読み込み(ステップST1101)、このスクリプトプログラム20に記述された内容を解釈して実行し(ステップST1102)、XML文書14が生成される(ステップST1103)。このときデータ収集部9は必要になったときに用いられる(ステップST1104)。つぎに全体制御部16は通信アプリケーション部15を動かしてXML文書14を上位情報系アプリケーションソフトウェア5に送出する(ステップST1105〜ステップST118)。
【0078】
以上説明したように実施の形態3によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。さらに、制御装置の動作状態を表すデータは、制御装置がPLC(プログラマブルロジックコントローラー)のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を8個まとめて1バイトと見立て、これを整数値データとして扱うことがある。これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという従来の問題点を解決できる効果が得られる。
【0079】
実施の形態4.
この発明の実施の形態4について図12および図13を参照して説明する。なお、図12は本発明の実施の形態4に係る通信情報変換装置の構成を示す図であり、図13は実施の形態4の他の通信情報変換装置の構成を示す図である。
【0080】
図12に示すよう実施の形態4は、上述した実施の形態1〜3と同様に各部の動きは全体制御部16により制御されている。そして、スクリプト処理部19を用いてスクリプトプログラム20に記載された内容を実行してXML文書14を生成し、通信アプリケーション部15を用いて上位情報系アプリケーションソフトウェア5にXML文書14を送る動作を行なう。
【0081】
このとき、データ収集部9を用いて制御装置2からデバイスのデータを集めると同時に、時計部21、グローバル変数部22を動かすことにより、制御装置2のデバイスの値を読み出すことのみでは得られない情報を作ることができる。例えば、あるデバイスがOFF状態からON状態に変化した時刻、或いはあるデバイスがOFF状態からON状態に変化した瞬間から、再びOFF状態に変化するまでの時間の長さである。
【0082】
これらが必要になるのは本発明の主題である上位情報系アプリケーションソフトウェア5において生産状態の管理を行なうための情報を生産ラインから抽出するときである。上記ではその情報はデバイスの値を読むだけでは得ることができないとしていた。従来例にあるようなツリー間リンクでは得ることはできないので、制御装置においてプログラミングして作り出しているのである。このとき、従来の方式であればラダープログラミングのできるプログラマーでなければ対応できないが、通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費や工期が増大するものであった。
【0083】
本実施の形態4では、このように上位情報系アプリケーションソフトウェアで生産管理、品質管理、稼動管理を行なう際に必要となるデータであって、従来はラダープログラミングすることで生成していたデータを、ラダープログラミング不要で生成するための機能部を設けることを特徴としている。
【0084】
まず時計部21の動きについて説明する。時計部の機能は2つある。ひとつはタイムスタンプ機能である。もうひとつはストップウォッチ機能である。タイムスタンプ機能はスクリプト処理部19にてこの機能を呼び出した瞬間の時刻を返答する機能である。スクリプト処理部19ではこれにより、次のようなときにその瞬間の時刻情報を得ることができ、その時刻情報を上位情報系アプリケーションソフトウェア5に送ることができる。第一に上位情報系アプリケーションソフトウェア5に送るXML文書14を生成した時刻であり、第二に制御装置2のあるデバイスの状態が変化した瞬間の時刻である(ただしスクリプト処理部19はあるデバイスの変化を監視するタスクもしくはプロセスもしくはスレッドを実行しているものとする)。
【0085】
さらにストップウォッチ機能であるが、ストップウォッチによる計測を開始する、停止する、ラップする(一時停止)、リセットする、計時時間を読み出すといった手続きを有している。ストップウォッチ機能は複数のストップウォッチを同時に独立して動かすことができる。このストップウォッチ機能により、制御装置2のあるデバイスがONに変化した瞬間にストップウォッチを計時開始し、OFFに変化した瞬間に計時停止することで、あるデバイスがONしていた時間の長さを計測することができ、それを読み出す手続きを経ることで上位情報系アプリケーションソフトウェア5に送るXML文書14にこの時間長さを含めることができる。
【0086】
つぎにグローバル変数部22について説明する。これは主として制御装置2のデバイスの値の変化を積算もしくは微分計算、移動平均、算術平均などの演算処理を実現する目的で設けられている。例えば生産ラインで処理したワークの個数を数えるのに、ワークを1個処理したときに変化するデバイスの変化回数を積算するために利用する。スクリプトプログラム20の処理が終了し、その後スクリプトプログラム20の処理が再び開始されたときにも前回の結果を残しておくことにも利用できる。
【0087】
これらの処理は予め制御装置2においてラダープログラミングしておけば生成することはできるのであるが、あとからそのような情報がほしいことがわかったときにラダープログラミングのできるプログラマーでなければ対応できない。通常はラダープログラマーと上位情報系プログラマーは別人であるため、人件費と工期が増大するものであった。
【0088】
またグローバル変数部22には、状態遷移モデル機能或いは階層的エラー状態モデルを含めることも可能であり、これを含めた場合の動作を説明する。
まず状態遷移モデルであるが、例えば米国の電子産業業界団体のIPC(http://www.ipc.org/)が定めた製造現場の組み立て機器間の通信メッセージの規約IPC−2541における装置の状態遷移モデルのことを指している。
【0089】
例えば製造装置が電源停止状態から準備状態に移行し、ワークが流れてこないので止まっている、下流工程が詰まっているので止まっている、ワークを加工している、障害が発生している、などの各状態間を遷移していくというモデルである。IPC−2541の規約ではこのような状態遷移モデルの標準仕様を定めている。このような標準的なモデルをたてる目的は、メーカーや目的、作業内容の異なる現場機器を統一的に上位情報系で扱って、管理手法の比較、最適化などを行なうことにある。
【0090】
この発明においてはグローバル変数部22にこのIPC−2541の状態遷移の各状態を製造装置ごとに保持する。そして、この標準化モデルの各状態と、実際の制御装置における複数のデバイスの値の組み合わせを関連付けておき、実際の制御装置2の複数のデバイスの値の組み合わせが変化したとき、標準化モデルの状態も遷移するように構成する。しかるのち、スクリプト処理部19から現在の標準化モデルの遷移の状態を読み出してXML文書14に含めたり、或いは遷移が起きたときにXML文書14の生成を開始することが可能となる。
【0091】
つぎに階層的エラーモデルであるが、品質管理、稼動管理の目的で、生産設備のエラー状態を細かく分類し障害要因を複雑な階層型に分類することが一般的になりつつある。このような複雑な階層型に分類された障害要因モデルと、実際の制御装置の複数のデバイスの値とを関連付けておき、複数のデバイスの値が一致したときにひとつの障害が発生したことにする。しかるのち、スクリプト処理部19から現在の障害要因モデルの状態を読み出してXML文書14に含めたり、或いは障害が起きたときにXML文書14の生成を開始することが可能となる。
【0092】
なお、システム変数部23を設けることもできる。この場合は、上位情報系アプリケーションソフトウェア5との通信にSOAPの手順を用いる際の上位側からのリクエストメッセージに含まれるリクエストヘッダと呼ばれる文字列、とりわけメッセージIDを格納したり、通信情報変換装置のホスト名、リクエストを発行したホスト名、メッセージ番号(読み出すごとに自動生成される)、その他通信情報変換装置ごとに異なる固有情報を読み出すことが可能な変数が複数格納されており、それを読み出して、XML文書14に含めるような動作を行なうことが可能となる。
【0093】
実施の形態4の他の実施の形態について説明する。図13に示すように、この実施の形態はXSL文書13によりXML変換を行なってXML文書14を生成している。この場合は先の例でスクリプト処理部19が行なうこととしていた処理、例えばストップウォッチによる計時を開始したり停止したりする処理を行なうためのデータ1次処理部24を設けている。
【0094】
この実施の形態4によれば、従来であればラダープログラミングの必要な場面であってもラダープログラミングすることなく、上位情報系アプリケーションソフトウェアで必要な情報を収集し生成することが可能となるので、情報システム構築の工数、費用、期間が短縮される効果がある。また、従来では上位情報系から制御装置に対し、いわゆるポーリングを実行することでデバイスの変化している時間を計ることも可能ではあるが、ポーリング時間間隔以上の時間制度が得られず、この発明によればポーリング不要で時間精度も向上する効果がある。
【0095】
実施の形態5.
この発明の実施の形態5について図14〜図16を参照して説明する。なお、図14は本発明の実施の形態5に係る通信情報変換装置の構成を示す図であり、図15は実施の形態5の通信情報変換装置の動作を説明するための図であり、図16は実施の形態5の他の通信情報変換装置の構成を示す図である。
【0096】
図14に示すようにこの実施の形態5の通信情報変換装置には、スクリプト埋め込みXML文書26が用意される。用意するとはプログラマーがテキストエディターなどを用いてこのスクリプト埋め込みXML文書を記述し、記述完了した後、通信情報変換装置に組み込んでおくという意味である。
【0097】
このスクリプト埋め込みXML文書26は図15に示すように、全体的にはXML文書である。そしてその一部(「<%」 と 「%>」で囲まれた部分)に実施の形態3で述べたようなスクリプトの文が記述されていることがわかる。プログラマーの視点からは、通信情報変換装置1にて最終的に生成したいXML文書14のなかで、制御装置2から直接得たデバイスの値、或いはデバイスから得た値を演算して得られるデータ、或いは実施の形態4で説明したデータを含めたい部分について、そのデータを取得もしくは生成するためのスクリプトを埋め込むことができるとみなすことができるものである。
【0098】
さて、スクリプト埋め込みXML文書26はスクリプト化部27に読み込まれて処理が行われる。XML文書として書かれている部分は、その文字列を出力するためのスクリプトプログラムに書き換えられる。例えば、「<生産量>」というタグの部分は、「printf(“<生産量>”);」というように書き換えられる。「<%」と「%>」で囲まれた部分はなんら処理されない。以上の結果、スクリプト化部27からの出力は、図10で示したスクリプトプログラムと同一のものになる。これ以降の動作は実施の形態3と同じであるので省略する。
【0099】
また、図16に示すように、時計部21、グローバル変数部22、システム変数部23を設けることで、制御装置のデバイスの値を読み出すことのみでは得られない情報を作ることができる。これらの部分の動作は実施の形態4と同一のものであるので省略する。
【0100】
以上説明したように実施の形態5によれば、プログラミングをスクリプト埋め込みXML文書26を記述することで情報変換を行なうことができる。これは上位情報系アプリケーションソフトウェア5が要求するXML文書の形式のうち、実データで置き換える部分についてスクリプトプログラミングすればよいということである。したがって、プログラミング効率が向上する効果が得られる。時計部21、グローバル変数部22、システム変数部23を設けた場合は、予めデータを生成する機能が用意されており、それについてはプログラミング不要であるので、さらにプログラミング効率が向上する効果が得られる。
【0101】
実施の形態6.
この発明の実施の形態6について図17および図18を参照して説明する。なお、図17および図18はこの本発明の実施の形態6に係る通信情報変換装置の動作を説明するための図である。
【0102】
図1に示すように通信情報変換装置1から上位情報系コンピュータ4にXML文書14を送ることを考えると、図17に示す実施の形態6においては、送り側70における元データ28が、送られて、受け取り側71における元データ29になることをあらわしている。このとき、送信中の通信路、例えばLAN8上でのデータフォーマットとしてバイナリーXML30を用いることをこの実施の形態6は特徴としている。
【0103】
つぎに、元データ28、29が2つの整数と1つの浮動少数の値を含んでいる例について説明する。このとき、例えば元データ28、29は、
<生産番号>123</生産番号>
<加工結果測定値>234.567</加工結果測定値>
<累積生産個数>23456</累積生産個数>
であるとする。
【0104】
ここで、このようなXML文書の元データ28に対し、この発明を適用しバイナリーXMLを用いる例について説明する。バイナリーXML30としては、図17に示すように、4バイト、8バイト、4バイトの、合計16バイトのデータ並びとして表現することにしてみる。もちろんデータのバイト長さは、取り扱うデータの変動範囲を十分に表せるように選択することはいうまでもない。
【0105】
このとき先頭から4バイトが整数値で、XMLのタグは「<生産番号>」であること、そのつぎの8バイトが不動小数点の値で、XMLのタグは「<加工測定結果>」であること、そのつぎの4バイトが整数値でXMLのタグは「<累積生産個数>」であること、バイト並びのいわゆるエンディアンの大小を記述したフォーマット定義XML文書31が用意しておく。これにより、バイナリーXML30と元データ28および29は、エンコード部32およびデコード部33により一意に相互変換可能となる。
【0106】
このときのフォーマット定義XML文書31を図18に示す。図中「<data>」と記述された部分が3つあり、それぞれが上記の3つのデータの名称、バイト長さ、エンディアン、変数型を定義していることがわかる。
【0107】
なお、上記実施例では送信側の元データ28のXML文書からエンコード部32を介してバイナリーXML30をエンコードすることにしているが、送り側でXML文書の元データ28を作ることなく直接バイナリーXML30を生成して送信することも可能である。この場合は送り出し側にXML生成機能を搭載せず、直接制御装置のメモリマップの一部を送出すれば良いということになる。その際、そのメモリマップの中身をフォーマット定義XML文書にて記述すればよい。
【0108】
以上説明したように実施の形態6によれば、通信情報変換装置から上位情報系の計算機にデータを送信する際、数秒、数百ミリ秒、数十ミリ秒といった短い間隙で送信する場合には、1回の送信データ量が増えるにしたがって、通信路のバンド幅を埋め尽くす可能性に対して、これを減らすことができる効果がある。また、CPU能力、メモリ容量に対して制限の多い制御装置においてテキスト型のXML文書を生成しなくても自身のメモリマップの該当する箇所をそのまま切り出して送ればよいのでCPU、メモリに負荷をかけずに目的を果たせる効果がある。
【0109】
実施の形態7.
この発明の実施の形態7について図19および図20を参照して説明する。なお、図19はこの発明の実施の形態7に係る通信情報変換装置の構成を示す図であり、図20は実施の形態7の通信情報変換装置の動作を説明するための図である。
【0110】
図19において全体制御部16が各部を順次作動させる。まずデータ収集部9を用いて制御装置2からデータが収集される。つぎに通信アプリケーション部15が用いられ、上位情報系アプリケーションソフトウェア5へのデータ送信が試みられる。このときこの実施の形態7においては通信アプリケーション部15の構成として送信キューイング部34と送信キュー部35を備えたことを特徴とする。
【0111】
図20に示すフローチャートに沿って実施の形態7に係る通信情報変換装置の動きを説明する。図20中、2つのシーケンスからなることが示されているが、まず左側のシーケンス(START▲3▼)を説明する。データ収集部9がデータを集め(ステップST2001)、送信キューイング部34が上位情報系アプリケーションソフトウェア5へデータを送信する(ステップST2002)、このとき、送信が完了したかどうかの判定が行われ(ステップST2003)、送信が完了しておれば、シーケンスは完了する。
【0112】
一方、完了していない場合は、送信キュー部35に送ることができなかったデータが格納される(ステップST2004)。完了していない場合とは、途中の通信路、この実施の形態7ではLAN8であるが、この通信路に障害が発生して、データ通信できなくなっている場合か、或いは上位情報系アプリケーションソフトウェア5自体か、またはこれを実行している上位情報系コンピュータ4に障害が発生しておりデータを受け取れない場合等がある。
【0113】
つぎに図20の右側のシーケンス(START▲4▼)について説明する。まず送信キューイング部34を用いて送信キュー部35に蓄えられているデータをひとつ取り出す(ステップST2005)。ここで取り出せたかどうかの判定を行なう(ステップST2006)。もし、なにもデータが蓄えられておらず、取り出すことができない場合は終了する。ひとつ取り出すことに成功した場合はデータ送信を行なう(ステップST2007)。そして送信が完了したかどうかを判定し(ステップST2008)、完了した場合は、そのデータを送信キュー部35から削除する(ステップST2009)。その後、再び最初に戻る。送信に失敗した場合はそのデータを再格納して(ステップST2010)、ステップST2005に戻る。
【0114】
送信キュー部35に格納するデータは、この例ではデータそのものを格納している。これは送信先の上位情報系アプリケーションソフトウェア5がひとつだけであるからである。上位情報系アプリケーションソフトウェアが複数あるときには、その送信先とデータとを組み合わせたものを送信キュー部35に格納すれば対応できる。
【0115】
図20におけるシーケンスは2つあることを説明したが、これら2つは全体制御部16により、その開始が決定されている。左側のシーケンスは、一定周期或いは上位情報系アプリケーションソフトウェア5からリクエストがあったとき、制御装置2で予め定めておいたイベントが発生したとき(往々にして障害が発生したときに報告したいことがある)に実行される。右側のシーケンスは一定周期で実行開始される。
【0116】
以上説明したように実施の形態7によれば、上位情報系アプリケーションソフトウェア5或いはLAN8に障害が発生したときに、送信を後回しにすることが可能となるのでデータが遺失しない通信情報変換装置が得られる効果がある。
【0117】
実施の形態8.
この発明の実施の形態8について図21を参照して説明する。なお、図21はこの発明の実施の形態8に係る通信情報変換装置の構成を示す図である。
【0118】
実施の形態8に係る通信情報変換装置は、プロトコル変換部36と、データフォーマット変換部37、物理現象−論理モデル変換部38の3つの部分から構成されることを特徴としている。さらにこれらの3つの部分はそれぞれより具体的な構成部品を備える。なおこのような概要構成から各部詳細化にむかう設計手法はオブジェクト指向プログラミングにより、実際にソフトウェア開発可能である。
【0119】
3つの部分を順に説明する。まず、プロトコル変換部36の目的は他システム55、すなわち上位情報系アプリケーションソフトウェア5および制御装置2と、この発明の通信情報変換装置の間で行われるデータ通信を処理するための部分である。
【0120】
上位情報系アプリケーションソフトウェア5および制御装置2の種類は数多く存在し、それと同時に、これら他システム55とデータ通信するための手段が数多く必要となる。このときプロトコル変換部36は、シリアル入出力部39、ソケット入出力部40、SQLクライアント41、SQLサーバ42、SOAPサーバ43、httpクライアント44、httpサーバ45、ftpクライアント46、ftpサーバ47、SOAPクライアント48、POP/IMAPサーバ49、制御装置入出力ライブラリ50、制御装置クライアント51、smtpクライアント52といった通信クライアント機能および通信サーバ機能を持った詳細構成部を備えている。
【0121】
図21においてはこれらのうち、httpサーバ45で上位情報系アプリケーションソフトウェア5と通信し、シリアル入出力部39および制御装置入出力ライブラリ50および制御装置クライアント51で制御装置をデータ通信している。
データフォーマット変換部37は、実施の形態1において説明したようなXML文書14の形式変換を行なう。
【0122】
物理現象−論理モデル変換部38は実施の形態4で説明したように、制御装置2のデバイスがON状態にある時間を計ったり、複数のデバイスの値を集計するなどの演算を施したりする部分である。この実施の形態8では制御装置2から集められた生データ53を直接およびデータ1次処理部54にて上記のような演算処理を施した結果をデータフォーマット変換部37に渡している。
【0123】
以上説明したように実施の形態8によれば、複数の種類の上位情報系アプリケーションソフトウェア5および制御装置2と通信可能で、かつデータのフォーマットも送り側のものから受け取り側が理解できる形式へ変換して通信できるとともに単なるデバイスのONとOFFなどで計測される物理現象を、上位情報系アプリケーションソフトウェア5で即刻用いることが可能な論理モデルにもとづくデータに変換することが可能な通信情報変換装置が得られる効果がある。
【0124】
さらに、通信プロトコルの変換、データフォーマットの変換、物理現象の論理モデルへのマッピングをそれぞれ独立してソフトウェアプログラミングできるので、通信相手の追加、利用したい論理モデルの変更、処理したいデータ追加などの機能の追加変更が容易に行えるという効果が得られる。
【0125】
実施の形態9.
この発明に係る実施の形態9について図22を参照して説明する。なお、図22は実施の形態9に係る通信情報変換装置の構成を示す図である。
【0126】
この実施の形態9の目的は制御装置2から例えば製造している製品の品質に関するデータ、具体的には各ワークごとの品質検査結果データなどを入出力するシリアル入出力部39、制御装置入出力ライブラリ50、制御装置クライアント51を介して回収し、得られた生データ53をそのまま、或いはデータ1次処理部54を用いた処理の後、典型的な上位情報系アプリケーションソフトウェア5であるRDB(Relational Data Base)システムに格納することにある。
【0127】
なおRDBとは、全てのデータは関係演算と集合演算で扱うように設計されていて、データは2次元の表として考えられ、互いの表の関連をキーによって擬似的に結合することによって表現される。また、夫々の表はキーによって結ばれ、データの重複を省き効率的にデータ管理ができ、また、データ構造の変更に柔軟に対応することができるデータベースである。
【0128】
まず上位情報系アプリケーションソフトウェア5は、SOAPサーバ43により、通信情報変換装置1からのデータ登録を待っている。通信プロトコルはSOAPを利用することにする。SOAPではいわゆるリモートプロシージャーコール、即ちネットワーク越しに通信相手のソフトウェアの機能を呼び出すことができるのであるが、この実施の形態9においてはSOAPを用いて上位情報系アプリケーションソフトウェア5におけるODBCクライアント56のデータ登録機能をリモートコンピュータから呼び出すことにしている。ここでのリモートコンピュータとは通信情報変換装置1のことである。通信情報変換装置1中のプロトコル変換部36は、このためSOAPクライアント48を備えている。
【0129】
SOAPクライアント48ではSOAPメッセージをSOAPサーバに送りつけて、その処理結果を受け取る動作を行なう。データフォーマット変換部37では、生データをRDB部61に登録するためのSOAPメッセージの生成が行われる。ここでの動作は実施の形態1で説明した動作であり、XSL文書13を用いて生データをXML文書14に変換する。ここでのXML文書14とはSOAPメッセージのことである。
【0130】
以上説明したように実施の形態9によれば、従来パソコンなどでいわゆるSCADAシステムを構成して制御装置2をポーリングすることでデータを回収し、上位情報系アプリケーションソフトウェア5にデータを送っていたが、実施の形態9では制御装置2と密結合した通信情報変換装置1を用いてデータを直送することができるため、上記ポーリング周期以上の頻度でデータ改修することできる効果がある。
【0131】
実施の形態10.
この発明に実施の形態10について図23〜図26を参照して説明する。なお、図23は実施の形態10に係る通信情報変換装置の構成を示す図であり、図24は実施の形態10に係る通信情報変換装置の他の構成を示す図である。また、図25および図26は実施の形態10に係る通信情報変換装置の動作を説明するための図である。
【0132】
実施の形態10では図23に示すように、IPC254Xモデル部57を備えている。IPC254Xとは、米国の電子産業業界団体のIPC(http://www.ipc.org/)が定めた製造現場の組み立て機器間の通信メッセージの規約のことを指しており、実施の形態4で説明している。
【0133】
図25はIPC−2541が規定する製造装置の状態遷移の様子を表している。図25からわかるように、製造装置は、Off、Setup、Blocked、Starved、Active、Executing、Downという7つの状態を持つとしている。したがって、自分の製造装置もしくはその製造装置を制御している制御装置の状態をあらわすデータとして4ビット以上の値を観測すれば、論理モデルにおけるこれら7つの状態のいずれかに自分の製造設備の状態をマッピングできることになる。
【0134】
この実施の形態10において、IPC254Xモデル部57は上記7つの状態のいずれにあるのかを保持しており、データ1次処理部54が生データ53のうちの上記4ビットに相当するデータを観測して、IPC254Xモデル部57の保持する状態を変更するよう構成されている。
【0135】
一方、図24に示すようにデータ1次処理部54と連携したSCMモデル部58が設けられている。SCMとはSupply Chain Managementの略であり、生産管理手法のひとつである。この実施の形態10はSCMを工場内の生産ラインに限定して適用するためのものである。すなわち生産ライン内のどの工程がボトルネックとなって生産速度を律速しているかを発見するために用いる。
【0136】
図26はある製品の製造工程表であり、加工、組み立て、検査工程が表されている。図26中、○印は部品または製品であり、□印は加工組み立て工程、▽印は検査工程である。図26においては、この製品は3つの部品が別々に加工されて、その後ひとつに組み立てられ、検査されて完成している様子を表している。このとき各工程はその処理速度が監視される。また、各工程の前後の矢印の部分は次の工程での処理待ちとなっているワークの個数などが監視される。
【0137】
実施の形態10におけるSCMモデルは図26に示したようなものであり、これは製造ラインごとに異なるものである。このとき、制御装置2から集めたデータをもとに各工程の処理速度、および工程前後の滞留数を1次処理により計算することができる。
【0138】
以上説明したように実施の形態10によれば、生産ラインのトータルの処理能力を向上させるためにはボトルネックを発見する必要があるが、滞留数の一覧表を、図1に示す上位情報系コンピュータ4の画面に表示するなどして、このボトルネックを発見することが可能な生産情報システムを構成することができる効果がある。
【0139】
実施の形態11.
この発明に係る実施の形態11について図27を参照して説明する。なお、図27は実施の形態11に係る通信情報変換装置の動作を説明するための図である。
【0140】
上述した実施の形態1および実施の形態の形態8における通信情報変換装置1の全体制御部16において、リクエスト応答型タスク、周期起動型タスク、ストップウォッチ型タスク、イベント駆動型タスクの各タスクを複数登録しておき、各タスクの起動条件が満たされたときにそれぞれのタスクが起動して処理内容が実行されることを特徴としている。夫々のタスクとその処理内容は図27に示すとおりである。
【0141】
以上説明したように実施の形態11によれば、タスクを登録しなおすことでさまざまな動作を行わせることができる通信情報変換装置が得られる効果がある。
【0142】
実施の形態12.
この発明の実施の形態12について説明する。なお、ここでは図1を参照することとする。
図1に示すようなLAN8で相互接続されたシステムにおいては、近年Ethernet(登録商標)上でTCP/IP通信を行うことが一般的となった。しかしながら、TCP/IPのネットワークを設営するためにはネットワーク設計作業が必要となる。この作業にはネットワークの専門知識が必要である。本発明の通信情報変換装置、制御装置、上位情報系コンピュータはつぎのような機能を備えることで上記専門知識を持った作業員を不要としている。
【0143】
(1)IPアドレスの合議制割り当て
(2)IPホスト名の合議制割り当て
(3)マルチキャストアドレス、ポートの合議制割り当て
(4)RDBシステムとそのクライアントなどLAN内に存在するアプリケーションの自動設定
ここで合議制とはたとえば制御装置間でその都度もうし合わせて、お互いのIPアドレスの割り当てを自動的に決定するようなことをさしている。
【0144】
以上説明したように実施の形態12によれば、ネットワークの専門知識を持った設営作業員の存在を不要とする効果が得られる。
【0145】
実施の形態13.
この発明に係る実施の形態13について図28を参照して説明する。なお、図28はこの実施の形態13に係る通信情報変換装置の動作を説明するための図である。
【0146】
実施の形態13は制御装置2の保持するデータをツリー構造で管理することを特徴とする通信情報変換装置である。このとき制御装置2は次のようなツリー構造のデータ64を管理しているとする。
【0147】
<A>
<B>値1</B>
<C>
<D>値2</D>
<E>値3</E>
</C>
</A>
【0148】
値1、値2、値3の3つの値が上記のツリー構造で管理されているとする。このとき、ツリー構造に含まれる、あるデータを読み出す際の方式に関する実施の形態が図28に示されている。
【0149】
例えば値2を知りたいとき、送り側70の空XMLクライアント59は、
<A>
<C>
<D></D>
</C>
</A>
というXML文書を生成して(これを空XML62と呼ぶことにする)、受け取り側71の空XMLサーバ60に送りつける。
【0150】
空XMLサーバ60はこれを受け取って、内容を解釈し、<D></D>の部分に実データを書き込めばよいことを知り、受け取り側71は下記のように値を書き込んで送り側70の空XMLクライアント59に返送する。
<A>
<C>
<D>123.456</D>
</C>
</A>
これを充XML63と呼ぶことにする。
【0151】
以上説明したように実施の形態13によれば、ツリー構造でデータを管理する設計だけを行えば、それらの値をリモートコンピュータから取得するプロトコルとそれを扱うミドルウェアおよびそのAPI(Application Program Interface:ミドルウェアを呼び出す関数名のリスト)が上記のごとく自動的に得られるので、プロトコル、ミドルウェア及びそのAPIの設計が不要となる効果がある。
【0152】
実施の形態14.
この発明に係る実施の形態14について図29を参照して説明する。なお、図29はこの実施の形態14に係る通信情報変換装置の構成を示す図である。
【0153】
図29において、データ収集部9は、制御装置2A、2B、2Cから指定されたデータの収集を行い、XML DB部72にそのデータを格納する。「指定された」とは、図13における収集データ指定文書10により指定されているものである。収集データは書く制御装置の動作状態を表しており、制御パラメータであったり、生産設備におけるワークの加工状態であったり、ワークの生産個数を表している。
【0154】
XML DB部72では、通常のRDB部においてテーブル構造でデータを管理しているのに対し、各データをツリー構造で管理している。
【0155】
Query処理部73は、上位情報系アプリケーションソフトウェア5からの問い合わせを処理するために存在する。XML DB部72に格納されたデータの一部、もしくは全部についての問い合わせが処理される。この問い合わせは、例えば実施の形態13の図28に示された空XMLによることができる。また、Queryと呼ばれる標準化問い合わせ言語によることができる。
【0156】
実施の形態14の通信情報変換装置は、次に述べるような生産情報システムを構築する際に有益である。つまり、生産情報システム内に実施の形態14の通信情報変換装置が複数個配置され、それぞれ別々の制御装置郡からデータ収集を実行する。生産情報システム内には上位情報系アプリケーションソフトウェアとしてリレーショナルデータベースを配置する。このリレーショナルデータベース内に各通信情報変換装置内に格納されたデータを格納するための領域(テーブルと呼ばれる)を設け、予め定められた周期で、各通信情報変換装置が収集し保持している複数のデータの内容を上位情報系アプリケーションソフトウェアとしてのリレーショナルデータベース内の前記領域にコピーする動作をリレーショナルデータベースに設定する。
【0157】
これにより、生産情報システム内で収集されたデータはすべて上位情報系アプリケーションソフトウェアであるリレーショナルデータベースに集められる。この結果、リレーショナルデータベース一箇所に集まったデータテーブルに対し、生産管理、品質管理、稼動管理を目的とする演算処理を施すことが可能となる。
【0158】
各通信情報変換装置からリレーショナルデータベースへデータをコピーする動作は、レプリケーションと呼ばれるソフトウェア、もしくはデータテーブルのエクスポーネントおよびインポートにより実現可能である。通信情報変換装置が集めたデータはすべてもしくはその一部が取り出されてリレーショナルデータベース内のテーブルにコピーされる。
【0159】
以上説明したように実施の形態14によれば、制御装置の動きを記録しておき、後からその動きを確認する必要が生じた際に、必要な部分を取り出すことができる通信情報変換装置が得られる効果がある。
【0160】
【発明の効果】
以上のように、この発明によれば、従来の通信情報変換装置が抱えていた問題を解決し、制御装置台数が増減するときの変化にたえることができるなど、ツリー構造でデータを表すことによる追従能力を生かす効果が得られる。
【0161】
この発明によれば、制御装置の動作状態を表すデータは、制御装置がPLC(プログラマブルロジックコントローラー)のような複数の電気接点の開閉を入出力するタイプの場合、電気接点を8個まとめて1バイトと見立て、これを整数値データとして扱うことがある。一方、これとは逆に整数値データのうちのひとつのビットを、ある種の条件の成立不成立を表していることに見立てる場合が有る。これらのことが必要になった場合、単にツリー間でリンクを張ることだけでは、それを実現することはできないという課題を解決できる効果が得られる。
【図面の簡単な説明】
【図1】この発明の実施の形態1に係る通信情報変換装置の構成を示す図である。
【図2】実施の形態1の通信情報変換装置を用いた生産情報システムの構成を示す図である。
【図3】実施の形態1の通信情報変換装置の動作を説明するための図である。
【図4】実施の形態1の通信情報変換装置の動作を説明するための図である。
【図5】実施の形態1の通信情報変換装置の動作を示すフローチャートである。
【図6】この発明の実施の形態2に係る通信情報変換装置の構成を示す図である。
【図7】実施の形態2の通信情報変換装置の動作を説明するための図である。
【図8】実施の形態2の通信情報変換装置の動作を示すフローチャートである。
【図9】この発明の実施の形態3に係る通信情報変換装置の構成を示す図である。
【図10】実施の形態3の通信情報変換装置の動作を説明するためのスクリプトプログラムである。
【図11】実施の形態3の通信情報変換装置の動作を示すフローチャートである。
【図12】この発明の実施の形態4に係る通信情報変換装置の構成を示す図である。
【図13】実施の形態4の他の通信情報変換装置の構成を示す図である。
【図14】この発明の実施の形態5に係る通信情報変換装置の構成を示す図である。
【図15】実施の形態5の通信情報変換装置の動作を説明するための図である。
【図16】実施の形態5の通信情報変換装置の、他の構成例を示す図である。
【図17】この発明の実施の形態6に係る通信情報変換装置の動作を説明するための図である。
【図18】実施の形態6に係る通信情報変換装置の動作を説明するための図である。
【図19】この発明の実施の形態7に係る通信情報変換装置の構成を示す図である。
【図20】実施の形態7の通信情報変換装置の動作を説明するための図である。
【図21】この発明の実施の形態8に係る通信情報変換装置の構成を示す図である。
【図22】この発明の実施の形態9に係る通信情報変換装置の構成を示す図である。
【図23】この発明の実施の形態10に係る通信情報変換装置の構成を示す図である。
【図24】実施の形態10に係る通信情報変換装置の、他の構成例を示す図である。
【図25】実施の形態10に係る通信情報変換装置の動作を説明するための図である。
【図26】実施の形態10に係る通信情報変換装置の動作を説明するための図である。
【図27】この発明の実施の形態11に係る通信情報変換装置の動作を説明するための図である。
【図28】この発明の実施の形態13に係る通信情報変換装置の動作を説明するための図である。
【図29】この発明の実施の形態14に係る通信情報変換装置の構成を示す図である。
【符号の説明】
1 通信情報変換装置、2,2A,2B,2C 制御装置、3,3A,3B,3C 生産設備、4 上位情報系コンピュータ、5 上位情報系アプリケーションソフトウェア、6 内部バス、7 シリアル回線、8 LAN、9 データ収集部(データ収集手段)、10 収集データ指定文書、11 XML化部(XML化手段)、12 XML変換部(XML変換手段)、13 XSL文書、14XML文書、15 通信アプリケーション部(通信アプリケーション手段)、16 全体制御部、17 論理名−物理名変換部(論理名−物理名変換手段)、18 変換テーブル、19 スクリプト処理部、20 スクリプトプログラム、21 時計部(計時手段)、22 グローバル変数部、23 システム変数部、24 データ1次処理部、25 1次処理方法指定文書、26 スクリプト埋め込みXML文書、27 スクリプト化部、28 元データ、29 元データ、30 バイナリーXML、31 フォーマット定義XML文書、32 エンコード部、33 デコード部、34 送信キューイング部、35 送信キュー部、36プロトコル変換部(プロトコル変換手段)、37 データフォーマット変換部(データフォーマット変換手段)、38 物理現象−論理モデル変換部(物理現象―論理モデル変換手段)、39 シリアル入出力部、40 ソケット入出力部、41 SQLクライアント、42 SQLサーバ、43 SOAPサーバ、44 httpクライアント、45 httpサーバ、46 ftpクライアント、47 ftpサーバ、48 SOAPクライアント、49 POP/IMAPサーバ、50 制御装置入出力ライブラリ、51 制御装置クライアント、52smtpクライアント、53 生データ、54 データ1次処理部(データ1次処理手段)、55 他システム、56 ODBCクライアント、57 IPC254Xモデル部、58 SCMモデル部、59 空XMLクライアント、60空XMLサーバ、61 RDB部、62 空XML、63 充XML、64 ツリー構造のデータ、70 送り側、71 受け取り側、72 XML DB部、73 Query処理部。
Claims (10)
- 制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、
制御装置のデータを収集するデータ収集部と、
前記データ収集部によって収集されたデータをXML文書に変換するXML化部と、
前記XML化部によって得られた前記XML文書を、別の形式のXML文書に変換するXML変換部と、
前記XML変換部によって得られた前記XML文書を上位情報系に伝達する通信アプリケーション部と、
前記XML変換部の動作内容をXSL文書で記述するXSL記述部と、
前記データ収集部の動作内容を、どのデータを収集すべきかを指定する収集データ指定部と
を備えたことを特徴とする通信情報変換装置。 - 制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、
制御装置のデータを収集するデータ収集部と、
前記データ収集部によって収集されたデータを格納するXML DB部と、
上位情報系からXML DB部に格納されるデータの一部もしくは全部を取り出すための問い合わせを処理して、当該問い合わせ内容に対応するデータを返答するQuery処理部と
を備えたことを特徴とする通信情報変換装置。 - 制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、
制御装置からデータを取得するプログラムを含むスクリプト言語プログラムを用いてXML文書を生成し、
もしくはXML文書の一部に、前記制御装置からデータを取得するスクリプト言語プログラムを記述したXML文書を入力とし、前記スクリプト言語プログラムを出力するスクリプト化部を備え、出力されたスクリプト言語プログラムを用いてXML文書を生成し、
前記XML文書を上位情報系に伝達する通信アプリケーション部と
を備えたことを特徴とする通信情報変換装置。 - タイムスタンプ機能およびストップウォッチ機能を有する計時部と、
データの演算処理に供するためのグローバル変数部と、
上位情報系とのデータ通信におけるパラメータを保持するためのシステム変換部と
を備えたことを特徴とする請求項1から請求項3のうちのいずれか1項記載の通信情報変換装置。 - XML文書データを2つ以上のコンピュータ間でやりとりする際、バイナリーフォーマットで転送し、そのフォーマットに格納されるデータのデータ長、データの意味を記述したフォーマット定義XML文書を備えることを特徴とする生産情報システム。
- 収集された生データを演算処理する物理現象−論理モデル変換部と、
前記物理現象−論理モデル変換部により演算処理されたデータのフォーマット形式を変換するデータフォーマット変換部と、
データ通信を処理するためのプロトコル変換部を備え、
前記プロトコル変換部において通信クライアントおよび通信サーバを備えたこと
を特徴とする通信情報変換装置。 - 物理現象−論理モデル変換部において、生産システムの論理モデルを備えることを特徴とする請求項6記載の通信情報変換装置。
- リクエスト応答型タスク、周期起動型タスク、ストップウォッチ型タスク、イベント駆動型タスクの各タスクを複数登録しておき、前記各タスクの起動条件が満たされたときにそれぞれのタスクが起動され処理が実行されることを特徴とする請求項1、請求項2、請求項3、請求項4、請求項6、請求項7のうちのいずれか1項記載の通信情報変換装置。
- データの値が空になったツリー構造データをクライアントから受けとったサーバは、空の値を埋めた前記ツリー構造データをクライアントに返送することを特徴とする生産情報システム。
- 制御装置、通信情報変換装置、上位情報系から構成される生産情報システムにおいて利用される通信情報変換装置であって、
前記制御装置と前記通信情報変換装置と前記上位情報系は合議制により互いのIPアドレス、IPホスト名、マルチキャストアドレスおよびポートの割り当て、およびLAN内に存在するアプリケーションの自動設定を行うことを特徴とする生産情報システム。
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 | 生産情報連携装置 |
JP2010238085A (ja) * | 2009-03-31 | 2010-10-21 | Fuji Electric Systems Co Ltd | 生産情報管理システム |
JP2010238084A (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 | 生産情報連携装置 |
JP2010238085A (ja) * | 2009-03-31 | 2010-10-21 | Fuji Electric Systems Co Ltd | 生産情報管理システム |
JP2010238084A (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 | |
Milenkovic | Internet of Things: Concepts and System Design | |
Parekh et al. | Retrofitting autonomic capabilities onto legacy systems | |
JP6624008B2 (ja) | エンジニアリングツール連携装置、エンジニアリングツール連携方法、エンジニアリングツール連携プログラム及び記録媒体 | |
JP6663060B2 (ja) | セマンティックゲートウェイのモデリング方法及びセマンティックゲートウェイ | |
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 | |
Erazo-Garzón et al. | A domain-specific language for modeling IoT system architectures that support monitoring | |
Trunzer et al. | Graphical modeling notation for data collection and analysis architectures in cyber-physical systems of systems | |
Kruger et al. | Evaluation of JADE multi-agent system and Erlang holonic control implementations for a manufacturing cell | |
Lam et al. | Dynamical orchestration and configuration services in industrial iot systems: An autonomic approach | |
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 | |
Dai et al. | Automatic information model generation for industrial edge applications based on IEC 61499 and OPC UA | |
Prist et al. | Cyber-physical manufacturing systems: An architecture for sensor integration, production line simulation and cloud services | |
JP2004355506A (ja) | 通信情報変換装置およびこれを用いた生産情報システム | |
Vierhauser et al. | GRuM—A flexible model-driven runtime monitoring framework and its application to automated aerial and ground vehicles | |
CN112084178A (zh) | 一种数据清洗方法、***、数据清洗设备和可读存储介质 | |
CN110324280A (zh) | 工业云中的协议配置***、装置和方法 | |
JP2008181299A (ja) | 通信エラー情報出力プログラム、通信エラー情報出力方法および通信エラー情報出力装置 | |
JP6793881B1 (ja) | 管理装置、管理システム、管理方法及びプログラム | |
CN102104612A (zh) | 基于移动智能代理的远程监护***及方法 | |
Velesaca et al. | Optimizing Smart Factory Operations: A Methodological Approach to Industrial System Implementation based on OPC-UA |
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 |