JP2006099809A - コントローラ - Google Patents

Abstract

【課題】 ＰＬＣと上位コンピュータはそれぞれコントローラと通信することにより、相手の状態を認識し、制御命令を送ることができるコントローラを提供すること
【解決手段】 コンピュータ２とＰＬＣ１との間に介在するコントローラである。ネットワーク接続可能な複数の通信部１１と、共有メモリ２８と、通信部を介して送受するデータにより、共有メモリとＰＬＣ内のメモリ１ａに同一の情報を記憶させる制御部１２（データ共有部３２）を備えた。これにより、コンピュータがＰＬＣの状態を知りたい場合には、コンピュータとの間で通信することにより取得できる。また、共有メモリに格納すると、ＰＬＣに対して制御命令を送ることができる。
【選択図】 図５

Description

本発明は、コントローラに関するもので、より具体的には、コンピュータとＰＬＣとの間に介在するコントローラに関する。

ＦＡシステム等において各種の制御をする場合、例えば、ＰＬＣにセンサ等を接続し、そのセンサで検出した情報をＰＬＣで解析し、その解析結果に基づいてＰＬＣの制御対象の機器に対して制御命令を送り、所定の作業を実行するようになっている。

そして、システム構成としては、ＰＬＣ単独で動作するスタンドアロンや、ネットワークで接続された複数台のＰＬＣを用いて、同期・協調制御等を行う方式などがある。また、協調制御等を行う場合に、図１に示すように、複数のＰＬＣ１を上位のコンピュータ（パソコン等）２にネットワーク接続し、その上位のコンピュータ２を介して、他のＰＬＣ１に対する情報の伝達を行うようにしたものもある。

ところで、従来のＰＬＣの利用方法としては、制御対象機器に対する装置制御がメインであり、ＰＬＣの上位にコンピュータが接続される場合でも、ＰＬＣ１，パソコン２の役割はあくまでも装置制御用の補助的な役割であった。

一方、製造現場にパソコンが広く普及し出している現在の状況から、及びパソコン自体に情報管理機能があることから、図示した上位のコンピュータを接続したシステム構成において、ＰＬＣ１は、自己に接続された装置（制御対象機器，センサ等）３との間で装置制御のための情報の伝送を行いつつ、上位コンピュータ２との間で情報の送受を行い、コンピュータ２側では、装置３から上がってくるデータ（センサで検出したデータや、制御対象機器の稼動状態等のデータ）を受け取り、そこにおいて各種の管理を行ったり、ユーザーがその受け取ったデータを加工したりできるようなシステムの開発が望まれている。

ところで、係る情報管理を上位のコンピュータ２で行うようにした場合、以下のような問題があり、実現性に欠ける。すなわち、図１には便宜上コンピュータ２に対し、２つのＰＬＣ１が接続され、各ＰＬＣ１はそれぞれ１つずつの装置（制御対象機器，センサ等）３が接続された例を示したが、実際には、各ＰＬＣ１には複数の装置が接続され、さらに、上位のコンピュータ２に接続されるＰＬＣ１も多数存在する。従って、上位のコンピュータ２でネットワーク管理化におけるＰＬＣ１，装置３の情報管理をするためには、コンピュータ２が全ての制御情報を扱うことになり、非常に負荷が高く、これにより、システムのボトルネックが発生することになる。さらに、上位のコンピュータ２がダウンすると、システム全体のダウンにつながり、システムの安定性に欠け、危険性も高い。

そこで、上記のように製造現場にパソコンが広く普及し、パソコン（上位コンピュータ）２の役割が「装置制御用の補助装置」から「装置から上がってくるデータをユーザーが自由に加工する端末」というものに変化するにつれて、ＰＬＣ１の役割も「装置制御」のみならず「装置制御＋上位コンピュータへのデータ受け渡し（情報管理）」へ切り替えることが望まれる。

しかしながら、ＰＬＣ１の動作を制御するプログラムは、「ラダーシーケンス」であり、これは装置などの動作制御を得意とした言語であり、情報管理には不向きであり、これを行おうとするには、かなり複雑なラダーシーケンスを書かなければならない。このため、システムの開発工数が非常に膨大になり、またメンテナンスも困難になっている。

しかも、ＰＬＣで動作するラダーシーケンスの習熟は多大な労力と時間がかかり、さらに、上記のラダーシーケンスにとって不得手な情報管理のプログラムを組むのは非常に困難である。

さらには、ネットワーク接続された複数のＰＬＣ１が、異なるメーカの製品であることがある。すると、ＰＬＣとネットワークを接続するための仕様・方式は、各社各様のため、上位コンピュータと各社のＰＬＣを接続するためには、接続するＰＬＣを調べ、コンピュータ２側で各ＰＬＣ１に合わせたプロトコル等を使用して通信を行う必要があり、煩雑となる。特に、システムが大型化し、接続されるＰＬＣ１や上位コンピュータ２の数が増えるほど、異なるメーカの製品が混在する可能性が高くなり、上記問題が顕著となる。

さらに、ＰＬＣ１と接続する上位のコンピュータ２にはパソコンが用いられることが多い。しかし、現在市販されている汎用のパソコンの仕様・スペックでは、ＦＡ現場で求められている信頼性を満たせないことが多く、パソコンを使用したくても使用できない場合がある。

本発明は、上記した背景に鑑みてなされたもので、その目的とするところは、上記した問題を解決し、ＰＬＣと上位コンピュータはそれぞれコントローラと通信することにより、コントローラを介して相手の状態を認識したり、制御命令を送ることができ、相手の通信プロトコルや、動作状況を意識することなくそれぞれが稼働することができ、情報収集・管理などのＰＬＣ（ラダーシステム）が不得手でしかもコンピュータに任せると過負荷になるような処理を実施することにより、係る相反する２つの問題を解決することのできるコントローラを提供することにある。

上記した目的を達成するために、本発明に係るコントローラでは、コンピュータとＰＬＣとの間に介在するコントローラであって、ネットワーク接続可能な通信部と、前記通信部を介して前記ＰＬＣの情報を収集する収集機能部と、その収集機能部により収集した情報を記憶する収集情報記憶部と、収集したいデータエリアを複数設定した情報と当該データエリア毎に収集タイミングを設定した情報とを記憶する記憶部を備え、前記収集機能部は、前記記憶部に記憶されたデータエリア毎の収集タイミングにしたがって前記ＰＬＣの情報を収集するように構成した。

