JP6152920B2 - プログラマブルコントローラシステム、そのコントローラ - Google Patents

Description

本発明は、プログラマブルコントローラシステムに関する。

近年の制御システムは、大規模化に伴って、複数のコントローラをネットワークで接続して分散配置するマルチコンフィグ構成（マルチコンフィグ制御システム）が用いられる場合がある。この様な構成の一例として、例えば図２１に概略的に示すシステムが知られている。

図２１は、この様なマルチコンフィグ制御システムの概略図である。

制御システムは、主なコンポーネントとして上位から、サーバやホストコンピュータ、監視制御用パソコン、シーケンス制御コントローラ、ＩＯモジュール／インバータなどがあり、それぞれの間をコンピュータレベルネットワーク、コントローラレベルネットワーク、デバイスレベルネットワークでそれぞれ接続している。

図２１に示すプログラマブルコントローラシステム例では、生産管理・指示などを行なうコンピュータレベルのネットワークと、加工機械などのコントローラ間を接続するコントローラレベルのネットワークと、コントローラ個々と各機器（Ｉ／Ｏ）間を接続するデバイスレベルのネットワークが設けられている。そして、これらネットワークを階層的に接続することで、統合監視制御を実現している。

図２２は、コントローラレベルネットワークに着目した従来システム構成例である。

大規模システムでは、そのシステムの処理の複雑さや物理的配置の問題などから、複数のコントローラによる制御アプリケーションの分割制御が行われる。一つ一つの制御単位はコンフィグレーション２０２(図中に点線で囲まれた範囲)とよばれ、複数のコンフィグレーション２０２をコントローラレベルネットワーク２０３で接続したシステム構成によって全体制御を行う。また、コントローラレベルネットワーク２０３には、更に、システム全体の監視制御や生産管理を行うためのサーバ２０１等が接続されるのが一般的である。

各コンフィグレーション２０２の構成は、例えば図２３に示すように、制御アプリケーションを実行するＣＰＵモジュール２１５、制御対象機器との入出力を行うＩ／Ｏモジュール２１４、コントローラレベルネットワーク２０３上での通信を行う通信モジュール２１３等からなる。

上記各モジュール２１３，２１４，２１５は、デバイスレベルネットワーク２１２に接続されており、当該ネットワーク２１２を介して相互に通信可能となっている。

尚、この例に限らず、例えばベースボードのようなボード形状のものにそれぞれのモジュールを実装し、ボード上のバスを経由してモジュール間のデータ交換を行う実装も可能である。また、更にＣＰＵモジュール２１５が上位支援ツール２１６に接続された構成であってもよい。

各コンフィグレーション２０２では、例えば、上位支援ツール２１６からＣＰＵモジュール２１５に対して、制御アプリケーションのダウンロードやアプリケーション起動/停止などの制御、モニタによる監視などが行われる。

上記デバイスレベルネットワークに関して、例えばモーション制御などに用いられる高速なデバイスレベルネットワークに関しては、スレーブ機器の入出力タイミングを同期する機能が知られている。例えば、本出願人は、デバイスレベルネットワークでのタイミング同期手法を提案している(特許文献１)。

図２４は、特許文献１におけるデバイスレベルネットワークの処理タイミング例である。

図２４において、図示の符号２２１には、ＣＰＵモジュールによるアプリ演算のタイミングを示し、図示の符号２２２にはＣＰＵモジュールから出力されるバス上のデータフレームを示し、図示の符号２２３にはＩＯモジュールにおけるデータ処理タイミングを示している。

尚、実際には、スレーブモジュール間もケーブル接続されており、それによりＭＣフレームのデータ取得タイミングがずれているが、ここでは割愛している。

デバイスレベルネットワーク上での通信に係わる各モジュールの処理は、所定周期（タクト周期と呼ばれる）で実行・管理される。

これは、ＣＰＵモジュールにおいては、タクト割込みと言われる周期割込みが生じるものである。ＣＰＵモジュールでは、上記タクト割込みにてアプリ演算を開始する。タクト割込みは、入力データ（ＴＦ（トータルフレーム)）の転送完了時点で発生するように構成されている。

尚、ＴＦフレームは、システムを構成するＩＯモジュールの種類や数に応じて予め計算されたタイミングの定周期割込みにて、ＣＰＵモジュールがデバイスレベルネットワーク上に送信する。この定周期割込みは、例えばタクト割込み発生タイミング（タクト周期開始タイミング）２２４から図示の符号２２６の時間経過したタイミングで、発生する。

上記ＴＦフレームは、図示のように各ＩＯモジュールを順次巡回して、各ＩＯモジュールにおいて任意のデータが付加されて、最終的にＣＰＵモジュールに戻ってきて不図示の受信バッファ等に格納される。これによって、ＣＰＵモジュールは各ＩＯモジュールのデータを取得できる（最新データを入力する）。この様なＴＦフレームを受信完了した時点が上記転送完了時点である。そして、ＣＰＵは、受信バッファから上記最新データを図示の入力データ２２８として取得することになる。

ＣＰＵモジュールは、上記最新の入力データ２２８に基づき所定のアプリ演算を行い、出力データ２２９を生成する。出力データ２２９は、ＭＣデータとして不図示の送信バッファに格納される。格納されたＭＣデータは、次のタクト割込み発生タイミングで、各ＩＯモジュールへ配信される。

尚、特に図示しないが、ＣＰＵモジュールは、一例として、上記アプリ演算等を行うＣＰＵと、上記送信バッファや受信バッファのデータ格納／送信を行うプロセッサ等から構成される。

また、尚、図２４に示すように、ＣＰＵモジュールにおけるタクト周期と、各ＩＯモジュールにおけるタクト周期とは、タイミングが異なっているが、これは位相が異なるだけであり、長さ自体は同じ（例えば１ms）である。全てのＩＯモジュールでタクト周期開始タイミングを同じとする必要がある為、各ＩＯモジュール毎に異なる“遅れ時間”が設定されている。各ＩＯモジュール毎に、ＴＦフレーム受信時から“遅れ時間”経過したタイミング、あるいはＭＣフレーム受信時から“遅れ時間”経過したタイミングを、タクト周期開始タイミングとする。これによって、全てのＩＯモジュールでタクト周期開始タイミングを、図示のように同じにすることができる。尚、“遅れ時間”は、予めＣＰＵモジュールが各ＩＯモジュールとの通信に基づいて決定して各ＩＯモジュールに設定している。

ここで、上述したことから、ＣＰＵモジュールにおけるタクト周期のタイミングを変えれば、ＴＦフレーム送信やＭＣフレーム送信のタイミングが変わることで、各ＩＯモジュールにおけるタクト周期も変わることになる。

また、図２４には明確には示していないが、ＣＰＵモジュールにおいてはタクト周期は２種類あると考えることもできる。すなわち、図２４において符号２２１で示す欄のタクト周期２２５と、符号２２２で示す欄のバス上でのデータ送受信に係わるタクト周期（不図示）である。この不図示のタクト周期内は、図示していないが、図示のＴＦフレームを巡回させる時間帯、図示のＭＣフレームを各ＩＯモジュールに配信する時間帯、図示のＭＳＧ帯域（任意の１対１のメッセージ送受信の時間帯）とに時分割されている。つまり、各タクト周期毎に、図示のＴＦ、ＭＣ、ＭＳＧの順で上記各処理が行われる。

尚、符号２２１で示す欄のタクト周期２２５は、ＣＰＵ等による所定の演算に係わるものであり「アプリ演算周期」等と呼ぶこともできる。一方、上記不図示のタクト周期は「バス・タクト周期」等と呼ぶこともできるものとする。

ここで、コントローラレベルのネットワークは、デバイスレベルのネットワークと比較して低速にデータ交換を行っており、制御周期を同期させる機能を持ったネットワークはなかった。

そこで本出願人は、先願（PCT/JP2013/050121）によって、コントローラレベルのネットワークに関し、コントローラ間の処理タイミングを同期する機能を提案している。

また、上記のようなマルチコンフィグ制御システムでは、分散配置された各コントローラが独自の周期（各局バラバラのタイミング）で制御機器のデータ（Ｉ／Ｏデータ）を収集する。これらコントローラが収集したＩ／Ｏデータは、更にホストコンピュータ等に収集されるが、収集された各Ｉ／Ｏデータは、時系列的にバラバラになる。すなわち、従来の制御システムでは、ホストコンピュータに集められた各Ｉ／Ｏデータの同時性の保証ができないシステムであった。

この問題に関して、従来では、例えば、仮に上記コントローラとして第１コントローラと第２コントローラがあるものとした場合、下記の方法を用いていた。

ここで、仮に、第１コントローラのアプリケーション実行周期が１０ｍｓであり、第２コントローラのアプリケーション実行周期が１８ｍｓであった場合、コントローラレベルネットワークのデータリフレッシュ周期を２０ｍｓにしていた。

この様に、一番遅いアプリケーションの実行周期に合わせてコントローラ間ネットワークのデータリフレッシュ周期を設定していた。従って、ホストコンピュータに収集された各Ｉ／Ｏデータは、２０ｍｓの間に何らかの変化が起こったという同時性しか保証されず、Ｉ／Ｏデータの状態変化の同時性の精度が粗かった。換言すれば、ホストコンピュータに収集された各データの同時性精度が、コントローラレベルネットワークのデータリフレッシュ周期に依存していた。

近年の金属圧延加工等の大規模制御システムでは、圧延ローラの制御パラメータ、圧延ローラの回転速度、圧力等の実測値や圧延対象の温度、板厚等のデバイスレベルネットワークに接続された機器のアナログ計測値を収集する。そして、収集データを分析することで、製品品質向上のためのパラメータをチューニングしたり、測定データの変異を取得することによって、各種機器の最適な予防保全を行うことが求められている。

しかしながら、上記従来の制御システムでは、ホストコンピュータに収集された各Ｉ／Ｏデータの同時性の精度が粗いため、現場機器を精度よくチューニングすることや予防保全の推進に限界があった。

従来のコントローラシステムデータ収集装置は、コントローラレベルネットワーク上でやり取りされる比較的低速のコントローラレベル制御データを非同期で収集するか、データ収集の対象としたいＩＯモジュール等へ制御ネットワークとは異なるデータ収集用ネットワークを接続し、別途収集する必要があった(特許文献２)。

図２５に、上記図２２に示す構成に対して特許文献２を適用した場合の構成例を示す。

図示のように、既存のコントローラレベルネットワーク２０３に加えて、更に、データ収集ネットワーク２０４を構築する必要がある。データ収集用ネットワーク２０４には、各ＩＯモジュール２１４とサーバ装置２０５等が接続されており、サーバ装置２０５はデータ収集用ネットワーク２０４を介して各ＩＯモジュール２１４のデータを収集できる。

しかしながら、この構成では、各ＩＯモジュール２１４への通信インタフェースの追加、データ収集用ケーブルのコストなどの部品コストのほか、システム構築、通信確認のための試験等の為のコストが増える。あるいは、誤配線による不具合等のリスクも考えられる。特に、金属圧延加工のシステムでは、圧延ローラを動作させるためのインバータが一システム当たり数十〜数百台設置されることもあり、これらのコスト、リスクはコントローラを用いてシステムを構築するユーザにとって大きな負担となる。

また、上記コントローラレベルネットワーク２０３とデータ収集用ネットワーク２０４との間には、制御上の因果関係はないため、それぞれの収集データを精度よく関連付けることは困難である。

次に、このようなデータ収集のためのネットワークを適用せず、既存のコントローラレベルネットワーク２０３を用いて、制御データやデバイスレベルの各機器からの収集データを交換する場合を考える。

この場合、モジュール形状やケーブルなどは既存システムと同じため、特許文献２で問題となったようなシステムのコスト増は発生しない。

各コントローラが最新のデバイスレベルデータをコントローラレベルネットワークへ送信すると仮定した場合における、既存コントローラレベルネットワーク(コモンメモリ型ネットワーク)を用いたデータ収集タイミングチャートを、図２６に示す。

図２６において、図上上段には、コモンメモリ型のコントローラレベルネットワーク上での各コントローラからの送信データＤ１，Ｄ２，Ｄ３を示している。図示の例では、コントローラＣＴＬ１がデータＤ１を送信し、コントローラＣＴＬ２がデータＤ２を送信している。尚、各コントローラには予め所定のデータ送信タイミング（コントローラ周期開始タイミング１６０からの遅れ時間）が設定されている。つまり、例えばコントローラＣＴＬ１は図示の「Ｄ１」で示すタイミングで上記送信データＤ１を送信し、コントローラＣＴＬ２は図示の「Ｄ２」で示すタイミングで上記送信データＤ２を送信している。

尚、コモンメモリ型のコントローラレベルネットワークの一例として知られるFL-netの場合、各局間で送信権(トークン、図中は表記せず)を巡回させ、トークンを持っている局が自局データを送信する。データ送信タイミングは各局の処理負荷状況に応じるため、データ送信周期はばらつきがあるのが一般的である。

また、図２６の図上中段と下段には、それぞれ、上記各コントローラＣＴＬ１、ＣＴＬ２の演算状況を示している。図示のように、各コントローラの演算処理は、各タクト周期毎に入力→演算→出力の順に行われる。尚、例えば図示の「入力」では上記入力データ２２８を入力し、図示の「出力」では上記出力データ２２９を出力することになる。

そして、本例では、例えばコントローラレベルネットワークに対して上記送信データＤ１，Ｄ２として、常に、図示のようにその時点での最新の入出力データを送信する。

ここで、上記演算は、デバイスレベルネットワークに係わる演算であり、上記入力はデバイスレベルネットワークを介して入力したＩＯモジュールのデータ等である。図示のように、各タクト周期開始タイミング１６９で入力処理が行われるが、コントローラＣＴＬ１とコントローラＣＴＬ２とでタクト周期開始タイミング１６９が異なる場合が多い。

