JP6900690B2 - 制御装置 - Google Patents

Description

本発明は、１または複数の機能ユニットを含む制御装置およびその制御装置を構成する通信装置に関する。

様々なＦＡ（Factory Automation）を実現するための主たるコンポーネントとして、ＰＬＣ（プログラマブルコントローラ）などの制御装置が普及している。このような制御装置では、ＣＰＵ（Central Processing Unit）ユニットと称される演算ユニットと１または複数の機能ユニットとの間で通信線を介してデータが遣り取りされる。

このようなデータの遣り取りの典型として、機能ユニットが収集しているデータ（「入力データ」とも称す。）を演算ユニットに送信するとともに、演算ユニットにて算出されるデータ（「出力データ」とも称す。）を各機能ユニットへ送信する処理（一般的には、「ＩＯ（Input Output）リフレッシュ処理」とも称される。）が周期的に実行される。

例えば、特開２０１４−１２０８８４号公報（特許文献１）は、ＩＯリフレッシュ周期を基準として同期タイミングを容易に決定する環境および方法を開示する。ＩＯリフレッシュ処理においては、周期的に通信フレームを一巡させることで入力データおよび出力データを伝送するので、通信線に接続される機能ユニットの数が増大することで、通信フレームの転送時間が増大し、ＩＯリフレッシュ処理の周期が長くなる。

このような現象に関して、特開２０１０−２２４９３９号公報（特許文献２）は、制御システムにおける１以上の制御対象装置に対し複数の異なる周期の制御処理を実行する制御用計算機の開発の手間を低減し、かつ、通信性能の低下を防止する技術を開示する。具体的には、各制御処理の周期に応じて、必要な制御指令値のみを含む送信データを作成および送信するようなアプローチを採用する。

特開２０１４−１２０８８４号公報 特開２０１０−２２４９３９号公報

特許文献２に開示されるアプローチによれば、各制御処理の周期に応じて、送信データに含めるべき制御指令値をスケジューリングする必要があり、処理が複雑化するとともに、そのスケジューリング処理によって、通信処理の更新周期が低下する可能性もある。さらに、特許文献２に開示されるアプローチによれば、複数の制御処理の間で影響を及ぼし合うので、制御処理の設計などの自由度が低下する可能性がある。

本発明は、上述したような課題を解決することを一つの目的とし、接続される機能ユニットの数が増大しても、予め定められた更新周期を確保できる新たな構成を提供するものである。

本発明のある局面に従う制御装置は、通信ユニットと、１または複数の機能ユニットと、通信ユニットと１または複数の機能ユニットとの間を接続する、互いに独立した複数の通信線とを含む。通信ユニットは、複数の通信線のうち第１通信線を介して、機能ユニットが収集しているデータの通信ユニットへの送信、および、通信ユニットが保持しているデータの機能ユニットへの送信のうち、少なくとも一方を実行するための第１通信フレームを第１周期で送出する第１タスクと、複数の通信線のうち第２通信線を介して、機能ユニットが収集しているデータの通信ユニットへの送信、および、通信ユニットが保持しているデータの機能ユニットへの送信のうち、少なくとも一方を実行するための第２通信フレームを第１周期とは独立に設定される第２周期で送出する第２タスクとを実行するように構成される。

好ましくは、１または複数の機能ユニットの各々は、通信ユニットとの間のデータの遣り取りを行うために、いずれかの１つの通信フレームのみを処理する。

好ましくは、１または複数の機能ユニットの各々は、通信ユニットとの間のデータの遣り取りを行うために処理する通信フレーム以外の通信フレームについては、そのまま転送する。

好ましくは、第１通信フレームおよび第２通信フレームの各々には、処理を行う機能ユニットに関連付けられるデータ領域が設けられている。

好ましくは、制御装置は、１または複数の機能ユニットの各々について、第１通信フレームおよび第２通信フレームのいずれと関連付けられるかを指定するユーザインターフェイス画面を提供する手段をさらに含む。

好ましくは、通信ユニットは、第１タスクおよび第２タスクを実行するプロセッサとメモリとを含む演算処理部と、通信フレームの送受信を担当する通信回路と、演算処理部および通信回路に接続される制御回路とを含む。制御回路は、演算処理部にアクセスするための第１ＤＭＡ（Direct Memory Access）コアと、通信回路にアクセスするための第２ＤＭＡコアと、演算処理部からのトリガに応じて、予め定義されたディスクリプタテーブルに従って、第１ＤＭＡコアおよび第２ＤＭＡコアに順次コマンドを与えるコントローラとを含む。

好ましくは、制御回路は、互いに異なる優先度が予め設定された複数のディスクリプタテーブルのうちから指定されたディスクリプタテーブルを選択的に起動するための起動手段と、異なるディスクリプタテーブルに従う処理が同時に要求されると、各ディスクリプタテーブルに設定されている優先度に基づいて調停するアービタとをさらに含む。

好ましくは、複数のディスクリプタテーブルは、演算処理部のメモリおよび制御回路の記憶領域の少なくとも一方に格納される。

好ましくは、通信ユニットは、演算ユニットおよび中継ユニットのいずれか一方である。

本発明のある局面に従えば、互いに独立した複数の通信線を介して１または複数の機能ユニットと接続される通信装置が提供される。通信装置は、複数の通信線での通信フレームの送受信を担当する通信回路と、演算処理部とを含む。演算処理部は、複数の通信線のうち第１通信線を介して、機能ユニットが収集しているデータの通信ユニットへの送信、および、通信ユニットが保持しているデータの機能ユニットへの送信のうち、少なくとも一方を実行するための第１通信フレームを第１周期で送出する第１タスクと、複数の通信線のうち第２通信線を介して、機能ユニットが収集しているデータの通信ユニットへの送信、および、通信ユニットが保持しているデータの機能ユニットへの送信のうち、少なくとも一方を実行するための第２通信フレームを第１周期とは独立に設定される第２周期で送出する第２タスクとを実行するように構成される。

本発明に従えば、通信ユニットに接続される機能ユニットの数が増大しても、予め定められた更新周期を確保できるとともに、通信ユニットなどで実行される複数の処理の設計自由度を高めることができる。

実施の形態１に係るＰＬＣの要部構成を示す模式図である。 実施の形態１に係るＰＬＣにおけるＩＯリフレッシュ処理の概要を説明するための模式図である。 図２に示すプライマリ定周期タスクおよび通常定周期タスクにより送出されるＩＯリフレッシュフレームを説明するための模式図である。 図２に示すような機能ユニットに対する設定を行うためのユーザインターフェイス画面の一例を示す図である。 図２に示す機能ユニットの設定に対応するＩＯリフレッシュフレームのデータ構造の一例を示す図である。 実施の形態２に係るＰＬＣの要部構成を示す模式図である。 実施の形態３に係るＰＬＣの要部構成を示す模式図である。 実施の形態３に係るＰＬＣのＣＰＵユニットの要部構成を示す模式図である。 実施の形態３に係るＰＬＣにおけるＩＯリフレッシュ処理の処理手順を示す模式図である。 実施の形態３に係るＰＬＣに用いられるディスクリプタテーブルのデータ構造の一例を示す模式図である。 実施の形態３に従うＰＬＣにおけるディスクリプタテーブルの起動および格納について説明するための模式図である。

本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。

以下の説明においては、「制御装置」の典型例として、ＰＬＣ（プラグラマブルコントローラ）を具体例として説明するが、ＰＬＣとの名称に限定されることなく、本明細書に開示された技術的思想は、任意の制御装置に対して適用可能である。

