JP6428805B2 - 演算装置、制御装置および制御方法 - Google Patents

Description

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

様々なＦＡ（Factory Automation）を実現するための主たるコンポーネントとして、ＰＬＣ（プログラマブルコントローラ）などの制御装置が普及している。このような制御装置は、各種プログラムを実行するＣＰＵユニットと、ＣＰＵユニットと伝送路を介して接続される１または複数の機能ユニットとから構成されることがある。このような構成において、ＣＰＵユニットと機能ユニットとの間では、伝送路を介してデータが遣り取りされる。

ところで、ＰＬＣなどの制御装置においては、入力値の取得および制御指令の出力を高精度に同期させたいという要求がある。このような要求に応えるために、伝送路を介して接続されているＣＰＵユニットおよび機能ユニットは、各々に内蔵されるクロック（典型的には、カウンタを用いて実装される）が互いに同期した状態に維持される。そして、ＣＰＵユニットおよび機能ユニットの各々は、互いに同期したクロックに基づいて、送信タイミングおよび受信タイミングを調整する。例えば、特開２０１１−２１６０８５（特許文献１）は、このようなクロックの同期、すなわち時刻合わせの一手法を開示する。

このような時刻同期された構成において、機能ユニットが収集した入力データをＣＰＵユニットが取得する処理、および、ＣＰＵユニットにて算出された制御指令を機能ユニットへ出力する処理を含むＩＯ（Input Output）リフレッシュが所定周期毎に実行される。ＩＯリフレッシュが実行される期間以外の期間に、メッセージ通信でデータが遣り取りされることもある。特許文献１においては、マスタユニットとスレーブユニットとの間で実際にメッセージを送受することで伝搬遅延時間を求めて、その伝搬遅延時間を用いて時刻補正を行うことが開示されている。

特開２０１１−２１６０８５号公報

上述したようなメッセージ通信は、例えば、ＣＰＵユニットと機能ユニットとの間の接続を確立するための処理や各種の起動処理に利用されることもある。このような用途に使用されるメッセージ通信で伝送されるデータは、可能な限り速やかに送出されることが好ましいが、一般的には、ＩＯリフレッシュには最も高い優先度が設定されるので、伝送路の状況によっては、メッセージ通信でデータを速やかに伝送できない場合がある。

本発明は、ＩＯリフレッシュなどに係る通信フレームが所定周期で伝送される伝送路において、メッセージ通信における送信先への到着時刻を保証するための新たな構成を提供することを目的とする。

本発明のある局面に従う、制御装置を構成する演算装置は、伝送路を介して１または複数の機能ユニットとの間でデータを遣り取りするための通信インターフェイスと、伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、第１の通信フレームが伝送されていない期間において、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、処理に応じて第１のイベント要求を発行する第１のイベント発行手段と、第１のイベント要求より優先度の高い第２のイベント要求を発行する第２のイベント発行手段と、第２のイベント発行手段により発行される第２のイベント要求を優先的に処理するための優先度管理手段とを含む。優先度管理手段は、第２のイベント発行手段から第２のイベント要求の発行要求を受けると、第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、第２のイベント発行手段に対して第２のイベント要求の発行を許可する。第２の伝送制御手段は、現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、第２のイベント要求に対する処理の完了まで中断する。

好ましくは、第２の伝送制御手段は、第１のイベント要求を順次格納する第１のキューと、第２のイベント要求を順次格納する第２のキューとを含む。

好ましくは、優先度管理手段は、第２のイベント要求の発行要求を受けると、当該発行要求を第２の伝送制御手段へ通知し、第２の伝送制御手段は、第２のイベント要求の発行要求を通知された後、現在処理中の第１のイベント要求についての処理が完了すると、第２のイベント要求が処理可能である旨を優先度管理手段へ通知する。

好ましくは、第２のイベント要求は、特定の機能ユニットが伝送路を介して演算装置との間で同期通信を確立するための指示を含む。

好ましくは、伝送路を介して接続される演算装置および１または複数の機能ユニットの各々は、互いに同期したクロックを有しており、同期通信を確立するための指示は、互いに同期したクロックが示すタイミングを含む。

好ましくは、タイミングは、第１の通信フレームの送出周期に関連付けられた値に設定される。

本発明の別の局面に従う制御装置は、演算装置と、演算装置と伝送路を介してデータを遣り取り可能に接続された１または複数の機能ユニットとを含む。演算装置は、伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、第１の通信フレームが伝送されていない期間において、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、処理に応じて第１のイベント要求を発行する第１のイベント発行手段と、第１のイベント要求より優先度の高い第２のイベント要求を発行する第２のイベント発行手段と、第２のイベント発行手段により発行される第２のイベント要求を優先的に処理するための優先度管理手段とを含む。優先度管理手段は、第２のイベント発行手段から第２のイベント要求の発行要求を受けると、第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、第２のイベント発行手段に対して第２のイベント要求の発行を許可する。第２の伝送制御手段は、現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、第２のイベント要求に対する処理の完了まで中断する。

本発明のさらに別の局面に従えば、演算装置と、演算装置と伝送路を介してデータを遣り取り可能に接続された１または複数の機能ユニットとを備えた制御装置における制御方法が提供される。制御方法は、伝送路を介して所定周期毎に第１の通信フレームを送出するステップと、処理に応じて第１のイベント要求を発行するステップと、第１のイベント要求より優先度の高い第２のイベント要求を発行するステップと、第１の通信フレームが伝送されていない期間において、第１のイベント要求または第２のイベント要求に応答して、第２の通信フレームを送出するステップと、第２のイベント要求の発行要求を受けると、現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、第２のイベント要求の発行を許可するステップと、現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、第２のイベント要求に対する処理の完了まで中断するステップとを含む。

本発明に従えば、ＩＯリフレッシュなどに係る通信フレームが所定周期で伝送される伝送路において、メッセージ通信における送信先への到着時刻を保証することができる。

本実施の形態に従うＰＬＣの要部構成を示す模式図である。 本実施の形態に従うＰＬＣのローカルバス上でのデータ伝送を説明するための模式図である。 本実施の形態に従うＰＬＣにおける関連技術に従う初期化処理の一例を示す模式図である。 ＣＰＵユニットと機能ユニットとの間の第１の初期化手順を示す模式図である。 ＣＰＵユニットと機能ユニットとの間の第２の初期化手順を示す模式図である。 関連技術に従う初期化処理における一つの課題を説明するための模式図である。 本実施の形態に従うＰＬＣにおける機能構成を示す模式図である。 本実施の形態に従う初期化処理におけるモジュール間の遣り取りを説明する模式図である。 本実施の形態に従う初期化処理における処理手順を示すシーケンス図である。 本実施の形態に従うＰＬＣのスケジューラが応答するスタートタイムを説明するための模式図である。 本実施の形態に従うＰＬＣのイベント通信処理タスクの通常イベントのキューおよび高優先イベントのキューにおける処理を説明するための模式図である。

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

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

＜Ａ．装置構成＞
まず、本実施の形態に従うＰＬＣの装置構成について説明する。図１は、本実施の形態に従うＰＬＣの要部構成を示す模式図である。

図１を参照して、本実施の形態に従うＰＬＣ１は、基本的な構成として、ＣＰＵユニット１００と、１または複数の機能ユニット１５０とからなる。ＣＰＵユニット１００は、ＰＬＣ１を構成する一要素であり、ＰＬＣ１全体の処理を制御する演算装置に相当する。機能ユニット１５０は、ＰＬＣ１による様々な機械や設備の制御を実現するための各種機能を提供する。ＣＰＵユニット１００と１または複数の機能ユニット１５０との間は、伝送路の一例であるローカルバス１１２を介して接続されている。