また、既存のコントローラレベルネットワークでは各コンフィグレーションでの同期は行われていないため、CTL1とCTL2の制御アプリケーションの実行タイミングに因果関係はなく、ひとつのコントローラレベルネットワークでデータ収集されているにもかかわらず、最大で「コントローラレベルネットワークの制御周期＋α」分のデータ収集タイミング誤差が生じることになる。さらにコントローラレベルネットワークの制御周期がアプリ負荷により増減するので上記の最大収集誤差も一意には決まらない。
特開２０１２−６８８５６号公報 特開平６−３０１６１７号公報

上記デバイスレベル、コントローラレベルの両方のネットワークにおいてタイミング調整のための機能を実現する場合、ネットワークの位置付けとしてより上位にあるコントローラレベルネットワークのタイミング調整を行ったうえで、そのタイミングに基づいてデバイスレベルネットワークのタイミングを調整することになる。

しかしながら、コントローラレベルネットワークの周期は、通常、デバイスレベルネットワークの制御周期よりも大きく、その分、制御周期の補正幅も大きくなるため、コントローラレベルネットワークのタイミング補正をそのままデバイスレベルネットワークに適用すると、デバイスレベルネットワークにおいて制御周期が乱れ、データ交換抜けなどが発生する。

例えばデバイスレベルネットワークが1msで運用され、それに対してコントローラレベルネットワークが10msで運用されている場合、コントローラレベルでの補正幅が5%の0.5msであってもデバイスレベルネットワークにおいては50%の補正となり、データ破壊、処理抜けが発生する問題がある。

デバイスレベルネットワークでは、その交換データを用いて入出力装置やインバータ、サーボなどの駆動制御装置に対して制御を実施しているので、タイミング補正のたびにデータの抜けや異常が発生すると、システムとして制御が正しく行われなくなる課題がある。

本発明の課題は、コントローラと各入出力対象とが第２ネットワークに接続されて成る制御ユニットを複数有し、該複数のコントローラは第１ネットワークにも接続されたプログラマブルコントローラシステムにおいて、全体のタイミングを同期させることができるプログラマブルコントローラシステム、そのコントローラ等を提供することである。

本発明のプログラマブルコントローラシステムは、まず、前提として、コントローラと各入出力対象とが第２ネットワークに接続されて成る制御ユニットを複数有し、該複数のコントローラは第１ネットワークにも接続された構成を有している。更に、各コントローラが前記第１ネットワークに係わる第１周期と前記第２ネットワークに係わる第２周期に従って演算／通信動作する。この様な構成において、下記の各特徴を有する。

前記複数のコントローラのうちの特定のコントローラは、自己の前記第２周期開始タイミングに基づいて自己の前記第１周期開始タイミングを決定する第１周期生成手段を有する。

前記特定コントローラ以外の各コントローラは、下記の各手段を有する。

・自己の前記第１周期開始タイミングを前記特定コントローラの第１周期開始タイミングに同期させる第１周期同期手段；
・自己の前記第２周期開始タイミングを自己の前記第１周期開始タイミングに基づいて補正する第２周期補正手段。

本例のプログラマブルコントローラシステムの構成図である。 ＣＰＵモジュールの構成図である。 本手法による同期方法の具体例を示す図である。 （ａ）、（ｂ）は、マスタ局、スレーブ局のタクト周期開始タイミングとズレ量の一例を示す図である。 タイマ制御部の構成例を示す図である。 図５のタイマ制御部に係わる各種信号のレジスタインタフェース例である。 補正値生成部に係わる各種信号のタイミングチャート図である。 （ａ）〜（ｃ）は、補正の上限値に関して説明する為の図である。 コントローラレベルネットワーク、デバイスレベルネットワークの周期開始タイミング制御の一例を示す図である。 図９の例に応じてずれ量分を一度に補正した場合の動作例を示す図である。 図１０の例に対して、本手法を適用した場合の動作例を示す図である。 図１１に関連して、補正完了後の動作例を示す図である。 実施例２におけるデータ収集動作例を示す図である。 ＴＣフレーム、データフレームのフレームフォーマット例である。 実施例２の変形例で用いられるデータフレームのデータ構成例である。 実施例２の変形例におけるデータ収集動作例を示す図である。 本例のプログラマブルコントローラシステムの機能ブロック図である。 先願のコントローラネットワーク同期化処理を説明する為の図（その１）である。 先願のコントローラネットワーク同期化処理を説明する為の図（その２）である。 先願のコントローラネットワーク同期化処理を説明する為の図（その３）である。 既存のマルチコンフィグ制御システムの概略図である。 コントローラレベルネットワークに着目した従来システム構成例である。 図２２に示すコンフィグレーションの詳細構成例である。 特許文献１におけるデバイスレベルネットワークの処理タイミング例である。 図２２に示す構成に対して特許文献２を適用した場合の構成例を示す図である。 従来のデータ収集動作例を示す図である。

以下、図面を参照して本発明の実施の形態について説明する。

尚、本例のプログラマブルコントローラシステムは、コントローラ（ＣＰＵモジュール）と各Ｉ／Ｏ機器とがデバイスレベルネットワークに接続されて成る上記“コンフィグレーション”を複数有すると共に、各コントローラがコントローラレベルネットワークに接続された構成のプログラマブルコントローラシステムである。本手法は、例えばこの様なマルチコンフィグ構成のシステムにおける、各コンフィグレーションの周期開始タイミングの同期に関する。

図１は、本例のプログラマブルコントローラシステムの構成図である。

図示の構成自体は、概略的には上記従来の図２２等の構成と略同様であってよいが、本例の場合、従来の通信モジュールの機能がＣＰＵモジュールに組み込まれている。

すなわち、図示の各コンフィグレーション１０（点線で囲む部分）は、ＣＰＵモジュール１１、Ｉ／Ｏモジュール１２等から成る。各モジュール１１、１２は、デバイスレベルネットワーク１３に接続されている。尚、コンフィグレーション１０は、制御ユニット１０等と呼んでもよい。制御ユニット１０は、ＣＰＵモジュール１１（コントローラ）とＩ／Ｏモジュール１２（入出力対象の一例）が、デバイスレベルネットワーク１３に接続されて成る構成と見做してよい。

ＣＰＵモジュール１１は、デバイスレベルネットワーク１３を介して、各Ｉ／Ｏモジュール１２との通信を行う。また、ＣＰＵモジュール１１は、コントローラレベルネットワーク１にも接続している。ＣＰＵモジュール１１は、上記の通り従来の通信モジュールの機能も有しており、コントローラレベルネットワーク１を介して、他のコンフィグレーション１０のＣＰＵモジュール１１との通信を行う。尚、従来の通信モジュールの機能とは、コントローラレベルネットワーク１上の通信機能である。

また、コントローラレベルネットワーク１には、従来と同様、更に、システム全体の監視制御や生産管理を行うためのサーバ装置２等が接続されていてもよい。各ＣＰＵモジュール１１は、コントローラレベルネットワーク１を介して、サーバ装置２との通信も行える。

ここで、ＣＰＵモジュール１１は、例えば先願（PCT/JP2013/050121）におけるコントローラレベルネットワーク機能内蔵のコントローラを用いるが、この例に限らない。例えば上記従来の通信モジュールから処理周期に応じた割込み信号を取得する構成のＣＰＵモジュール等であってもよい。つまり、必ずしも通信モジュールの機能を有しなくてもよい。

図２は、上記ＣＰＵモジュール１１の構成図である。上記の通り、ＣＰＵモジュール１１は、デバイスレベルネットワーク１３上の通信機能だけでなく、コントローラレベルネットワーク１上の通信機能も有するので、それに応じた構成も有している。

図示の例のＣＰＵモジュール１１は、ＣＰＵ２１、コントローラレベルネットワーク制御ＬＳＩ(NET LSI)２２、デバイスレベルネットワーク制御ＬＳＩ(DEV LSI)２４等をメインの構成とする。更に、フラッシュメモリ（FLASH MEM）２３、ＳＲＡＭ２５、DDR SDRAM２６、信号線２７、PC I/F２８等を有する。

ＣＰＵ２１は、コントローラアプリケーションの実行（制御演算）や、上記NET LSI２２、DEV LSI２４等を制御する。尚、ＣＰＵ２１にこの様な各種機能を実行させる為のプログラム（システムソフトウェア、コントローラアプリケーション等）は、予め不揮発メモリである上記FLASH MEM２３に記憶されている。ＣＰＵ２１は、このプログラムを実行することで上記制御等を含む各種機能を実現する。尚、プログラムは、実行時に高速なメモリデバイスである上記DDR SDRAM２６等へ展開されて実行される。

尚、ＣＰＵ２１は、１個のＣＰＵで構成されていてもよいが、複数のＣＰＵで構成されていてもよい。これに関して、複数のＣＰＵそれぞれが各機能に対応するものであってもよい。

また、本例では、DEV LSI２４に対して、制御データ等を格納するためのＳＲＡＭ２５が設けられている。ＳＲＡＭ２５には、例えば後述するＴＦフレームやＭＣフレーム等が一時的に格納される。尚、ＣＰＵ２１もDEV LSI２４を介してＳＲＡＭ２５にアクセス可能である。

また、DEV LSI２４は、タイマー（ＴＩＭＥＲ）２４ａを内蔵している。ＴＩＭＥＲ２４ａは、デバイスレベルネットワーク１３上の各接続機器（Ｉ／Ｏモジュール１２など）に対して、データ出力タイミングを同期させるために用いられる。ＴＩＭＥＲ２４ａの一例が後述するタクトカウンタ４１であると見做しても構わない。つまり、ＴＩＭＥＲ２４ａは、本例では基本的に１（ms）周期のタクト周期を作り出すものである。勿論、この例に限らない。

同様に、NET LSI２２もタイマー（ＴＩＭＥＲ）２２ａを内蔵している。コントローラレベルネットワーク１上の通信に関して、ＴＩＭＥＲ２２ａを用いて各コントローラ（ＣＰＵモジュール１１）間の同期を実現している。本例では基本的に５（ms）周期のコントローラ周期を作り出すものである。

尚、本説明では、デバイスレベルネットワーク１３に係わる周期をタクト周期と呼ぶものとし、コントローラレベルネットワーク１に係わる周期をコントローラ周期と呼ぶものとする。これより、上記具体例では、タクト周期は１（ms）周期であり、コントローラ周期は５(ms)周期となる。周期開始タイミングは、各周期の開始のタイミングであり、例えばタクト周期の場合、任意のタクト周期開始タイミングから１（ｍｓ）後が次のタクト周期開始タイミングとなる。

尚、NET LSI２２は、図示のＮＥＴコネクタを介して、コントローラレベルネットワーク１に接続している。同様に、DEV LSI２４は、図示のDEV NETコネクタを介して、デバイスレベルネットワーク１３に接続している。

また、NET LSI２２とDEV LSI２４との間を接続する上記信号線２７が設けられている。NET LSI２２とDEV LSI２４とは、信号線２７を介して直接的に信号を送受信できる。

信号線２７は、一例としては、NET LSI２２とDEV LSI２４の双方からの割込み信号線と見做しても良い。ここで、本例のコントローラレベルネットワーク１、デバイスレベルネットワーク１３上の通信は、何れも各々の所定周期で実行されるものであり、基本的に、コントローラレベルネットワーク１は、デバイスレベルネットワーク１３よりも長周期である。ここでは具体例として上記の通り、コントローラレベルネットワーク１は５（ｍｓ）周期、デバイスレベルネットワーク１３は１（ｍｓ）周期であるものとする。そして、NET LSI２２とDEV LSI２４は、相互に上記信号線２７を介して自己の周期開始タイミングを示す割込みを通知するようにしてもよい。

ここで、本手法では、上記複数のＣＰＵモジュール１１に関して、そのうちの１台をマスタ局とし、残りはスレーブ局とする。そして、コントローラレベルネットワーク１に関して、マスタ局のコントローラ周期開始タイミングを基準として各スレーブ局のコントローラ周期開始タイミングを同期させる。但し、その前に、マスタ局は、例えば下記のようにして自己のコントローラ周期開始タイミングを決定する。

すなわち、本手法では、マスタ局において、自己の上記タクト周期開始タイミングに基づいて、自己の上記コントローラ周期開始タイミングを生成する。その際、上記図２の信号線２７を介したＬＳＩ相互の割込み通知を利用する。つまり、上記具体例の場合、NET LSI２２は、DEV LSI２４に対して信号線２７を介して、５（ｍｓ）毎に割込み通知を送ることになる。一方、DEV LSI２４は、NET LSI２２に対して信号線２７を介して、１（ｍｓ）毎に割込み通知を送ることになる。

これを利用して、NET LSI２２は、上記DEV LSI２４からの１（ｍｓ）毎に割込み通知に基づいて、コントローラ周期開始タイミングを決定する。上記の例では、DEV LSI２４からの割込み通知５回で、コントローラレベルネットワーク１の１周期とすることになる。

そして、上記決定（調整）後のマスタ局のコントローラ周期開始タイミングに基づいて、各スレーブ局のコントローラ周期開始タイミングを調整（補正）する。つまり、各スレーブ局のコントローラ周期を、マスタ局のコントローラ周期に同期させる。これには、例えば上記先願（PCT/JP2013/050121）の方法を用いる。

更に、各スレーブ局毎に、調整（補正）後のコントローラ周期開始タイミングに基づいて、自己のデバイスレベルネットワーク１３のタクト周期開始タイミングを調整する。つまり、各スレーブ局毎に、上記図２の構成において、DEV LSI２４が、NET LSI２２からの信号線２７を介した割込み通知（５ｍｓに１回の通知）に基づいて、自己のデバイスレベルネットワーク１３のタクト周期開始タイミングの調整を行う。この調整処理については後述する。

尚、図２に示す構成は、一例であり、この例に限らない。例えば他の例としてＣＰＵ２１にNET LSI２２の機能が含まれていても良い。これは、例えばコントローラレベルネットワーク１をEthernet（登録商標）ベースのものとして、ＣＰＵ２１にEthernet（登録商標）機能が搭載されている形態などであっても構わない。そして、この例では当然、信号線２７はＣＰＵ２１とDEV LSI２４との間に設けられる。そして、例えば、DEV LSI２４からＣＰＵ２１へ信号線２７を介して割込み信号が送信される。ＣＰＵ２１からは、例えば、DEV LSI２４へのレジスタリード／ライトのインタフェースで割込みを行う。但し、この例に限らず、信号線２７は。例えば、双方に対するレジスタリード／ライトのインタフェースと見做しても構わない。