また、前記収集情報記憶部に記憶された情報を、Ｗｅｂブラウザで閲覧できる形式に変換する機能を備え、前記コンピュータからＷｅｂブラウザで前記収集情報記憶部に記憶された情報を閲覧可能とするように構成するとよい。

このように構成すると、収集機能部により、接続されるＰＬＣの情報を取得でき、コントローラで集中管理ができる。つまり、ラダーシステムで稼働するＰＬＣは、情報管理が苦手であるが、本発明ではそれに替わってコントローラが情報管理ができるので、ＰＬＣは、本来の制御を実行すれば良くなる。なお、転送する機能は、コントローラ側が自発的にデータ送信する場合と、コンピュータからのアクセスにしたがって送信する機能などがある。

本発明に係るコントローラでは、ＰＬＣの苦手な情報収集を行うことができるので、ＰＬＣは得意な制御を実行すれば良くなる。また、上位のコンピュータがＰＬＣの状態を知る場合には、コントローラを見に行けば良いので、ＰＬＣを直接制御する必要もなく、上位コンピュータに負荷が集中することもない。

図２は、本発明が適用されるシステム構成の一例を示している。同図に示すように、本形態では、ＰＬＣ１と上位コンピュータ２との間に、コントローラたるオープンコントローラ１０を介在させ、そのオープンコントローラ１０を介してＰＬＣ１と上位コンピュータ２との間の情報の送受を行うようにしている。さらに、情報管理などのＰＬＣ１の不得手な処理をオープンコントローラ１０で実行するようにした。なお、本形態では、色々な種類のネットワークに自由に接続可能なコントローラという意味で、オープンネットワークコントローラ、略してオープンコントローラと称するようにしているが、その名称にとらわれないのは言うまでもない。

そして、オープンコントローラ１０と上位コンピュータ２との間は、イーサネット（登録商標）等の汎用ネットワーク５で接続するようにした。これにより、例えば複数の上位コンピュータ２がイーサネット（登録商標）５によりＬＡＮ接続されているような場合、オープンコントローラ１０を簡単に接続することができる。また、オープンコントローラ１０とＰＬＣ１とは、ＲＳ２３２Ｃ，フィールドバスその他の各種の通信プロトコルにより接続される。

つまり、オープンコントローラ１０を介在させることで、ＰＬＣ１が接続されるネットワーク，通信ケーブルにおける通信プロトコルと、上位コンピュータ２が接続されるネットワークの通信プロトコルが異なっていても、その相違をオープンコントローラ１０で吸収することができ、ＰＬＣ１，上位コンピュータ２がそれぞれ従来から行っていた通信プロトコルを用いて情報の送受が行える。さらには、ＰＬＣ１同士であっても異なる通信プロトコルのネットワークに接続される場合には、その異なる通信プロトコルがともにオープンコントローラ１０に対応するものであると、そのオープンコントローラ１０を介して情報の送受が行える。このことは、ＰＬＣ１同士に限らず、他の機器との間でも言える。

そして、上記した各機能を実現するためのオープンコントローラ１０の内部構造（ハードウエア）としては、図３に示すようになっており、また、ソフトウェアから見ると、図４に示すようになる。

すなわち、複数の通信プロトコルに対応するため、各通信プロトコルに応じた接続端子（コネクタ）等を持つ通信部１１と、各通信部１１を介して受信したデータを解析し、必要な処理をしたり、その受け取ったデータの真の送信先（相手先）が、他の機器の場合には、その送信先を認識し、対応する通信部１１に向けてデータを送信するなどの各種制御を行う制御部１２と、各種データを記憶しておくメモリ１３並びに補助記憶装置１４を備えている。

通信部１１としては、本形態では、イーサネット通信部１１ａ，シリアル通信部１１ｂ（ＲＳ２３２Ｃは、このシリアル通信部１１ｂを介して接続される。），フィールドバス通信部１１ｃ，ＦＡネットワーク通信部１１ｄを備え、さらに拡張通信部１１ｅを備えている。なお、特に分ける必要がない場合には、総称して単に通信部１１と称する。各通信部１１の構成は、それぞれ一般に用いられているものを組み込むことになる。なお、本形態では、通信部として複数種類に対応するようにしたが、本発明はこれに限ることはなく、少なくとも１つあれば良い。

そして、各通信部１１には、それぞれ所定の通信ケーブルを介して各種装置・機器が接続される。具体的には、イーサネット通信部１１ａには、イーサネット（登録商標）のネットワーク５ａを介して上位コンピュータ２が接続される。さらに、他のオープンコントローラ１０や、他のＰＬＣ１が接続されることもある。

また、シリアル通信部１１ｂは、ＲＳ２３２Ｃに準拠したネットワーク５ｂを接続し、そのネットワーク５ｂを介してＰＬＣ１と接続される。フィールドバス通信部１１ｃは、Ｉ／Ｏ（センサ等）６を接続するためのネットワーク５ｃ（デバイスネットとも称される）を連結し、そのデバイスネット５ｃには、複数のＩ／Ｏ６が接続されている。もちろん、このデバイスネットにＰＬＣ等を接続してもかまわない。さらに、ＦＡネットワーク通信部１１ｄには、ＦＡネットワーク５ｄが接続され、このＦＡネットワーク５ｄに、複数のＰＬＣ１が接続される。さらに図示省略するが、各ＰＬＣ１には、その下位に、センサ等の機器が接続される。

また、特に制御部１２の内部構造としては、本発明との関係でいえば、図４に示すようになっている。すなわち、情報収集・処理を行うための機能拡張モジュール部２１と、データの送受を司る通信ミドルウェア部２２及び、ＯＳ（オペレーションシステム）２５を備えている。