ＣＰＵユニット１００は、ローカルバス１１２を介して、任意の機能ユニット１５０との間でデータを遣り取りすることができる。典型的には、ＣＰＵユニット１００は、１または複数の機能ユニット１５０との間で所定周期毎にＩＯリフレッシュが実行される。このＩＯリフレッシュにおいては、各機能ユニット１５０が収集している入力データがＣＰＵユニット１００へ送信されとともに、ＣＰＵユニット１００にて算出される制御指令が任意の機能ユニット１５０へ送信される。このようなＩＯリフレッシュに加えて、ＣＰＵユニット１００と任意の機能ユニット１５０との間、あるいは、任意の機能ユニット１５０の間で、メッセージ通信でのデータの送受信が可能になっている。メッセージ通信は、一対一の態様に限らず、一対複数の態様が可能であってもよい。

図１には、応用的な構成として、ＰＬＣ１にリモートＩＯ装置が接続されている構成を示す。すなわち、ＣＰＵユニット１００には、伝送路の別の一例であるフィールドネットワーク１１４を介して、１または複数の通信カプラユニット２００が接続されている。通信カプラユニット２００の各々には、伝送路の一例であるローカルバス２１２を介して、１または複数の機能ユニット２５０が接続されている。

なお、機能ユニット１５０と機能ユニット２５０とは実質的に同様の構成を有しており、説明の便宜上、符号を異ならせているだけである。但し、ＣＰＵユニット１００に接続される機能ユニット１５０と、通信カプラユニット２００に接続される機能ユニット２５０との間で、何らかの機能を異ならせるようにしてもよい。

ＣＰＵユニット１００は、通信カプラユニット２００に接続されている機能ユニット２５０に対してもＩＯリフレッシュおよびメッセージ通信が可能になっている。すなわち、通信カプラユニット２００は、ＣＰＵユニット１００と機能ユニット２５０との間のデータの遣り取りを仲介する機能を提供する。より具体的には、ＣＰＵユニット１００からフィールドネットワーク１１４を介して送信されるデータは、通信カプラユニット２００を介してローカルバス２１２上に転送され、目的の機能ユニット２５０まで届けられる。逆に、任意の機能ユニット２５０からローカルバス２１２を介して送信されたデータは、通信カプラユニット２００を介してフィールドネットワーク１１４上に転送され、ＣＰＵユニット１００まで届けられる。

より具体的には、ＣＰＵユニット１００は、プロセッサ１０２と、メインメモリ１０４と、ストレージ１０６と、バス通信回路１０８と、ネットワークインターフェイス１１０とを含む。

プロセッサ１０２は、システムプログラムおよびユーザプログラムを実行することで、ＰＬＣ１での処理を実現する。プロセッサ１０２は、例えば、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）などを用いることができる。プロセッサ１０２としては、シングルコアかつシングルチップの構成であってもよいし、マルチコアのシングルチップ、シングルコアのマルチチップ、マルチコアのマルチチップのいずれであってもよい。

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

ストレージ１０６は、フラッシュメモリなどの半導体記憶デバイスで構成され、ＣＰＵユニット１００の基本的な機能を実現するためのシステムプログラムや、制御対象に応じて任意に作成されるユーザプログラムなどを格納する。

バス通信回路１０８は、伝送路を介して１または複数の機能ユニット１５０との間でデータを遣り取りするための通信インターフェイスに相当し、ＣＰＵユニット１００と各機能ユニット１５０との間のローカルバス１１２（伝送路）を介したデータ伝送を仲介する。バス通信回路１０８の少なくとも一部は、ハードワイヤードな回路で実装してもよい。バス通信回路１０８は、ローカルバス１１２上のデータ伝送を管理する「マスター」として機能してもよい。この場合、ローカルバス１１２に接続される機能ユニット１５０の各々は、バス通信回路１０８の管理下でデータ伝送を行う「スレーブ」として機能してもよい。バス通信回路１０８を用いた、ＣＰＵユニット１００と各機能ユニット１５０との間のデータ送受信の処理については、後述する。

ネットワークインターフェイス１１０は、ＣＰＵユニット１００と各通信カプラユニット２００を含む任意のデバイスとの間のフィールドネットワーク１１４を介したデータ伝送を仲介する。ネットワークインターフェイス１１０は、フィールドネットワーク１１４上のデータ伝送を管理する「マスター」として機能してもよい。この場合、フィールドネットワーク１１４に接続される通信カプラユニット２００および他のデバイスの各々は、ネットワークインターフェイス１１０の管理下でデータ伝送を行う「スレーブ」として機能してもよい。なお、フィールドネットワーク１１４としては、例えば、ＥｔｈｅｒＣＡＴ（登録商標）、ＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）、ＤｅｖｉｃｅＮｅｔ（登録商標）、ＣｏｍｐｏＮｅｔ（登録商標）などの公知のプロトコルに従う、定周期ネットワークを採用してもよい。

機能ユニット１５０は、ＣＰＵユニット１００で実行されるユーザプログラムに必要な情報の収集、ユーザプログラムの実行により算出される制御指令の出力、ＣＰＵユニット１００とは独立した特殊処理の実行といった、任意の機能を提供する。典型的には、機能ユニット１５０は、ＩＯユニット、通信ユニット、温度調整ユニット、ＩＤ（Identifier）センサユニットなどを包含し得る。

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

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

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

より具体的には、機能ユニット１５０の各々は、バス通信回路１５２と、通信コントローラ１５４と、機能モジュール１５６とを含む。

通信コントローラ１５４は、ローカルバス１１２を伝送されるデータ（典型的には、通信フレーム）を処理する。具体的には、通信コントローラ１５４は、マスターであるバス通信回路１０８による管理に従って、ローカルバス１１２を介して要求されたデータを送信するとともに、ローカルバス１１２を介して何らかのデータを受信すると、通信コントローラ１５４へ出力する。

通信コントローラ１５４は、予め格納されたプログラムまたはロジックを実行することで、ローカルバス１１２上でのデータの送受信を制御する。通信コントローラ１５４は、所定のソフトウェアを実行するように構成されたプロセッサ、あるいは、所定のロジックが組み込まれた処理回路などを用いて実装することができる。

機能モジュール１５６は、各機能ユニット１５０が提供する各種機能、例えば、フィールドからの各種情報（入力データ）の収集や、フィールドにある制御対象（機械や設備）への制御指令の出力などを行う。

機能ユニット１５０においては、基本的には、機能モジュール１５６が各機能ユニット１５０に固有の処理の実行または固有の機能の提供を担当し、バス通信回路１５２および通信コントローラ１５４がローカルバス１１２を介したデータ伝送を担当する。

通信カプラユニット２００は、ローカルバス２１２を介した機能ユニット２５０との間のデータ伝送を担当するとともに、フィールドネットワーク１１４を介したＣＰＵユニット１００との間のデータ伝送を担当する。より具体的には、通信カプラユニット２００は、コントローラ２０１と、ネットワークインターフェイス２１０と、バス通信回路２０８とを含む。

コントローラ２０１は、主として、ネットワークインターフェイス２１０およびバス通信回路２０８を制御する。典型例とし、コントローラ２０１は、プロセッサ２０２と、メインメモリ２０４と、ストレージ２０６とを含む。プロセッサ２０２は、ストレージ２０６に格納されているシステムプログラムなどをメインメモリ２０４に展開して実行することで、通信カプラユニット２００において必要な処理および機能を提供する。なお、コントローラ２０１の少なくとも一部をハードワイヤードな回路で実装してもよい。

ネットワークインターフェイス２１０は、フィールドネットワーク１１４を介したデータ伝送を担当する。ネットワークインターフェイス２１０は、フィールドネットワーク１１４においてスレーブとして機能する点を除いて、基本的な構成は、ＣＰＵユニット１００のネットワークインターフェイス１１０と同様である。