あるいは、本例ではNET LSI２２とDEV LSI２４とに別チップとして示しているが、大規模ＬＳＩを用いて、NET LSI２２及びDEV LSI２４の機能を同一ＬＳＩ上に実現することも可能である。

何れにしても、本例では、各ＣＰＵモジュール１１において、例えば上記信号線２７を介して、NET LSI２２とDEV LSI２４との間で、各々の割込みタイミングを相手に通知することができる。これより、ＣＰＵモジュール１１内で、自己のコントローラ周期開始タイミングを、自己のタクト周期開始タイミングに合わせるように補正することができる。その逆に、自己のタクト周期開始タイミングを、自己のコントローラ周期開始タイミングに合わせるように補正することもできる。

そして、これによって、例えば全てのコンフィグレーションのコントローラ周期開始タイミング及びタクト周期開始タイミングを、同期させることができる。その具体的イメージを図３に示す。

図３の例でも、上記と同様、コントローラレベルネットワーク１の周期（コントローラ周期）が５ｍｓ、タクト割込みタイミングの周期（タクト周期）が１ｍｓであるものとする。

そして、図３では、マスタ局においては既に自己のコントローラ周期開始タイミングを、自己のタクト周期開始タイミングと同期させた後の状態を示している。

マスタ局は、例えば立上り時に自局がマスタであると認識すると、自局のタクト周期開始タイミングをコントローラ周期開始タイミング生成の基準のタイマとする。つまり、本例では、タクト周期開始タイミング５回毎に、コントローラ周期開始タイミングとする。これより、マスタ局においては、自己のタクト周期開始タイミングとコントローラ周期開始タイミングとが同期していることになる。

その後、各スレーブ局のコントローラ周期開始タイミングを、マスタ局のコントローラ周期開始タイミングと同期させる。これより、図示していないが、スレーブ局のコントローラ周期開始タイミングは、マスタ局と同じとなっているものとする。そして、図示のように、任意のスレーブ局に関して、自己のコントローラ周期開始タイミングと自己のタクト周期開始タイミングとにズレが生じているものとする。このズレ量が図３や図４に示す“Ｐ”である。

これより、本手法では、スレーブ局において、自己のコントローラ周期開始タイミングに基づいて、自己のタクト周期開始タイミングの上記ズレＰを修正する。これによって、自己のタクト周期開始タイミングを、自己のコントローラ周期開始タイミングに同期させる。これは、自己のタクト周期開始タイミングを、マスタ局のタクト周期開始タイミングに同期させることを意味することになる。

上記のことから、各スレーブ局は、コントローラ周期を介して間接的に、自己のタクト周期開始タイミングとマスタ局のタクト周期開始タイミングとのズレ量Ｐを検出して、このズレを補正することで、自己のタクト周期開始タイミングをマスタ局のタクト周期開始タイミングに同期させる。

但し、後に図４で説明するように、検出したズレ量Ｐをそのまま補正量とする場合もあれば、そうではない場合もある。また、補正量分を一度に補正するとは限らず、１回当たりに補正出来る上限値を設けている。一例としては、ここでは、補正の上限値（補正値）を０．０５ｍｓとする。よって、補正量＞上限値である場合には、複数回に分けてズレを補正することになる。例えば補正量が仮に０．１５ｍｓであるとした場合には、０．０５ｍｓずつ３回、補正を行うことになる。この様なズレ量・補正量の検出・算出のイメージと補正のイメージを、図４（ａ）、（ｂ）に示す。

図４（ａ）、（ｂ）には、上記のことから、マスタ局と任意のスレーブ局のそれぞれのタクト周期開始タイミングを示し、以ってズレ量の一例を示す。ここで、検出されるズレ量“Ｐ”は、上述したように、任意のコントローラ周期開始タイミングから、その直後のスレーブ局のタクト周期開始タイミングまでの時間である。但し、検出されるズレ量“Ｐ”をそのまま補正量とするとは限らない。尚、後述するAJUST_TIMEが、補正量を意味する。

例えば本例では、図４（ａ）のような例の場合には、検出されるズレ量“Ｐ”を、そのまま後述する補正量“AJUST_TIME”とすると共に、後述する補正方向“AJST_VEC”を“＋”とする。一方、図４（ｂ）のような例の場合には、検出されるズレ量“Ｐ”から「タクト周期−Ｐ」を算出して、これを後述する補正量“AJUST_TIME”とすると共に、後述する補正方向“AJST_VEC”を“−”とする。尚、後述するAJUST_TIMEは、スレーブ局が調整すべき位相ずれ時間（補正量）である。

一例としては、上記ズレ量“Ｐ”が「タクト周期／２」（本例では０．５ｍｓとなる）以上であるか未満であるかによって、補正量と補正方向が変わることになる。ズレ量“Ｐ”が「タクト周期／２」以上である場合、補正量を「タクト周期―Ｐ」とすると共に、＋方向へ修正する。ズレ量“Ｐ”が「タクト周期／２」未満である場合、ズレ量Ｐをそのまま補正量とすると共に、−方向へ修正する。

図４（ａ）は、ズレ量“Ｐ”が「タクト周期／２」未満であるケースの一例を示す。図４（ｂ）は、ズレ量“Ｐ”が「タクト周期／２」以上であるケースの一例を示す。

また、本例では、補正値（１回当たりの補正量）に上限を設けており、この上限値は後述する「調整の単位時間AJST_UNIT」として設定されている。本例ではAJST_UNIT＝０．０５ｍｓであるものとする。

そして、上記−方向へ修正する場合には、タクト周期＝「タクト周期−AJST_UNIT」とする。本例では、タクト周期＝１−０．０５＝０．９５ｍｓとなる。これより、図４（ａ）に示すように、補正期間中はタクト周期＝＝０．９５ｍｓとなっている。

一方、上記＋方向へ修正する場合には、タクト周期＝「タクト周期＋AJST_UNIT」とする。本例では、タクト周期＝１＋０．０５＝１．０５ｍｓとなる。これより、図４（ｂ）に示すように、補正期間中はタクト周期＝＝１．０５ｍｓとなっている。

この様に、本例では、タクト周期の長さを一時的に変更することで、ズレを補正する。特に、デバイスレベルネットワークの複数の周期にわたって補正を行うことで、つまり１回当たりの補正量に上限を設けたことで、デバイスレベルネットワークのデータ破壊、処理抜けを起こさずにシステム全体の同期を可能とする。

尚、ズレの補正は、処理的には各スレーブ局毎に自己のコントローラ周期開始タイミングとタクト周期開始タイミングとのズレの補正となるが、本質的には図４（ａ）、（ｂ）に示すようにマスタ局のタクト周期開始タイミングと各スレーブ局のタクト周期開始タイミングとのズレの補正となる。

上記のように、本手法では、「マスタ局のタクト周期開始タイミング」を基準として、そこから、「マスタ局のコントローラ周期開始タイミング」→「各スレーブ局のコントローラ周期開始タイミング」→「各スレーブ局のタクト周期開始タイミング」の順で周期開始タイミング補正を行うことで、全体を同期化させることができる。

例えば上記図３、図４で説明したような、各スレーブ局における自己のタクト周期開始タイミングの補正機能（タイマ制御部）は、例えばDEV_LSI２４に搭載される。

図５に、DEV_LSI２４のタイマ制御部の構成例を示す。

尚、本例においては、タイマ補正機能をDEV LSI２４に搭載されるハードウェア機能とするが、この例に限らず、例えばＣＰＵ２１上で動作するソフトウェアとして実現することも可能である
また、図６には、図５のタイマ制御部に係わる各種信号のレジスタインタフェース例を示す。

まず、図６を参照して、各種信号について説明する。

図６に示すように、本例のタイマ制御部では、AJUST_EN３１、AJUST_VEC３２、AJUST_TIME３３、AJUST_UNIT３４、AJUST_STA３５、及びREMAIN_TIME３６等の各種信号が、利用されるものとする。尚、これらだけでなく、タイマ制御部内では更に図５に示す“takt_ajust”信号、“is_updated”信号なども生成される。

AJUST_EN３１、AJUST_TIME３３、AJUST_UNIT３４は、図５に示す補正値生成部４２への入力となる。尚、図５については後に説明する。補正値生成部４２は、これらの入力等に基づいて、AJUST_STA３５、REMAIN_TIME３６等を生成する。AJUST_EN３１、AJUST_TIME３３、AJUST_UNIT３４、AJUST_VEC３２は、外部（例えばNET LSI２２）で生成される。

尚、AJUST_VEC３２は図５に示す加減算器４３への入力となる。また、尚、図６に示すレジスタは、補正値生成部４２に内蔵されているものと見做しても構わないが、この例に限らない。

AJUST_UNIT３４は、既に説明したように予め設定される上限値（調整の単位時間）であり、ここではAJUST_UNIT＝０．０５ｍｓとしている。AJUST_TIME３３は、上述したように、検出される上記ズレ量“Ｐ”に基づいて算出／決定される、スレーブ局が調整すべき位相ずれ時間（補正量）である。また、AJUST_VEC３２も、上述したように、上記ズレ量“Ｐ”に基づいて決定される、調整方向（＋か−）を示すものである。

AJUST_EN３１は、調整要求を示すビットであり、その立上りで調整開始と認識される。AJUST_EN３１は、上位ソフトウェアあるいはコントローラレベルネットワークから送信される、補正要求受付ビットである。

AJUST_EN３１は、例えば上記のようにNET LSI２２が生成して補正値生成部４２へ入力させる。NET LSI２２は、自己が生成するコントローラ周期開始タイミング（５ｍｓ周期）と、DEV LSI２４から信号線２７を介して通知される上記１（ｍｓ）毎の割込み通知とに基づいて、上記ズレ量“Ｐ”を求める。そして、これより上記AJUST_TIME３３やAJST_VEC３２を生成する。尚、AJST_TIME３３は補正量を示す。AJST_VEC３２は、補正方向を示すビットである。

NET LSI２２は、例えばこのAJUST_TIMEが‘０’ではない場合または所定値以上である場合、タイミング調整が必要と見做して、AJUST_EN３１をＯＮする。勿論、その際、生成したAJUST_TIME３３やAJST_VEC３２を、補正値生成部４２に入力させる。

補正値生成部４２は、AJUST_EN３１の立ち上がりタイミングで、AJST_TIME３３をREMAIN_TIME３６にコピーする。あるいは、AJST_TIME３３を後述するタクトカウンタ４１のカウンタ値に換算して、これをREMAIN_TIME３６とする。

補正値生成部４２は、その後、調整を行う毎に、AJST_UNIT３４の分だけREMAIN_TIME３６から減算する。つまり、「REMAIN_TIME３６＝REMAIN_TIME３６−AJST_UNIT３４」によってREMAIN_TIME３６を更新する。

また、補正値生成部４２は、REMAIN_TIME３６が‘０’より大きいときはAJST_STA３５（１ビット）をＯＮする。

AJST_STA３５は、補正処理中および補正完了を示すビットである。ＯＮで補正処理中を示し、ＯＦＦになると補正完了を示す。

REMAIN_TIME３６は、上位から設定されたAJST_TIME３３に基づいて上記のように生成・更新されるものであり、残りの補正量を示すものであり、以って補正処理の残り時間を示すものと言える。

AJST_UNIT３４は、デバイスレベルネットワークの周期に関して一度に補正可能な単位時間を示す。当該補正可能単位時間AJST_UNIT３４は、固定の値でもよいし、デバイスレベルネットワークの制御周期に応じてソフト的に設定してもよい。補正可能単位時間AJST_UNIT３４は、予め開発者等が決定して設定している数値であり、例えばタクト周期と入出力処理の帯域時間により決定される数値である（ＩＯモジュール数、ＩＯサイズ、タクト周期が決まれば、一意に計算できる）。

補正可能単位時間AJST_UNIT３４は、例えば、ＭＳＧ帯域後から次のＴＦフレームを送信するまでの余裕時間、またはＴＦフレーム送信からＭＣフレーム送信までの余裕時間の何れか短い時間以下に設定すればよい。勿論、この例に限らない。

上記AJST_UNIT３４の決定方法について、以下、図８を参照して説明する。

まず、図２４で説明したように、タクト周期（ここでは、上記“バス・タクト周期”）は、ＴＦ、ＭＣ、ＭＳＧの各帯域に分割されている。そして、通常は、ある程度のマージンが与えられている。これより、上記タクト周期＝１（ｍｓ）の例において、例えば図８（ａ）に示すようにＴＦ帯域＝０．２（ｍｓ）、ＭＳ帯域＝０．３（ｍｓ）、ＭＳＧ帯域＝０．４（ｍｓ）とした場合には、０．１（ｍｓ）分の空き時間（マージン）がある。よって、この例では、次のタクト周期開始タイミングを０．０５（ms）早くしても、これは図示のように空き時間帯における任意のタイミングとなるので、特に問題ないことになる。尚、次のタクト周期開始タイミングが０．０５（ｍｓ）早くなることで、例えば図４（ａ）に示すようにタクト周期は０．９５（ｍｓ）となることになる。例えばこの様にしてAJST_UNIT３４は決定される。

一方、図４（ｂ）に示す例では、次のタクト周期開始タイミングを０．０５（ｍｓ）遅くすることになるが、遅くし過ぎると以下に説明する問題が生じるので、これを考慮してAJST_UNIT３４の値を設定する必要がある。