機能拡張モジュール２１は、随時、追加することが可能な機能ソフトウェア・モジュールであり、例えば、Ｗｅｂ機能であったり、ＰＬＣ１の動作状況等を収集する情報管理機能であったりする。そして、情報管理機能を組み込んだ場合、ＰＬＣにおける情報管理のシーケンスが不用になり、ラダーシーケンス技術者の開発効率も格段に向上するため、ラダーシーケンス技術者の不足を補うことが可能となる。また、上位コンピュータ２にとっても、情報管理を行わなくて良くなるので、負荷が軽減される。つまり、ＰＬＣ・上位コンピュータがそれぞれ得意な処理だけを行えばよいため、開発効率，メンテナンス性，性能の向上が可能となる。

さらに、オープンコントローラ１０が、その下位に接続された各種機器の動作を管理するようにすれば、万一、上位コンピュータ２がダウンしても、「オープンコントローラ１０がダウンしない限り製造現場を停止させない。」というシステムを構築することが容易に実現でき、システム全体の信頼性が向上する。

また、通信ミドルウェア部２２は、ネットワークを通じて送受信される通信メッセージを管理するソフトウェアであり、この通信ミドルウェア部２２により、上位コンピュータ２やＰＬＣ１などからのデータの送受信（ゲートウェイ機能）や、オープンコントローラ１０の制御や、オープンコントローラ１０内のメモリのデータ読み書きなどが実行されることになる。

そして、係る機能を実現するため、まず、各通信部１１に対してデータの送受を行うための通信ユニット部２３，２３′を有している。ここで通信ユニット部２３は、各通信部１１（通信伝送路）に接続するためのドライバであり、本形態では、イーサネット（Ｅｔｈｅｒｎｅｔ）（登録商標）、フィールドバス（ＤｅｖｉｃｅＮｅｔ）、シリアル（ＲＳ−２３２Ｃ準拠）用のドライバが組み込まれている。また、拡張通信部１１′（拡張通信ユニット部２３′）は、空きスロットとなっており、通信ユニット部２３として標準装備された通信プロトコル以外のネットワークに接続するためのもので、接続するネットワークボードを装着することによって、ＦＡネットワークなどの通信ユニットを増設することができるようにしている。つまり、上記したＦＡネットワーク通信部１１ｄは、この空きスロットにボードをセットすることにより形成され、ボード上に組み込まれたプログラムにより拡張通信ユニット部２３′としてのＦＡネットワーク通信ユニットが構築される。

このように、異なる複数の通信ユニット部２３，２３′を設けることにより、通信プロトコルの相違は、オープンコントローラ１０で吸収し、異なる通信プロトコルのネットワークに接続された装置（ＰＬＣ１，上位コンピュータ２等）間での情報の伝送が可能となる。

また、この拡張通信用の空きスロットにＰＬＣボードを装着することにより、オープンコントローラ自身にＰＬＣのシーケンス制御の機能を持たせることもできる。

そして、通信ミドルウェア部２２の具体的な内部構造は、図５に示すようになる。すなわち、同図に示すように、メッセージ制御部２６と、共有メモリ２８と、各種通信ユニット部２３としてのイーサネット通信ユニット部２３ａ，シリアル通信ユニット部２３ｂ，フィールドパス通信ユニット部２３ｃ並びにＦＡネットワーク通信ユニット部２３ｄ等の異なる複数の通信ユニット部が実装されている。

そして、実装する複数の通信ユニットの種別は、図示した例に限るものではなく、実装するネットワークシステムに対応して異なるが、通常は上位コンピュータ２との間ではイーサネット（登録商標）で接続されるため、イーサネット通信ユニット部２３ａを組み込み、さらに、ＰＬＣその他の機器と接続するための通信プロトコルに対応したユニットを組み込むことになる。

この通信ミドルウェア部２２により、上位コンピュータやＰＬＣなどからのデータの送受信（ゲートウェイ機能）や、オープンコントローラの制御や、オープンコントローラ内のメモリのデータ読み書きなどを実現する。

共有メモリ２８は、オープンコントローラ１０内にあるメモリ領域で、複数のプロセスから共通に利用できるようになっている。しかも、本形態では、ＰＬＣ１の持つリレー，データメモリなどの変数エリア領域と同様の構成にしている。これにより他のＰＬＣ１などから、オープンコントローラ１０のデータをアクセスする際にも、通常のＰＬＣ１に対してデータアクセスするのと全く同じ方法で、等価的にアクセスできるようになる。なお、この共有メモリ２８についての詳細は、後述する。

また、メッセージ制御部２６は、各通信ユニット部２３，２３′から渡されたコマンドやレスポンスを制御する機能を持つ。すなわち、各通信ユニット部２３，２３′から渡されたコマンド（ＰＬＣ１や上位コンピュータ２並びにその他の機器から送られてきたもの）を受け取り、そのコマンドが自ノード宛てであれば、その指示内容にしたがって共有メモリ２８をアクセスするなどの機能を実行し、その返事であるレスポンスを作成して、返事の送り先（相手先）に接続される通信ユニット部２３，２３′へ渡す。また、自己宛てでない場合には、真の相手先を認識し、それが接続される通信ユニット部２３，２３′へ渡す（転送する）。

ここで、送信されるコマンド，レスポンスのデータフォーマットは、例えば図６に示すように、ヘッダー部とコマンド部とデータ部が、その順に並ぶようにしている。そして、ヘッダー部には、相手先の指定や、プロセス識別子などが記憶される。コマンド部には、指示する命令コードなどが記憶され、レスポンスであれば、要求処理に対する終了結果コードも含まれる。さらに、データ部には、指示内容にしたがった必要データなどが記憶される。

すなわち、本形態では、送信元は送信先（相手先）と指示内容、及び必要なデータを持つコマンドを作成するとともに送信し、このコマンドを受け取った受信側では、その指示内容にしたがったデータ読み書きなどの処理を実施して、レスポンスを作成し、返信することで、１回の通信を完了する通信方式をとっている。そして、このコマンド及びレスポンスは、一旦オープンコントローラ１０内に取り込まれ、取り込んだオープンコントローラ１０宛てのコマンド／レスポンスでない限り、オープンコントローラ１０にて真の相手先を認識し、必要なプロトコルに変換された後、転送されるようにしている。