［１．実施の形態１］
＜Ａ．装置構成＞
まず、実施の形態１に係るＰＬＣの装置構成について説明する。図１は、実施の形態１に係るＰＬＣの要部構成を示す模式図である。図１を参照して、実施の形態１に係るＰＬＣ１は、典型的には、ＣＰＵユニット１００と、１または複数の機能ユニット２００とから構成される。ＣＰＵユニット１００は、ＰＬＣ１を構成する一要素であり、ＰＬＣ１全体の処理を制御する演算ユニットに相当する。機能ユニット２００は、ＰＬＣ１による様々な機械や設備の制御を実現するための各種機能を提供する。ＣＰＵユニット１００と１または複数の機能ユニット２００との間は、通信線の一例であるローカルバス群２を介して接続されている。一例として、ローカルバス群２としては、一種のデイジーチェーンの構成が採用される。

実施の形態１においては、ローカルバス群２は、複数の互いに独立したチャネルを有している。一例として、ローカルバス群２は、第１ローカルバス２１および第２ローカルバス２２からなる。ローカルバス群２としては、２つより多いチャネルを有する構成を採用してもよい。このように、ローカルバス群２は、ＣＰＵユニット１００と１または複数の機能ユニット２００との間を接続する、互いに独立した複数の通信線に相当する。

図１に示す構成においては、ＣＰＵユニット１００は、通信ユニットまたは通信装置としても機能する。より具体的には、ＣＰＵユニット１００は、ローカルバス群２における通信全体を管理するマスターの通信ユニットとして機能するようにしてもよく、各機能ユニット２００がＣＰＵユニット１００の管理下で通信を行うスレーブの通信ユニットとして機能するように構成してもよい。このようなマスター／スレーブの構成を採用することで、ローカルバス群２を転送される通信フレームのタイミング制御などを容易に行うことができる。

ＣＰＵユニット１００は、演算処理部１１０と、通信回路１３０とを含む。なお、ＣＰＵユニット１００とは別に通信ユニットを配置するような構成であってもよい。

演算処理部１１０は、プロセッサ１１２と、メインメモリ１１４と、ストレージ１２０とを含む。説明の便宜上、図１には、１つのプロセッサ１１２のみを描くが、複数のプロセッサを実装してもよい。なお、各プロセッサは、複数のコアを有していてもよい。

メインメモリ１１４は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などで構成され、プロセッサ１１２でのプログラムの実行に必要なワーク領域を提供する。

ストレージ１２０は、フラッシュメモリやハードディスクなどで構成され、システムプログラム１２２、ユーザプログラム１２４、コンフィギュレーション１２６などを格納する。システムプログラム１２２は、プロセッサ１１２においてユーザプログラム１２４を実行するためのＯＳ（Operating System）およびライブラリなどを含む。システムプログラム１２２は、機能ユニット２００により収集されるフィールド値（入力データ）をＣＰＵユニット１００へ送信するとともに、ＣＰＵユニット１００で算出される制御指令値（出力データ）を機能ユニット２００へ送信する処理（後述する、ＩＯリフレッシュ処理）を周期的に実行するためのタスクを含む。ユーザプログラム１２４は、制御対象の機械や設備に応じて任意に作成される。コンフィギュレーション１２６は、ＣＰＵユニット１００でのプログラム実行に必要な各種設定値やネットワーク構成を定義する各種設定値を含む。

通信回路１３０は、通信線であるローカルバス群２を介して、１または複数の機能ユニット２００とデータを遣り取りする。すなわち、通信回路１３０は、通信フレームの送受信を担当する。より具体的には、通信回路１３０は、ローカルバス群２と物理的に接続され、演算処理部１１０からの指令に従って電気信号を生成して、ローカルバス群２（第１ローカルバス２１または第２ローカルバス２２）上に送信するとともに、ローカルバス群２（第１ローカルバス２１または第２ローカルバス２２）上に生じる電気信号を復調して演算処理部１１０へ出力する。

ローカルバス群２は互いに独立したチャネルを有しているので、それぞれのチャネルで独立して通信フレームを伝送することができる。通信回路１３０は、それぞれのチャネルに対応する独立した回路（図示しない）を有しており、後述するように、各チャネルに独立に設定された周期でデータのリフレッシュ（更新）が行われる。

本明細書において、「ＩＯリフレッシュ処理」は、機能ユニット２００が収集している入力データの通信ユニット（ＣＰＵユニット１００、または、後述するような通信カプラユニット３００など）への送信、および、通信ユニットが保持している出力データの機能ユニット２００への送信のうち、少なくとも一方を実行する処理を意味する。すなわち、「ＩＯリフレッシュ処理」との名称は便宜上のものであり、入力データおよび出力データの一方のみの更新処理も含み得る。

ＩＯリフレッシュ処理に用いられる通信フレームは、ローカルバス群２（第１ローカルバス２１または第２ローカルバス２２）を一巡するように伝送される。このＩＯリフレッシュ処理に用いられる通信フレームが伝送されていない期間において、ＣＰＵユニット１００と任意の機能ユニット２００との間、あるいは、複数の機能ユニット２００との間には、通信フレームがメッセージ伝送されることもある。

ローカルバス群２上でデータを遣り取りするためのプロトコルとしては、任意のプロトコルを採用することができる。さらに、通信線の一例として、ローカルバス群２を例示するが、これに限らず、任意の定周期ネットワークを採用してもよい。このような定周期ネットワークとしては、ＥｔｈｅｒＣＡＴ（登録商標）、ＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）、ＤｅｖｉｃｅＮｅｔ（登録商標）、ＣｏｍｐｏＮｅｔ（登録商標）などの公知のネットワークを採用してもよい。

図１に示す構成においては、説明の便宜上、演算処理部１１０および通信回路１３０に区別した構成を描いているが、これに限られることなく任意の実装形態を採用できる。例えば、演算処理部１１０の全部または一部と通信回路１３０の全部または一部とを同一のチップ上に実装したＳｏＣ（System on Chip）で構成してもよい。このような実装形態については、要求される性能やコストなどを考慮して適宜選択される。

機能ユニット２００は、典型的には、Ｉ／Ｏユニット、通信ユニット、温度調整ユニット、ＩＤ（Identifier）センサユニットなどを包含し得る。

Ｉ／Ｏユニットとしては、例えば、デジタル入力（ＤＩ）ユニット、デジタル出力（ＤＯ）ユニット、アナログ出力（ＡＩ）ユニット、アナログ出力（ＡＯ）ユニット、パルスキャッチ入力ユニット、および、複数の種類を混合させた複合ユニットなどが挙げられる。

通信ユニットは、他のＰＬＣ、リモートＩ／Ｏ装置、機能ユニットなどとデータの遣り取りを仲介するものであり、例えば、ＥｔｈｅｒＣＡＴ（登録商標）、ＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）、ＤｅｖｉｃｅＮｅｔ（登録商標）、ＣｏｍｐｏＮｅｔ（登録商標）などのプロトコルに係る通信装置などを包含し得る。

温度調整ユニットは、温度計測値などを取得するアナログ入力機能と、制御指令などを出力するアナログ出力機能と、ＰＩＤ（Proportional Integral Differential）制御機能とを含む制御装置である。ＩＤセンサユニットは、ＲＦＩＤ（Radio Frequency IDentifier）などから非接触でデータを読出す装置である。

機能ユニット２００の各々は、通信処理部２１０と、機能モジュール２２０と、ＩＯインターフェイス２３０とを含む。

機能モジュール２２０は、各機能ユニット２００の主たる処理を実行する部分であり、制御対象の機械や設備などからのフィールド値（入力データ）の収集や、制御対象の機械や設備などへの制御指令値（出力データ）の出力などを司る。

ＩＯインターフェイス２３０は、制御対象の機械や設備などとの間の信号の遣り取りを仲介する回路である。