まず、前提として、一例として各Ｉ／Ｏモジュール毎に自己のタクト周期開始タイミングをＴＦフレーム受信時を基準にして決定している。例えば図８（ｂ）に示すように、Ｉ／ＯモジュールＡは、ＴＦフレーム受信時からｔａ時間経過時をタクト周期開始タイミングとする。同様に、Ｉ／ＯモジュールＢは、ＴＦフレーム受信時からｔｂ時間経過時をタクト周期開始タイミングとする。Ｉ／ＯモジュールＣは、ＴＦフレーム受信時からｔｃ時間経過時をタクト周期開始タイミングとする。これらｔａ、ｔｂ、ｔｃは、ＣＰＵモジュールが決定して各Ｉ／Ｏモジュールに通知する。決定方法については特に説明しないが、図８（ｂ）に示すように全Ｉ／Ｏモジュールでタクト周期開始タイミングが同一になるように、ｔａ、ｔｂ、ｔｃを決定する。

但し、実際には、ＴＦフレームが途中で消失する場合があることから、各Ｉ／Ｏモジュールは、上記のようにＴＦフレーム受信時を基準にしてタクト周期開始タイミングを決定したら、その後は内蔵のタイマ等に基づいて例えば１秒周期でタクト周期開始タイミングを決定していた。

ここで、図８（ｂ）は通常時を示し、図８（ｃ）は上記図４（ｂ）等のように次のタクト周期開始タイミングを遅くした場合を示している。

ＣＰＵモジュールにおいて次のタクト周期開始タイミングを遅くすると、その分だけＣＰＵモジュールによるＭＣフレーム送信タイミングが遅くなり、それによって図８（ｃ）に示すように各Ｉ／ＯモジュールのＭＣフレーム受信タイミングも遅れることになる。

ここで、タクト周期開始タイミングは直ちに修正することは困難である為、例えば図８（ｂ）に示すタイミングのままであり、従ってＭＣフレーム受信タイミングがタクト周期開始タイミングに近づくことになる。そして、遅れを大きくすれば、特に一番遅く受信するＩ／ＯモジュールＣにおいて、図８（ｃ）に示すようにＭＣフレーム受信タイミングがタクト周期開始タイミングより遅くなる場合が起こり得る。この場合、Ｉ／ＯモジュールＡ，Ｂは今回のＭＣフレームで得た最新の出力（指令等）に基づいて演算動作するが、Ｉ／ＯモジュールＣのみは前回のＭＣフレームで得た旧い出力のままで演算動作することになる。

尚、図２４で説明したように、各ＩＯモジュールは、自己のタクト周期タイミングで、その時点での最新のＭＣデータを用いて演算開始する。

ここで、各Ｉ／Ｏモジュールは、図２４に示す演算時間において、例えばＭＣフレームで得たＣＰＵモジュール出力（指令等）に基づいて、制御対象機器（モータ等）を制御している。ここで、仮に図示のＩ／ＯモジュールＡ，Ｂ，Ｃが１つのベルトコンベアに係わる３台のモータをそれぞれ制御する場合、Ｉ／ＯモジュールＡ，Ｂは最新の指令（起動指令とする）に応じてモータを起動して運転開始させたが、Ｉ／ＯモジュールＣだけはモータ停止状態を維持すること等が起こり得る。当然、この例の場合、制御対象機器は異常動作することになる。

例えば上述した理由等により、例えば最も遅くＭＣフレームを受信するＩ／ＯモジュールＣのＭＣフレーム受信時からタクト周期開始タイミングまでの時間をｔｃ２とした場合、AJST_UNIT３４の値はｔｃ２未満となるように決定する。

尚、上述したことから、AJST_UNIT３４の値は、ＣＰＵモジュールにおいてタクト周期開始タイミングを早める場合と遅くする場合それぞれに応じて２種類設定してもよい。

以下、図５に示すタイマ制御部について説明する。

タイマ制御部は、タクトカウンタ４１、補正値生成部４２、加減算器４３、比較器４４等から成る。

タクトカウンタ４１は、所定のクロック信号によってカウントアップするロード機能付カウンタであり、デバイスレベルネットワークのタクト周期開始タイミング（タクト割込み信号）を生成・出力する。尚、タクトカウンタ４１自体は、既存の構成である。

タクトカウンタ４１は、ロード付アップカウンタであり、クロック信号CLKの立上り毎にカウントアップしてカウント値Ｑを＋1インクリメントする。LOAD端子への入力がＯＮになると、Data端子への入力(＝０)に応じてカウント値Ｑを‘０’リセットする。尚、クロック信号CLKは、DEV LSI２４のクロック等を用いる。

加減算器４３は、補正処理中にタクト周期を補正する為の構成であり、後に説明する。

比較器４４は、タクトカウンタ４１の出力（カウント値Ｑ）と、加減算器４３によって補正後のタクト周期とを比較し、カウント値Ｑが“補正後タクト周期”以上である場合に出力（“is_updated”信号）をＯＮする。この“is_updated信号”が上記LOAD端子への入力となると共に補正値生成部４２に入力している。

補正値生成部４２は、上記AJST_TIME、AJST_UNIT、AJUST_ENを入力とし、AJUST_ENの立上りで補正処理を開始し、まずAJST_TIMEをREMAIN_TIMEにコピーする。その後は、REMAIN_TIMEを随時更新しつつ、REMAIN_TIMEとAJST_UNITの何れか小さい方の値を、図示の補正値“takt_ajust”として加減算器４３へ出力する。

AJST_STAは、AJUST_ENの立上りでＯＮし、REMAIN_TIMEが‘０’になるとＯＦＦする。AJST_STAのＯＮ／ＯＦＦは補正値生成部４２が行う。尚、上記の通り、AJST_STA＝ＯＮの状態は補正処理中を意味し、ＯＦＦになると補正完了を意味する。

加減算器４３は、加算（＋）か減算（−）かを示すAJST_VECと、デバイスレベルネットワークのタクト周期（本例では１ｍｓ）と、上記補正値“takt_ajust”とを入力とし、これら入力に基づく演算結果を比較器４４へ出力する。

加減算器４３は、AJST_VECが＋の場合には、「タクト周期＋“takt_ajust”」を上記“補正後タクト周期”として生成して比較器４４へ出力する。加減算器４３は、AJST_VECが−の場合には、「タクト周期−“takt_ajust”」を上記“補正後タクト周期”として生成して比較器４４へ出力する。

比較器４４は、タクトカウンタ４１の出力Ｑが上記比較器４４への入力（補正後タクト周期）以上になった場合にＯＮする。比較器４４の出力（is_updated）は、タクトカウンタ４１のＬＯＡＤ端子に入力しており、ＯＮすることでタクトカウンタ４１がリセット（リロード）されることになると共に、タクトカウンタ４１から不図示のタクト割込み信号が出力されることになる。尚、従来では、タクトカウンタ４１と比較器４４のみが存在する構成であったと見做してもよい。従来では、この構成において、比較器４４にはタクト周期と上記カウント値Ｑが入力された構成によって、タクト割込み信号を生成していたものと見做してよい。

ここで、本例では、比較器４４の出力（“is_updated”）は、補正値生成部４２にも入力している。そして、補正値生成部４２は、上記出力（is_updated）がＯＮする際の立上りにより、REMAIN_TIMEからAJST_UNITを減算する。つまり、「REMAIN_TIME＝REMAIN_TIME−AJST_UNIT」によって、REMAIN_TIMEを更新する。

尚、AJST_UNITは、コントローラのタクト周期がユーザにより設定されれば、パソコン（支援ツール等）で一意に計算される値である。AJUST_ENはコントローラがコントローラレベルネットワークのスレーブとして動作し、上位コントローラレベルのネットワークタイマの割込みがデバイスレベルネットワークのタクト周期とずれていることを認識したコントローラ上のソフトウェアによりＯＮされる。

ここで、補正値生成部４２において、各出力信号は以下の論理で生成される(ここでは、Ｃ言語的に記述する)
・REMAIN_TIME
IF (AJUST_EN == ON) {
IF (AJUST_EN前回値 == OFF) { /*AJUST_EN立上り*/
REMAIN_TIME = AJST_TIME;
} ELSE IF (is_updated == ON) {
IF (REMAIN_TIME >= AJST_UNIT) {
REMAIN_TIME = REMAIN_TIME - AJST_UNIT;
} ELSE {
REMAIN_TIME = 0;
}
}
}
上記REMAIN_TIME信号の生成処理について、以下、説明する。

上記のように、AJUST_ENの立ち上がりすなわちＯＦＦからＯＮになるときに、AJST_TIMEをREMAIN_TIMEに代入する。また、AJUST_ENがＯＮの状態において、もし“is_updated”がＯＮになったならば、REMAIN_TIMEを更新する。この更新方法は、もしREMAIN_TIMEがAJST_UNIT以上である場合には、現在のREMAIN_TIMEからAJST_UNITを差し引いた値を、新たなREMAIN_TIMEとする。一方、もしREMAIN_TIMEがAJST_UNIT未満である場合には、REMAIN_TIMEを‘０’にする。

後述する図７の例では、REMAIN_TIMEが‘１８’でAJST_UNITが‘５’であるので、図示のようにAJUST_ENの立ち上がりでREMAIN_TIMEが‘１８’にセットされ、その後は、“is_updated”がＯＮとなる毎にREMAIN_TIMEの値が‘５’ずつ減少していくことになる。つまり、REMAIN_TIMEの値は図示のように１８→１３→８→３と順次更新されていくことになる。そして、最後は、REMAIN_TIME（＝３）がAJST_UNIT（＝５）未満であることから、REMAIN_TIMEは‘０’になる。
・AJST_STA
AJST_STA = (REMAIN_TIME <> 0);
上記AJST_STA信号の生成処理について、以下、説明する。

AJST_STA３５は、REMAIN_TIME３６が‘０’より大きいときにＯＮする。図７の例の場合、上記のようにAJUST_ENの立ち上がりでREMAIN_TIMEが‘１８’にセットされることでAJST_STA３５はＯＮする。そして、その後、上記のようにREMAIN_TIMEが‘５’ずつ減少していき最後に‘０’になるまでの間、AJST_STA３５はＯＮ状態となっている。
・takt_ajust
IF (AJUST_STA == ON) {
IF (REMAIN_TIME >= AJST_UNIT) {
takt_ajust = AJST_UNIT;
} ELSE {
takt_ajust = REMAIN_TIME;
}
} ELSE {
takt_ajust = 0;
}
上記takt_ajust信号の生成処理について、以下、説明する。

REMAIN_TIMEをAJST_UNITと比較して、何れか小さい方の値をtakt_ajustとして加減算器４３へ出力する。これより、図７の例の場合、REMAIN_TIMEが‘１８’、‘１３’、‘８’のときには、AJST_UNITの値（＝５）がtakt_ajustとして出力される。そして、REMAIN_TIMEが‘３’のときには、この値‘３’がtakt_ajustとして出力される。

尚、AJUST_STAがＯＦＦになったら、takt_ajustは‘０’とする。

図７は、上記補正値生成部４２に係わる各種信号のタイミングチャート図である。

この例は、下記の条件の場合の動作例である。

すなわち、クロックＣＬＫ＝1μs、タクト周期＝1ms、AJST_UNIT＝5μs、AJST_VEC −方向、AJST_TIME 18μsの場合とする。尚、タクトカウンタ４１は０からカウントするため、1ms(1000μs)の場合999をセットする。尚、ここでは−方向を例とするが、＋方向の場合も基本的に動きは同様であり、補正後タクト周期が＋方向に調整される点で相違するのみである。

ここで、図７に示す各種信号について、その殆どは既に説明済みであり、上述したように、AJUST_ENがＯＮになった後は、takt_ajustの値は、しばらくの間は‘５’になっており、その後に‘３’になった後、最後は‘０’に戻る。これによって、タクトカウンタ４１の動作は、図７にその出力値Ｑで示すと共に“is_updated”に示す通りとなる。すなわち、takt_ajustの値が‘５’であるときには、Ｑ値が‘９９４’（＝９９９−５）のときに“is_updated”がＯＮとなり、カウンタ４１はリセットされて、再び‘０’からカウントアップしていく。つまり、通常よりも短い時間でリセットされ、以って通常よりもタクト周期が短くなる。

その後、タクトtakt_ajustの値が‘３’であるときには、Ｑ値が‘９９６’（＝９９９−３）のときに“is_updated”がＯＮとなる。

尚、補正値生成部４２の上述した処理機能・動作は、ＣＰＵ等がプログラムを実行することで実現してもよいし、プログラマブルロジックデバイス (programmable logic device: PLD)等によって実現してもよいが、実現方法はこれらの例に限らない。

ここで、図９に、コントローラレベルネットワーク、デバイスレベルネットワークの周期開始タイミング制御の一例を示す。

この例では、コントローラ周期は、図示のＴＣ帯域、ＴＳ帯域、ＭＳＧ帯域に時分割される。ＴＣ帯域は、同期フレームを送信するための帯域である。ＴＳ帯域は、コモンメモリデータを交換するための帯域である。ＭＳＧ帯域は、任意の局間で１対１のメッセージ交換を行う為の帯域である。

尚、図９の例では、タクト周期の２周期分が、コントローラ周期の１周期となっているが、勿論、この例に限らず、ユーザによる設定等により任意に定められる。但し、一般的に、コントローラレベルネットワークの制御周期の方が、デバイスレベルネットワークの制御周期に比べて長い。また、本手法では、上述したことから、コントローラ周期の１周期が、タクト周期の整数倍となるように設定することが望ましい。これによって、デバイスレベルネットワークとコントローラレベルネットワークを同期して運用することができる。

また、図９に示す例では、コントローラレベルネットワークのＴＣ帯域開始位置を、デバイスレベルネットワークにおけるＭＣフレーム送信タイミングとする例を示している。尚、これは、コントローラ周期開始タイミングとタクト周期開始タイミングとを同期させることと同義と見做しても良い。つまり、図９に示す通り、コントローラ周期開始タイミングは、ＴＣ帯域開始位置を意味する。また、上記図２４におけるタクト周期開始タイミング（タクト周期の開始位置２２４）は、バス上へのＭＣフレーム送信開始タイミングに相当する。尚、ここではバスとは、デバイスレベルネットワークを意味するものとする。