そして、相手先の認識は、ルーティング設定情報記憶部３０に格納されたルーティング情報に基づいて行う。つまり、ルーティング情報は、オープンコントローラ１０の持つ複数のネットワークを利用する際に、通信データが正しく相手に届くために必要な通信経路（道順）を決めるための情報で、例えば図７に示すようなデータ構造でルーティング設定情報記憶部３０に記憶保持されている。この図示した例では、オープンコントローラ１０自身が持つ複数の通信部（通信ユニット部）を区別するための「自ネットワークテーブル」であり、対応するネットワーク（通信ユニット部）とネットワーク番号を関連付けたテーブルとなっている。

これにより、例えばコマンドのヘッダー部で指定された宛先が、ネットワーク番号「３」であれば、フィールドバス通信ユニット部２３ｃひいてはフィールドバス通信部１１ｃにデバイスネットを介して接続された所定のＩ／Ｏ６に対してデータを送ることを意味する。

そして、このメッセージ制御部２６の具体的な機能は、図８に示すフローチャートのようになる。すなわち、まず、各通信ユニット部２３，２３′からコマンド（レスポンスも含む）を受け取る（ＳＴ１）と、その受け取ったコマンドのヘッダー部を解析し、ルーティング設定情報記憶部３０に記憶されたルーティング情報から、そのコマンドの宛て先を認識する（ＳＴ２）。

次いで、その認識した宛て先が、自分宛て（自己のオープンコントローラ宛て）か否かを判断し（ＳＴ３）、自分宛ての場合には、コマンドの内容、つまり、データ部を認識し、そのコマンドにしたがった処理を実行する（ＳＴ４，ＳＴ５）。その後、レスポンスを作成し、送信元の通信ユニット部、つまり、ステップ１で受信したコマンドが送られてきた通信ユニット部へ転送し、処理を終了する（ＳＴ６，ＳＴ７）。

一方、ステップ３の判断で自分宛てでない場合には、真の相手先の通信ユニット部へ転送する（ＳＴ８）。このようにすることにより、メッセージ制御部２６は、オープンコントローラ１０を経由して、上位コンピュータやＰＬＣに対してコマンド／レスポンスの送受信を行うためのメッセージ転送の機能であるゲートウェイ機能を発揮する。

また、上記したように、通信ユニット部２３，２３′は、各通信部（通信デバイス）ごとに用意され、それぞれのドライバソフトとして機能するもので、通信ユニット部は、それぞれの通信部の動作設定情報である「デバイス設定情報」を記憶したデバイス設定情報記憶部２７ａ〜２７ｄを持ち、それぞれの実デバイスはこの内容にしたがって動作する。つまり、通信ユニット部２３，２３′は、実伝送路から各種通信部１１を通じて届いたメッセージを受け取り、メッセージ制御部２６へ渡す機能と、メッセージ制御部２６から渡されたメッセージを所定の通信部を通じて伝送路に発信する機能を持つ。具体的には、前者の機能が、図９に示すフローチャートで実現され、後者の機能が、図１０に示すフローチャートで実現される。

そして、各通信ユニット部２３，２３′に接続される各通信部１１における通信プロトコルが異なるため、ある通信部を介し受信したコマンドの送信相手先が、その通信部と別の通信部に接続されているような場合、その別の通信部からコマンドを発信する際には、当然のことながらその別の通信部の通信プロトコルに合わせる必要がある。そこで、本形態では、係るプロトコルの変換が必要か否かを通信ユニット部が判断し（ＳＴ１２，ＳＴ２２）、必要な場合にはコマンドをプロトコル変換するようにしている（ＳＴ１３，ＳＴ２３）。なお、どのように変換するかの情報は、デバイス設定情報記憶部２７に格納されている。

さらに本形態では、各通信ユニット部２３，２３′とメッセージ制御部２６との間の通信プロトコルは、イーサネット（登録商標）と同様のものを用いるようにした。これにより、イーサネット（登録商標）と同一のプロトコルを用いるネットワークに接続される通信ユニット部２３は、受信した情報をそのままメッセージ制御部２６に伝え、メッセージ制御部２６から受け取ったコマンドは、真の相手先に向けて発信（転送）できる。逆に、イーサネット（登録商標）以外のプロトコルの場合には、通信ユニット部を通過する際に変換することになる。

従って、内部の通信プロトコルであるイーサネット（登録商標）のプロトコルと同一のプロトコルを用いる通信ユニットは、プロトコル変換についての情報が不要であり、また、プロトコル変換するものにおいても、自己の通信部に接続されるネットワークの通信プロトコルと、イーサネット用のプロトコルとの間の変換のみで済む。これは、オープンコントローラに接続される通信部の種類が増えても同じである。

上記した構成をとることにより、コントローラ１０を介してＰＬＣ１と上位コンピュータ２の間での通信はもちろんのこと、ＰＬＣ１同士やその他コントローラ１０を介して接続される各種装置・機器との間で通信ができる。そして、本形態では、オープンコントローラ１０内に設けた共有メモリ２８を、そのオープンコントローラ１０に接続されたＰＬＣ１，各種Ｉ／Ｏ６などのメモリ間で、データの共有を行うことができるようになっている。

具体的には、図１１に示すように、オープンコントローラ１０の共有メモリ２８の所定のメモリ領域に、ＰＬＣ１等のメモリ１ａに格納された情報と同一内容を記憶させるようにしている。また、共有メモリ２８に格納された所定の情報が、ＰＬＣ１等のコントローラ１０に接続された機器のメモリに書き込まれるようにしている。一例を示すと、ＰＬＣ１のメモリ１ａのメモリ領域Ｍ１′に格納された情報が、共有メモリ２８のメモリ領域Ｍ１に書き込まれ、共有メモリ２８のメモリ領域Ｍ２に格納された情報がＰＬＣ１のメモリ１ａのメモリ領域Ｍ２′に書き込まれる。

そして、係るメモリの書き替え管理は、図１２に示すようなマッピング情報にしたがって、オープンコントローラ１０の通信ミドルウェア部２２（データ共有部３２）がデータの転送を行うようになっている。なお、図５に示す例では、メッセージ制御部２６内にデータ共有部３２を設けたが、外に設けてももちろん良い。

マッピング情報は、マッピング情報記憶部３１内に図１２に示すデータ構造で格納されている。具体的には、転送（情報の送受）を行う相手先と、その相手先のメモリアドレスと、転送する情報のメモリサイズと、共有メモリ２８内のメモリ領域を特定する先頭アドレスと、処理種別を関連付けたテーブルとなっている。