通信処理部２１０は、ローカルバス群２（第１ローカルバス２１または第２ローカルバス２２）を順次転送される通信フレームを処理する。より具体的には、通信処理部２１０は、ローカルバス群２を介して何らかの通信フレームを受信すると、必要に応じて、当該受信した通信フレームに対するデータ書込みおよび／またはデータ読出しを行った後に、ローカルバス群２上において次に位置する機能ユニット２００へ当該通信フレームを送信する。通信処理部２１０は、このようなフレームリレーの機能を提供する。なお、通信処理部２１０は、自ユニット宛ではない通信フレームについては、単純に次に位置する機能ユニット２００へ当該通信フレームを転送することもある。

より具体的には、通信処理部２１０は、送受信ポート２１１，２１２，２１３，２１４と、通信回路２１６とを含む。送受信ポート２１１，２１２，２１３，２１４は、ローカルバス群２と物理的に接続されるインターフェイスであり、通信回路２１６からの指令に従って電気信号を生成して、ローカルバス群２上に送信するとともに、ローカルバス群２上に生じる電気信号をデジタル信号に変換して通信回路２１６へ出力する。図１に示す構成においては、送受信ポート２１１，２１３が第１ローカルバス２１を担当し、送受信ポート２１２，２１４が第２ローカルバス２２を担当する。

通信回路２１６は、ローカルバス群２（第１ローカルバス２１または第２ローカルバス２２）上を伝送される通信フレームに対するデータ書込みおよび／またはデータ読出しを行う。通信回路２１６は、それぞれのチャネルに対応する独立した回路（図示しない）を有しており、各チャネルをそれぞれ伝送する通信フレームに対して独立に処理を行うことができる。

＜Ｂ．複数のＩＯリフレッシュフレーム＞
実施の形態１に係るＰＬＣ１においては、ローカルバス群２を構成する第１ローカルバス２１および第２ローカルバス２２を用いて、互いに独立に設定される周期（一定周期）でのＩＯリフレッシュ処理をそれぞれ独立に行うことができる。

図２は、実施の形態１に係るＰＬＣ１におけるＩＯリフレッシュ処理の概要を説明するための模式図である。図２を参照して、ＣＰＵユニット１００においては、システムプログラム１２２に含まれる、プライマリ定周期タスク１２２１（一定周期Ｔ１で繰返し実行）と、通常定周期タスク１２２２（一定周期Ｔ２（＞Ｔ１）で繰返し実行）とが実行される。これらのタスクは、いずれもＩＯリフレッシュ処理を実現するためのタスクである。

プライマリ定周期タスク１２２１は、ＩＯリフレッシュを実現するための、ＩＯリフレッシュフレーム１を第１ローカルバス２１上に一定周期Ｔ１毎に繰返し送出する。つまり、ＣＰＵユニット１００で実行されるプライマリ定周期タスク１２２１は、複数の通信線であるローカルバス群２のうち１つの通信線（例えば、第１ローカルバス２１）を介して、ＩＯリフレッシュ処理を実行するためのＩＯリフレッシュフレーム１を一定周期Ｔ１で送出するタスクである。

また、通常定周期タスク１２２２は、ＩＯリフレッシュを実現するための、ＩＯリフレッシュフレーム２を第２ローカルバス２２上に一定周期Ｔ２毎に繰返し送出する。これらのタスクは、基本的には、互いに独立に実行される。つまり、ＣＰＵユニット１００で実行される通常定周期タスク１２２２は、複数の通信線であるローカルバス群２のうち別の１つの通信線（例えば、第２ローカルバス２２）を介して、ＩＯリフレッシュ処理を実行するためのＩＯリフレッシュフレーム２を一定周期Ｔ２で送出するタスクである。

なお、プロセッサ１１２のリソースの制約によって、プライマリ定周期タスク１２２１が通常定周期タスク１２２２より優先して実行されることもある。

各機能ユニット２００は、ＩＯリフレッシュフレーム１およびＩＯリフレッシュフレーム２の少なくとも一方を利用して、入力データの送信および出力データの取得を行う。図２に示す例においては、ローカルバス群２を介して、ＣＰＵユニット１００と機能ユニット２００−１〜２００−５とが接続されている。

図３は、図２に示すプライマリ定周期タスク１２２１および通常定周期タスク１２２２により送出されるＩＯリフレッシュフレームを説明するための模式図である。図３（Ａ）には、プロセッサ１１２において、プライマリ定周期タスク１２２１および通常定周期タスク１２２２が互いに独立して実行できる状態の例を示す。図３（Ａ）に示すように、プライマリ定周期タスク１２２１が繰返し実行される周期Ｔ１毎にＩＯリフレッシュフレーム１がＣＰＵユニット１００から第１ローカルバス２１上に送出される。同様に、通常定周期タスク１２２２が繰返し実行される周期Ｔ２毎にＩＯリフレッシュフレーム２がＣＰＵユニット１００から第２ローカルバス２２上に送出される。

それぞれのＩＯリフレッシュフレームによって、周期Ｔ１およびＴ２のそれぞれでのＩＯリフレッシュ処理を実現できる。

図３（Ｂ）には、プロセッサ１１２において、プライマリ定周期タスク１２２１および通常定周期タスク１２２２を同時には実行できない状態の例を示す。図３（Ｂ）に示す例においては、プライマリ定周期タスク１２２１および通常定周期タスク１２２２は互いに重ならない時間帯に処理が実行される。基本的には、プライマリ定周期タスク１２２１には、通常定周期タスク１２２２より高い優先度が設定されているので、周期やリソースの制限によって、両タスクの実行タイミングが重なってしまった場合には、プライマリ定周期タスク１２２１が優先的に実行されるようにしてもよい。

図３（Ｂ）に示すような例においても、それぞれのＩＯリフレッシュフレームによって、周期Ｔ１およびＴ２のそれぞれでのＩＯリフレッシュ処理を実現できる。

図３には、説明の便宜上、通常定周期タスク１２２２を繰返し実行する周期Ｔ２がプライマリ定周期タスク１２２１を繰返し実行する周期Ｔ１の２倍である例を示すが、これに限られるものではなく、周期Ｔ１および周期Ｔ２は互いに独立して任意に設定することができる。

＜Ｃ．機能ユニットの設定＞
再度図２を参照して、一例として、機能ユニット２００−１，２００−２，２００−５がプライマリ定周期タスク１２２１に関連付けられており、機能ユニット２００−３，２００−４が通常定周期タスク１２２２に関連付けられている。

機能ユニット２００の各々について、ＩＯリフレッシュフレーム１を用いるタスクおよびＩＯリフレッシュフレーム２を用いるタスクのいずれと関連付けられるかを指定するユーザインターフェイス画面を提供する機能を提供するようにしてもよい。

図４は、図２に示すような機能ユニットに対する設定を行うためのユーザインターフェイス画面５００の一例を示す図である。図４に示すユーザインターフェイス画面５００は、通信ユニット（ＣＰＵユニット１００、または、後述するような通信カプラユニット３００など）内に実装される機能により生成される画面をサポート装置上で提供するような形で実装してもよいし、サポート装置に実装される機能により生成される画面をユーザに提示するとともに、ユーザ操作に応じて設定された内容を通信ユニットへ送信するようにしてもよい。

図４を参照して、ユーザインターフェイス画面５００は、プライマリ定周期タスク１２２１の実行周期を設定するための入力項目５０２と、通常定周期タスク１２２２の実行周期を設定するための入力項目５０４と、ローカルバス群２を介してＣＰＵユニット１００に接続されている各機能ユニット２００に対する設定を行うためのラジオボタン群５０６とを含む。