バス通信回路２０８は、ＣＰＵユニット１００のバス通信回路１０８と同様に、通信カプラユニット２００と各機能ユニット２５０との間のローカルバス２１２を介したデータ伝送を仲介する。

機能ユニット２５０は、通信カプラユニット２００に接続される点を除いて、上述の機能ユニット１５０と実質的に同一である。機能ユニット２５０の各々は、バス通信回路２５２と、通信コントローラ２５４と、機能モジュール２５６とを含む。これらの機能の詳細については、機能ユニット１５０に関して説明したので、ここでは詳細な説明は繰返さない。

＜Ｂ．ローカルバス上のデータ伝送＞
次に、ＣＰＵユニット１００と各機能ユニット１５０との間のローカルバス１１２を介したデータ伝送について説明する。なお、通信カプラユニット２００と各機能ユニット２５０との間のローカルバス２１２を介したデータ伝送についても同様である。

図２は、本実施の形態に従うＰＬＣ１のローカルバス上でのデータ伝送を説明するための模式図である。図２には、所定周期毎に繰返し実行されるＩＯリフレッシュに加えて、任意のデータがメッセージ通信される例を示す。

具体的には、図２（Ａ）に示すように、ローカルバス１１２（伝送路）を介して、所定のシステム周期Ｔｓ毎にＩＯリフレッシュを行うための通信フレームＦＬが送出される。典型的には、ＩＯリフレッシュを行うための通信フレームＦＬは、ＣＰＵユニット１００から送出されて、隣接する機能ユニット１５０に対して順次転送される。各機能ユニット１５０にて収集される入力データ、および、各機能ユニット１５０に対する指令を含む出力データを、互いに異なる通信フレームＦＬを用いて伝送してもよいし、同一の通信フレームＦＬで伝送するようにしてもよい。

このような所定周期毎に繰返し伝送されるＩＯリフレッシュを行うための通信フレームＦＬが転送されていない期間にて、任意のメッセージ通信でデータを送信することもできる。このメッセージフレームＭＳＧＦＬについては、ＣＰＵユニット１００から特定の機能ユニット１５０に伝送される場合、もしくは、その逆方向に転送される場合、または、任意の機能ユニット１５０の間で伝送される場合などがある。

但し、通信フレームＦＬとメッセージフレームＭＳＧＦＬとは同時に送出することができないので、メッセージフレームＭＳＧＦＬの送信要求などが発行されたとしても、ＩＯリフレッシュ中であれば、指定されたメッセージフレームＭＳＧＦＬの生成および送出は遅れることになる。

例えば、図２（Ｂ）に示すように、ＩＯリフレッシュを行うための通信フレームＦＬの伝送中に、メッセージ送信要求が与えられたとする。この場合、通信フレームＦＬの伝送完了後に、メッセージフレームＭＳＧＦＬが生成および送出されることになる。図２（Ｂ）に示す例では、メッセージフレームＭＳＧＦＬは、メッセージ送信要求が与えられてから遅延時間Ｄ１後に送出が開始される。

また、図２（Ｃ）に示すように、ＩＯリフレッシュを行うための通信フレームＦＬの伝送中直前に、メッセージ送信要求が与えられたとする。この場合、通信フレームＦＬの伝送期間が迫っているので、メッセージフレームＭＳＧＦＬの生成および送出は妨げられ、後続の通信フレームＦＬの伝送完了後に、メッセージフレームＭＳＧＦＬが生成および送出されることになる。図２（Ｃ）に示す例では、メッセージフレームＭＳＧＦＬは、メッセージ送信要求が与えられてから遅延時間Ｄ２後に送出が開始される。

このように、ＩＯリフレッシュを行うための通信フレームＦＬが周期的に伝送されているローカルバスにおいては、メッセージ送信要求が与えられてから、実際に通信フレームＦＬが送出されるまでには、ある程度の伝送遅延が発生することになる。

なお、説明の便宜上、図２（Ｂ）および（Ｃ）には、ＩＯリフレッシュ以外を考慮していないが、多数のメッセージ送信要求が先に発行されているような場合には、先になされている送信要求の数などに応じて、メッセージフレームの送信遅延が発生する。

＜Ｃ．関連技術に従う初期化処理の一例＞
次に、ローカルバス上をメッセージ通信される通信フレームを用いた、関連技術に従う初期化処理の一例について説明する。

（ｃ１：初期化処理）
図３は、本実施の形態に従うＰＬＣ１における関連技術に従う初期化処理の一例を示す模式図である。図３に示す初期化処理は、マスターとして機能するＣＰＵユニット１００からスレーブとして機能する機能ユニット１５０に対して、ローカルバス１１２を介したデータ伝送を同期するためのスタートタイムを指示する例を示す。このスタートタイムは、同期通信を確立するための指示に相当し、互いに同期したクロックが示すタイミングを含む。

図３（Ａ）を参照して、マスターとして機能するＣＰＵユニット１００と、ローカルバス１１２を介してＣＰＵユニット１００に接続されるそれぞれの機能ユニット１５０−１〜１５０−３との各々は、互いに同期したクロックを有している。より具体的には、ＣＰＵユニット１００のバス通信回路１０８は、ローカルバス１１２上でのデータ伝送の基準となるマスタークロック１０９を有しており、各機能ユニット１５０のバス通信回路１５２は、マスタークロック１０９と同期するオーディナリークロック１５３を有している。

各機能ユニット１５０の通信コントローラ１５４は、バス通信回路１５２のオーディナリークロック１５３が示すタイミングを基準としてデータの送受信を管理する。このような互いに同期したクロックを用いたデータ送受信のタイミング管理によって、ローカルバス１１２上で衝突のないデータ伝送を実現できる。

図３（Ａ）には、機能ユニット１５０−１，１５０−２についてのみＣＰＵユニット１００との間で同期通信が確立されている状態を示す。図３（Ｂ）には、図３（Ａ）に示す状態において、機能ユニット１５０−３についても新たに同期通信を確立させる初期化処理を示す。

具体的には、機能ユニット１５０−３のオーディナリークロック１５３がＣＰＵユニット１００のマスタークロック１０９と同期している状態において、ＣＰＵユニット１００から対象の機能ユニット１５０−３に対して、同期通信を開始すべきタイミング（スタートタイム）を通知する。機能ユニット１５０−３は、オーディナリークロック１５３が通知されたスタートタイムを示すと、データの送信または受信を開始する。

但し、ＣＰＵユニット１００から通知するスタートタイムは、未来の時刻でなければならず、過去の時刻が指定されると無効なものとして処理されることになる。このようなスタートタイムの通知は、以下のいずれかに示すような手順に従って、メッセージ通信にて送信される。

（ｃ２：第１の初期化手順）
第１の初期化手順として、スレーブとして機能する機能ユニット１５０のバス通信回路１５２のレジスタにスタートタイムを書込む方法を説明する。バス通信回路１５２は、図示しないレジスタを有しており、自己のオーディナリークロック１５３のクロック値がこのレジスタに書込まれたスタートタイムに到達すると、通信コントローラ１５４に対して割込み指令を発行して、同期を確立する。

図４は、ＣＰＵユニット１００と機能ユニット１５０との間の第１の初期化手順を示す模式図である。図４を参照して、先に、ＣＰＵユニット１００の基本的なソフトウェア構造について説明する。

ＣＰＵユニット１００においては、スケジューラ１２０と、複数のタスク（ＩＯリフレッシュタスク１３０およびシステムサービスタスク１４０）と、バスドライバ１１３と、フィールドネットワークドライバ１１５とを含む。これらのコンポーネントは、ＣＰＵユニット１００のプロセッサ１０２がシステムプログラムおよびユーザプログラムを実行することで実現される。