より具体的には、「相手先」は、接続されているＰＬＣ１，各種ｌ／Ｏ６などを特定する相手先アドレスを格納し、一例としては、相手先ネットワーク番号やノード番号を格納する。また、「種別」は、データ転送方向を特定するもので、「書き込み」は、オープンコントローラ１０から接続されたＰＬＣ１や各種Ｉ／Ｏ６などへデータを転送することを意味し、「読み出し」は、接続されたＰＬＣ１や各種ｌ／Ｏ６などからオープンコントローラ１０にデータを転送することを意味する。

したがって、例えば図１２の一番上の欄に格納されたマッピング情報は、相手先４．１の装置のメモリアドレスＡ１０００のデータ（メモリサイズ１００）が、オープンコントローラ１０内の共有メモリ２８のアドレスＤ００００に転送されること意味する。また、３番目の欄に格納されたマッピング情報は、オープンコントローラ１０内の共有メモリ２８のアドレスＤ０２００のデータ（データサイズ５００）が相手先４．２の装置のメモリアドレスＤ５０００に転送されることを意味している。

そして、上記マッピング情報に基づいて行われるデータの転送機能は、図１３に示すフローチャートのようになる。すなわち、まずマッピング情報を読み込み（ＳＴ３１）、次いで、予め定められた転送周期になったか否かを判断する（ＳＴ３２）。そして、転送周期になったならば、マッピング情報の種別の欄を取得し、マッピング方向が読み出しか否かを判断する（ＳＴ３３）。

そして、読み出しの場合には、読み出しコマンド（マッピング情報に格納された相手先メモリアドレスとメモリサイズに基づき、対応する部分のデータをレスポンスとともに返送してもらう指示）を作成し（ＳＴ３４）、相手先が接続された通信ユニット部２３（２３′）へ、その作成した読み出しコマンドを転送する（ＳＴ３５）。この通信ユニット部２３（２３′）も、マッピング情報の相手先の欄に格納されたアドレスにより択一的に選択される。

その後、上記読み出しコマンドに対するレスポンスが、相手先から送られてくるので、それを受信し（ＳＴ３６）、マッピング先で特定される共有メモリのアドレスに、レスポンスとともに受け取った読み込みデータを書き込む（ＳＴ３７）。これにより、対応する機器のメモリ情報とオープンコントローラ１０の共有メモリ２８の内容が同一のものとなる。

一方、ステップ３３の分岐判断で「Ｎｏ」、つまり、「書き込み」の場合には、共有メモリ２８の該当するメモリ領域（マッピング先で特定）のデータを読み出すとともに、書き込みコマンドを作成する（ＳＴ３８，ＳＴ３９）。次いで、その書き込みコマンドを、相手先の機器が接続された通信ユニット部２３（２３′）へ転送する（ＳＴ４０）。そして、その転送した書き込みコマンドが、相手先に到達し、相手先メモリの指定メモリ領域にデータを書き込むと完了通知がレスポンスとして送られてくるので、その相手先からのレスポンスを通信ユニット部２３（２３′）を介して受信することにより、転送（書き込み）が正しく行われたことを確認し、処理を終了する（ＳＴ４１）。

そして、上記読み出し／書き込みの処理を、マッピング情報記憶部３１に格納された全てのマッピング情報について実行したならば（ＳＴ４２）、ステップ３２に戻り、次の転送周期まで待つ。

このように構成することにより、以下のような効果を奏する。すなわち、上位コンピュータ２からは、オープンコントローラ１０の共有メモリ２８を参照するだけで、接続されている機器のデータを読み出したり、接続されている機器へデータを書き込むことができる。したがって、オープンコントローラ１０を経由したゲートウェイ機能が利用できない機器についても、このオープンコントローラ１０の共有メモリ２８を介することにより、上位コンピュータその他の接続された機器は、所定の機器のデータ等を取得することができる。

図１４は、本発明のさらに別の実施の形態を示している。同図に示すように、本形態では、機能拡張モジュールの１つとして、データ収集機能４０を設けた。このデータ収集機能部４０は、通信ミドルウェア２２と連携して動作し、オープンコントローラ１０からネットワークによりつながったＰＬＣ１などの各機器のデータの収集，管理を行うもので、具体的な構造は、図１５に示すようになっている。

すなわち、各種動作の制御を行う動作制御部４１と、その動作制御部４１からの命令にしたがって、実際にデータの収集・管理を行うデータ収集サービス部４２を備えている。そして、このデータ収集機能部４０は、データの収集・管理をスムーズに行うためのルール・条件等を規定する機器別情報ファイル１３ａやデータ収集情報ファイル１３ｂを参照しながら動作し、収集等したデータは、収集データベース１３ｃに格納される。

次に各部について詳述する。まず、オープンコントローラ１０に接続されるＰＬＣ１などの各種機器と通信するためのプロトコルの相違は、通信ミドルウェアにより吸収するのはすでに説明したが、機器別情報ファイル１３ａは、通信ミドルウェアでサポートしている通信機器やそのエリア情報のアクセス方法を意識せず、収集したいデータエリアをタグ名で仮想化し、このタグ名でデータを取得できるように定義した情報を格納するようになっている。具体的には、以下のような情報を含み、データ構造の一例を示すと、図１６のようになる。
・対象とする機種はどのようにアクセスできるか。
・どの機種のどのエリアになんというタグ名をつけるか。
・対象エリアにはどのようなフォーマットでデータが格納されているか。

また、データ収集情報ファイル１３ｂは、データを収集するために必要な動作の設定情報が記述されたファイルであり、この記述に従ってデータ収集サービス部４２が動作する。そして、本形態では、処理番号と収集処理名称を対応付けており、ユーザーが内容を容易に理解できるようにしている。

そして、具体的には、以下のような情報を含み、その具体的なデータ構造（テーブル）としては、図１７に示すように、１つのテーブルに収まっていても良いし、図１８に示すように、別途スクリプトファイルに処理内容を記述するようにしてもよい。

・どこからデータを取得するか（収集タグ）。
・どんなタイミングでデータを取得するか（収集タイミング，タイミング個別情報）。
・取得したデータを、どこにどのような形式（収集先種別）で格納するか。
・サービスを開始したときに、各収集処理を開始するかどうか（収集先個別情報）。