ユーザは、ユーザインターフェイス画面５００の入力項目５０２および入力項目５０４に対する操作を行って、各定周期タスクを繰返し実行する際の周期をそれぞれ設定する。その上で、ユーザは、ラジオボタン群５０６に含まれる各ラジオボタンを選択することで、各機能ユニット２００を、プライマリ定周期タスク１２２１（すなわち、ＩＯリフレッシュフレーム１）および通常定周期タスク１２２２（すなわち、ＩＯリフレッシュフレーム２）のいずれに関連付けるのかを設定する。

図４に示すようなユーザインターフェイス画面５００を提供することで、ユーザは、定周期タスクおよび各機能ユニット２００に対する設定を容易に行うことができる。

＜Ｄ．ＩＯリフレッシュフレーム＞
ＩＯリフレッシュフレーム１およびＩＯリフレッシュフレーム２は、いずれもローカルバス群２に接続されるすべての機能ユニット２００を順次転送されることになるが、機能ユニット２００の各々は、予め設定されたいずれかのＩＯリフレッシュフレームのみを処理するようにしてもよい。なお、同一のＩＯリフレッシュフレームに、入力データおよび出力データを格納するようにしてもよいし、入力データおよび出力データのそれぞれ専用のＩＯリフレッシュフレームを用いるようにしてもよい。

例えば、図２に示される設定例においては、機能ユニット２００−１，２００−２，２００−５の各々は、プライマリ定周期タスク１２２１が送出するＩＯリフレッシュフレーム１が到着すると、ＩＯリフレッシュフレーム１に対して要求されている入力データを書込み、ＩＯリフレッシュフレーム１から対象となる出力データを読出す。一方、機能ユニット２００−１，２００−２，２００−５の各々は、通常定周期タスク１２２２が送出するＩＯリフレッシュフレーム２が到着すると、受信したＩＯリフレッシュフレーム２を次に位置する機能ユニット２００へそのまま転送する。

また、機能ユニット２００−３，２００−４の各々は、通常定周期タスク１２２２が送出するＩＯリフレッシュフレーム２が到着すると、ＩＯリフレッシュフレーム２に対して要求されている入力データを書込み、ＩＯリフレッシュフレーム２から対象となる出力データを読出す。一方、機能ユニット２００−３，２００−４の各々は、プライマリ定周期タスク１２２１が送出するＩＯリフレッシュフレーム１が到着すると、受信したＩＯリフレッシュフレーム１を次に位置する機能ユニット２００へそのまま転送する。

このように、ＩＯリフレッシュフレーム１については、機能ユニット２００−１，２００−２，２００−５のみがデータの書込みおよび読出しを行い、ＩＯリフレッシュフレーム２については、機能ユニット２００−３，２００−４のみがデータの書込みおよび読出しを行う。すなわち、機能ユニット２００の各々は、通信ユニット（ＣＰＵユニット１００、または、後述するような通信カプラユニット３００など）との間のデータの遣り取りを行うために、いずれかの１つの通信フレーム（ＩＯリフレッシュフレーム）のみを処理するようにしてもよい。この場合、機能ユニット２００の各々は、通信ユニットとの間のデータの遣り取りを行うために処理する通信フレーム以外の通信フレームについては、そのまま転送することになる。

図５は、図２に示す機能ユニット２００の設定に対応するＩＯリフレッシュフレームのデータ構造の一例を示す図である。図５を参照して、ＩＯリフレッシュフレーム１および２は、フレーム種別および宛先を格納するヘッダ部と、データを格納する本体部とからなる。

フレーム種別としては、通信フレームの種類を特定するための識別情報が用いられ、例えば、ユニキャスト、マルチキャスト、ブロードキャストのいずれであるかを示す識別情報が用いられる。ＩＯリフレッシュフレーム１および２は、ＣＰＵユニット１００から送出されて、ローカルバス群２を一巡した後にＣＰＵユニット１００に戻るので、典型的には、マルチキャストを示す識別情報が格納される。このとき、マルチキャストでの送信においては、特定の宛先が存在しないので、特殊値が格納されるようにしてもよい。

本体部には、入力データの領域および出力データの領域が規定されており、それぞれの領域は、図４に示すユーザインターフェイス画面５００によって規定される設定値などに応じて定まる。

ＩＯリフレッシュフレーム１およびＩＯリフレッシュフレーム２の各々には、処理を行う機能ユニット２００に関連付けられるデータ領域が設けられる。例えば、図５に示すＩＯリフレッシュフレーム１には、機能ユニット２００−１，２００−２，２００−５にそれぞれ対応する入力データの領域および出力データの領域が規定されている。一方、ＩＯリフレッシュフレーム２には、機能ユニット２００−３，２００−４にそれぞれ対応する入力データの領域および出力データの領域が規定されている。

上述したように、ＩＯリフレッシュフレーム１およびＩＯリフレッシュフレーム２においては、データの書込みおよび読出しを行う機能ユニット２００の数に応じたデータ容量のみを確保すればよい。そのため、ＣＰＵユニット１００に接続される機能ユニット２００の数が増大したとしても、ＩＯリフレッシュフレームの各々に関連付けられる機能ユニット２００の数のみを考慮すればよく、フレーム長が不要に長大化することはない。

また、例えば、ＩＯリフレッシュフレーム２に関連付けられる機能ユニット２００が追加されたとしても、ＩＯリフレッシュフレーム１には影響を与えないので、ＩＯリフレッシュフレーム１のフレーム長が変化することはなく、プライマリ定周期タスク１２２１によるＩＯリフレッシュ処理の周期などへの影響はない。そのため、ＣＰＵユニット１００に対して、機能ユニット２００を追加する際の自由度を高めることができる。

なお、単一の機能ユニット２００をＩＯリフレッシュフレーム１および２の両方に関連付けるようにしてもよい。この場合、ＩＯリフレッシュフレーム１および２の両方に、該当する機能ユニット２００の入力データまたは出力データの領域が設定されており、いずれの通信フレームが到着しても、指定された入力データの書込みおよび／または出力データの読出しを行うようにしてもよい。

ここで、再度図２を参照して、ＩＯリフレッシュフレームが各機能ユニット２００に到着するタイミングと、各機能ユニット２００において、制御対象の機械や設備などからのフィールド値（入力データ）の収集、および、制御対象の機械や設備などへの制御指令値（出力データ）の出力（図２においては、これらの処理をまとめて「内部リフレッシュ」と記す。）のタイミングとの関係について説明する。

例えば、ＩＯリフレッシュフレームの送信周期および送信タイミングは、予め定められているので、各機能ユニット２００の内部リフレッシュの開始タイミングを、対象となるＩＯリフレッシュフレームの送信周期に同期させることで、ＣＰＵユニット１００においては、各機能ユニット２００から最も短い遅れ時間で入力データを取得することができる。機能ユニット２００におけるこのような内部リフレッシュを入出力同期方式と称することもある。

但し、必ずしも入出力同期方式の内部リフレッシュを採用する必要はなく、別のリフレッシュ方式を採用してもよい。例えば、各機能ユニット２００は、互いに同期するタイマを有しており、各タイマが示す値（カウント値）に基づいてタイミングを決定するようにしてもよい。このような内部リフレッシュをタイムスタンプ方式と称することもある。タイムスタンプ方式によれば、各機能ユニット２００の内部リフレッシュのタイミングは、ＩＯリフレッシュフレームとは同期しないが、すべての機能ユニット２００について、同一のタイミングで内部リフレッシュすることができるので、ＩＯリフレッシュフレームの送信周期が複数存在する場合であっても、入力データおよび出力データの間の整合性をとることが容易になる。