図１０は、上記図９の例に基づいて、特に上限を設けることなく、コントローラ周期開始タイミングに基づいてタクト周期開始タイミングの補正を行った場合の一例を示す。つまり、ここでは、ずれ量分を一度に補正した場合の動作例を示す。

まず、図１０の図上上側に示すように、上記図９に示す例から、マスタ局においては、タクト周期開始タイミングの２回に１回を、コントローラレベルネットワークのＴＣ帯域開始位置（コントローラ周期開始タイミング）とする。これは、タクト周期開始タイミングからコントローラ周期開始タイミングを決定することに相当する。

尚、ここでは、タクト周期開始タイミングが、図示のアプリ演算周期の開始タイミングであると共に、図示のバス・タクト周期におけるＭＣフレーム送信開始タイミングであるものとする。尚、ここではＣＰＵモジュールにおけるタクト周期が、アプリ演算周期とバス・タクト周期の２種類あるものと見做して説明するものとする。アプリ演算周期とバス・タクト周期については、既に従来技術等で説明している。また、タクト周期には更に図示のようなＩＯモジュール側のタクト周期もある。従来技術で説明したように、全てのＩＯモジュールにおいてそのタクト周期開始タイミングを図１０に示すように同期させること、すなわち演算開始タイミングを同期させることは、既存技術である。

その後、特に図示しないが、任意のスレーブ局のコントローラ周期開始タイミングを、マスタ局のコントローラ周期開始タイミングと同期させたものとする。そして、ここでは、このスレーブ局に関しては、ＭＣフレーム送信開始タイミングとＴＣ帯域開始位置とに、図示の符号５０で示すズレが生じているものとする。このズレを一度に修正するようにタクト周期開始タイミングを調整した場合、図示のように各ＩＯモジュールをＴＦフレームが巡回している状態で、ＭＣフレーム送信が行われることになる。この為、ＴＦフレームの巡回が途中で疎外され、ＴＦフレームがＣＰＵモジュールに正しく戻らなくなる、すなわち各ＩＯモジュールからの入力データがＣＰＵモジュールに正しく収集されなくなる可能性がある。

図１１に、図１０の例に対して、本手法を適用した場合の動作例を示す。

図１１に示すように、図示の符号５１で示すズレ量、すなわちＭＣフレーム送信開始タイミングとＴＣ帯域開始位置とのズレ量は、図１０の例よりも大きくなっている。しかし、図示の符号５２、５３に示すように、１回当たりの補正量は小さくなっている。つまり、例えば１回当たりの補正量が上記上限値（＝０．０５ms）等となっている。これによって、問題なく補正できる。

そして、上記１回当たりの補正量に上限を設けた補正を繰り返し実行することで、最終的には図１２に示す状態となる。すなわち、図１２に示すように、スレーブ局において、ＭＣフレーム送信開始タイミングとＴＣ帯域開始位置とが一致した状態となる。これは、換言すれば、スレーブ局において、タクト周期開始タイミングがコントローラ周期開始タイミングと同期していることを意味する。そして、これは、スレーブ局のタクト周期開始タイミングが、マスタ局のタクト周期開始タイミングと一致していることも意味している。

以上の実施例により、複数プログラマブルコントローラからなるマルチコンフィグレーションシステムにおいて、全てのコンフィグレーションのネットワーク制御周期を、データ交換抜けなく同期させることが可能となる。

尚、以上の実施例を実施例１とする。

実施例１の上述した特徴は、換言すれば例えば下記のように言うこともできる。

まず、複数のコントローラ（ＣＰＵモジュール）を、マスタ局と、それ以外（スレーブ局）とし、マスタ局では、コントローラレベルネットワークの周期制御に、デバイスレベルネットワークのタイマカウンタを使用する。このタイマカウンタは、上記タスク周期（１ms）をカウントするものであり、一例が上記タクトカウンタ４１である。マスタ局では、コントローラ周期を、タスク周期の整数倍とする。マスタ局では、自局におけるタスク周期に基づいてコントローラ周期を生成し、以って当該コントローラ周期は当該タスク周期に同期している。

そして、例えば先願に記載の処理によって、各スレーブ局のコントローラ周期を、上記マスタ局のコントローラ周期に同期させる。尚、各スレーブ局は、同期完了後、自局のコントローラ周期用のカウンタを用いて、例えば上記５ｍｓ周期のコントローラ周期開始タイミングを生成してもよい。また、各スレーブ局も上記デバイスレベルネットワークのタイマカウンタを有している。

その後、各スレーブ局毎に、上記マスタ局のコントローラ周期に同期させた自局のコントローラ周期に、自局のタクト周期を同期させる。これは、上記補正方向や補正量を求めて、これらに基づいて上記タイマカウンタの周期を一時的に変更させること等で実現する。その際、補正量が上限値を超えている場合には、デバイスレベルネットワークの複数周期に分けて補正を実施する。尚、上限値は、一度に補正可能な単位であり、予め決定されて設定されている。

尚、コントローラレベルネットワークに接続されるコントローラは常に同期を必要としているとは限らない。これより、デバイスレベルネットワークのタイマカウンタを使用してコントローラレベルネットワークの周期制御を行うか、別のタイマカウンタを使用してコントローラレベルネットワークの周期制御を行うかを、選択可能としてもよい。

以上、実施例１について説明した。

次に、以下、実施例２について説明する。

近年の金属圧延加工等の大規模高速システムでは、圧延ローラの制御パラメータ、圧延ローラの回転速度、圧力等の実測値や圧延対象の温度、板厚等のデバイスレベルネットワークに接続された機器のアナログ計測値を収集し、分析する。この様にすることで、製品品質向上のためのパラメータチューニングや、測定データの変異を取得しシステム構成機器の予防保全へ適用するシステムが求められている。

このような課題に対し、システムのデータ収集対象となる機器のデータを収集する方法として、上記特許文献２のような方式が提案されている。

しかしながら特許文献２のような方式では、例えば上記図２５に示したように、データ収集対象となる機器に対しデータ収集用に別ネットワークを接続する必要があり、以下のような課題がある。
・ データ収集対象機器にてシステム制御、データ収集で別処理を行う必要があり、機器のソフト的負荷が増大する。
・ 別途敷設するデータ収集用のケーブルのため、部品コスト、ケーブル敷設コスト、システム試験コストなどが増大する。

また、別ネットワークを用いずに、コントローラレベルネットワークを活用したデータ収集を行う場合では、収集されるデータについて以下の課題がある。
・ コントローラレベルの制御データしか収集できない。
・ コントローラレベルネットワークとアプリケーション制御周期（アプリ演算周期）に依存関係がない。
・ 一般的に、コントローラレベルネットワークの制御周期がコントローラのアプリケーション制御周期より長い。

別の収集ネットワーク等を設ける必要なく、以ってコストアップを避けつつ、上記のようなデバイスレベルの各種データを収集するためには、コントローラレベルネットワークに接続される全てのコントローラにおいて、デバイスレベルネットワークの制御周期を同期化すると共に、コントローラレベルネットワークにてデバイスレベルネットワークのデータをシステム全体で基準となる時間情報と共に扱うようにすればよい。

これらの条件のうち、前者の条件（同期化）は、上記実施例１によって実現される。すなわち、実施例１によって、全てのコントローラのタクト周期開始タイミングが同期化できている。後者の条件（基準となる時間情報）に関しては後述する。

また、コントローラレベルネットワークの制御周期が、デバイスレベルのネットワークの制御周期の整数倍（特に２倍以上）となるような場合(たとえばコントローラ周期が１０msであるのに対して、タクト周期が２msなど)には、デバイスレベルネットワークに係わるデータ（各ＩＯモジュールのデータ等）をコントローラにて収集し、この収集データをコントローラレベルネットワークの制御周期で一括して上位パソコン等へ通知できるようにすることが望ましい。

その為に、例えば、デバイスレベルネットワーク上でのＩＯモジュール等とのデータ交換の度に、この収集データをコントローラレベルネットワークに係わる送信データバッファ領域（NET_LS２２内に不図示のバッファメモリ等）へコピーし、かつ収集時のデバイスレベル制御周期（タクト周期）を示す識別情報をデータに付加して、コントローラレベルネットワーク上へ送信する。

上位パソコンは、コントローラレベルネットワークを介して、各コントローラからの上記送信データを受信する。そして、上記付加データ等に基づいて各データの時系列を判別できる。

上述した各処理について、詳しくは後述する。

ここで、実施例２は、システム構成自体は、上記実施例１と略同様であってよく、ここでは特に図示、説明は行わないものとする。

ここで、上述したコンフィグレーション内では、上位支援ツール等から制御アプリケーションのダウンロードやアプリケーション起動/停止などの制御、モニタによる監視などが行われる。

各コンフィグレーションにおける各種処理は、制御アプリケーションの実行を制御するＣＰＵモジュールを中心に行われるのが一般的であり、通信機能も含まれる。各コンフィグレーションは機能的、物理的に離れて配置されるので、通信機能によるデータ交換は非同期となるのが一般的である。

例えば上記サーバ装置２は、個々のコンフィグレーションの情報収集や指示通知のため、コントローラレベルネットワークを介して各コントローラと個別に通信を行う。サーバ装置２が、デバイスレベル機器（ＩＯモジュール等）のデータを一括収集しようとしても、通信タイミングによりデータ取得時期がずれてしまい、一連の処理の中で収集されたデータであっても取得タイミングの保証はない。

ここで、本出願人は、上記先願（PCT/JP2013/050121）において、コントローラレベルネットワークに接続された複数のコントローラコンフィグレーションに係わる同期方式を提案している。

この発明によれば、コントローラレベルネットワークに先願２（国際公開番号；ＷＯ２０１３／１２１５６８Ａ１）の発明を用い、かつこのコントローラレベルネットワークで用いられる「タイマ」をコントローラアプリケーションの実行周期管理に用いることにより、異なるコンフィグレーションに属するコントローラを同期させることができる。

ところで、コントローラのデバイスレベルに適用されるネットワークとして特開2012-68856号公報に開示されているようなネットワークがある。このネットワークは、リング形状を構成しているネットワークにおいて、ＩＯ機器への出力タイミングを同期させることを特徴とするネットワークである。このデバイスレベルネットワークを本発明のコントローラに適用すれば、コントローラレベルネットワークを介して接続されるコントローラおよびその制御デバイスが同期されたタイミングで制御データを与えられることになり、その結果、収集されるデータ(コントローラからみて各デバイス機器からの入力データ)も同一のタイミングで得ることができる。

図１３に、実施例２におけるデータ収集動作例を示す。

尚、図１３では、タクト周期がコントローラ周期と同じ長さである場合を例にするが、通常は、上記の通り、コントローラ周期の長さはタクト周期の整数倍（特に、２倍以上）である。また、図１３には、上記実施例１によって、システム上の全てのコントローラのコントローラ周期及びタクト周期が同期している状態を示している。

まず、コントローラレベルネットワークに関して、マスタ局は、各スレーブ局に対して、コントローラ周期開始タイミング毎に同期化フレーム(ＴＣフレーム)を送信する。図１３に示す「ＴＣ」が、ＴＣフレーム送信タイミングを示している。

尚、同期化フレームは、先願２（国際公開番号；ＷＯ２０１３／１２１５６８Ａ１）等に開示されているように、本来はシステム全体で各コントローラの制御周期開始タイミングを調整するためのものである。但し、本手法では、同期化フレームによって制御周期開始タイミングの調整を行うとは限らない。本手法では、同期化フレームに含める時間情報等を用いて、各収集データの時系列管理を行う。

ここで、図示の符号５１は、制御周期開始タイミングを示す。

上記の通り、図示の例の場合、コントローラ周期＝タクト周期となっており、且つ、実施例１によって全制御周期開始タイミングが合っている状態であるので、図示の符号５１は、全てのコントローラ（マスタ局と各スレーブ局）のコントローラ周期開始タイミング、及びタクト周期開始タイミング（ここでは、アプリ演算周期の開始タイミング）を意味している。

また、図２４に示す例では、ＣＰＵモジュールにおけるバス上の動作（ＴＦ、ＭＣ、ＭＳＧ）に関しては、タクト周期開始タイミングの直前にＴＦフレーム受信完了、直後にＭＣフレーム送信処理がある。上記の通り、ＣＰＵモジュールは、ＴＦフレームをバス上に送出し、これが各ＩＯモジュールを巡回して再びＣＰＵモジュールに戻ってくる。その際、各ＩＯモジュールは、自己の何等かの情報をＴＦフレームに付加している。これより、上記ＴＦフレーム受信完了は、ＣＰＵモジュールが各ＩＯモジュールの情報を収集したことを意味する。

ここで、ＣＰＵモジュールの処理を図２に示すＣＰＵ２１の処理とＤＥＶ＿ＬＳＩ２４とに分けて説明するならば、上記バス上の動作（ＴＦ、ＭＣ、ＭＳＧ）はＤＥＶ＿ＬＳＩ２４が実行する。上記収集した各ＩＯモジュールの情報は、例えばＳＲＡＭ２５に格納される。これが、上記ＴＦフレーム受信完了に相当する。ＣＰＵ２１は、例えば図２４に示すように、タクト周期開始タイミングが到来する毎に、例えばＳＲＡＭ２５からＴＦフレームの情報を取得して、この情報等に基づいて所定の演算処理等を実行し、演算結果を例えばＳＲＡＭ２５に格納する。ＤＥＶ＿ＬＳＩ２４は、ＭＣフレーム送信タイミングが到来する毎に、当該演算結果を上記ＭＣフレームとしてバス上に送出する。これは、各ＩＯモジュールに対して演算結果を出力することに相当する。

上記のように、上記バス上の動作（ＴＦ、ＭＣ等）は、アプリ演算周期を基準にして考えた場合、上記の通り、周期開始タイミングの直前にＴＦフレーム受信完了（入力）、直後にＭＣフレーム送信処理（出力）が行われるものと見做すことができる。図１３では、これを図示の「入力」、「出力」として示している。そして、上記実施例１によって制御周期開始タイミング補正を行っていることで、図示のように全てのコントローラ（ＣＴＬ１，ＣＴＬ２）で「入力」のタイミング、及び「出力」のタイミングが一致していることになる。尚、ここではコントローラ（ＣＰＵモジュール）の一例としてＣＴＬ１，ＣＴＬ２の２つのみを示している。