さらに、収集データベース１３ｃは、ＰＬＣ１などから収集されたデータを、実際に蓄積しておくデータベースであり、この蓄積データは、メモリ１３にファイル形式に保存してもよいし、共有メモリ２８上に展開するようにしてもよい。これにより、収集，蓄積されたデータは、上位コンピュータなどの外部から、ネットワークを通じて参照できるため、必要な時に、必要に応じたデータを取得し、自由に情報管理に利用することができる。

次に、データ収集機能部４０の各構成要素について説明する。動作制御部４１は、図１９に示すように、メイン制御フローとして、外部から受信したコマンドを取得し（ＳＴ５１）、その取得したコマンドの内容を認識し、処理ごとに振り分ける。そして、本形態では、以下の９個の処理を用意しているが、本発明はこれに限られるものではないのはもちろんである。
・データ収集サービスの開始・停止
・各個別の収集機能の実行開始、停止の制御
・データ収集設定情報の入れ替え（再起動）
・機器別情報の入れ替え（再起動）
・収集開始のトリガ（指示通知）
・タグでのデータのＲｅａｄ／Ｗｒｉｔｅ、つまり、「タグ名」により指定された内容にしたがったＰＬＣなどのデータの読み書き
・外部要求による蓄積データ（履歴データ）の取り出し・提供（取得）
・データ収集情報の取得，追加，削除，変更
・タグ情報の取得，追加，削除，変更
次いで、どの内容かを認識したならば、そのコマンドの内容を実行するための処理機能を起動し（ＳＴ５３）、当該処理を実行する（ＳＴ５４）。

そして、ステップ５４において実際に行う処理としては、例えば図２０，図２１に示すように、現在の状態を取得し、その状態と取得したコマンドの要求とを比較し、異なっている場合（コマンド要求が開始で状態が停止中，コマンド要求が停止で状態が稼働中）に、そのコマンドの内容（開始／停止）を実行する。

また、コマンドが「データ収集情報の入れ替え」の場合には、図２２に示すように、入れ替え要求のあったデータ収集情報を取得する（ＳＴ６１）。次いで、現在サービス起動中か否かを判断し、停止中の場合にはそのまま、また起動中の場合には、そのサービスを停止した後、取得した入れ替えファイルをデータ収集情報ファイル１３ｂに上書きする（ＳＴ６２〜ＳＴ６４）。

このようにすることにより、データ収集情報ファイル１３ｂの記憶内容が更新される。その後、ステップ６３の「サービス停止処理」をしたか否かを判断し（ＳＴ６５）、停止処理をした場合には、サービスを開始する（ＳＴ６６）。また、サービス停止処理をしなかった場合、つまり、サービスが起動していなかった場合には、そのまま処理を終了する。

同様に、コマンドが「機器情報の入れ替え」の場合には、図２３に示すフローチャートを実行することになる。この図２３と図２２を比較すると明らかなように、基本的に図２２のステップと同様の処理手順で各処理ステップを実行する。そして、相違点は、取得する情報（機器情報）と、その取得した情報の上書き先が、機器別情報ファイル１３ａとなることである。

更に、コマンドが「収集開始のトリガ（指示通知）」の場合には、図２４に示すフローチャートを実行することになる。つまり、個別収集処理の実行状態を取得し（ＳＴ６７）、個別処理開始中であった場合には、データ収集サービス部４２内のタイミング発生部４３に対し、トリガ発生通知を送る（ＳＴ６８，ＳＴ６９）。後述するように、このトリガ発生通知を受けたタイミング発生部は、収集処理部４４に対してタイミング発生通知をし、それを受けた収集処理部４４が実際に通信ミドルウェア部２２を介して対応する機器の情報を収集し、収集データベース１３ｃに格納するようになる。

タグでのデータのＲｅａｄ／Ｗｒｉｔｅや、履歴データの取得コマンドの場合には、それぞれ図２５，図２６に示すフローチャートを実行する。さらに、受信したコマンドが、データ収集情報の取得，追加，削除，変更の場合には、それぞれ図２７（ａ），（ｂ），図２８（ａ），（ｂ）に示すフローチャートを実行する。図から明らかなように、データ収集情報ファイルをアクセスし、格納されている情報の取得，追加，変更，削除を実行することになる。さらにまた、受信したコマンドが、タグ情報の取得，追加，削除，変更の場合には、それぞれ図２９（ａ），（ｂ），図３０（ａ），（ｂ）に示すフローチャートを実行する。図から明らかなように、機器別情報ファイルをアクセスし、格納されている情報の取得，追加，変更，削除を実行することになる。

データ収集サービス部４２は、動作制御部４１からの命令を受け、実際にデータ収集を行う処理の実態の総称であり、タイミング発生部４３と収集処理部４４を備えている。

タイミング発生部４３は、データ収集に必要な各種タイミングを生成し、タイミングが発生した際に、これを収集処理部４４に通知する。そして、収集処理部４４は、タイミング発生部４３から通知された処理要求（タイミング発生通知）に対して、データ収集情報ファイル１３ｂの内容にしたがって、ＰＬＣ１などの機器からのデータ収集処理を行うようになっている。そして、具体的な処理機能は、以下のようになっている。

まずタイミング発生部４３は、図３１に示すようなフローチャートを基本構成としている。すなわち、データ収集情報ファイル１３ｂからタイミング処理種別としてサポートしている種別を取得し、対応するタイミング発生個別処理を起動する（ＳＴ７０）。具体的には、収集タイミングの欄に格納された定周期，定刻，対象記条件一致（タグの状態が指定した条件に一致），外部からのトリガ発生要求を受信などを取得する。

このステップ７０の実行に伴い起動される処理機能は、図３２に示すフローチャートのようになる。つまり、データ収集情報ファイル１３ｂに格納されたタイミング種別の各個別処理を取得する（ＳＴ７４）。具体的には、図１７に示すテーブルの処理番号１の場合には、３０秒ごとにタイミング発生することを取得する。