あるいは、入力データおよび出力データの間の同期性などが要求されない場合には、各機能ユニット２００が各自のタイミングまたは条件で内部リフレッシュを行うようにしてもよい。このような内部リフレッシュをフリーラン方式と称することもある。この場合、複数の機能ユニット２００に対してそれぞれタイミングなどを通知する必要がないので、処理を簡素化できる。

＜Ｅ．まとめ＞
実施の形態１に係るＰＬＣ１においては、互いに独立したチャネルを有するローカルバス群２を採用することで、それぞれのチャネルを利用して、ＩＯリフレッシュフレームをそれぞれ独立に伝送させることができる。これによって、各機能ユニット２００は、各機能ユニット２００が扱う入力データおよび出力データの特性や用途に応じて、より好ましいＩＯリフレッシュフレームにてＩＯリフレッシュ処理を行うことができる。

それぞれのチャネルによる複数のＩＯリフレッシュフレームを用いることで、単一のＩＯリフレッシュフレームを用いる場合に比べて、効率的な入力データおよび出力データの伝送が可能になるとともに、ＩＯリフレッシュフレームのフレーム長さが長大化して、ＩＯリフレッシュ周期が伸びるような事態を回避できる。

［２．実施の形態２］
実施の形態１においては、ＣＰＵユニット１００とローカルバス群２を介して接続された１または複数の機能ユニット２００との間で、ＩＯリフレッシュフレームが遣り取りされる構成について主として説明した。しかしながら、フィールドネットワークを介して接続される１または複数の機能ユニット２００に対しても、同様のスキームを適用可能である。

図６は、実施の形態２に係るＰＬＣ１Ａの要部構成を示す模式図である。図６を参照して、ＰＬＣ１ＡのＣＰＵユニット１００Ａは、フィールドネットワーク６を制御するネットワークインターフェイス１５０をさらに含む。フィールドネットワーク６には、通信カプラユニット３００の他、様々なデバイスが接続され得る。

フィールドネットワーク６としては、例えば、ＥｔｈｅｒＣＡＴ（登録商標）、ＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）、ＤｅｖｉｃｅＮｅｔ（登録商標）、ＣｏｍｐｏＮｅｔ（登録商標）などの公知のネットワークを採用してもよい。

通信カプラユニット３００は、１または複数の機能ユニット２００とＰＬＣ１Ａとをネットワーク接続するための中継ユニットである。すなわち、通信カプラユニット３００は、通信ユニットまたは通信装置としても機能する。通信カプラユニット３００は、ローカルバス群４における通信全体を管理するマスターの通信ユニットとして機能するようにしてもよく、各機能ユニット２００が通信カプラユニット３００の管理下で通信を行うスレーブの通信ユニットとして機能するように構成してもよい。このようなマスター／スレーブの構成を採用することで、ローカルバス群４を転送される通信フレームのタイミング制御などを容易に行うことができる。より具体的には、通信カプラユニット３００は、コントローラ３１０と、通信回路３３０と、ネットワークインターフェイス３５０とを含む。

通信回路３３０は、通信線であるローカルバス群４を介して、１または複数の機能ユニット２００とデータを遣り取りする。より具体的には、通信回路３３０は、ローカルバス群４と物理的に接続され、コントローラ３１０からの指令に従って電気信号を生成して、ローカルバス群４（第１ローカルバス４１または第２ローカルバス４２）上に送信するとともに、ローカルバス群４（第１ローカルバス４１または第２ローカルバス４２）上に生じる電気信号を復調してコントローラ３１０へ出力する。

ネットワークインターフェイス３５０は、通信線であるフィールドネットワーク６を介して、ＣＰＵユニット１００Ａとデータを遣り取りする。

コントローラ３１０は、ネットワークインターフェイス３５０おいてＣＰＵユニット１００Ａまたは他のデイバスとの間で遣り取りされるデータと、通信回路３３０において１または複数の機能ユニット２００との間で遣り取りされるデータとを互いに転送する処理を実行する。

このような構成においても、通信カプラユニット３００のコントローラ３１０は、ローカルバス群４を構成する第１ローカルバス４１および第２ローカルバス４２を用いて、異なる周期（一定周期）でのＩＯリフレッシュ処理をそれぞれ独立に行うことができる。より具体的には、ＣＰＵユニット１００Ａから各通信カプラユニット３００に対して各種設定値が与えられ、通信カプラユニット３００のコントローラ３１０は、ＣＰＵユニット１００Ａからの各種設定値に従って、ＩＯリフレッシュフレームの送信周期などを決定する。

通信カプラユニット３００によるＩＯリフレッシュ処理については、上述の実施の形態１と同様であるので、詳細な説明は繰返さない。

実施の形態２に係るＰＬＣ１Ａのような構成を採用することで、ＣＰＵユニット１００Ａに接続される機能ユニット２００だけではなく、通信カプラユニット３００に接続される機能ユニット２００に対しても、互いに独立したＩＯリフレッシュフレームを利用することができるの、ＰＬＣ１Ａの全体として効率的なＩＯリフレッシュ処理を実現できる。

［３．実施の形態３］
実施の形態１に係るＰＬＣ１のＣＰＵユニット１００においては、プロセッサ１１２を含む演算処理部１１０が通信回路１３０に対して指令を与えることで、ローカルバス群２を介したＩＯリフレッシュフレームの遣り取りを実現する。ローカルバス群２を介したＩＯリフレッシュフレームの遣り取りをより高速化するために、演算処理部１１０を代理して、通信回路１３０との間で各種データを遣り取りする制御回路をさらに配置してもよい。このような制御回路を採用することで、演算処理部１１０のプロセッサ１１２での演算処理を低減できるとともに、演算処理部１１０と通信回路１３０との間の通信線の伝送容量が相対的に小さい場合であっても、ＩＯリフレッシュ処理を効率かつ高速に実現できる。

＜Ａ．装置構成＞
図７は、実施の形態３に係るＰＬＣ１Ｂの要部構成を示す模式図である。図７を参照して、ＰＬＣ１ＢのＣＰＵユニット１００Ｂは、演算処理部１１０と通信回路１３０との間に配置される制御回路１４０をさらに含む。制御回路１４０は、演算処理部１１０および通信回路１３０に接続され、演算処理部１１０と通信回路１３０との間で要求を仲介する機能を有しており、例えば、プロセッサ１１２からの通信要求に応答して、通信回路１３０に対して指令を与えてデータの送信または受信を行う。制御回路１４０は、後述するように、例えば、ＤＭＡ（Direct Memory Access）などのデータアクセスを高速化するための機能などが実装される。

制御回路１４０の少なくとも主要部については、ハードワイヤードな構成を有することで、プロセッサ１１２より高速な処理を実現するようにしてもよい。典型的には、制御回路１４０は、ハードウェアロジックを用いて実現される。例えば、制御回路１４０は、ＰＬＤ（Programmable Logic Device）の一例であるＦＰＧＡ（Field-Programmable Gate Array）や、ＩＣ（Integrated Circuit）の一例であるＡＳＩＣ（Application Specific Integrated Circuit）などを用いて実装されてもよい。さらに、演算処理部１１０のプロセッサ１１２および制御回路１４０の主要機能を同一のチップ上に実装したＳｏＣを用いてもよい。

図８は、実施の形態３に係るＰＬＣ１ＢのＣＰＵユニット１００Ｂの要部構成を示す模式図である。図８を参照して、ＰＬＣ１ＢのＣＰＵユニット１００Ｂは、演算処理部１１０と、制御回路１４０と、通信回路１３０とを含む。

演算処理部１１０のプロセッサ１１２がシステムプログラムなどを実行することで、ＩＯリフレッシュ処理が実行される。ＩＯリフレッシュ処理によって、メインメモリ１１４には、入力データおよび出力データが記憶されるとともに、ＩＯリフレッシュ周期に応じて、各値が更新される。