スケジューラ１２０は、予め登録された複数のタスクについて、各タスクに設定される優先度などに基づいて、実行周期および実行タイミングを制御する。これらのタスクのうち、ＩＯリフレッシュタスク１３０については、最高の優先度が設定されており、所定のシステム周期毎にＩＯリフレッシュを行うための通信フレーム（図２など参照）などを送出するための処理を実行する。一方、システムサービスタスク１４０については、最低の優先度が設定されており、ＩＯリフレッシュタスク１３０などの他のタスクが実行されていない期間に適宜実行される。

ＩＯリフレッシュタスク１３０は、ローカルバス１１２（伝送路）を介して所定周期（システム周期Ｔｓ）毎に通信フレームを送出する機能の少なくとも一部を提供するものであり、バスドライバ１１３に要求を与えることで、ローカルバス１１２上にＩＯリフレッシュを行うための通信フレームを伝送させる。併せて、ＩＯリフレッシュタスク１３０は、フィールドネットワークドライバ１１５に指令を与えることで、フィールドネットワーク１１４上にＩＯリフレッシュを行うための通信フレームまたはパケットを伝送させる。

システムサービスタスク１４０は、メッセージルーチングタスク１４２と、スレーブ状態管理タスク１４４と、イベント通信処理タスク１４６とを含む。メッセージルーチングタスク１４２は、ローカルバス１１２上またはフィールドネットワーク１１４上のメッセージフレームを解釈し、そのメッセージフレームを伝送する際の経路を決定する。スレーブ状態管理タスク１４４は、ローカルバス１１２を介して接続されているスレーブ（機能ユニット１５０）の状態を管理する。

イベント通信処理タスク１４６は、ＩＯリフレッシュを行うための通信フレームが伝送されていない期間において、任意のイベント要求に応答して、別の通信フレームを送出する機能の少なくとも一部を提供する、具体的には、イベント通信処理タスク１４６は、何らかのイベント要求に応答してメッセージフレームを送信する処理を実行する。イベント通信処理タスク１４６は、送信要求を順次登録するキュー１４８を管理している。

以下の説明においては、キューへの何らかのデータの登録（入力）をキューイング（queuing）とも称し、キューからのデータの削除（出力）をデキューイング（dequeuing）とも称す。

まず、ＣＰＵユニット１００が起動すると、あるいは、ローカルバス１１２上に新たな機能ユニット１５０が追加されると、スレーブ状態管理タスク１４４は、クロック設定処理を実行する。より具体的には、スレーブ状態管理タスク１４４は、機能ユニット１５０の各々に対して、オーディナリークロック１５３をマスタークロック１０９と同期させるように指示を与える。

クロックが同期された状態において、第１の手順として、スレーブ状態管理タスク１４４は、バス通信回路１０８のマスタークロック１０９からクロック値を読出してスレーブに設定すべきスタートタイムを算出する。そして、第２の手順として、スレーブ状態管理タスク１４４は、特定のスレーブ（機能ユニット１５０）に対して、算出したスタートタイムをレジスタに書込むためのレジスタ書込みフレームの送信要求をイベント通信処理タスク１４６へ出力する。このレジスタ書込みフレームの送信要求は、キュー１４８に登録される。イベント通信処理タスク１４６は、キュー１４８に登録されている送信要求を順次処理する。キュー１４８に登録されている送信要求が順次処理されて、先に登録されたレジスタ書込みフレームの送信要求が処理できる状態になると、第３の手順として、イベント通信処理タスク１４６は、イベントフレーム送信要求をバスドライバ１１３へ出力する。第４の手順として、バスドライバ１１３は、イベントフレーム送信要求を受けてバス通信回路１０８の通信を起動する。すると、バス通信回路１０８からローカルバス１１２上にレジスタ書込みフレームが送出される。

第５の手順として、機能ユニット１５０にてレジスタ書込みフレームが受信されると、第６の手順として、機能ユニット１５０のバス通信回路１５２は、受信したレジスタ書込みフレームに含まれるスタートタイムを内部のレジスタに書込む。そして、機能ユニット１５０のバス通信回路１５２は、オーディナリークロック１５３がレジスタに書込まれたスタートタイムに到達すると同期処理を開始する。

以上のような第１〜第６の手順によって、ＣＰＵユニット１００と機能ユニット１５０との間に新たに同期通信を確立させる初期化処理は完了する。

（ｃ３：第２の初期化手順）
次に、上述の第１の初期化手順とは異なる第２の初期化手順について説明する。第２の初期化手順として、ＣＰＵユニット１００から機能ユニット１５０にメッセージ通信されるメッセージフレームに応答して、通信コントローラ１５４がバス通信回路１５２のレジスタにスタートタイムを書込む方法について説明する。

図５は、ＣＰＵユニット１００と機能ユニット１５０との間の第２の初期化手順を示す模式図である。図５を参照して、先に、機能ユニット１５０の基本的なソフトウェア構造について説明する。

機能ユニット１５０においては、メッセージルーチングタスク１６２と、状態管理タスク１６４と、バスドライバ１６６とが実装される。これらのコンポーネントは、通信コントローラ１５４によって提供される。

メッセージルーチングタスク１６２は、ローカルバス１１２上のメッセージフレームを解釈し、そのメッセージフレームを伝送する際の経路を決定する。状態管理タスク１６４は、ローカルバス１１２を介してＣＰＵユニット１００に接続するための状態を管理する。バスドライバ１１３は、バス通信回路１５２を介してローカルバス１１２上で遣り取りされるデータの送受信管理を行う。

まず、ＣＰＵユニット１００が起動すると、あるいは、ローカルバス１１２上に新たな機能ユニット１５０が追加されると、スレーブ状態管理タスク１４４は、クロック設定処理を実行する。より具体的には、スレーブ状態管理タスク１４４は、機能ユニット１５０の各々に対して、オーディナリークロック１５３をマスタークロック１０９と同期させるように指示を与える。

クロックが同期された状態において、第１の手順として、スレーブ状態管理タスク１４４は、バス通信回路１０８のマスタークロック１０９からクロック値を読出してスレーブに設定すべきスタートタイムを算出する。そして、第２の手順として、スレーブ状態管理タスク１４４は、特定のスレーブ（機能ユニット１５０）に対して、算出したスタートタイムを含む通信フレームについてのメッセージルーチング要求をメッセージルーチングタスク１４２へ出力する。第３の手順として、メッセージルーチングタスク１４２は、スレーブ状態管理タスク１４４からのメッセージルーチング要求を解釈して送信先のスレーブを特定するとともに、当該スレーブへのメッセージフレームを送信するためのメッセージフレーム送信要求をイベント通信処理タスク１４６へ出力する。このメッセージフレーム送信要求は、キュー１４８に登録される。イベント通信処理タスク１４６は、キュー１４８に登録されている送信要求を順次処理する。キュー１４８に登録されている送信要求が順次処理されて、先に登録されたメッセージフレーム送信要求が処理できる状態になると、第４の手順として、イベント通信処理タスク１４６は、イベントフレーム送信要求をバスドライバ１１３へ出力する。第５の手順として、バスドライバ１１３は、イベントフレーム送信要求を受けてバス通信回路１０８の通信を起動する。すると、バス通信回路１０８からローカルバス１１２上にメッセージフレームが送出される。

第６の手順として、機能ユニット１５０にてメッセージフレームが受信されると、第７の手順として、機能ユニット１５０のバス通信回路１５２は、バスドライバ１６６に対して、メッセージフレームの受信に伴う割込みを発行する。第８の手順として、バスドライバ１６６は、受信したメッセージフレームをメッセージルーチングタスク１６２へ出力して、受信したメッセージフレームに対するルーチングを要求する。第９の手順として、メッセージルーチングタスク１６２は、バスドライバ１６６からのメッセージフレームの内容がバス通信回路１５２に対するスタートタイムの設定要求であると解釈し、クロック設定要求を状態管理タスク１６４へ出力する。