次いで、取得した情報を基にタイミングが発生するかどうかを監視し（ＳＴ７５）、指定したタイミングになった場合に、収集処理部４４に通知する（ＳＴ７６）。ここで、ステップ７５の監視手法としては、例えば定周期の場合には、タイマなどを起動し、タイムアップのカウントにタイミング個別情報の時間を設定することにより定周期を発生することができる。定刻の場合には、内部時計を監視することにより認識できる。さらに、タグの条件一致は、定期的に条件を読み込み比較するようにしたり、或いは、通信ミドルウェア部２２に条件一致のイベント通信機能を持たせることにより、その通信ミドルウェア部２２から通知を受けるようにしても良い。

また、図３１のステップ７０を実行し、タイミング発生個別処理を起動したならば、次に収集処理部４４から処理依頼があったか否かを判断し（ＳＴ７１）、あった場合には、その依頼された処理を実行する（ＳＴ７２）。このステップ７１，７２の処理をサービス終了するまで繰り返し実行する。これにより、タイミング発生部４３は、図３２により行われる予め定められたタイミング発生をするとともに、収集処理部４４からの不定期の依頼に基づく処理を実行することになる。そして、ステップ７２における具体的な処理の一例を示すと、図３３（ａ）〜（ｃ）に示すようになる。

一方、収集処理部４４の機能は、図３４に示すようなフローチャートを基本構成としている。すなわち、データ収集情報ファイル１３ｂから収集情報を取得し、サービス開始時に収集開始する処理に対する初期設定を行う（ＳＴ８０）。具体的には、収集するタグから実エリアの変換を行ったり、収集先ファイルをオープンする処理などを行う。そして、その初期設定終了後、各処理を開始状態とする。

次いで、タイミング発生部４４を起動し（ＳＴ８１）、データ収集サービスを開始状態とする（ＳＴ８２）。以後、動作制御部４１から処理依頼があった場合には、その依頼されたコマンドの処理を実行し（ＳＴ８３，ＳＴ８４）、また、タイミング発生部４３からタイミング発生通知があった場合には、発生したタイミングに対応したデータ収集を通信ミドルウェア部２２を介して取得し、その取得したデータをデータ収集情報ファイルに格納する（ＳＴ８６〜ＳＴ８８）。そして、上記収集処理をサービス終了まで順次繰り返し実行する（ＳＴ８５）。

また、ステップ８４において実行する具体的な処理としては、図３５から図３７に示すようなものがある。そして、タイミング発生部４３が、図３２に示す各処理を実行することになる。

このように構成することにより、オープンコントローラ１０では、それに接続されたＰＬＣその他の機器の状態などの情報を収集し、収集データベース１３ｃに格納することができるので、上位コンピュータ１０は、その収集データベース１３ｃを参照することにより、ＰＬＣ等の状態等に関する情報を任意のタイミングで取得することができる。逆に、上位コンピュータ２が直接各ＰＬＣ等の状態を一括管理するのではないので、上位コンピュータ２が過負荷状態になることもなく、また、仮に上位コンピュータ２がダウンしたとしても、ＰＬＣ等は動作することができる。さらに、取得した情報に基づいて各種の集計までをオープンコントローラ１０で実行し、上位コンピュータ２はその集計結果のみを取得するようにすると、さらに負荷が軽減される。

さらに、上記したように通信ミドルウェア部２２を介して動作制御部４１に対して所定の制御命令コマンドを外部から与えることができ、そのコマンドにしたがって動作制御部４１が機器別情報ファイル１３ａやデータ収集情報ファイル１３ｂの記憶内容を書き替えることができるので、このオープンコントローラ１０でのデータ収集機能は、そのコントローラの外部からの設定指示内容に合わせて自由に機能，動作を設計，変更できる。

なお、本形態に係るオープンコントローラは、ＯＳ２５により動作し、通信機能を持ったパソコン・コンピュータの一種とも採れるが、専用の装置であることから、高機能なＣＰＵなどを実装することが可能であり、ＦＡ現場で求められている信頼性を満たす使用・スペックのものを容易に実現できる。

また、本発明では、拡張機能モジュール部２１として、各種の機能を追加することで、下記のような機能を実現することができる。もちろん、それぞれの機能を組み合わせて使用することも可能である。

一例としては、図３８に示すように、拡張機能としてＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバ５０を付加することができる。これにより、コンピュータなどのＷｅｂブラウザを備えたものであれば、特別なソフトを用意しなくても、オープンコントローラ１０内の情報にアクセスすることが可能になる。つまり、オープンコントローラ１０に搭載されているデータ収集部４０が、ネットワークによりつながったＰＬＣ１などからの制御情報を、通信ミドルウェア部２２及び各種通信部１１と連携して収集データ１３ｃに蓄積する。この蓄積されたデータを、ＷＷＷサーバソフト５０が集計し、Ｗｅｂブラウザで閲覧できる形式に変換して、ＷＷＷへ提供するようになる。

これにより、クライアントコンピュータからは、Ｗｅｂブラウザだけでオープンコントローラに蓄積されたデータや、ＰＬＣなどの機器のデータを簡単にいつでも見ることができる。

また、機能拡張モジュールとして、動作設定モジュール（設定変更用サーバーソフト）を付加すると、ネットワーク上のクライアントコンピュータ（上位コンピュータ）などからオープンコントローラの動作設定が変更できるようになる。つまり、クライアントコンピュータ側に、「設定変更用クライアントソフト」と「設定ファイル作成ソフト」を用意する。そして、ユーザーが、設定ファイル作成ソフトにより、オープンコントローラ内のデータ収集部が用いる、新しい内容の、データ収集情報ファイルを作成する。

そして、新しい情報ファイルが作成した後、設定変更用クライアントソフトを使って、新情報ファイルを、設定変更用サーバソフトに対して通知する。この新情報ファイルを受け取った設定変更用サーバソフトは、データ収集部のデータ収集情報ファイルを新しいものに置き換え、データ収集部に対し、動作の切り替えを指示することになる。

さらにまた、図３９に示すように、オープンコントローラ１０の拡張通信部１１′に「ボードＰＬＣ」（ＰＬＣの機能をボード形状にし、オープンコントローラ内に装着できるようにしたもの）を付加したり、或いは、拡張機能モジュールとしてソフトＰＬＣ５３を付加してもよい。