通信回路１３０は、ローカルバス群２上で通信フレームを用いて遣り取りされる入力データ１３４および出力データ１３５を格納するバッファ１３２を含む。後述するように、制御回路１４０は、出力データ１３５を通信回路１３０のバッファ１３２に書込み、通信回路１３０のバッファ１３２に格納される入力データ１３４を読出す。通信回路１３０のバッファ１３２には、指定された宛先に通信フレームを伝送するための決定するためのルーティングテーブル１３３が格納されていてもよい。

図８に示すように、通信回路１３０のバッファ１３２に格納される入力データおよび出力データと演算処理部１１０のメインメモリ１１４に格納される入力データおよび出力データとを同期させる必要がある。実施の形態３においては、制御回路１４０がＤＭＡを用いて、プロセッサ１１２によるデータアクセスなどの処理を低減しつつ、データ転送をより高速化する。

より具体的には、制御回路１４０は、バスアービタ１４２と、処理エンジン１４００とを含む。制御回路１４０は、任意のハードウェアを用いて実装できる。

バスアービタ１４２は、演算処理部１１０のプロセッサ１１２と処理エンジン１４００とを接続するバス上に配置され、複数のデータアクセス要求が競合したときに、優先度などを用いた予め定められた規則に従って調停する。

処理エンジン１４００は、制御回路１４０の主たる機能を提供するコンポーネントであり、演算処理部１１０と通信回路１３０との間のデータの遣り取りを代理するような機能を提供する。

処理エンジン１４００は、互いに異なる優先度（「priority」と標記することもある。）が設定された複数のＤＭＡコアを有し、このＤＭＡコアに対して１または複数のコマンドからなるディスクリプタテーブルが与えられることで、指定された処理が実行される。ディスクリプタテーブルは、典型的には、アセンブラまたは機械語で記述される。後述するように、ディスクリプタテーブルに優先度が設定されることで、各ディスクリプタテーブルを処理するＤＭＡコアが決定される。このような優先度別のＤＭＡコアおよびディスクリプタテーブルを用いることで、プライマリ定周期タスク１２２１で繰返し実行されるＩＯリフレッシュ処理と、通常定周期タスク１２２２で繰返し実行されるＩＯリフレッシュ処理とを並列的に実行させることができる。

ディスクリプタテーブルに設定される優先度は、演算処理部１１０へデータアクセスするためのＤＭＡコア１４０１，１４０２へのアクセス権、ディスクリプタテーブル格納部１４７０、ディスクリプタ起動レジスタ１４７２、コマンドキャッシュ１４７４などの処理エンジン１４００内部のメモリへのアクセス権、通信回路１３０を起動させるためのアクセス権、および、通信回路１３０へのアクセス権、などの管理に用いられる。

具体的には、処理エンジン１４００は、ＤＭＡコア１４０１，１４０２，１４４０と、バスアービタ１４１１，１４１２，１４３０と、ディスクリプタ（以下、「Descriptor」と標記することもある。）コントローラ１４２０＿０〜１４２０＿Ｎと、ディスクリプタテーブル格納部１４７０と、ディスクリプタ起動レジスタ１４７２と、コマンドキャッシュ１４７４とを含む。

図８には、一例として、Ｎ段階の優先度を設定可能な構成を示す。このＮ段階の優先度に対応して、Ｎ個のディスクリプタコントローラ１４２０＿０〜１４２０＿Ｎ（「ディスクリプタコントローラ１４２０」と総称することもある。）が用意されている。優先度をＮ段階に設定しているのは一例であり、段階数については任意に設定できる。実施の形態１においては、優先度が「０」（priority0）が最高優先度であり、優先度が「Ｎ」（priority0）が最低優先度であるとしている。

ＤＭＡコア１４０１，１４０２は、演算処理部１１０（主として、メインメモリ１１４）へのアクセスを担当する。ＤＭＡコア１４０１，１４０２には、ディスクリプタコントローラ１４２０の優先度に対応させて、３段階の優先度が設定されている。一例として、ＤＭＡコア１４０１は、優先度が「０」〜「ｎ」のディスクリプタコントローラ１４２０に対応し、ＤＭＡコア１４０２は、優先度が「ｍ」〜「Ｎ」のディスクリプタコントローラ１４２０に対応する。

なお、図８に示される２段階の優先度は一例であり、これに限られることなく、アクセス頻度などに応じて、任意の数のＤＭＡコアを採用すればよい。

処理エンジン１４００は、異なるディスクリプタテーブルに従う処理が同時に要求されると、各ディスクリプタテーブルに設定されている優先度に基づいて調停するアービタを含む。

より具体的には、バスアービタ１４１１，１４１２は、それぞれＤＭＡコア１４０１，１４０２へのコマンド入力を調停する。すなわち、バスアービタ１４１１は、ディスクリプタコントローラ１４２０＿０〜１４２０＿ｎからＤＭＡコア１４０１へのコマンド入力が競合しないように調停する。バスアービタ１４１２は、ディスクリプタコントローラ１４２０＿ｍ〜１４２０＿ＮからＤＭＡコア１４０２へのコマンド入力が競合しないように調停する。

ＤＭＡコア１４４０は、通信回路１３０（主として、バッファ１３２）へのタアクセスを担当する。バスアービタ１４３０は、ＤＭＡコア１４４０へのコマンド入力を調停する。すなわち、バスアービタ１４３０は、ディスクリプタコントローラ１４２０＿０〜１４２０＿ＮからＤＭＡコア１４４０へのコマンド入力が競合しないように、コマンド発行元のディスクリプタコントローラ１４２０に設定されている優先度などに基づいて調停する。

ディスクリプタテーブル格納部１４７０は、ＤＭＡコアに与えるコマンドを格納する。すなわち、ディスクリプタテーブル格納部１４７０は、一種のコマンドバッファとして機能する。

ディスクリプタ起動レジスタ１４７２は、各ディスクリプタテーブルに格納される各コマンドに対する優先度を設定するためのレジスタからなる。ディスクリプタテーブル格納部１４７０に何らかのコマンドが格納されるのに併せて、ディスクリプタ起動レジスタ１４７２には、ディスクリプタテーブル格納部１４７０に格納されたコマンドを参照するためのアドレスが、当該コマンドに設定される優先度に応じたレジスタにセットされる。例えば、ディスクリプタテーブル格納部１４７０に優先度が「０」であるコマンドＡが格納されると、当該格納されたコマンドＡを参照するためのアドレスが、ディスクリプタ起動レジスタ１４７２の優先度「０」に対応付けられる領域にセットされる。一方、ディスクリプタテーブル格納部１４７０に優先度が「１」であるコマンドＢが格納されると、当該格納されたコマンドＢを参照するためのアドレスが、ディスクリプタ起動レジスタ１４７２の優先度「１」に対応付けられる領域にセットされる。このように、ディスクリプタ起動レジスタ１４７２は、それぞれの優先度に対応付けられるレジスタを含む。

そして、ディスクリプタ起動レジスタ１４７２にセットされている優先度毎のレジスタ値に基づいて、ディスクリプタテーブル格納部１４７０に格納されたコマンドが指定されたＤＭＡコアへ順次与えられることで、ディスクリプタテーブルに記述された処理が実行される。

このように、ディスクリプタテーブル格納部１４７０およびディスクリプタ起動レジスタ１４７２は、互いに異なる優先度が予め設定された複数のディスクリプタテーブルのうちから指定されたディスクリプタテーブルを選択的に起動するための機能の一部として用いられる。

コマンドキャッシュ１４７４は、指定されたディスクリプタテーブルに含まれる１または複数のコマンドを一時的に格納する。コマンドキャッシュ１４７４に格納された１または複数のコマンドは、指定されたＤＭＡコアへ順次与えられて、記述された処理が実行される。