また、従来より、コントローラレベルネットワークにおけるＴＳ帯域は、各コントローラに割り当てられた帯域に時分割されている。図１３に示す例では、ＣＴＬ１には図示の「Ｄ１」の帯域が割り当てられており，ＣＴＬ２には図示の「Ｄ２」の帯域が割り当てられているものとする。これより、各コントローラＣＴＬ１，ＣＴＬ２は、各コントローラ周期毎に、自己に割り当てられた帯域のときに、その時点の最新の上記「入力」及び「出力」を出力することになる。そして、これは、図示の通り、全てのコントローラにおいて同じタイミングで得られた「入力」及び「出力」が、コントローラレベルネットワーク上の送信先にパケット送信されることになる。このパケット送信先は例えばマスタ局あるいはサーバ装置２等である。

マスタ局あるいはサーバ装置２は、任意のコントローラ周期において受信したパケットは、全てが、当該コントローラ周期の開始時（コントローラ周期開始タイミング）の直前の「入力」と直後の「出力」であるものと見做すことができる。よって、サーバ装置２では、受信したパケットのデータの収集時間と出力時間を正しく推定することができる。しかし、より確実に推測する為に、後述するように上記ＴＣフレームに含まれる時間情報を利用することが望ましい。これについては後に図１４等を参照して説明する。

尚、実施例１で説明したように、コントローラ周期の１サイクルは、ＴＣ帯域、ＴＳ帯域等から成り、上記ＴＣフレームはＴＣ帯域内で送受信される。また、そして、上述したように、各局のデータ送信は、ＴＳ帯域内に行われる。ＴＳ帯域内を時分割して各局に割り当てられる。各局は、自己に割り当てられたタイミングでデータ送信を行う。例えば図示のように、コントローラCTL1は図示のデータＤ１、コントローラCTL2は図示のデータＤ２を図示のタイミングで送信する。

上記実施例１のタイミング調整処理によって、全コントローラ間で、コントローラ周期開始タイミングが同期していると共に、タクト周期も同期している。これより、図示のように、入力処理がコントローラCTL1とCTL2とで同一タイミングとなると共に、出力処理もコントローラCTL1とCTL2とで同一タイミングとなる。よって、各コントローラ周期毎に、そのデータＤ１とデータＤ２とは、同一タイミングで入力／出力されたデータであることになる。これは他のコントローラの送信データ（図示のデータＤ３等）も同様である。よって、例えば任意のコントローラ周期内で送信される各データフレーム（データＤ１とデータＤ２とデータＤ３）は、同一タイミングで入力／出力されたデータであることになる。

このようにすることで、図２６の場合と異なり、入出力データの抜け、重複がなくなり、かつ全てのコントローラが、同一のタイミングの入出力データを、コントローラレベルネットワーク上の送信先へ送信することになる。

尚、「入力」、「出力」のタイミングは、必ずしも図１３に示すタイミングでなくても構わない。例えば「入力」は、図１３では周期開始タイミングの直前となっているが、この例に限らない。但し、全てのコントローラで同一のタイミングとなるように予め設定しておく必要がある。例えば、「入力」は周期開始タイミングの直後とするとしたならば、全てのコントローラにおいて周期開始タイミングの直後に「入力」（ＴＦフレーム受信完了）が行われるように構成する必要がある。

この様に、各コントローラ毎に、自己の周期開始タイミング等に基づいて「入力」、「出力」のタイミングを決定するが、この「入力」、「出力」タイミングは予め全てのコントローラで同一設定とする。これより、実施例１によって全てのコントローラの周期開始タイミングが一致するように調整すれば、全てのコントローラで同じタイミングで「入力」、「出力」が行われることになる。

コントローラレベルネットワーク上で収集されるデータは、フレームの異常や上位ＰＣの処理負荷などにより、データ抜けが発生することがあり、また各コントローラから収集したデータの取得タイミングの一意性を保障するために、システム全体で同一のタイミングを保障する情報が必要となる。

各局から送信されるデータフレームの一意性を示すには、マスタ局から各周期毎に必ず全スレーブ局にブロードキャスト送信される同期化フレーム（ＴＣフレーム）に含まれる“マスタ局の「タイマ値」(NET_TIME)(96)”を利用すればよい。すなわち、各スレーブ局は、自己の送信データフレームに、“マスタ局の「タイマ値」(NET_TIME)(96)”を格納して、送信すればよい。

図１４に、上記同期化フレーム(ＴＣフレーム)、データフレームのフレームフォーマット例を示す。

尚、例えばマスタ局がＴＣフレームを全スレーブ局へ送信し、各スレーブ局は上記独自のタイミングでデータフレームを返信する。

図示の例のＴＣフレーム９０は、H_TYPE９１、SIZE９２、ＦＣ９３、S_ADDR９４、R_ADDR９５、NET_TIME９６、F_SEQ９７、STA９８等から成る。尚、これらはフレームヘッダのデータ構成と見做してよい。

H_TYPE９１はフレームヘッダタイプを示し、SIZE９２はフレーム全体のサイズを示している。ＦＣ９３は、フレーム種別を示しており、ここでＴＣフレームのフレーム種別が格納される。S_ADDR９４、R_ADDR９５は、送信局番、受信局番を示している。

F_SEQ９７は、フレーム番号であり、フレーム種別によらずフレーム送信毎にインクリメントして付加される通し番号である。これは、受信側においてNET_TIME９６等と合わせてフレーム受信抜けをチェックする為の情報である。

そして、NET_TIME９６は、例えば当該ＴＣフレーム９０の送信時間を示すものであり、例えば不図示のタイマの現在値を用いるが、この例に限らない。本例ではデータ収集タイミングを一意に示す情報として「タイマ値」(NET_TIME)を使用するが、コントローラレベルネットワークの周期を示すカウンタ値(スキャンシーケンス番号)等を用いてもよい。尚、上記タイマ値は、ＴＣフレームの送信元の装置（例えばマスタ局）内蔵のタイマの値である。

一方、図示の例では、データフレーム１００は、H_TYPE１０１、SIZE１０２、ＦＣ１０３、S_ADDR１０４、R_ADDR１０５、NET_TIME１０６、F_SEQ１０７、STA１０８、制御データ１０９、収集データ１１０等から成る。

上記H_TYPE１０１〜STA１０８は、上記H_TYPE９１〜STA９８と略同様と見做してよく、ここでは説明を省略する。但し、ＦＣ１０３には、データフレームのフレーム種別が格納されることになる。

ここで、制御データ１０９には、例えば上記ＭＣフレームによる各ＩＯモジュールへの出力データが格納される。

収集データ１１０には、例えば上記ＴＦフレームによって各ＩＯモジュールから収集したデータ（上記「入力」）である図示のデータ１１５が含まれるが、これ以外にも図示のD_TYPE111、データ部サイズ(DT_SIZE)112、NET_TIME113、自局番(S_ADDR)114等も含まれる。尚、D_TYPE111は、収集データであることを示す識別情報である。

ここで、NET_TIME113は、上記ＴＣフレーム９０のNET_TIME９６をコピーしたものである。これより、この収集データ１１０等を取得した装置側（マスタ局やサーバ装置２等）では、各収集データ１１０がどのコントローラ周期に係わるものであるかを判別できる。よって、上述したことから、各収集データ１１０の収集タイミングを判別できる。

ここで、上記実施例２では、コントローラ周期がタクト周期のＮ倍（Ｎ＝２，３，４，５、・・・；２倍以上の整数倍）となっている場合、コントローラ周期開始タイミング直近のデータしか収集されない。

そこで、各コントローラ（スレーブ局）内に上記ＩＯモジュールからの収集データ等を一時的に蓄積する中間バッファ(不図示)を設け、当該中間バッファに各タクト周期毎の収集データ等を順次蓄積する。そして、コントローラ周期開始タイミング毎に、中間バッファに蓄積したデータ全てをコントローラレベルネットワークの送信先（マスタ局など）へパケット送信すると共に、中間バッファの蓄積データを消去する。これを実施例２の変形例とする。

ここで、任意のコントローラ周期でパケットを受信したマスタ局などでは、これが当該コントローラ周期の直前等の所定期間内の収集データ群等であることは分かるが、その各データがどのタクト周期に係わるデータであるのかまでは分からない。そこで、図１５に示すように、各データに、どのタクト周期に係わるデータであるのかを識別させる為の識別情報を付加することが望ましい。この識別情報は、例えば中間バッファに蓄積する際に付加している。よって、この例では、パケット生成・送信時には、単に、中間バッファの蓄積データをパケットに格納するだけである。

図１５は、上記実施例２の変形例で用いられるデータフレーム１００のデータ構成例である。

図１５において図１４に示すデータフレーム１００のデータ構成と略同様のものには同一符号を付してあり、その説明は省略する。

図１５に示す例では、図１４に示す例に対して、収集データ１１０において更に図示のIO_SIZE１２１、収集数(IO_NUM)１２２を追加すると共に、複数の各収集データ１２４毎にデバイスレベルでの収集周期を示すIO_SEQ１２３（識別情報）を付加している。

図１６は、実施例２の変形例におけるデータ収集動作例を示す図である。

図１６に示す例では、コントローラ周期の長さは、タクト周期の３倍となっている。

従って、各コントローラ周期毎に、タクト周期３回分の収集データを、コントローラレベルネットワーク上の送信先に送信することになる。

この例では、１回のコントローラ周期に対して、３回のタクト周期開始タイミング毎に、収集データを中間バッファに格納・蓄積することになる。その際、上記識別情報（IO_SEQ１２３に相当）を各収集データに付加する。

これは、図１６に示す例では、上記３回のタクト周期のうち、まず最初のタクト周期において、そのときの収集データ等を中間バッファに格納する。その際、上記識別情報として図では‘１’を付加する。これは、このときの収集データ等全てに対して‘１’を付加する。これによって、中間バッファには図示の蓄積データ１３３が格納された状態となる。

同様にして、２回目のタクト周期において、そのときの収集データ等を中間バッファに追加格納すると共に、当該収集データ等に上記識別情報として‘２’を付加する。これによって、中間バッファには図示の蓄積データ１３４が格納された状態となる。

同様にして、３回目のタクト周期において、そのときの収集データ等を中間バッファに追加格納すると共に、当該収集データ等に上記識別情報として‘３’を付加する。これによって、中間バッファには図示の蓄積データ１３５が格納された状態となる。

この様にして任意のコントローラ周期内の収集データを識別情報を付加して中間バッファに蓄積する。そして、次のコントローラ周期における所定のタイミング（例えば図示のコントローラCTL1の場合は図示の「Ｄ１」のタイミング）で、中間バッファの蓄積データ全てをコントローラレベルネットワークの送信先（マスタ局など）へパケット送信する。上記の例では、蓄積データ１３５を所定の送信先へ送信する。

送信先側では、上記各データの識別情報に基づいて、各データが上記コントローラ周期内のどのタイミング（１回目のタクト周期、２回目のタクト周期、３回目のタクト周期）における収集データであるのかを判別できる。

上述した実施例２によれば、まず、図２６で説明した問題を解消できる。すなわち、全てのコントローラにおいて、デバイスレベルネットワークに係わるデータの入力、出力のタイミングを、同期化させることができる。更に、例えば、送信先装置等に集められた各Ｉ／Ｏデータの同時性を保証できると共に、時系列の判別精度を高めることができる。つまり、どのデータがどのデータと同じときに収集されたデータであるのか、あるいは各データ毎の他のデータとの時系列的な前後関係等が、高精度で判別可能となる。高精度とは、タクト周期の長さ（ここでは１ｍｓ）に応じたものを意味する。

尚、従来では、図２６で説明したように、同じコントローラ周期で各コントローラから集めたデータであっても、同じタイミングで収集されたデータであるとは限らなかった。また、従来では、コントローラ周期の長さ（ここでは５ｍｓ）に応じた精度しか得られなかった。実施例２では、この様な問題を解消できる。

図１７は、本例のプログラマブルコントローラシステムの機能ブロック図である。

本例のプログラマブルコントローラシステムは、基本的には、コントローラと各入出力対象とが第２ネットワークに接続されて成る制御ユニットを複数有し、該複数のコントローラは第１ネットワークにも接続されており、各コントローラが前記第１ネットワークに係わる第１周期と前記第２ネットワークに係わる第２周期に従って演算／通信動作するプログラマブルコントローラシステムである。

上記第１ネットワークの一例が上記コントローラレベルネットワーク１であり、よって上記第１周期の一例が上記コントローラ周期となる。上記第２ネットワークの一例が上記デバイスレベルネットワーク１３であり、よって上記第２周期の一例が上記タクト周期となる。

上記複数のコントローラは、特定コントローラ１５０と、該特定コントローラ１５０以外の各コントローラ１６０（以下、他コントローラ１６０と記す）等である。尚、特定コントローラ１５０の一例が上記マスタ局のコントローラ（ＣＰＵモジュール等）である。他コントローラ１６０の一例が上記各スレーブ局のコントローラである。

上記特定コントローラ１５０は、自己の前記第２周期開始タイミングに基づいて自己の前記第１周期開始タイミングを決定する第１周期生成部１５１を有する。

上記他コントローラ１６０は、それぞれ、第１周期同期部１６１、第２周期補正部１６２等を有する。

第１周期同期部１６１は、自己の上記第１周期開始タイミングを、特定コントローラ１５０の第１周期開始タイミングに同期させる。これは、一例としては上記先願（PCT/JP2013/050121）によるコントローラレベルネットワーク上の各コントローラのコントローラ周期の同期処理によって実現させるが、この例に限らない。