第１０の手順として、状態管理タスク１６４は、クロック設定要求に応答して、指定されたスタートタイムをバス通信回路１５２のレジスタに書込む。そして、機能ユニット１５０のバス通信回路１５２は、オーディナリークロック１５３がレジスタに書込まれたスタートタイムに到達すると同期処理を開始する。

以上のような第１〜第１０の手順によって、ＣＰＵユニット１００と機能ユニット１５０との間に新たに同期通信を確立させる初期化処理は完了する。

（ｃ４：課題）
次に、図４および図５に示す初期化手順に生じ得る課題について説明する。図４および図５を参照して説明したように、ＣＰＵユニット１００からメッセージ通信される通信フレーム（レジスタ書込みフレームまたはメッセージフレーム）は、最低の優先度が設定されているシステムサービスタスク１４０において生成される送信要求に応じて送信される。

また、送信要求は他のタスクからも生成されることもあるので、イベント通信処理タスク１４６のキュー１４８には、レジスタ書込みフレーム送信要求またはメッセージフレーム送信要求以外のメッセージ送信要求が既に登録されている場合もある。そのため、レジスタ書込みフレーム送信要求またはメッセージフレーム送信要求を発行した後、当該フレーム送信要求がいつ処理されるのかは、先にキュー１４８に登録されている送信要求の状態に依存することになる。

図６は、関連技術に従う初期化処理における一つの課題を説明するための模式図である。図６を参照して、フレーム送信要求は、イベント通信処理タスク１４６のキュー１４８にＦＩＦＯ（First In First Out）で登録および処理（キューおよびデキュー）されることになる。図６には、上述したような初期化処理を実行するためのレジスタ書込みフレーム送信要求（またはメッセージフレーム送信要求）がキュー１４８に登録された時点で、既に２つの送信要求がキュー１４８に登録されている状態を示す。このような状態において、先に登録されている２つの送信要求がいつ処理（デキュー）されるのかについては正確に見積もることができない。

上述したように、ＣＰＵユニット１００から通知するスタートタイムは未来の時刻でなければならない。これは、機能ユニット１５０に到着した時点において、指定されたスタートタイムが未来の時刻である必要がある。一方で、上述したように、スタートタイムを含む通信フレームがいつのタイミングで送信されるのかについては不確定な要素が存在する。

そこで、キュー１４８における通信フレームの送信に要する最悪の時間を見積もっておき、その見積もった時間に応じて、指定するスタートタイムに十分なマージンを持たせることにより、機能ユニット１５０に到着した時点において、当該スタートタイムが過去の時刻にならないように設計する必要がある。

なお、通信カプラユニット２００のローカルバス２１２などにおいては、コントローラ２０１のリソースを多く使用できるため、スタートタイムに設定するマージンの見積もりおよびその正確性の担保が比較的容易である。一方、ＣＰＵユニット１００においては、複数のタスクが実行されるため、スタートタイムに設定すべきマージンが大きく変化し、その見積もりが容易ではない。さらに、図６に示すような、先行の送信要求の処理完了を待たざるを得ない場合がある。

以上のような理由によって、指示するスタートタイムに設定されるマージンを過剰に大きくして初期化処理を実行したり、最悪の場合、初期化処理が失敗し、初期化処理をやり直す必要が生じたりする。つまり、上述したような関連技術に従う初期化処理では、処理を早期かつ確実に完了させることは容易ではなかった。

＜Ｄ．本実施の形態に従う初期化処理に係る機能構成＞
次に、本実施の形態に従う初期化処理に係る機能構成について説明する。図７は、本実施の形態に従うＰＬＣ１における機能構成を示す模式図である。図７を参照して、本実施の形態に従うＰＬＣ１のＣＰＵユニット１００は、図４および図５に示す構成に比較して、高優先イベントキュー管理タスク１３６が追加されるとともに、イベント通信処理タスク１４６においては、通常イベントのキュー１４８に加えて、高優先イベントのキュー１４９が用意されている。イベント通信処理タスク１４６は、通常イベント要求を順次格納するキュー１４８と、高優先イベント要求を順次格納するキュー１４９とを含む。

システムサービスタスク１４０としては、図７に示すメッセージルーチングタスク１４２およびスレーブ状態管理タスク１４４だけではなく、他のシステムサービスタスク（システムサービス群１４１）が存在する。システムサービス群１４１の一部または全部はイベント処理クライエント１４５を生じさせ、イベント処理クライエント１４５は処理に応じてイベント要求を発行する。これらのイベント要求は、イベント通信処理タスク１４６などに登録されることになる。

イベント処理クライエント１４５は、処理に応じて通常イベント要求を発行し、スレーブ状態管理タスク１４４は、機能ユニット１５０との間の初期化処理の開始に係るイベント要求を発生し、このイベント要求は、通常イベント要求より優先度の高い高優先イベント要求に相当する。イベント処理クライエント１４５からの高優先イベント要求は、特定の機能ユニット１５０がローカルバス１１２（伝送路）を介してＣＰＵユニット１００との間で同期通信を確立するための指示を含むことになる。

本明細書において、「イベント要求」とは、何らかの条件または周期の到来によって内部イベントが発行され、その発行された内部イベントによって生成された各種処理（メッセージ通信によるデータ送信を含む）に係る要求を意味する。「通常」および「高優先」は、相対的な優先度の優劣を示す用語であり、「高優先」イベント要求は、「通常」イベント要求より優先して処理されることを意味する。この「通常」および「高優先」の呼称は便宜上のものであり、この用語を限定的に解釈すべきではない。

高優先イベントキュー管理タスク１３６は、スレーブ状態管理タスク１４４により発行される高優先イベント要求を優先的に処理するための優先度管理機能の少なくとも一部を提供する。具体的には、高優先イベントキュー管理タスク１３６は、高優先イベントのキュー１４９への送信要求の出力タイミングなどを制御するための高優先イベントキュー１３８を管理する。高優先イベントキュー１３８には、後述するように、スレーブ状態管理タスク１４４から高優先イベント要求が必要に応じて登録される。高優先イベントキュー管理タスク１３６とイベント通信処理タスク１４６との間の処理手順については後述する。

＜Ｅ．本実施の形態に従う初期化処理における処理手順＞
次に、本実施の形態に従う初期化処理における処理手順について説明する。

図８は、本実施の形態に従う初期化処理におけるモジュール間の遣り取りを説明する模式図である。図９は、本実施の形態に従う初期化処理における処理手順を示すシーケンス図である。なお、図８に示すカッコ内の番号と、図９に示すカッコ内の番号とは対応するものとなっている。

まず、ＣＰＵユニット１００が起動すると、あるいは、ローカルバス１１２上に新たな機能ユニット１５０が追加されると、スレーブ状態管理タスク１４４は、クロック設定処理を実行する。より具体的には、スレーブ状態管理タスク１４４は、機能ユニット１５０の各々に対して、オーディナリークロック１５３をマスタークロック１０９と同期させるように指示を与える。図９に示す各ステップは、クロックが同期された状態において実行される。

図８および図９を参照して、まず、スレーブ状態管理タスク１４４は、初期化処理要求を受けると（ステップＳ１）、高優先イベントキュー管理タスク１３６に高優先イベント要求を発行する（ステップＳ２）。すると、高優先イベントキュー管理タスク１３６では、発行された高優先イベント要求を高優先イベントキュー１３８にキューイングする（ステップＳ３）。つまり、高優先イベントキュー１３８に高優先イベント要求が登録される。そして、高優先イベントキュー管理タスク１３６は、高優先イベント要求が登録されていることをイベント通信処理タスク１４６（通常イベントのキュー１４８および高優先イベントのキュー１４９）へ通知する（ステップＳ４）。