後述するように、ディスクリプタテーブル格納部１４７０または演算処理部１１０のメインメモリ１１４とディスクリプタ起動レジスタ１４７２とを組み合わせて、ＤＭＡコアに任意のコマンドを与えることができる。

＜Ｂ．リフレッシュ処理の処理手順＞
次に、図８に示すＣＰＵユニット１００ＢにおけるＩＯリフレッシュ処理の手順について概略する。図９は、実施の形態３に係るＰＬＣ１ＢにおけるＩＯリフレッシュ処理の処理手順を示す模式図である。なお、ディスクリプタテーブル格納部１４７０には、予め優先度付けされたディスクリプタテーブルが格納されているとする。

図９を参照して、タスク実行周期が到来して、プライマリ定周期タスク１２２１または通常定周期タスク１２２２が実行されると（図９の（１））、演算処理部１１０のプロセッサ１１２は、ディスクリプタ起動レジスタ１４７２を構成するフラグのうち、実行すべき処理を規定したディスクリプタテーブルに対応するフラグをセットする（図９の（２））。すると、セットされたフラグに対応するディスクリプタテーブルがディスクリプタテーブル格納部１４７０から、対応するディスクリプタコントローラ１４２０へ与えられる（図９の（３））。

ディスクリプタコントローラ１４２０は、演算処理部１１０（プロセッサ１１２）からのトリガに応じて、予め定義されたディスクリプタテーブルに従って、ＤＭＡコア１４０１，１４０２，１４０３および／またはＤＭＡコア１４４０に順次コマンドを与える（図９の（４））。

ＩＯリフレッシュ処理においては、ＤＭＡコア１４４０に対しては、ＩＯリフレッシュフレームの発行などを指示するための１または複数のコマンドが与えられる。これらのコマンドに従って、ＤＭＡコア１４４０は、通信回路１３０の通信を起動して、通信回路１３０からＩＯリフレッシュフレームが送出する（図９の（５））。

通信回路１３０から送出されたＩＯリフレッシュフレームがローカルバス（第１ローカルバス２１または第２ローカルバス２２）を一巡することで、ＩＯリフレッシュ処理が実行される（図９の（６））。これにより、通信回路１３０のバッファ１３２に格納される入力データ１３４を更新する。

そして、ＤＭＡコア１４０１およびＤＭＡコア１４４０によるデータアクセスによって、通信回路１３０のバッファ１３２に格納される入力データ１３４が演算処理部１１０のメインメモリ１１４へ転送され、演算処理部１１０のメインメモリ１１４に格納される出力データが通信回路１３０のバッファ１３２へ転送される（図９の（７））。

以上のような処理手順によって、制御回路１４０を利用したＩＯリフレッシュ処理が完了する。

図９には、一例として、ディスクリプタテーブル格納部１４７０およびディスクリプタ起動レジスタ１４７２を用いる構成について例示するが、メインメモリ１１４にディスクリプタテーブル１４８が格納される構成であっても、ほぼ同様の処理手順が実施される。

＜Ｃ．ディスクリプタテーブルのデータ構造＞
次に、ディスクリプタテーブルのデータ構造の一例について説明する。

図１０は、実施の形態３に係るＰＬＣ１Ｂに用いられるディスクリプタテーブルのデータ構造の一例を示す模式図である。図１０を参照して、実施の形態３に係るＰＬＣ１Ｂにおいては、優先度付けされたディスクリプタテーブル１４８＿０〜１４８＿Ｎ（以下、「ディスクリプタテーブル１４８」とも総称する。）が用いられる。ディスクリプタテーブル１４８の各々は、１または複数のコマンド１４８２で構成され、ディスクリプタテーブル１４８に記述されたコマンド１４８２に従ってＤＭＡコアで処理が実行される。コマンド１４８２の各々は、コマンド番号１４８３および命令１４８４の組み合わせで構成される。命令１４８４には、ＤＭＡコアが解釈できるようなアセンブラまたは機械語が用いられてもよい。

＜Ｄ．ディスクリプタテーブルの起動および格納＞
次に、ディスクリプタテーブル１４８に従ってＤＭＡコアで処理を実行する場合の起動方法およびディスクリプタテーブル１４８の格納方法の一例について説明する。

図１１は、実施の形態３に従うＰＬＣ１Ｂにおけるディスクリプタテーブル１４８の起動および格納について説明するための模式図である。図１１を参照して、ディスクリプタテーブル１４８は、（１）処理エンジン１４００のディスクリプタテーブル格納部１４７０に格納されてディスクリプタコントローラ１４２０へ転送される方法、および、（２）メインメモリ１１４に格納されて処理エンジン１４００のコマンドキャッシュ１４７４を介してディスクリプタコントローラ１４２０へ転送される方法が可能である。

（１）の起動方法によれば、起動指令を与えてからディスクリプタコントローラ１４２０へディスクリプタテーブルの転送が完了するまでの時間を短縮できる。但し、ディスクリプタテーブル格納部１４７０の容量を確保する必要がある。

一方、（２）の起動方法によれば、起動指令を与えてからディスクリプタコントローラ１４２０へディスクリプタテーブルの転送が完了するまでの時間をより多く必要とするが、メインメモリ１１４を用いるので容量についての制約が少ない。

（１）の起動方法および／または（２）の起動方法を採用した場合には、ディスクリプタテーブルは、演算処理部１１０のメインメモリ１１４および制御回路の記憶領域（一例として、ディスクリプタテーブル格納部１４７０）の少なくとも一方に格納されることになる。

一例として、図１１に示す構成例においては、優先度の高い８つのディスクリプタテーブル１４８のみがディスクリプタテーブル格納部１４７０に格納され、残りの優先度の低い８つのディスクリプタテーブル１４８についてはメインメモリ１１４に格納されている。図１１に示すような両方の起動方法を優先度別に採用することで、高優先の処理の実行速度を高めるとともに、ＣＰＵユニット１００Ｂのコストを抑制することができる。

例えば、高速処理が要求されるプライマリ定周期タスク１２２１のＩＯリフレッシュ処理を実現するためのディスクリプタテーブル１４８については、ディスクリプタテーブル格納部１４７０に格納し、複雑な処理が要求される通常定周期タスク１２２２のＩＯリフレッシュ処理を実現するためのディスクリプタテーブル１４８については、メインメモリ１１４に格納するようにしてもよい。

各ディスクリプタテーブル１４８の起動は、ディスクリプタ起動レジスタ１４７２へのフラグ書込みによって行われる。ディスクリプタテーブル１４８には、処理エンジン１４００が利用可能なディスクリプタテーブル１４８の数（優先度の数）に応じたフラグ領域が用意される。

但し、図１１に示す構成に限定されるものではなく、すべてのディスクリプタテーブル１４８をディスクリプタテーブル格納部１４７０に格納するようにしてもよいし、すべてのディスクリプタテーブル１４８をメインメモリ１１４に格納するようにしてもよい。

より具体的には、（１）の具体的な起動方法によれば、プロセッサ１１２がシステムプログラム１２２を実行することで、ディスクリプタテーブル格納部１４７０に格納されているディスクリプタテーブル１４８のうち、指定されたディスクリプタテーブル１４８に対応するディスクリプタ起動レジスタ１４７２のフラグをセットする。ディスクリプタ起動レジスタ１４７２のフラグのセットに応答して、対応するディスクリプタテーブル１４８が起動し、ディスクリプタテーブル格納部１４７０から対応するディスクリプタコントローラ１４２０へディスクリプタテーブル１４８のコマンドが転送される。