つまり、オープンコントローラ１０の内部に、ＰＬＣと同等のラダーシーケンスを実現し、製造装置の制御機能を持たせる。ラダーシーケンスの演算処理、Ｉ／Ｏの入出力管理の機能などは、このＰＬＣボード内で動作し、オープンコントローラのゲートウェイ機能やデータ収集機能と平行して動作させることができる。

これにより、オープンコントローラ１０を、ＰＬＣと同様の「制御コントローラ」として利用することができる。また、オープンコントローラだけで、情報管理、装置制御の両方をになうことができ、システムのコストダウンや、設置場所の節約になる。

また、本形態によれば、図４０に示すように、他の機器との通信インタフェースとして、シリアルポートのみを備える旧型，小型のＰＬＣ１１′その他の機器が存在する場合、それをオープンコントローラ１０に接続することにより、通信ユニット有りのＰＬＣ１１″と同一のＬＡＮに接続することができる。よって、係るＰＬＣ１１′であっても、高速ネットワーク対応として利用することができるようになる。

なおまた、上記した実施の形態では、ネットワークにオープンコントローラ１０を１つ接続した例を示したが、本発明の利用形態はこれに限ることはなく、たとえ図４１に示すように複数のオープンコントローラ１０が接続され、各オープンコントローラ１０の下位にそれぞれＰＬＣ１などが接続されるようなネットワークシステムにおいても適用できる。

その場合、オープンコントローラ１０に設けるルーティング設定情報記憶部３０に記憶するルーティング情報としては、図４２に示すように、別のコントローラユニットに接続された機器へ情報を送るための順路を示す「中継ネットワークテーブル」を記憶させる。これにより、メッセージ制御部２６では、受け取ったメッセージの真の送信する相手先が、どの中継ノードの下位にあるかを判断し、当該中継ノードにメッセージを送るための通信ユニットを選択し、発信することになる。

さらにまた、図４３に示すように、シリアル通信を利用する機器（ＰＬＣ１１′，上位コンピュータ２′）同士のデータ通信において、双方をオープンコントローラ１０に接続し、伝送路をＥｔｈｅｒｎｅｔ等に変換することにより、通信伝送路の距離を伸ばすこともできる。また、ルーティング設定を行っておくことにより、シリアル回線のマルチプレクスとして使用することも可能となる。

さらに上記した各形態によれば、オープンコントローラのゲートウェイ機能を使用することにより、ネットワークによりオープンコントローラとつながったＰＬＣなどに対し、運転状態の切り替え、ラダーシーケンスのダウンロードなどの制御、メンテナンス作業を、遠隔地から実施できる。

上位パソコンにＰＬＣをネットワーク接続したシステムの一例を示す図である。 本発明に係るコントローラの使用形態の一例を示す図である。 本発明に係るコントローラの一実施の形態（ハードウエア構成）を示す図である。 本発明に係るコントローラの一実施の形態（ソフトウェア構成）を示す図である。 通信ミドルウェア部の内部構造を示す図である。 コマンドのデータフォーマットの一例を示す図である。 ルーティング設定情報記憶部３０に記憶されるルーティング情報のデータ構造の一例を示す図である。 メッセージ制御部の機能を示すフローチャートである。 通信ユニット部の受信機能を示すフローチャートである。 通信ユニット部の送信機能を示すフローチャートである。 本発明に係るコントローラの好適な一実施の形態（共有メモリを利用）の使用状況を説明する図である。 マッピング情報記憶部３１に記憶されるマッピング情報のデータ構造の一例を示す図である。 データ共有部の機能を説明するフローチャートである。 本発明に係るコントローラの好適な一実施の形態（データ収集機能）を示す図である。 データ収集機能の内部構造を含む図である。 機器別情報ファイルのデータ構造の一例を示す図である。 データ収集情報ファイルのデータ構造の一例を示す図である。 データ収集情報ファイルのデータ構造の一例を示す図である。 動作制御部の機能（メイン）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 動作制御部の機能（サブ）を説明するフローチャートである。 タイミング発生部の機能（メイン）を説明するフローチャートである。 タイミング発生部の機能（サブ）を説明するフローチャートである。 タイミング発生部の機能（サブ）を説明するフローチャートである。 収集処理部の機能（メイン）を説明するフローチャートである。 収集処理部の機能（サブ）を説明するフローチャートである。 収集処理部の機能（サブ）を説明するフローチャートである。 収集処理部の機能（サブ）を説明するフローチャートである。 本発明の変形例を示す図である。 本発明の変形例を示す図である。 本発明の変形例を示す図である。 本発明に係るコントローラの使用形態の他の例を示す図である。 ルーティング設定情報記憶部３０に記憶されるルーティング情報のデータ構造を示す図である。 本発明の変形例を示す図である。

符号の説明

１ ＰＬＣ
２ 上位コンピュータ
６ Ｉ／Ｏ
１０ オープンコントローラ
１１，１１ａ〜１１ｄ 通信部
１２ 制御部
１３ メモリ
１３ａ 機器別情報ファイル
１３ｂ データ収集情報ファイル
１３ｃ 収集データベース
２１ 機能拡張モジュール部
２３，２３′ 通信ユニット部
２８ 共有メモリ
３０ ルーティング設定情報記憶部
３１ マッピング情報記憶部
３２ データ共有部
４０ データ収集機能部
４１ 動作制御部
４２ データ収集サービス部
４３ タイミング発生部
４４ 収集処理部

Claims (2)

1. コンピュータとＰＬＣとの間に介在するコントローラであって、
   ネットワーク接続可能な通信部と、
   前記通信部を介して前記ＰＬＣの情報を収集する収集機能部と、
   その収集機能部により収集した情報を記憶する収集情報記憶部と、
   収集したいデータエリアを複数設定した情報と当該データエリア毎に収集タイミングを設定した情報とを記憶する記憶部を備え、
   前記収集機能部は、前記記憶部に記憶されたデータエリア毎の収集タイミングにしたがって前記ＰＬＣの情報を収集することを特徴とするコントローラ。
2. 前記収集情報記憶部に記憶された情報を、
   Ｗｅｂブラウザで閲覧できる形式に変換する機能を備え、前記コンピュータからＷｅｂブラウザで前記収集情報記憶部に記憶された情報を閲覧可能とすることを特徴とする請求項１に記載のコントローラ。

Images