イベント通信処理タスク１４６では、通常イベントのキュー１４８に登録されている通常イベント要求のうち送信処理中のものがあれば、その送信処理中の通常イベント要求の処理が継続される（ステップＳ５）。より具体的には、イベント通信処理タスク１４６は、キュー１４８に登録されている通常イベント要求のうち送信処理中のものをバスドライバ１１３へ出力する（ステップＳ５１）。バスドライバ１１３は、通常イベント要求に従ってバス通信回路１０８の通信を起動する（ステップＳ５２）。すると、バス通信回路１０８からローカルバス１１２上に、当該通常イベント要求に応じた通信フレームなどが送出される。登録されている通常イベント要求についての処理が完了すると、イベント通信処理タスク１４６は、キュー１４８に登録されている通常イベント要求を削除（デキューイング）する（ステップＳ５３）。

イベント通信処理タスク１４６は、高優先イベント要求が登録されていることの通知を受けたときに送信処理中の通常イベント要求が存在すれば、その送信処理中の通常イベント要求の処理が完了すると、高優先処理可能通知を高優先イベントキュー管理タスク１３６へ通知する（ステップＳ６）。このとき、イベント通信処理タスク１４６のキュー１４８に登録されているものの、未だ処理の対象になっていないものは、処理が一旦中段される。

また、高優先イベントのキュー１４９に何らかの高優先イベント要求が先に登録されている場合には、その先に登録されている高優先イベント要求の処理が完了した後に、高優先処理可能通知が高優先イベントキュー管理タスク１３６へ通知される。つまり、高優先処理可能通知は、後述するような、高優先イベント要求を優先的に処理できる状態であることを示す通知である。

その後、スケジューラ１２０は、高優先イベントキュー管理タスク１３６に対して、処理の開始を指示するトリガを周期的に発行する（ステップＳ７）。スケジューラ１２０は、ＩＯリフレッシュタスク１３０によるＩＯリフレッシュの実行を妨げないタイミングで、ステップＳ７のトリガを発行する。

高優先イベントキュー管理タスク１３６は、スケジューラ１２０からのトリガを受信したときに、高優先イベントに係るスレッド（優先度は通常より高く設定されている）が起動しており、かつ、イベント通信処理タスク１４６から高優先処理可能通知を受信していれば、高優先イベント開始をスレーブ状態管理タスク１４４へ通知する（ステップＳ８）。高優先イベントに係るスレッドは、現実的なリアルタイム性を保証できる程度に高い優先度が設定されているが、ＩＯリフレッシュの優先度よりは低くなっている。

上述のステップＳ４〜Ｓ８に示すように、高優先イベント要求の発行要求（ステップＳ２に示す高優先イベント要求）を受けると、現在処理中の通常イベント要求に対応する通信フレームの送出処理の完了を待って、高優先イベント要求の発行が許可（高優先処理可能通知が発行）される。このとき、現在処理中の通常イベント要求に引き続く後続の通常イベント要求に対する処理は、高優先イベント要求に対する処理が完了するまで中断される。

スレーブ状態管理タスク１４４へ通知される高優先イベント開始は、スレーブ状態管理タスク１４４からの高優先イベント要求（ステップＳ２）に対する肯定応答（コールバック）に相当し、高優先イベント開始によって、初期化処理に必要なタイミング（スタートタイム）などを決定する処理が開始される。より具体的には、スレーブ状態管理タスク１４４は、初期化処理の対象となる機能ユニット１５０に対して設定すべきスタートタイムをスケジューラ１２０に問い合わせる（ステップＳ９）。この問い合わせに応答して、スケジューラ１２０は、スタートタイムを算出してスレーブ状態管理タスク１４４へ応答する（ステップＳ１０）。このスタートタイムは、バス通信回路１０８のマスタークロック１０９と同期する、各機能ユニット１５０のオーディナリークロック１５３が管理する値が用いられる。

一例として、スケジューラ１２０が応答するスタートタイムとして、ＩＯリフレッシュの送出周期（システム周期）に関連付けられた値が用いられてもよい。具体的には、ＩＯリフレッシュの通信フレームの送信前に設定されるＴｉｃｋタイムが用いられてもよい。図１０は、本実施の形態に従うＰＬＣ１のスケジューラ１２０が応答するスタートタイムを説明するための模式図である。図１０を参照して、所定のシステム周期Ｔｓ毎にＩＯリフレッシュを行うための通信フレームが伝送される。各機能ユニット１５０は、予め定められた通信手順に従って、１または複数の通信フレームを用いて、予め収集していた入力データをマスターとして機能するＣＰＵユニット１００へ伝送するとともに、ＣＰＵユニット１００から送信される出力データを取得する。

Ｔｉｃｋタイムは、各機能ユニット１５０にＩＯリフレッシュを行うための通信フレームが到着する所定時間ΔＴｔだけ前に設定され、Ｔｉｃｋタイムにおいて、各機能ユニット１５０は入力データの収集を開始する。したがって、いずれかのＴｉｃｋタイムがスタートタイムとして指定されていれば、指定されたＴｉｃｋタイムの直後に到着する通信フレームに対する入力データの書込みなどを行うことができる。つまり、ＣＰＵユニット１００との間で同期通信を確立できる。

本実施の形態に従うＰＬＣ１においては、現時点から２つ先（あるいは、それより先）のＴｉｃｋタイムをスタートタイムとして設定するようにしてもよい。上述したように、スレーブ状態管理タスク１４４からスケジューラ１２０に対してスタートタイムの問い合わせ（ステップＳ９）がなされたタイミングにおいて、ＩＯリフレッシュ以外の中では最も高い優先度でスタートタイムを通知できる状態になっている。そのため、少なくとも２つ先のＴｉｃｋタイムまでの間に、スタートタイムを通知することが保証されるからである。

例えば、図１０（Ａ）に示すように、先行のＩＯリフレッシュ直後であって、後続のＩＯリフレッシュのＴｉｃｋタイムが到来する前に、スタートタイムの問い合わせを受けると、２つ先のＩＯリフレッシュにＴｉｃｋタイムであるＴｉｃｋ０２がスタートタイムとして設定される。

あるいは、図１０（Ｂ）に示すように、あるＩＯリフレッシュの直前に、スタートタイムの問い合わせを受けると、２つ先のＩＯリフレッシュにＴｉｃｋタイムであるＴｉｃｋ０３がスタートタイムとして設定される。

再度、図８および図９を参照して、スレーブ状態管理タスク１４４は、必要に応じてメッセージルーチングタスク１４２に、メッセージルーチング用ヘッダの作成を要求する（ステップＳ１１）。具体的には、上述の図５に示す第２の初期化手順のように、ＣＰＵユニット１００から機能ユニット１５０に対してメッセージフレームを送信する方法で初期化手順を実現する場合には、スレーブ状態管理タスク１４４は、メッセージフレームを初期化対象の機能ユニット１５０へ送信するための、メッセージルーチング用ヘッダの作成を要求する。メッセージルーチングタスク１４２は、初期化対象の機能ユニット１５０のローカルバス１１２，２１２および／またはフィールドネットワーク１１４上の位置に応じて、必要なヘッダを作成して、スレーブ状態管理タスク１４４へ応答する（ステップＳ１２）。上述したように、これらのステップＳ１１およびＳ１２の処理はオプションの処理である。

そして、スレーブ状態管理タスク１４４は、高優先イベント要求として送信すべきデータをイベント通信処理タスク１４６へ出力する（ステップＳ１３）。イベント通信処理タスク１４６では、スレーブ状態管理タスク１４４からのデータを、高優先イベントのキュー１４９にキューイングする（ステップＳ１４）。つまり、高優先イベント要求として送信すべきデータがイベント通信処理タスク１４６のキュー１４９に登録される。高優先イベント要求として送信すべきデータは、ステップＳ１０において取得されるスタートタイムを含む。なお、上述の第１の初期化手順と同様の初期化手順が採用される場合には、スタートタイムに加えて、レジスタ書込みフレームの生成に必要な情報が含まれる。一方、上述の第２の初期化手順と同様の初期化処理が採用される場合には、スタートタイムに加えて、メッセージフレームの生成に必要な情報が含まれる。