第２周期補正部１６２は、自己の第２周期開始タイミングを自己の第１周期開始タイミングに基づいて補正する。尚、上記の通り、自己の第１周期開始タイミングは、特定コントローラ１５０の第１周期開始タイミングと同期している。更に、上記第１周期生成部１５１によって、特定コントローラ１５０においてはその第１周期開始タイミングは第２周期開始タイミングに同期化されている。従って、上記第２周期補正部１６２による補正が行われることで、全ての他コントローラ１６０における第２周期開始タイミングが、特定コントローラ１５０における第２周期開始タイミングと同期することになる。

上記第２周期補正部１６２は、例えば、上記第２周期開始タイミングの補正量が所定の上限値を越える場合には、該上限値以下の補正値によって複数回に分けて前記第２周期開始タイミングの補正を行う。上記補正量の一例が上記ズレ量Ｐや「タクト周期−Ｐ」等であり、上記上限値の一例が上述したAJST_UNIT等である。

上記上限値は、例えば、第２周期内の予め割り当てられた各帯域以外の空き時間帯に基づいて決定されている。

あるいは、例えば、上記第２周期内は、コントローラ１６０等が第２ネットワークを介して各入出力対象からデータを収集する帯域であるＴＦ帯域と、コントローラ１６０等が各入出力対象への出力を行う帯域であるＭＣ帯域と、任意の１対１のメッセージ送受信帯域であるＭＳＧ帯域とから成る。そして、上記上限値は、上記ＭＳＧ帯域後の空き時間に基づいて決定されている。

あるいは、例えば、上記第２周期内は、コントローラ１６０等が第２ネットワークを介して各入出力対象からデータを収集する帯域であるＴＦ帯域、コントローラ１６０等が各入出力対象への出力を含むＭＣフレームを第２ネットワーク上に巡回させる帯域であるＭＣ帯域と、任意の１対１のメッセージ送受信帯域であるＭＳＧ帯域とから成る。そして、各入出力対象は、第２周期に基づくＩＯ周期に従って動作している。そして、上記上限値は、上記補正によって第２周期開始タイミングが補正値分変わっても、上記ＭＣフレームを最後に受信する入出力対象が該ＭＣフレームを受信する前に、次のＩＯ周期とならないようにして決定されている。

尚、上記上限値の決定方法は、例えば上述したAJST_UNITの値の決定方法に準じている。これより、上記ＩＯ周期は、例えば図２４の符号２２３に示す各ＩＯモジュールＡ，Ｂ，Ｃに係わるタクト周期に相当する。

また、上記第２周期補正部１６２は、例えば、補正方向を−方向とするか＋方向とするかを決定し、補正方向を−方向とする場合には自己の第２周期の長さを一時的に短くすることで該第２周期開始タイミングの補正を行う。一方、補正方向を＋方向とする場合には自己の第２周期の長さを一時的に長くすることで該第２周期開始タイミングの補正を行う。この処理の一例を上記図４（ａ）、（ｂ）に示して説明しているが、この例に限らない。

また、上記第２周期補正部１６２は、例えば、自己の第１周期開始タイミングからその直後の第２周期開始タイミングまでのズレ量が、該第２周期の長さの半分未満である場合には前記補正方向を前記−方向とし、該ズレ量が該第２周期の長さの半分以上である場合には前記補正方向を前記＋方向とする。この処理の一例を上記図３に関して説明している。上記ズレ量の一例が、図３の説明におけるズレ量Ｐであるが、この例に限らない。

また、上記第２周期補正部１６２は、例えば、上記補正方向を上記−方向とする場合には上記ズレ量を第２周期の補正量とし、上記補正方向を上記＋方向とする場合には「第２周期の長さ−ズレ量」を第２周期の補正量とする。この処理の一例を上記図３に関して説明している。上記補正方向の一例が図３の説明におけるAJST_VECであり、上記第２周期の補正量の一例が図３の説明におけるAJST_TIMEであるが、これらの例に限らない。

また、例えば、前記各コントローラ１６０は、上記第１周期毎に、上記第２ネットワークを介して得た各入出力対象からの直近の収集データを、上記第１ネットワークを介して所定の送信先装置へ送信する送信部１６３を更に有する。

これに関して、例えば、上記送信先装置は、各第１周期開始時に、そのときの時間情報を含む特定パケットを各コントローラ１６０へ送信する。そして、各コントローラ１６０の上記送信部１６３は、各第１周期毎に、受信した特定パケットに含まれる上記時間情報を、上記直近の収集データの送信パケットに付加して、上記送信先装置へ送信する。尚、この処理の一例を上記図１３、図１４等で説明している。

また、上記第１周期は、例えば、上記第２周期の整数倍の長さである。これは、特に２倍以上の長さである。例えば図３の例では、コントローラ周期はタクト周期の５倍の長さとなっている。

このような例において、例えば、上記送信部１６３は、上記第１周期毎に、該第１周期内の各第２周期毎に各入出力対象から取得した収集データを、どの第２周期の際の収集データであるのかを示す識別情報と共に蓄積し、最後に該蓄積データをまとめて前記送信先装置へ送信する。尚、この処理の一例を上記図１５、図１６等で説明している。

尚、上記送信先装置は、例えばコントローラ１５０（マスタ局など）であるが、この例に限らず、例えばサーバ装置２等であってもよい。

最後に、先願（PCT/JP2013/050121）によるコントローラレベルネットワーク上の各コントローラのコントローラ周期の同期処理について説明する。これは、図１８、図１９、図２０を参照して一例について説明する。

尚、上記ＣＰＵモジュール１１は、一例としては以下に説明する先願のＣＰＵモジュール１８０の機能の一部（特に、同期補正処理）を有するものと見做して構わないが、この例に限らない。

図１８は、先願におけるＣＰＵモジュール１８０の各機能部を説明するための機能ブロック図である。

ＣＰＵモジュール１８０は、遅延時間計測部１８１、同期化フレーム送信部１８２、遅延時間受信部１８４、同期補正部１８６、アプリケーション実行部１８８、データ更新部１９０、データ送信部１９２等の各種機能部を有する。

これらの各機能部は、そのプログラマブルコントローラがマスタとして動作するか、スレーブとして動作するかに応じて機能する場合と機能しない場合がある。ここでは、図上左側にマスタとして動作する場合のＣＰＵモジュール１８０であるマスタＣＰＵモジュール１８０ａの構成例を示す。同様に、図上右側にはスレーブとして動作するＣＰＵモジュール１８０であるスレーブＣＰＵモジュール１８０ｂの構成例を示す。そして、マスタであるかスレーブであるかによって機能しない機能部については破線で示している。
なお、本実施形態は、上記の構成に限定されるものではなく、１つのＣＰＵモジュール１２２がマスタＣＰＵモジュール１８０ａにもスレーブＣＰＵモジュール１８０ｂにもなり得るように同一の構成を有している。

遅延時間計測部１８１は、ＣＰＵモジュール１８０がマスタＣＰＵモジュール１８０ａとして機能する場合に、マスタＣＰＵモジュール１８０ａとスレーブＣＰＵモジュール１８０ｂとの伝送遅延時間を計測するための伝送遅延時間リクエストフレームを、任意のスレーブＣＰＵモジュール１８０ｂに送信する。この伝送遅延時間リクエストフレームは、同期化フレームとフォーマットが実質的に等しく、同期化フレーム内の所定部分（例えば、コマンド部）のデータが異なるフレームである。この伝送遅延時間リクエストフレームは、マスタＣＰＵモジュール１８０ａ内で生成された基準信号に同期して送信される。

また、遅延時間計測部１８１は、伝送遅延時間リクエストフレームを送信後、任意のスレーブＣＰＵモジュール１８０ｂから受信完了フレームを受信すると、受信完了フレームを受信したときの時刻を取得する。そして、遅延時間計測部１８１は、伝送遅延時間リクエストフレームを送信したときの時刻と受信完了フレームを受信したときの時刻との差分から、マスタＣＰＵモジュール１８０ａと任意のスレーブＣＰＵモジュール１８０ｂ間の往復伝送遅延時間を計算する。そして、遅延時間計測部１８１は、計算した往復伝送遅延時間を２で除算し、その結果である伝送遅延時間を含む伝送遅延時間通知フレームを次の基準信号に同期させて任意のスレーブＣＰＵモジュール１８０ｂに送信する。こうして、任意のスレーブＣＰＵモジュール１８０ｂに、ネットワーク１９４による伝送遅延時間を通知することができる。尚、ネットワーク１９４は、上記コントローラレベルネットワーク１に相当すると見做してもよいが、この例に限らない。

同期化フレーム送信部１８２は、ＣＰＵモジュール１８０がマスタＣＰＵモジュール１２２ａとして機能する場合に、基準信号に同期して、予め用意された同期化フレームを複数のスレーブＣＰＵモジュール１８０ｂに送信する。この同期化フレームは、スレーブＣＰＵモジュール１８０ｂの基準信号生成部の計数値をマスタＣＰＵモジュール１８０ａの基準信号生成部の計数値に合わせるための信号である。

遅延時間受信部１８４は、ＣＰＵモジュール１８０がスレーブＣＰＵモジュール１８０ｂとして機能する場合に、マスタＣＰＵモジュール１８０ａから伝送遅延時間リクエストフレームを受信し、その伝送遅延時間リクエストフレームに応じて、受信完了フレームをマスタＣＰＵモジュール１８０ａに送信する。また、遅延時間受信部１８４は、マスタＣＰＵモジュール１８０ａから伝送遅延時間通知フレームを受信すると、そのフレームに含まれる伝送遅延時間をＲＡＭ１６４等に退避する。このようにして、スレーブＣＰＵモジュール１８０ｂは、マスタＣＰＵモジュール１８０ａとスレーブＣＰＵモジュール１８０ｂ間の伝送遅延時間を得ることができる。

同期補正部１８６は、ＣＰＵモジュール１８０がスレーブＣＰＵモジュール１８０ｂとして機能する場合に、スレーブＣＰＵモジュール１８０ｂ内の基準信号生成部（不図示）によって生成された基準信号を伝送遅延時間分進める。

具体的に、同期補正部１８６は、まず、マスタＣＰＵモジュール１８０ａから同期化フレームを受信すると、基準信号生成部から計数値を取得し、伝送遅延時間に相当する値（基準信号生成部（不図示）の時間換算値）と、取得した計数値との差分である補正量を算出する。続いて、基準値から補正量を減算して補正基準値を導出し、その補正基準値を新たな基準値として一時的に基準信号生成部に設定する。したがって、補正基準値は、「基準値−（“伝送遅延時間に相当する値”−“基準信号生成部の計数値”）」で表される。

そして、補正基準値を設定し、基準信号生成部において、その補正基準値での計数が完了すると、同期補正部１８６は、速やかに、元の基準値を、基準信号生成部に設定する。こうして、一時的に基準値を伝送遅延時間分だけ進めることができる。ここでは、伝送遅延時間分の補正を一度に実行する例を挙げているが、かかる場合に限らず、複数回に分けて実行してもよい。なお、本実施形態において、同期補正部１８６が、マスタＣＰＵモジュール１８０ａから伝送遅延時間を得ることなく同期化フレームを受信した場合でも、伝送遅延時間をゼロ（０）として上記の補正処理を行えばよい。

こうして、本実施形態では、マスタＣＰＵモジュール１８０ａの基準信号生成部（不図示）とスレーブＣＰＵモジュール１８０ｂの基準信号生成部（不図示）とを高精度に同期させることができる。なお、このような同期補正処理は、連続的に行ってもよいし、所定の時間毎に間欠的に行ってもよい。

アプリケーション実行部１８８は、マスタＣＰＵモジュール１８０ａおよびスレーブＣＰＵモジュール１８０ｂのいずれにおいても、基準信号生成部で生成された基準信号に応じて（基準信号を割込信号として受けて）、実行プログラムを実行し、入出力モジュール１９１を介して被制御機器１９２を制御する。したがって、当該実行プログラムは、基準信号に応じて周期的に実行されることとなる。

データ更新部１９０は、マスタＣＰＵモジュール１８０ａおよびスレーブＣＰＵモジュール１８０ｂのいずれにおいても、データ（例えば、ステータス情報、センサの検出結果、制御結果等）が生成されると、生成されたデータで、自己のＣＰＵモジュール１８０内のコモンメモリ（不図示）の内容を更新する。

また、データ更新部１９０は、他のＣＰＵモジュール１８０にそのデータを転送する。また、データ更新部１９０は、他のＣＰＵモジュール１８０からデータが転送されると、かかるデータに基づいて自己のＣＰＵモジュール１８０内のコモンメモリ（不図示）の内容を更新する。こうして、他のＣＰＵモジュール１８０とデータを共有化できる。また、データ更新部１９０がデータを他のＣＰＵモジュール１８０に送信する送信タイミングは、基準信号生成部（不図示）に基づいてＣＰＵモジュール１８０毎に予め定められている。

データ送信部１９２は、マスタＣＰＵモジュール１８０ａおよびスレーブＣＰＵモジュール１８０ｂのいずれにおいても、アプリケーション実行部１８８が実行プログラムを遂行することで生成されたデータのうち、管理装置１９３に収集要求されているデータを、管理装置１９３へ送信する。かかる送信タイミングは、データ更新部１９０の送信タイミングに倣う。本実施形態では、ＣＰＵモジュール１８０同士が同期しているので、管理装置１９３に、生成タイミングの等しいデータが収集される。

尚、管理装置１９３は、上記サーバ装置２の一例と見做しても構わないが、この例に限らない。

（同期補正処理）
図１９は、同期補正処理例を説明するためのタイムチャート図である。ここでは、仮に、スレーブＣＰＵモジュール１８０ｂの基準信号が、マスタＣＰＵモジュール１８０ａの基準信号より１０μｓｅｃ遅れているとする。なお、基準値（処理周期）は、１０００μｓｅｃとするが、これに限定されるものではなく、例えば管理装置１９３０により適宜設定を変更することができる。また、図中、簡略のためμｓｅｃをμｓと表現する。