実施の形態３に従うＰＬＣ１Ｂの処理エンジン１４００においては、複数のディスクリプタテーブル１４８にはそれぞれ優先度が設定されており、それぞれに設定されている優先度に応じて、転送先のディスクリプタコントローラ１４２０は予め定められている。

一方、（２）の具体的な起動方法によれば、プロセッサ１１２がシステムプログラム１２２を実行することで、ディスクリプタテーブル格納部１４７０に格納されているディスクリプタテーブル１４８のうち、指定されたディスクリプタテーブル１４８に対応するディスクリプタ起動レジスタ１４７２のフラグをセットする。ディスクリプタ起動レジスタ１４７２のフラグのセットに応答して、メインメモリ１１４に格納されているディスクリプタテーブル１４８のうち、指定されたディスクリプタテーブル１４８に含まれるコマンドの全部または一部がコマンドキャッシュ１４７４に転送されて一時的に格納される。その上で、コマンドキャッシュ１４７４から対応するディスクリプタコントローラ１４２０へその格納されたコマンドが順次転送される。ディスクリプタテーブル１４８に含まれるコマンドのすべてをコマンドキャッシュ１４７４に一度に転送できない場合には、コマンドキャッシュ１４７４をリングバッファのように使用して、コマンドの格納および転送を順次行うようにしてもよい。

以上のような方法によって、ディスクリプタテーブル１４８をＤＭＡコアに与えて必要な処理を実行させることができる。

［４．実施の形態３の変形例］
実施の形態３に係るＰＬＣ１Ｂに含まれる制御回路１４０に相当する構成および機能については、図６に示す通信カプラユニット３００にも実装してもよい。このような構成を採用することで、通信カプラユニット３００での処理も高速化することができる。

［５．まとめ］
本実施の形態に係るＰＬＣにおいては、通信線の一例であるローカルバスを複数設けるとともに、それぞれ異なる周期でＩＯリフレッシュ処理を行うことができる。このように、複数のＩＯリフレッシュ処理を互いに独立して実行できるようにすることで、１つのＣＰＵユニットに接続される機能ユニットの数が増大したり、対象となる入力データおよび出力データのデータサイズが大きくなったりすると、通信フレームのデータサイズが大きくなり、通信処理に必要な時間が長くなり、ＩＯリフレッシュ処理の周期も長くせざるを得ないという課題を解決することができる。

また、ＩＯリフレッシュ処理の周期を異ならせることで、高速応答が可能な機能ユニットと低速応答で十分な機能ユニットとを分離することができる。これによって、低速応答で十分な機能ユニットが増大することで、高速応答が可能な機能ユニットの能力を十分に発揮できないといった事態を回避できる。

また、本実施の形態に従うＰＬＣによれば、ＤＭＡを用いてメモリアクセスすることで、プロセッサを含む演算処理部１１０と、通信回路１３０とを接続する通信線の容量が小さい場合であっても、高速なＩＯリフレッシュ処理を実現できる。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１，１Ａ，１Ｂ ＰＬＣ、２，４ ローカルバス群、６ フィールドネットワーク、２１，４１ 第１ローカルバス、２２，４２ 第２ローカルバス、１００，１００Ａ，１００Ｂ ＣＰＵユニット、１１０ 演算処理部、１１２ プロセッサ、１１４ メインメモリ、１２０ ストレージ、１２２ システムプログラム、１２４ ユーザプログラム、１２６ コンフィギュレーション、１３０，２１６，３３０ 通信回路、１３２ バッファ、１３３ ルーティングテーブル、１３４ 入力データ、１３５ 出力データ、１４０ 制御回路、１４２，１４１１，１４１２，１４３０ バスアービタ、１４７ 外部インターフェイス、１４８ ディスクリプタテーブル、１５０，３５０ ネットワークインターフェイス、２００ 機能ユニット、２１０ 通信処理部、２１１，２１２，２１３，２１４ 送受信ポート、２２０ 機能モジュール、２３０ ＩＯインターフェイス、３００ 通信カプラユニット、３１０ コントローラ、５００ ユーザインターフェイス画面、５０２，５０４ 入力項目、５０６ ラジオボタン群、１２２１，１２２２ 定周期タスク、１４００ 処理エンジン、１４０１，１４０２，１４４０ ＤＭＡコア、１４２０ ディスクリプタコントローラ、１４７０ ディスクリプタテーブル格納部、１４７２ ディスクリプタ起動レジスタ、１４７４ コマンドキャッシュ、１４８２ コマンド、１４８３ コマンド番号、１４８４ 命令。

Claims (7)

1. 制御装置であって、
   通信ユニットと、
   １または複数の機能ユニットと、
   前記通信ユニットと前記１または複数の機能ユニットとの間を接続する、互いに独立した複数の通信線とを備え、
   前記通信ユニットは、
   前記複数の通信線のうち第１通信線を介して、前記機能ユニットが収集しているデータの前記通信ユニットへの送信、および、前記通信ユニットが保持しているデータの前記機能ユニットへの送信のうち、少なくとも一方を実行するための第１通信フレームを第１周期で送出する第１タスクと、
   前記複数の通信線のうち第２通信線を介して、前記機能ユニットが収集しているデータの前記通信ユニットへの送信、および、前記通信ユニットが保持しているデータの前記機能ユニットへの送信のうち、少なくとも一方を実行するための第２通信フレームを前記第１周期とは独立に設定される第２周期で送出する第２タスクとを実行するように構成され、
   前記１または複数の機能ユニットの各々は、前記通信ユニットとの間のデータの遣り取りを行うために、前記第１通信フレームおよび前記第２通信フレームのうち一方の通信フレームのみを処理するとともに、処理対象の通信フレーム以外はそのまま転送するように構成されており、
   前記制御装置は、前記１または複数の機能ユニットの各々について、前記第１通信フレームおよび前記第２通信フレームのいずれを処理対象とするのかを指定するユーザインターフェイス画面を提供する手段をさらに備える、制御装置。
2. 前記第１通信フレームおよび前記第２通信フレームの各々には、処理を行う機能ユニットに関連付けられるデータ領域が設けられている、請求項１に記載の制御装置。
3. 前記ユーザインターフェイス画面は、前記第１通信フレームおよび前記第２通信フレームのそれぞれの送信周期の指定を受け付ける、請求項１または２に記載の制御装置。
4. 前記通信ユニットは、
   前記第１タスクおよび前記第２タスクを実行するプロセッサとメモリとを含む演算処理部と、
   通信フレームの送受信を担当する通信回路と、
   前記演算処理部および前記通信回路に接続される制御回路とを備え、
   前記制御回路は、
   前記演算処理部にアクセスするための第１ＤＭＡ（DirectMemoryAccess）コアと、
   前記通信回路にアクセスするための第２ＤＭＡコアと、
   前記演算処理部からのトリガに応じて、予め定義されたディスクリプタテーブルに従って、前記第１ＤＭＡコアおよび前記第２ＤＭＡコアに順次コマンドを与えるコントローラとを備える、請求項１〜３のいずれか１項に記載の制御装置。
5. 前記制御回路は、
   互いに異なる優先度が予め設定された複数のディスクリプタテーブルのうちから指定されたディスクリプタテーブルを選択的に起動するための起動手段と、
   異なるディスクリプタテーブルに従う処理が同時に要求されると、各ディスクリプタテーブルに設定されている優先度に基づいて調停するアービタとをさらに備える、請求項４に記載の制御装置。
6. 前記複数のディスクリプタテーブルは、前記演算処理部の前記メモリおよび前記制御回路の記憶領域の少なくとも一方に格納される、請求項５に記載の制御装置。
7. 前記通信ユニットは、演算ユニットおよび中継ユニットのいずれか一方である、請求項１〜６のいずれか１項に記載の制御装置。

Images