必要なデータがキュー１４９に登録された後、高優先イベントキュー管理タスク１３６は、イベント通信処理タスク１４６に対してイベント通信の開始を通知する（ステップＳ１５）。イベント通信の開始によって、イベント通信処理タスク１４６では、必要な電文（通信フレームまたはメッセージ）の生成、および、バス通信回路１０８に対する通信の起動が開始される。すなわち、イベント通信処理タスク１４６は、高優先イベントキュー管理タスク１３６からのイベント通信の開始の通知を受けて、イベントフレーム送信要求をバスドライバ１１３へ出力する（ステップＳ１６）。バスドライバ１１３は、イベントフレーム送信要求を受けてバス通信回路１０８の通信を起動する（ステップＳ１７）。すると、バス通信回路１０８からローカルバス１１２上に指定された通信フレーム（レジスタ書込みフレームまたはメッセージフレーム）が送出される（ステップＳ１８）。

なお、高優先イベント要求および通常イベント要求に応じた通信フレームは、ＩＯリフレッシュの通信フレームが伝送されていない期間において送出される。

イベント通信処理タスク１４６からバスドライバ１１３へのイベントフレーム送信要求の出力の後、高優先イベントキュー管理タスク１３６は、高優先イベントキュー１３８から高優先イベント要求をデキューイングする（ステップＳ１９）。つまり、高優先イベント要求が高優先イベントキュー１３８から削除される。併せて、イベント通信処理タスク１４６は、高優先イベントのキュー１４９から処理対象のデータをデキューイングする（ステップＳ２０）。つまり、初期化処理に必要なデータが高優先イベントのキュー１４９から削除される。

その後、第１の初期化手順と同様の初期化手順が採用される場合には、機能ユニット１５０において、図４を参照して説明したのと同様の処理が実行される（図８の（１１）および（１２）参照）。あるいは、第２の初期化手順と同様の初期化手順が採用される場合には、機能ユニット１５０において、図５を参照して説明したのと同様の処理が実行される（図８の（１１’）〜（１５’）参照）。

以上のような処理手順によって、ＣＰＵユニット１００と機能ユニット１５０との間に新たに同期通信を確立させる初期化処理は完了する。

ここで、高優先イベントキュー管理タスク１３６およびイベント通信処理タスク１４６における処理（図９に示すステップＳ４，Ｓ５，Ｓ１４，Ｓ１６など参照）についてより詳細に説明する。図１１は、本実施の形態に従うＰＬＣ１のイベント通信処理タスク１４６の通常イベントのキュー１４８および高優先イベントのキュー１４９における処理を説明するための模式図である。

図１１（Ａ）を参照して、例えば、通常イベント要求ＡおよびＢがキュー１４８に登録されており、通常イベント要求Ａが送信処理中であるときに、高優先イベントキュー管理タスク１３６が高優先イベント要求の登録通知を行った場合を想定する。このとき、高優先イベントキュー管理タスク１３６は、スレーブ状態管理タスク１４４から高優先イベント要求の発行要求（図８のステップＳ２に示す高優先イベント要求）を受けると、イベント通信処理タスク１４６において現在処理中の通常イベント要求に対応する通信フレームの送出処理の完了を待って、スレーブ状態管理タスク１４４に対して高優先イベント要求の発行を許可する（図８のステップＳ６に示す高優先処理可能通知の発行）。

具体的には、高優先イベントキュー管理タスク１３６は、スレーブ状態管理タスク１４４から高優先イベント要求の発行要求（図８のステップＳ２に示す高優先イベント要求）を受けると、その高優先イベント要求の発行要求をイベント通信処理タスク１４６へ通知する。すると、イベント通信処理タスク１４６は、通常イベント要求Ａに対して実行されている送信処理を継続する。そして、図１１（Ｂ）に示すように、先に実行されていた通常イベント要求Ａに対する送信処理が完了すると、通常イベント要求Ａをキュー１４８から削除する一方で、次にキュー１４８に登録されていた通常イベント要求Ｂに対する送信処理の実行は一旦停止される。そして、イベント通信処理タスク１４６は、高優先イベント要求の発行要求を通知された後、現在処理中の通常イベント要求についての処理が完了すると、高優先イベント要求が処理可能である旨である高優先処理可能通知を高優先イベントキュー管理タスク１３６へ通知する。

すると、図１１（Ｃ）に示すように、高優先イベント要求に対応するデータがキュー１４９に登録される。そして、イベント通信の開始の通知を受けて、キュー１４９に登録されているデータがバスドライバ１１３へ出力される。

なお、図１１（Ｂ）に示すように、キュー１４８に登録されている通常イベント要求に対する処理の実行が一旦停止されている状態であっても、新たな通常イベント要求は受け付けるようになっている。つまり、新たに通常イベント要求が発行されると、その通常イベント要求はキュー１４８に追加して登録されることになる。これらの通常イベント要求については、高優先イベント要求に対する処理が完了した後、順次実行されることになる。

このように、イベント通信処理タスク１４６は、現在処理中の通常イベント要求に引き続く後続の通常イベント要求に対する処理を、高優先イベント要求に対する処理の完了まで中断する。すなわち、キュー１４８に先に登録されている通常イベント要求のうち処理中のものだけが処理された後に、その後の通常イベント要求の処理は中断された状態で、高優先処理可能が通知される。このような処理を採用することで、要求されている高優先イベント要求に対応する通信フレームを最優先で送信できるような状態になった上で、キュー１４９には対応する必要なデータが登録される。

図１１に示すように、通常イベント要求と高優先イベント要求との調停処理を採用することで、例えば、初期化処理などに用いられる通信フレームの到着時刻を保証することができる。

図７および図１１においては、通常イベントのキュー１４８および高優先イベントのキュー１４９がそれぞれ独立に配置される例を示すが、必ずしも独立に２つ配置する必要はなく、図１１に示すような処理方法に従って、通常イベント要求に比較して、高優先イベント要求を優先的に処理する構成であれば、どのような実装形態であってもよい。

＜Ｆ．変形例＞
上述の実施の形態においては、典型例として、ＣＰＵユニット１００とローカルバス１１２を介して接続される機能ユニット１５０との間の初期化処理に適用した場合について例示したが、これに限らず、本実施の形態に従う通信手順は任意の処理に適用可能である。同様の初期化処理については、例えば、通信カプラユニット２００とローカルバス２１２を介して接続される機能ユニット２５０との間の初期化処理に適用してもよいし、ＣＰＵユニット１００とフィールドネットワーク１１４を介して接続される任意のデバイス（通信カプラユニット２００を含み得る）との間の初期化処理に適用してもよい。

さらに、ＣＰＵユニット１００と特定の１または複数の機能ユニット１５０との間、通信カプラユニット２００と特定の１または複数の機能ユニット２５０との間、複数の機能ユニット１５０の間、あるいは、複数の機能ユニット２５０の間で、メッセージ通信によってデータを遣り取りすることで実現される、任意の処理手続きに適用可能である。

＜Ｇ．利点＞
上述したような関連技術に従う初期化処理においては、メッセージ通信は、低優先度のスケジューリングに従ってタイミングが決定されるので、他のメッセージ通信を要求するイベントが発生した場合には、いずれのタイミングで要求した通信フレームを送出できるのかを予測することが難しい。

これに対して、本実施の形態に従うＰＬＣ１の初期化処理においては、初期化処理に係る通信フレームの送出を高優先イベント要求とすることができ、他のイベント処理クライエントが発生する通常イベント要求よりも優先的に処理が可能になっている。