図１９では、マスタＣＰＵモジュール１８０ａの基準信号生成部が計数を行っている。その計数値が“図１９に図上（１）で示す時点”（以下、“図１９の（１）時点”と記す。他の同様）で基準値に達すると、マスタＣＰＵモジュール１８０ａ内において基準信号を出力する。そして、アプリケーション実行部１８８は、当該基準信号に応じて実行プログラムを遂行する。図１９中、ハッチングで示した三角形の領域は、計数値の推移を示し、時間の経過に従い計数値が増加し、計数目標（例えば基準値）に達するとリセットされる。

また、マスタＣＰＵモジュール１８０ａと並行して、スレーブＣＰＵモジュール１８０ｂの基準信号生成部も計数を行っている。その計数値が図１９の（２）時点で基準値に達すると基準信号を出力する。そして、アプリケーション実行部１８８は、当該基準信号に応じて実行プログラムを遂行する。このように、マスタＣＰＵモジュール１８０ａおよびスレーブＣＰＵモジュール１８０ｂでは、それぞれ、独立した基準信号に応じて所定の処理が遂行されている。

また、マスタＣＰＵモジュール１８０ａにおいて同期補正処理が開始されると、マスタＣＰＵモジュール１８０ａの遅延時間計測部１８１は、伝送遅延時間を算出するために伝送遅延時間リクエストフレームを送信する（図１９の（３））。スレーブＣＰＵモジュール１８０ｂの遅延時間受信部１８４は、マスタＣＰＵモジュール１８０ａから伝送遅延時間リクエストフレームを受信すると、その伝送遅延時間リクエストフレームに応じて受信完了フレームをマスタＣＰＵモジュール１８０ａに送信する（図１９の（４））。

続いて、マスタＣＰＵモジュール１８０ａの遅延時間計測部１８１は、受信完了フレームを受信すると、マスタＣＰＵモジュール１８０ａとスレーブＣＰＵモジュール１８０ｂ間の往復伝送遅延時間を計算する。そして、遅延時間計測部１８１は、計算した往復伝送遅延時間（４００μｓｅｃ）を２で除算した伝送遅延時間（２００μｓｅｃ）を含む伝送遅延時間通知フレームを、スレーブＣＰＵモジュール１８０ｂに送信する（図１９の（５））。スレーブＣＰＵモジュール１８０ｂの遅延時間受信部１８４は、伝送遅延時間通知フレームを受信すると、そのフレームに含まれる上記往復伝送遅延時間（相当値）をメモリ／バッファに退避する（図１９の（６））。

同期補正処理を開始後、マスタＣＰＵモジュール１８０ａの同期化フレーム送信部１８２は、同期化フレームを割り込み信号としてスレーブＣＰＵモジュール１８０ｂに送信する（図１９の（７））。そして、スレーブＣＰＵモジュール１８０ｂは、ネットワーク１９４の片道の伝送遅延時間（２００μｓ）を経て図１９の（８）の時点で同期化フレームを受信すると、同期補正部１８６は、基準信号生成部から計数値（１９０μｓｅｃに相当）を取得する（図１９の（９））。そして、同期補正部１８６は、伝送遅延時間（２００μｓｅｃ）と、基準値（１０００μｓｅｃ）を用いて、「基準値−（“伝送遅延時間に相当する値”−“基準信号生成部の計数値”）＝１０００−（２００−１９０）」によって、補正基準値９９０μｓｅｃを得る。そして、同期補正部１８６は、その補正基準値を新たな基準値として一時的に基準信号生成部に設定する（図１９の（１０））。

その後、基準信号生成部は、図１９の（１１）時点で計数値が一時的な補正基準値９９０μｓに達したため、リスタートしている。こうして、スレーブＣＰＵモジュール１８０ｂの基準信号が、マスタＣＰＵモジュール１８０ａの基準信号と同期する。

図２０は、同期補正処理の概略的なシーケンス例を示す図である。図２０の例では、説明の便宜上、マスタＣＰＵモジュール１８０ａとスレーブＣＰＵモジュール１８０ｂとを用いた同期について説明するが、本実施形態においてはこれに限定されるものではなく、１つのマスタＣＰＵモジュール１８０ａに対して複数のスレーブＣＰＵモジュール１８０ｂを同期させることができる。

図２０の同期補正処理において、まず、マスタＣＰＵモジュール１８０ａの基準信号生成部（不図示）は基準信号を生成し（Ｓ１１）、スレーブＣＰＵモジュール１８０ｂの基準信号生成部（不図示）は、マスタＣＰＵモジュール１８０ａと独立して基準信号を生成する（Ｓ１２）。また、この処理は、周期的に行われる。

マスタＣＰＵモジュール１８０ａの同期補正処理が開始されると、マスタＣＰＵモジュール１８０ａの遅延時間計測部１８１は、伝送遅延時間を算出するために伝送遅延時間リクエストフレームをスレーブＣＰＵモジュール１８０ｂに送信する（Ｓ１３）。スレーブＣＰＵモジュール１８０ｂの遅延時間受信部１８４は、伝送遅延時間リクエストフレームを受信すると、マスタＣＰＵモジュール１８０ａに受信完了フレームを送信する（Ｓ１４）。

マスタＣＰＵモジュール１８０ａの遅延時間計測部１８１は、受信完了フレームを受信すると、例えば伝送遅延時間を算出し（Ｓ１５）、算出した伝送遅延時間等を含む伝送遅延時間通知フレームを生成する（Ｓ１６）。そして、遅延時間計測部１８１は、生成した伝送遅延時間通知フレームを、ネットワーク１９４を介してスレーブＣＰＵモジュール１８０ｂに送信する（Ｓ１７）。スレーブＣＰＵモジュール１８０ｂの遅延時間受信部１８４は、伝送遅延時間通知フレームを受信すると、その伝送遅延時間通知フレームに含まれる伝送遅延時間（換算値）を、メモリ／バッファ等に退避する（Ｓ１８）。

そして、マスタＣＰＵモジュール１８０ａの同期化フレーム送信部１８２は、基準信号に同期させて、同期化フレームを割り込み信号としてスレーブＣＰＵモジュール１８０ｂに送信する（Ｓ１９）。

スレーブＣＰＵモジュール１８０ｂが同期化フレームを受信すると、同期補正部１８６は、基準信号生成部（不図示）から計数値を取得する（Ｓ２０）。そして、同期補正部１８６は、伝送遅延時間と基準値を用いて、「基準値−（“伝送遅延時間に相当する値”−“基準信号生成部の計数値”）」を計算して、補正基準値を得る（Ｓ２１）。そして、その補正基準値を新たな基準値として一時的に基準信号生成部に設定する（Ｓ２２）。また、補正基準値を設定し、その補正基準値での計数が完了すると、同期補正部１８６は、速やかに、元の基準値を基準信号生成部に設定する（Ｓ２３）。

このような同期補正処理を、制御システムに含まれる全てのスレーブＣＰＵモジュール１８０ｂに対して実行する。こうして、スレーブＣＰＵモジュール１８０ｂの基準信号は、マスタＣＰＵモジュール１８０ａの基準信号に同期する。すなわち、各ＣＰＵモジュール１８０上で動作する実行プログラム（アプリケーション）を同期させることができる。

以上説明したように、実施例２やその変形例によれば、複数プログラマブルコントローラからなるマルチコンフィグレーションシステムにおいて、各コンフィグレーション毎のデバイスレベルネットワークを介した収集データを、システム全体における時系列（収集タイミング；どのデータがどのデータより前か後か等）が分かる形で取得・管理できる。これは、例えば上位装置等が、コントローラレベルネットワークを介して各コンフィグレーションのコントローラから取得するものである。これより、既存システムよりも高精度にシステムパラメータチューニングや故障診断が可能となる。

尚、上記デバイスレベルネットワークは、例えばリング形状ネットワークであるが、この例に限らない。コントローラレベルネットワークは、例えば従来のタイマ同期機能を有するネットワークであるが、この例に限らない。

Claims (15)

1. コントローラと各入出力対象とが第２ネットワークに接続されて成る制御ユニットを複数有し、該複数のコントローラは第１ネットワークにも接続されており、各コントローラが前記第１ネットワークに係わる第１周期と前記第２ネットワークに係わる第２周期に従って演算／通信動作するプログラマブルコントローラシステムであって、
   前記複数のコントローラのうちの特定のコントローラは、自己の前記第２周期開始タイミングに基づいて自己の前記第１周期開始タイミングを決定する第１周期生成手段を有し、
   前記特定コントローラ以外の各コントローラは、
   自己の前記第１周期開始タイミングを前記特定コントローラの第１周期開始タイミングに同期させる第１周期同期手段と、
   自己の前記第２周期開始タイミングを自己の前記第１周期開始タイミングに基づいて補正する第２周期補正手段とを有する、
   ことを特徴とするプログラマブルコントローラシステム。
2. 前記第２周期補正手段による前記補正が行われることで、前記特定コントローラ以外の各コントローラにおける前記第２周期開始タイミングが、前記特定コントローラにおける前記第２周期開始タイミングと同期することを特徴とする請求項１記載のプログラマブルコントローラシステム。
3. 前記第２周期補正手段は、前記第２周期開始タイミングの補正量が所定の上限値を越える場合には、該上限値以下の補正値によって複数回に分けて前記第２周期開始タイミングの補正を行うことを特徴とする請求項２記載のプログラマブルコントローラシステム。
4. 前記上限値は、前記第２周期内の予め割り当てられた各帯域以外の空き時間帯に基づいて決定されていることを特徴とする請求項３記載のプログラマブルコントローラシステム。
5. 前記第２周期内は、前記コントローラが前記第２ネットワークを介して前記各入出力対象からデータを収集する帯域であるＴＦ帯域と、前記コントローラが前記各入出力対象への出力を行う帯域であるＭＣ帯域と、任意の１対１のメッセージ送受信帯域であるＭＳＧ帯域とから成り、
   前記上限値は、前記ＭＳＧ帯域後の空き時間に基づいて決定されていることを特徴とする請求項４記載のプログラマブルコントローラシステム。
6. 前記第２周期内は、前記コントローラが前記第２ネットワークを介して前記各入出力対象からデータを収集する帯域であるＴＦ帯域と、前記コントローラが前記各入出力対象への出力を含むＭＣフレームを巡回させる帯域であるＭＣ帯域と、任意の１対１のメッセージ送受信帯域であるＭＳＧ帯域とから成り、
   前記各入出力対象は、前記第２周期に基づくＩＯ周期に従って動作しており、
   前記上限値は、前記補正によって前記第２周期の開始タイミングが前記補正値分変わっても、前記ＭＣフレームを最後に受信する前記入出力対象が該ＭＣフレームを受信する前に、次の前記ＩＯ周期とならないようにして決定されていることを特徴とする請求項４記載のプログラマブルコントローラシステム。
7. 前記第２周期補正手段は、補正方向を−方向とするか＋方向とするかを決定し、−方向とする場合には前記自己の第２周期を一時的に短くすることで該第２周期開始タイミングの補正を行い、＋方向とする場合には前記自己の第２周期を一時的に長くすることで該第２周期開始タイミングの補正を行うことを特徴とする請求項１〜６の何れかに記載のプログラマブルコントローラシステム。
8. 前記第２周期補正手段は、自己の第１周期開始タイミングからその直後の第２周期開始タイミングまでのズレ量が、該第２周期の長さの半分未満である場合には前記補正方向を前記−方向とし、該ズレ量が該第２周期の長さの半分以上である場合には前記補正方向を前記＋方向とすることを特徴とする請求項７記載のプログラマブルコントローラシステム。
9. 前記第２周期補正手段は、前記補正方向を前記−方向とする場合には前記ズレ量を第２周期の補正量とし、前記補正方向を前記＋方向とする場合には「第２周期の長さ−ズレ量」を第２周期の補正量とすることを特徴とする請求項７記載のプログラマブルコントローラシステム。
10. 前記各コントローラは、
    前記第１周期毎に、前記第２ネットワークを介して得た前記各入出力対象からの直近の収集データを、前記第１ネットワークを介して所定の送信先装置へ送信する送信手段を更に有することを特徴とする請求項１〜６の何れかに記載のプログラマブルコントローラシステム。
11. 前記送信先装置は、各第１周期開始時に、そのときの時間情報を含む特定パケットを各コントローラへ送信し、
    前記各コントローラの前記送信手段は、各第１周期毎に、受信した特定パケットの前記時間情報を、前記直近の収集データの送信パケットに付加して、前記送信先装置へ送信することを特徴とする請求項１０記載のプログラマブルコントローラシステム。
12. 前記第１周期は、前記第２周期の整数倍の長さであり、
    前記送信手段は、前記第１周期毎に、該第１周期内の各第２周期毎に前記各入出力対象から取得した収集データを、どの第２周期の際の収集データであるのかを示す識別情報と共に蓄積し、最後に該蓄積データをまとめて前記送信先装置へ送信することを特徴とする請求項１０記載のプログラマブルコントローラシステム。
13. コントローラと各入出力対象とが第２ネットワークに接続されて成る制御ユニットを複数有し、該複数のコントローラは第１ネットワークにも接続されており、各コントローラが前記第１ネットワークに係わる第１周期と前記第２ネットワークに係わる第２周期に従って演算／通信動作するプログラマブルコントローラシステムにおける特定のコントローラ以外のコントローラであって、
    自己の前記第１周期開始タイミングを前記特定コントローラの第１周期開始タイミングに同期させる第１周期同期手段と、
    自己の前記第２周期開始タイミングを自己の前記第１周期開始タイミングに基づいて補正する第２周期補正手段と、
    を有することを特徴とするコントローラ。
14. 前記第２周期補正手段による前記補正が行われることで、前記特定コントローラ以外の各コントローラにおける前記第２周期開始タイミングが、前記特定コントローラにおける前記第２周期開始タイミングと同期することを特徴とする請求項１３記載のコントローラ。
15. 前記第２周期補正手段は、前記第２周期開始タイミングの補正量が所定の上限値を越える場合には、該上限値以下の補正値によって複数回に分けて前記第２周期開始タイミングの補正を行うことを特徴とする請求項１４記載のコントローラ。
    

Images