また、先に発行された通常イベント要求が処理中である場合に、高優先イベント要求を発行すると、先に処理中の通常イベント要求の処理完了を待つ必要があるが、本実施の形態においては、先に処理中の通常イベント要求の処理が完了した後に、高優先イベント要求自体を発行するように制御する。このような制御方法を採用することで、通常イベント要求と高優先イベント要求との競合、つまり、通常イベント要求が完了しなければ、高優先イベント要求を処理できないといった事態を回避して、優先度に応じたイベント要求の処理を確実に行うことができる。

上述したような関連技術に従う制御方法を採用すると、各イベント要求についての処理時間が保障されないため、時間制約を守るためには、余裕を持った最悪到達時間を想定して通信処理を実行する必要があったが、本実施の形態によれば、高優先イベントに係る通信処理については、到達時間を保証できるので、最悪到達時間などの想定は必要ない。

また、上述したような関連技術に従う制御方法を採用すると、イベント要求の発行後、現実に通信フレームが送信先に到達するまでの最悪到達時間の想定が困難であり、安全サイドに最悪到達時間を想定すると、システム全体の処理遅延につながる可能性がある。これに対して、本実施の形態によれば、到達時間を保証できるので、必要な処理時間などの見積もりが容易になるとともに、その処理時間そのものを短縮化できるので、処理の起動時間などが短縮されて、ユーザビリティを向上させることもできる。

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

１ ＰＬＣ、１００ ＣＰＵユニット、１０２，２０２ プロセッサ、１０４，２０４ メインメモリ、１０６，２０６ ストレージ、１０８，１５２，２０８，２５２ バス通信回路、１０９ マスタークロック、１１０，２１０ ネットワークインターフェイス、１１２，２１２ ローカルバス、１１３，１６６ バスドライバ、１１４ フィールドネットワーク、１１５ フィールドネットワークドライバ、１２０ スケジューラ、１３０ リフレッシュタスク、１３６ 高優先イベントキュー管理タスク、１３８ 高優先イベントキュー、１４０ システムサービスタスク、１４１ システムサービス群、１４２，１６２ メッセージルーチングタスク、１４４ スレーブ状態管理タスク、１４５ イベント処理クライエント、１４６ イベント通信処理タスク、１４８，１４９ キュー、１５０，２５０ 機能ユニット、１５３ オーディナリークロック、１５４，２５４ 通信コントローラ、１５６，２５６ 機能モジュール、１６４ 状態管理タスク、２００ 通信カプラユニット、２０１ コントローラ、ＦＬ 通信フレーム、ＭＳＧＦＬ メッセージフレーム、Ｔｓ システム周期。

Claims (7)

1. 制御装置を構成する演算装置であって、
   伝送路を介して１または複数の機能ユニットとの間でデータを遣り取りするための通信インターフェイスと、
   前記伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、
   前記第１の通信フレームが伝送されていない期間において、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、
   処理に応じて第１のイベント要求を発行する第１のイベント発行手段と、
   前記第１のイベント要求より優先度の高い第２のイベント要求を発行する第２のイベント発行手段と、
   前記第２のイベント発行手段により発行される前記第２のイベント要求を優先的に処理するための優先度管理手段とを備え、
   前記優先度管理手段は、前記第２のイベント発行手段から前記第２のイベント要求の発行要求を受けると、前記第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、前記第２のイベント発行手段に対して前記第２のイベント要求の発行を許可し、
   前記第２の伝送制御手段は、前記現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、前記第２のイベント要求に対する処理の完了まで中断し、
   前記第２のイベント要求は、特定の機能ユニットが前記伝送路を介して前記演算装置との間で同期通信を確立するための指示を含み、
   前記伝送路を介して接続される前記演算装置および前記１または複数の機能ユニットの各々は、互いに同期したクロックを有しており、
   前記同期通信を確立するための指示は、前記互いに同期したクロックが示すタイミングを含み、
   前記タイミングは、前記第１の通信フレームの送出周期に関連付けられた値に設定される、演算装置。
2. 前記第２の伝送制御手段は、
   前記第１のイベント要求を順次格納する第１のキューと、
   前記第２のイベント要求を順次格納する第２のキューとを含む、請求項１に記載の演算装置。
3. 前記優先度管理手段は、前記第２のイベント要求の発行要求を受けると、当該発行要求を前記第２の伝送制御手段へ通知し、
   前記第２の伝送制御手段は、前記第２のイベント要求の発行要求を通知された後、前記現在処理中の第１のイベント要求についての処理が完了すると、前記第２のイベント要求が処理可能である旨を前記優先度管理手段へ通知する、請求項２に記載の演算装置。
4. 制御装置であって、
   演算装置と、
   前記演算装置と伝送路を介してデータを遣り取り可能に接続された１または複数の機能ユニットとを備え、
   前記演算装置は、
   前記伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、
   前記第１の通信フレームが伝送されていない期間において、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、
   処理に応じて第１のイベント要求を発行する第１のイベント発行手段と、
   前記第１のイベント要求より優先度の高い第２のイベント要求を発行する第２のイベント発行手段と、
   前記第２のイベント発行手段により発行される前記第２のイベント要求を優先的に処理するための優先度管理手段とを備え、
   前記優先度管理手段は、前記第２のイベント発行手段から前記第２のイベント要求の発行要求を受けると、前記第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、前記第２のイベント発行手段に対して前記第２のイベント要求の発行を許可し、
   前記第２の伝送制御手段は、前記現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、前記第２のイベント要求に対する処理の完了まで中断し、
   前記第２のイベント要求は、特定の機能ユニットが前記伝送路を介して前記演算装置との間で同期通信を確立するための指示を含み、
   前記伝送路を介して接続される前記演算装置および前記１または複数の機能ユニットの各々は、互いに同期したクロックを有しており、
   前記同期通信を確立するための指示は、前記互いに同期したクロックが示すタイミングを含み、
   前記タイミングは、前記第１の通信フレームの送出周期に関連付けられた値に設定される、制御装置。
5. 前記第２の伝送制御手段は、
   前記第１のイベント要求を順次格納する第１のキューと、
   前記第２のイベント要求を順次格納する第２のキューとを含む、請求項４に記載の制御装置。
6. 演算装置と、前記演算装置と伝送路を介してデータを遣り取り可能に接続された１または複数の機能ユニットとを備えた制御装置における制御方法であって、
   前記伝送路を介して所定周期毎に第１の通信フレームを送出するステップと、
   処理に応じて第１のイベント要求を発行するステップと、
   前記第１のイベント要求より優先度の高い第２のイベント要求を発行するステップと、
   前記第１の通信フレームが伝送されていない期間において、前記第１のイベント要求または前記第２のイベント要求に応答して、第２の通信フレームを送出するステップと、
   前記第２のイベント要求の発行要求を受けると、現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、前記第２のイベント要求の発行を許可するステップと、
   前記現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、前記第２のイベント要求に対する処理の完了まで中断するステップとを備え、
   前記第２のイベント要求は、特定の機能ユニットが前記伝送路を介して前記演算装置との間で同期通信を確立するための指示を含み、
   前記伝送路を介して接続される前記演算装置および前記１または複数の機能ユニットの各々は、互いに同期したクロックを有しており、
   前記同期通信を確立するための指示は、前記互いに同期したクロックが示すタイミングを含み、
   前記タイミングは、前記第１の通信フレームの送出周期に関連付けられた値に設定される、制御方法。
7. 前記第２の通信フレームを送出するステップは、
   前記第１のイベント要求を第１のキューに順次格納するステップと、
   前記第２のイベント要求を第２のキューに順次格納するステップとを含む、請求項６に記載の制御方法。

Images