(57)【要約】【課題】製造装置または生産設備の制御に用いる制御装置を含むネットワークに適したデータ伝送を実現するための構成が要望されている。【解決手段】予め定められた周期毎にデータが更新されるネットワークに接続される通信装置が提供される。通信装置は、製造装置または生産設備の制御に用いる第１のデータを予め定められた周期毎に更新するのに必要な第１の通信帯域を確保する第１のスケジューリング手段と、ネットワークが有する通信帯域のうち第１の通信帯域以外の通信帯域内に、第２のデータを指定された時間内に送信先へ到着させるのに必要な第２の通信帯域を確保する第２のスケジューリング手段と、ネットワークが有する通信帯域のうち第１の通信帯域および第２の通信帯域のいずれにも設定されていない通信帯域内に、第３のデータを伝送するための第３の通信帯域を確保する第３のスケジューリング手段とを含む。【選択図】図５
2018064245.tif 000002
【特許請求の範囲】
【請求項１】
予め定められた周期毎にデータが更新されるネットワークに接続される通信装置であって、
製造装置または生産設備の制御に用いる第１のデータを前記予め定められた周期毎に更新するのに必要な第１の通信帯域を確保する第１のスケジューリング手段と、
前記ネットワークが有する通信帯域のうち前記第１の通信帯域以外の通信帯域内に、第２のデータを指定された時間内に送信先へ到着させるのに必要な第２の通信帯域を確保する第２のスケジューリング手段と、
前記ネットワークが有する通信帯域のうち前記第１の通信帯域および前記第２の通信帯域のいずれにも設定されていない通信帯域内に、第３のデータを伝送するための第３の通信帯域を確保する第３のスケジューリング手段とを備える、通信装置。
【請求項２】
前記第２のスケジューリング手段は、前記第２のデータを、各周期において利用可能な通信帯域に応じたデータサイズに分割した上で、分割後のそれぞれのデータを複数の周期に割り当てる、請求項１に記載の通信装置。
【請求項３】
前記第２のスケジューリング手段は、前記送信先にて受信可能なデータサイズに応じて、前記第２のデータを分割した上で、分割後のそれぞれのデータを複数の周期に割り当てる、請求項１に記載の通信装置。
【請求項４】
前記第２のスケジューリング手段は、前記第２のデータを分割した上で、分割後のそれぞれのデータを、前記送信先での受信データの処理状況に応じて、前記予め定められた周期より長い周期で順次送信する、請求項１に記載の通信装置。
【請求項５】
前記第２のスケジューリング手段は、前記予め定められた周期において、前記第２のデータまたは前記第３のデータを複数回送信する、請求項１に記載の通信装置。
【請求項６】
前記第２のスケジューリング手段は、前記送信先での受信エラーの回数、および、前記送信先から受信応答を受信できなかった回数、の少なくとも一方に基づいて、前記送信先での受信データの処理状況を判断する、請求項５に記載の通信装置。
【請求項７】
前記第２のスケジューリング手段は、前記第２のデータの分割により、前記第２のデータを前記指定された時間内に送信先へ到着させることができない場合に、異常通知を行う、請求項２〜６のいずれか１項に記載の通信装置。
【請求項８】
前記第２のスケジューリング手段は、前記ネットワークの通信状況に応じて、前記第２のデータを分割して送信する単位サイズを変化させる、請求項１に記載の通信装置。
【請求項９】
前記第２のスケジューリング手段は、前記送信先からの受信応答のうち破損していたものの数、および、受信データの破損を示す前記送信先からの通知の数、の少なくとも一方に基づいて、前記ネットワークの通信状況を判断する、請求項８に記載の通信装置。
【請求項１０】
前記第３のスケジューリング手段は、単位サイズを変化させることが指定されている場合に、前記ネットワークの通信状況に応じて、前記第３のデータを分割して送信する単位サイズを変化させる、請求項８または９に記載の通信装置。
【請求項１１】
製造装置または生産設備を制御する制御装置であって、
予め定められた周期毎にデータが更新されるネットワークに接続される通信インターフェイスと、
前記製造装置または生産設備の制御に用いる第１のデータを前記予め定められた周期毎に更新するのに必要な第１の通信帯域を確保する第１のスケジューリング手段と、
前記ネットワークが有する通信帯域のうち前記第１の通信帯域以外の通信帯域内に、第２のデータを指定された時間内に送信先へ到着させるのに必要な第２の通信帯域を確保する第２のスケジューリング手段と、
前記ネットワークが有する通信帯域のうち前記第１の通信帯域および前記第２の通信帯域のいずれにも設定されていない通信帯域内に、第３のデータを伝送するための第３の通信帯域を確保する第３のスケジューリング手段とを備える、制御装置。
【請求項１２】
予め定められた周期毎にデータが更新されるネットワークでの通信方法であって、
製造装置または生産設備の制御に用いる第１のデータを前記予め定められた周期毎に更新するのに必要な第１の通信帯域を確保するステップと、
前記ネットワークが有する通信帯域のうち前記第１の通信帯域以外の通信帯域内に、第２のデータを指定された時間内に送信先へ到着させるのに必要な第２の通信帯域を確保するステップと、
前記ネットワークが有する通信帯域のうち前記第１の通信帯域および前記第２の通信帯域のいずれにも設定されていない通信帯域内に、第３のデータを伝送するための第３の通信帯域を確保するステップとを備える、通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、予め定められた周期毎にデータが更新されるネットワークに接続される通信装置、当該通信装置を含む制御装置、および、通信方法に関する。
【背景技術】
【０００２】
近年の情報通信技術（ＩＣＴ：Information and Communication Technology）の進歩に伴って、生産ラインについても、現場の製造機器から上位の管理装置までを一体のネットワーク化するようなシステムが実現されつつある。
【０００３】
このようなネットワーク化されたシステムにおいて伝送されるデータには、その用途、目的などに応じた要件が課される。例えば、製造装置や生産設備などの制御に用いるデータ（制御系データ）は、そのデータサイズはそれほど大きくないものの、リアルタイム性が要求される。これに対して、上位の管理装置などが扱うデータ（情報系データ）は、リアルタイム性などは必要ないものの、比較的大きいサイズのデータを伝送しなければならない。これらの互いに相反する要件を同一のネットワーク上で満足させることは容易ではない。すなわち、制御機器の情報化を実現するためには、制御系通信と情報系通信とを融合することが重要である。
【０００４】
例えば、非特許文献１は、情報系通信と制御系通信との間の連携アーキテクチャを提案している。具体的には、非特許文献１は、制御系通信の周期に対して、情報系通信のパケットが大きく、送信が許可されない場合は、所定連続回数の失敗後に情報系通信のパケットを破棄してＣＰＵへ割り込みを通知し、この通知に基づいて、ユーザが上位層でのフラグメンテーションの適用を可能にする構成を開示する。
【０００５】
また、特開２００４−３６３７８２号公報（特許文献１）は、制御系通信のリアルタイム性を担保しつつ、情報系通信のスループットを向上させる構成を開示する。特許文献１は、情報系通信のサイズはできるだけ大きくするが、制御系通信の頻度が高い場合などには、フレームを小さくすることを開示する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−３６３７８２号公報
【非特許文献】
【０００７】
【非特許文献１】丸山龍也、山田勉、「リアルタイムＥｔｈｅｒｎｅｔ向け情報系・制御系通信の連携アーキテクチャの開発」、電子情報通信学会論文誌Ｂ  Ｖｏｌ．Ｊ９６−Ｂ，Ｎｏ．１０，ｐｐ．１１１４−１１２１，２０１３年１０月１日
【発明の概要】
【発明が解決しようとする課題】
【０００８】
例えば、製造装置または生産設備を制御する制御装置（典型的には、ＰＬＣ（Programmable Logic Controller））の情報化および高機能化に伴って、制御装置は、制御系データに加えて、情報系データに分類され得るデータを遣り取りする場合も多い。このような制御装置が利用する情報系データは、一般的な情報系データのようなベストエフォート形式ではなく、データの到着時間を保証しなければならない場合がある。上述の先行技術は、このような課題に対して何ら解決手段を提供するものではない。
【０００９】
すなわち、製造装置または生産設備の制御に用いる制御装置を含むネットワークに適したデータ伝送を実現するための構成が要望されている。
【課題を解決するための手段】
【００１０】
本発明のある実施の形態に従えば、予め定められた周期毎にデータが更新されるネットワークに接続される通信装置が提供される。通信装置は、製造装置または生産設備の制御に用いる第１のデータを予め定められた周期毎に更新するのに必要な第１の通信帯域を確保する第１のスケジューリング手段と、ネットワークが有する通信帯域のうち第１の通信帯域以外の通信帯域内に、第２のデータを指定された時間内に送信先へ到着させるのに必要な第２の通信帯域を確保する第２のスケジューリング手段と、ネットワークが有する通信帯域のうち第１の通信帯域および第２の通信帯域のいずれにも設定されていない通信帯域内に、第３のデータを伝送するための第３の通信帯域を確保する第３のスケジューリング手段とを含む。
【００１１】
好ましくは、第２のスケジューリング手段は、第２のデータを、各周期において利用可能な通信帯域に応じたデータサイズに分割した上で、分割後のそれぞれのデータを複数の周期に割り当てる。
【００１２】
好ましくは、第２のスケジューリング手段は、送信先にて受信可能なデータサイズに応じて、第２のデータを分割した上で、分割後のそれぞれのデータを複数の周期に割り当てる。
【００１３】
好ましくは、第２のスケジューリング手段は、第２のデータを分割した上で、分割後のそれぞれのデータを、送信先での受信データの処理状況に応じて、予め定められた周期より長い周期で順次送信する。
【００１４】
好ましくは、第２のスケジューリング手段は、予め定められた周期において、第２のデータまたは第３のデータを複数回送信する。
【００１５】
好ましくは、第２のスケジューリング手段は、送信先での受信エラーの回数、および、送信先から受信応答を受信できなかった回数、の少なくとも一方に基づいて、送信先での受信データの処理状況を判断する。
【００１６】
好ましくは、第２のスケジューリング手段は、第２のデータの分割により、第２のデータを指定された時間内に送信先へ到着させることができない場合に、異常通知を行う。
【００１７】
好ましくは、第２のスケジューリング手段は、ネットワークの通信状況に応じて、第２のデータを分割して送信する単位サイズを変化させる。
【００１８】
好ましくは、第２のスケジューリング手段は、送信先からの受信応答のうち破損していたものの数、および、受信データの破損を示す送信先からの通知の数、の少なくとも一方に基づいて、ネットワークの通信状況を判断する。
【００１９】
好ましくは、第３のスケジューリング手段は、単位サイズを変化させることが指定されている場合に、ネットワークの通信状況に応じて、第３のデータを分割して送信する単位サイズを変化させる。
【００２０】
本発明の別の実施の形態に従えば、製造装置または生産設備を制御する制御装置が提供される。制御装置は、予め定められた周期毎にデータが更新されるネットワークに接続される通信インターフェイスと、製造装置または生産設備の制御に用いる第１のデータを予め定められた周期毎に更新するのに必要な第１の通信帯域を確保する第１のスケジューリング手段と、ネットワークが有する通信帯域のうち第１の通信帯域以外の通信帯域内に、第２のデータを指定された時間内に送信先へ到着させるのに必要な第２の通信帯域を確保する第２のスケジューリング手段と、ネットワークが有する通信帯域のうち第１の通信帯域および第２の通信帯域のいずれにも設定されていない通信帯域内に、第３のデータを伝送するための第３の通信帯域を確保する第３のスケジューリング手段とを含む。
【００２１】
本発明のさらに別の実施の形態に従えば、予め定められた周期毎にデータが更新されるネットワークでの通信方法が提供される。通信方法は、製造装置または生産設備の制御に用いる第１のデータを予め定められた周期毎に更新するのに必要な第１の通信帯域を確保するステップと、ネットワークが有する通信帯域のうち第１の通信帯域以外の通信帯域内に、第２のデータを指定された時間内に送信先へ到着させるのに必要な第２の通信帯域を確保するステップと、ネットワークが有する通信帯域のうち第１の通信帯域および第２の通信帯域のいずれにも設定されていない通信帯域内に、第３のデータを伝送するための第３の通信帯域を確保するステップとを含む。
【発明の効果】
【００２２】
本発明のある実施の形態によれば、製造装置または生産設備の制御に用いる制御装置を含むネットワークに適したデータ伝送を実現できる。
【図面の簡単な説明】
【００２３】
【図１】本実施の形態に従うネットワーク化システムの全体構成の一例を示す模式図である。
【図２】図１のネットワーク化システムにおいて伝送されるデータ種別を示す図である。
【図３】本実施の形態に従う通信装置を含む制御装置のハードウェア構成の一例を示す模式図である。
【図４】本実施の形態に従う通信処理を実現するための制御装置のソフトウェア構成の一例を示す模式図である。
【図５】本実施の形態に従う通信処理の通信時間管理モードの処理を説明するための模式図である。
【図６】本実施の形態に従う通信処理の通信時間管理モードの処理手順を示すフローチャートである。
【図７】本実施の形態に従う通信処理のデバイス管理モード（その１）の処理を説明するための模式図である。
【図８】本実施の形態に従う通信処理のデバイス管理モード（その１）の処理手順（初期起動時）を示すフローチャートである。
【図９】本実施の形態に従う通信処理のデバイス管理モード（その１）の処理手順（通信処理の実行中）を示すフローチャートである。
【図１０】本実施の形態に従う通信処理のデバイス管理モード（その２）の処理を説明するための模式図である。
【図１１】本実施の形態に従う通信処理のデバイス管理モード（その２）の処理手順（初期起動時）を示すフローチャートである。
【図１２】本実施の形態に従う通信処理の通信状況管理モードの処理を説明するための模式図である。
【図１３】本実施の形態に従う通信処理の通信状況管理モードの処理手順を示すフローチャートである。
【図１４】本実施の形態に従う通信処理の応用例１を説明するための模式図である。
【図１５】本実施の形態に従う通信処理の応用例２を説明するための模式図である。
【図１６】本実施の形態に従う通信処理の応用例３を説明するための模式図である。
【発明を実施するための形態】
【００２４】
本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。
【００２５】
＜Ａ．ネットワーク化システム全体構成＞
まず、本実施の形態に従う通信処理を採用したネットワーク化システムの全体構成について説明する。図１は、本実施の形態に従うネットワーク化システム１の全体構成の一例を示す模式図である。
【００２６】
図１を参照して、ネットワーク化システム１では、ネットワークが複数レベルに接続されており、各レベルのネットワークには、それぞれ異なる機能が割り当てられる。具体的には、４つのレベルのネットワーク１１〜１４が設けられている。
【００２７】
ネットワーク１１は、コントロールレベルのネットワークであり、マシン制御機器である制御装置１００と、装置／ライン管理機器である装置／ライン管理装置１９０およびＳＣＡＤＡ（Supervisory Control And Data Acquisition）機能を提供する表示装置１８０とが接続されており、装置間でデータを交換できるリンクが形成される。ネットワーク１１は、コントローラ（制御装置１００）と管理機器（装置／ライン管理装置１９０および表示装置１８０）との間でデータリンクを構築する。
【００２８】
制御装置１００には、センサ、アクチュエータといった各種デバイスが接続される。これらのデバイスは、制御装置１００に装着される入出力ユニットを介して直接接続される場合もあるが、フィールドネットワークを介して接続されることもある。図１に示す構成例においては、制御装置１００には、フィールドネットワーク１１０および１２０が接続されており、それぞれのフィールドネットワークには、デバイス群１１２および１２２が接続される。デバイス群は、フィールド信号を取得する入力デバイス、および、制御装置１００からの指示に従ってフィールドに対して何らかのアクションを行う出力デバイスあるいはアクチュエータを含む。したがって、図１に示すネットワーク化システム１には、ネットワーク１１〜１４の４つのレベルに加えて、フィールドレベルのフィールドネットワークがさらに追加されることになる。フィールドレベルは、入力およびデバイス制御を主たる機能として提供する。
【００２９】
ネットワーク１２は、管理レベルのネットワークであり、装置／ライン管理装置１９０および表示装置１８０と、製造管理装置２００およびデータベース装置２１０とが接続されており、装置間でデータを交換できるリンクが形成される。ネットワーク１２は、管理情報の遣り取りおよび装置／ラインの情報の伝送を主たる機能として提供する。
【００３０】
ネットワーク１３は、コンピュータレベルのネットワークであり、製造管理装置２００およびデータベース装置２１０と生産計画などを管理する生産管理装置３００とが接続されており、装置間でデータを交換できるリンクが形成される。ネットワーク１３は、生産管理および情報系のデータの伝送を主たる機能として提供する。
【００３１】
ネットワーク１４は、インターネットなどの外部ネットワークであり、生産管理装置３００とクラウドやサプライチェーンなどとが接続される。
【００３２】
図１に示すネットワーク化システム１において、ネットワーク１２およびそれ以下のレベルは、「ファクトリーネットワーク」とも称され、機器を現実に制御するためのデータ（以下、「制御系データ」と総称することもある）を遣り取りする制御系通信を提供する。一方、ネットワーク１３以上のレベルは、「コーポレートネットワーク」とも称され、生産ライン／工場での生産活動などを監視・管理・制御するためのデータ（以下、「情報系データ」と総称することもある）を遣り取りする情報系通信を提供する。
【００３３】
ネットワーク１１〜１４およびフィールドネットワーク１１０，１２０には、このような要求される特性の違いに応じたプロトコルおよびフレームワークが採用される。例えば、ファクトリーネットワークに属するネットワーク１１および１２ならびにフィールドネットワーク１２０のプロトコルとしては、汎用的なＥｔｈｅｒｎｅｔ（登録商標）上に制御用プロトコルを実装した産業用オープンネットワークであるＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）を用いてもよい。また、フィールドネットワーク１１０としては、マシンコントロール用ネットワークの一例であるＥｔｈｅｒＣＡＴ（登録商標）を採用してもよい。
【００３４】
このようなマシンコントロールに適したネットワーク技術を採用することで、機器間の伝送に要する時間が保証されたリアルタイム性を提供できる。但し、１回の通信周期で伝送可能なデータ量には制限がある。
【００３５】
一方、コーポレートネットワークに属するネットワーク１３および１４のプロトコルとしては、接続先の多様性を担保するために、汎用的なＥｔｈｅｒｎｅｔなどが用いられる。汎用的なＥｔｈｅｒｎｅｔを採用することで、リアルタイム性は実現できないものの、送信可能なデータ量などの制限は存在しない。
【００３６】
＜Ｂ．要求される通信性能＞
図１に示すファクトリーネットワークにおいては、基本的には、上述したような制御系データが周期的に伝送されることになるが、コーポレートネットワークに含まれる製造管理装置２００、データベース装置２１０、生産管理装置３００などが要求する情報系データも伝送する必要がある。なお、以下の説明においては、ファクトリーネットワークとの対比において、コーポレートネットワークに含まれる装置の全部または一部を「上位管理システム」とも総称する。
【００３７】
さらに、制御系データのような高速なリアルタイム性は要求されないものの、ある程度の到着時刻の保証が必要なデータ（例えば、機器の設定および管理に関するデータ）も存在する。以下では、説明の便宜上、このようなデータを「制御情報系データ」とも称す。
【００３８】
図２は、図１のネットワーク化システム１において伝送されるデータ種別を示す図である。図２を参照して、ネットワーク化システム１においては、主として、（１）制御系データ、（２）制御情報系データ、（３）情報系データ、が伝送される。なお、これらのいずれにも分類されないデータが伝送されることを排除するものではなく、さらに別の種類のデータを伝送するようにしてもよい。
【００３９】
（１）制御系データは、その主旨として、機器を現実に制御するためのデータを含む。すなわち、制御系データは、製造装置または生産設備の制御に用いるデータに相当する。制御系データの一例としては、サーボ指令値、エンコーダ値、センサのＯＮ／ＯＦＦ値などが挙げられる。このような制御系データの通信周期は１０ｍｓｅｃ以下に設定されることが好ましい。そして、この通信周期を確実に保証する必要がある。一方で、ネットワーク上で伝送される制御系データの内容は予め設定されているため、データサイズとしては、固定的で比較的小さい。
【００４０】
（２）制御情報系データは、情報系通信において用いられるデータのうち、制御に必要な情報に分類されるものであり、その主旨として、機器の設定・管理に関するデータを含む。すなわち、制御情報系データは、指定された時間内に送信先へ到着させるのに必要なデータに相当する。制御情報系データの一例としては、センサデバイスに対するしきい値といった各種パラメータの設定、各機器に格納されている異常情報（ログ）の収集、各機器に対する更新用のファームウェアなどが挙げられる。このようなネットワーク上で伝送される制御情報系データの内容は多種多様であるが、基本的には、機器の設定・管理に関するデータであるので、データサイズとしては、数ｋｂｙｔｅ程度が想定される。そのため、制御情報系データの通信周期は１００ｍｓｅｃ未満に設定されることが好ましい。通信周期は比較的長くてもよいが、データの到達時間は保証される必要がある。なお、到着時間の指定は、ユーザが任意に行ってもよいし、データを生成または要求するアプリケーションもしくは装置が予め定められたルールに従って行ってもよい。
【００４１】
（３）情報系データは、情報系通信において用いられるデータのうち、上位管理システムに必要な情報に分類されるものであり、その主旨として、上位管理システムで利用されるデータを含む。情報系データの一例としては、ある期間に亘るセンサでの収集情報といった統計的データや、何らかの条件で撮像された監視画像（静止画像／動画像）などが挙げられる。このようなネットワーク上で伝送される制御系データの内容は多種多様であり、データサイズとしても多種多様である。典型的には、情報系データのデータサイズは、制御情報系データのデータサイズより大きいことが想定される。また、機器の制御には直接関係しないので、情報系データはベストエフォート形式で伝送されることが想定される。この場合、リアルタイム性（すなわち、指定された時間にデータが到着すること）ではなく、スループットの大きさが重視される。
【００４２】
なお、データ毎に、制御系、制御情報系、情報系のいずれに分類されるのかを一意に決定するようにしてもよいし、同じデータであっても、その用途に応じて、制御系、制御情報系、情報系のいずれに分類されるのかが変化するようにしてもよい。後者の場合には、典型的には、各データが対象となるレイヤでどのように使われるかによって、いずれの種別に分類されるのかが決定されることになる。このような分類は、データ毎に予め設定されていてもよい。
【００４３】
このように、制御系データについては高速高精度の通信が要求され、情報系データについては大容量の通信が要求される。そして、制御情報系データについては、制御系データと情報系データとの間の中間的な特性が要求される。
【００４４】
本実施の形態に従う通信処理は、これらの互いに異なる３種類の要件をそれぞれ満たしつつデータ伝送を行うための構成および処理を提供する。すなわち、本実施の形態に従う通信処理は、要求される特性の異なる３種類のデータを単一ネットワーク上で統合した通信を実現する。
【００４５】
より具体的には、予め定められたシステム周期を維持しつつ、３種類のデータを適宜パケットに格納するという動的スケジューリングの機能を提供する。
【００４６】
＜Ｃ．ハードウェア構成＞
本実施の形態に従う通信装置は、予め定められた周期毎にデータが更新されるネットワークに接続される。その上で、本実施の形態に従う通信装置は、制御系データ、制御情報系データ、情報系データのそれぞれを適切にスケジューリングする。本実施の形態に従う通信装置は、これらの３種類のデータが伝送される経路上に配置されるものであれば、特に、その実装形態については限定されるものではない。
【００４７】
以下では、ネットワーク１１に接続される制御装置１００の通信機能の一部として実装された場合を想定して説明する。但し、制御装置１００に限定されることなく、例えば、ネットワーク１１に接続される装置／ライン管理装置１９０または表示装置１８０に係る通信機能の一部として実装してもよいし、フィールド上の各種機器をネットワーク化するためのリモート入出力装置に係る通信機能の一部として実装してもよい。
【００４８】
図３は、本実施の形態に従う通信装置を含む制御装置１００のハードウェア構成の一例を示す模式図である。制御装置１００は、典型的には、ＰＬＣをベースとして構成されてもよい。図３を参照して、制御装置１００は、主たるコンポーネントとして、プロセッサ１０２と、メモリ１０４と、ストレージ１０６と、ネットワークコントローラ１３０と、フィールドネットワークコントローラ１４０，１５０と、内部バスコントローラ１６０とを含む。
【００４９】
プロセッサ１０２は、ストレージ１０６に格納されているシステムプログラム１０７およびユーザアプリケーションプログラム１０８をメモリ１０４に読み出して実行することで、後述するような処理を含む各種処理を実現する。メモリ１０４は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性記憶装置からなる。ストレージ１０６は、ハードディスクやフラッシュメモリなどの不揮発性記憶装置からなる。ストレージ１０６には、制御装置１００の各部を制御するためのシステムプログラム１０７に加えて、制御対象などに応じて設計されるユーザアプリケーションプログラム１０８が格納される。
【００５０】
ネットワークコントローラ１３０は、制御装置１００がネットワーク１１を介して他の装置との間でデータを遣り取りするためのインターフェイスを提供する。ネットワークコントローラ１３０は、主たるコンポーネントとして、受信回路（ＲＸ）１３１と、受信バッファ１３２と、送受信コントローラ１３３と、送信バッファ１３４と、送信回路（ＴＸ）１３５とを含む。
【００５１】
受信回路１３１は、ネットワークコントローラ１３０上を定周期で伝送されるパケットを受信して、その受信したパケットに格納されているデータを受信バッファ１３２に書込む。送受信コントローラ１３３は、受信バッファ１３２に書込まれた受信パケットを順次読出すとともに、当該読出したデータのうち制御装置１００での処理に必要なデータのみをプロセッサ１０２へ出力する。送受信コントローラ１３３は、プロセッサ１０２からの指令に従って、他の装置へ送信すべきデータあるいはパケットを送信バッファ１３４へ順次書込む。送信回路１３５は、ネットワークコントローラ１３０上をパケットが転送される周期に応じて、送信バッファ１３４に格納されているデータを順次送出する。
【００５２】
フィールドネットワークコントローラ１４０は、制御装置１００がフィールドネットワーク１１０を介して各種デバイス（図１に示すデバイス群１１２）との間でデータを遣り取りするためのインターフェイスを提供する。フィールドネットワークコントローラ１４０は、主たるコンポーネントとして、受信回路（ＲＸ）１４１と、受信バッファ１４２と、送受信コントローラ１４３と、送信バッファ１４４と、送信回路（ＴＸ）１４５とを含む。これらのコンポーネントの機能は、ネットワークコントローラ１３０の対応するコンポーネントの機能と同様であるので、詳細な説明は繰返さない。
【００５３】
同様に、フィールドネットワークコントローラ１５０は、制御装置１００がフィールドネットワーク１２０を介して各種デバイス（図１に示すデバイス群１２２）との間でデータを遣り取りするためのインターフェイスを提供する。フィールドネットワークコントローラ１５０は、主たるコンポーネントとして、受信回路（ＲＸ）１５１と、受信バッファ１５２と、送受信コントローラ１５３と、送信バッファ１５４と、送信回路（ＴＸ）１５５とを含む。これらのコンポーネントの機能は、ネットワークコントローラ１３０およびフィールドネットワークコントローラ１４０の対応するコンポーネントの機能と同様であるので、詳細な説明は繰返さない。
【００５４】
内部バスコントローラ１６０は、制御装置１００に装着される入出力ユニットと間で、が内部バス（図示しない）を介してデータを遣り取りするためのインターフェイスを提供する。内部バスコントローラ１６０は、主たるコンポーネントとして、受信回路（ＲＸ）１６１と、受信バッファ１６２と、送受信コントローラ１６３と、送信バッファ１６４と、送信回路（ＴＸ）１６５とを含む。これらのコンポーネントの機能は、ネットワークコントローラ１３０の対応するコンポーネントの機能と同様であるので、詳細な説明は繰返さない。
【００５５】
＜Ｄ．ソフトウェア構成＞
次に、本実施の形態に従う通信処理（動的スケジューリング）を実現するためのソフトウェア構成の一例について説明する。図４は、本実施の形態に従う通信処理を実現するための制御装置１００のソフトウェア構成の一例を示す模式図である。
【００５６】
図４を参照して、制御装置１００のプロセッサ１０２ではスケジューラ１７０が実行される。スケジューラ１７０は、予め定められたシステム周期に従って、複数の処理の実行順序や実行中断などを決定する。より具体的には、スケジューラ１７０は、ユーザアプリケーション実行処理１７３と、各種処理を含む周辺処理１７４と、制御系通信処理１７５と、制御情報系通信処理１７６と、情報系通信処理１７７に対して、予め定められた優先度およびシステム周期などに従って、処理リソース（プロセッサ時間およびメモリなど）を割り当てる。
【００５７】
ユーザアプリケーション実行処理１７３は、ユーザアプリケーションプログラム１０８の実行に係る処理を含む。
【００５８】
制御系通信処理１７５は、制御系データに係る処理、例えば、データ作成、エンコーディング、デコーディング、抽出、加工編集などを含む。同様に、制御情報系通信処理１７６は、制御情報系データに係る処理を含み、情報系通信処理１７７は、情報系データに係る処理を含む。
【００５９】
さらに、制御装置１００のプロセッサ１０２には、通信ドライバ１７８が実装されており、通信ドライバ１７８がネットワークコントローラ１３０（図３参照）などを制御する。
【００６０】
スケジューラ１７０は、３種類のデータ（制御系データ、制御情報系データ、情報系データ）を互いに異なる要求特性を満足できるように、動的スケジューリングを行う。この動的スケジューリングとしては、典型的には、通信時間管理モード、デバイス管理モード、通信状況管理モードの３つの管理モード１７２が用意されている。これらの３つの管理モードのすべてを実装する必要はなく、制御装置１００を含むネットワーク化システム１での処理全体を考慮して、必要な管理モードのみを実装するようにしてもよい。３つの管理モード１７２に加えて、あるいは、３つの管理モード１７２に代えて、３つの管理モード１７２以外の管理モードを採用してもよい。
【００６１】
＜Ｅ：動的スケジューリング＞
本実施の形態に従う通信処理（動的スケジューリング）は、要求されるデータの特性および各種状況に対して、動的に最適化する手法を含む。より具体的には、本実施の形態に従う動的スケジューリングは、予め定められた周期毎にデータが更新されるネットワークに適用されるものであり、基本的には、制御系通信を最優先しつつ、残りの通信帯域を他の通信において最大限に活用する。
【００６２】
本明細書において、「通信帯域」とは、ネットワーク上でデータを伝送するためのリソースを意味し、時間分割方式でデータを伝送する場合には、データを伝送するために割り当てられる時間幅を意味する。あるいは、周波数分割方式または符号分割方式でデータを伝送する場合には、データを伝送するために割り当てられる周波数または符号系列（論理的なチャネル）を意味し得る。本実施の形態に従う動的スケジューリングは、対象のネットワークが有している有限の通信帯域に制約の下、各データに対して必要な通信帯域をどのように割り当てるのかという問題に向けられている。
【００６３】
また、本実施の形態に従う動的スケジューリングの実装については、任意の形態を採用できる。例えば、ネットワークを管理するホストと、当該ホストからの指示に従って通信処理を実行する１または複数のクライエントとからなる構成においては、本実施の形態に従う動的スケジューリングは、ホストに実装されてもよい。あるいは、クライエントにその一部の機能が実装されるとともに、ネットワーク全体として、本実施の形態に従う動的スケジューリングを実現するようにしてもよい。さらに、マスターと１または複数のスレーブとから構成されるネットワークについても同様の方法で実装するようにしてもよい。
【００６４】
すなわち、本実施の形態に従う動的スケジューリングの実装形態については、対象となるネットワークの構成や機能に応じて、一括または分散して適宜実装することができる。
【００６５】
以下、本実施の形態に従う通信処理（動的スケジューリング）に関して、いくつかの具体例を示す。すなわち、図４に示す３つの管理モード（（１）通信時間管理モード、（２）デバイス管理モード、（３）通信状況管理モード）の観点から、動的スケジューリングの具体的な処理を例示する。
【００６６】
（１）通信時間管理モードは、主として、各通信処理の優先度を考慮したスケジューリングである。（２）デバイス管理モードは、主として、通信先デバイスの状態を考慮したスケジューリングである。（３）通信状況管理モードは、主として、通信環境を考慮したスケジューリングである。
【００６７】
（ｅ１．通信時間管理モード）
まず、通信時間管理モードについて説明する。通信時間管理モードでは、制御系通信を最優先し、残りの通信帯域を最大限に活用することを主旨とする。
【００６８】
図５は、本実施の形態に従う通信処理の通信時間管理モードの処理を説明するための模式図である。図５を参照して、本実施の形態に従う通信処理においては、予め定められたシステム周期Ｔｓに従って、制御系データ、制御情報系データ、情報系データの送受信（それぞれ、制御系通信、制御情報系通信、情報系通信と記す）がスケジューリングされる。
【００６９】
通信時間管理モードにおいては、まず、制御系通信が優先的に割り当てられる。図５（Ａ）に示すように、システム周期Ｔｓに対して、制御系通信に要する処理時間ｔ１が先に割り当てられる。図５（Ｂ）に示すように、必要に応じて、制御系通信を行っていない空帯域で制御情報系通信が行われる。すなわち、システム周期Ｔｓのうち、制御系通信に要する処理時間ｔ１を除いた残り時間に対して、制御情報系通信に要する処理時間ｔ２が割り当てられる。
【００７０】
制御情報系通信は、すべてのシステム周期で発生するものではないので、図５（Ｃ）に示すように、システム周期Ｔｓのうち、制御系通信に要する処理時間ｔ１を除いた残り時間に対して、情報系通信に要する処理時間ｔ３が割り当てられることもある。すなわち、情報系通信は、制御系通信および制御情報系通信のいずれもが存在しない通信帯域で行われる。
【００７１】
また、図５（Ｄ）に示すように、システム周期Ｔｓに対して、制御系通信に要する処理時間ｔ１、制御情報系通信に要する処理時間ｔ２、および、情報系通信に要する処理時間ｔ３のすべてが割り当てられてもよい。
【００７２】
図６は、本実施の形態に従う通信処理の通信時間管理モードの処理手順を示すフローチャートである。図６に示す処理手順は、典型的には、制御装置１００のプロセッサ１０２（図３）によってシステム周期毎に繰返し実行される。
【００７３】
図６を参照して、制御装置１００は、制御系通信に要する処理時間ｔ１を算出する（ステップＳ１００）とともに、システム周期Ｔｓから算出した処理時間ｔ１を除いた残り時間Ｔｒ１を算出する（ステップＳ１０２）。そして、残り時間Ｔｒ１が負の値であれば（ステップＳ１０４においてＮＯの場合）、制御系通信に要する処理時間ｔ１がシステム周期Ｔｓを超えることを意味するので、制御装置１００はエラー処理を実行し（ステップＳ１０６）、当該システム周期での処理は終了する。
【００７４】
これらのステップＳ１００〜Ｓ１０６に係る処理は、製造装置または生産設備の制御に用いる制御系データ（第１のデータ）を予め定められた周期毎に更新するのに必要な第１の通信帯域を確保するスケジューリング処理に相当する。つまり、これらのステップにおいて、制御系通信に要する時間が確保される。
【００７５】
一方、残り時間Ｔｒ１がゼロ以上であれば（ステップＳ１０４においてＹＥＳの場合）、制御装置１００は、制御情報系通信に要する処理時間ｔ２を算出する（ステップＳ１０８）とともに、ステップＳ１０２において算出した残り時間Ｔｒ１から処理時間ｔ２を除いた残り時間Ｔｒ２を算出する（ステップＳ１１０）。そして、残り時間Ｔｒ２が負の値であれば（ステップＳ１１２においてＮＯの場合）、システム周期Ｔｓ内に対象の制御情報系通信を追加できないことを意味するので、制御装置１００は、残り時間Ｔｒ２がゼロ以上となるように、通信対象の制御情報系データを分割する（ステップＳ１１４）。すなわち、制御情報系データに関するスケジューリングにおいては、対象の制御情報系データを、各システム周期において利用可能な通信帯域に応じたデータサイズに分割した上で、分割後のそれぞれのデータを複数のシステム周期に割り当てる。
【００７６】
そして、通信対象の制御情報系データの分割後のデータ数（すなわち、必要なシステム周期の数）に基づいて、対象の制御情報系データを指定された時間内に送信先へ到着させることができるか否かを判断する（ステップＳ１１６）。対象の制御情報系データを指定された時間内に送信先へ到着させることができれば（ステップＳ１１６においてＹＥＳの場合）、ステップＳ１０８以下の処理が繰返される。これらの分割されたデータは、次のシステム周期以降に再度割り当てられることになる。
【００７７】
これに対して、対象の制御情報系データを指定された時間内に送信先へ到着させることができなければ（ステップＳ１１６においてＮＯの場合）、通信異常が通知される（ステップＳ１１８）。制御情報系データに関する到着時間は、予めユーザまたはアプリケーションによって指定されていてもよい。
【００７８】
この通信異常の通知は、システムフラグをオンするなどの方法を用いてもよいし、制御装置１００の表示面にあるインジケータを点灯させるなどの方法を採用してもよい。このように、制御情報系データの分割によって、制御情報系データの指定された時間（到着時間）を保証できない場合には、適切な方法で通信異常を通知するようにしてもよい。このような通信異常の通知を受けて、ユーザは、指定された時間（到着時間）の要件を緩和するか、デバイス側のアプリケーション処理量を削減するなどの措置をとることができる。このように、ステップＳ１１６およびＳ１１８は、制御情報系データの分割により、制御情報系データを指定された時間内に送信先へ到着させることができない場合に、異常通知を行う処理に相当する。
【００７９】
上述のステップＳ１０８〜Ｓ１１８に係る処理は、ネットワークが有する通信帯域のうち制御系データに向けられた通信帯域以外の通信帯域内に、制御情報系データ（第２のデータ）を指定された時間内に送信先へ到着させるのに必要な通信帯域を確保するスケジューリング処理に相当する。つまり、これらのステップにおいて、制御情報系通信に要する時間が確保される。なお、通信対象の制御情報系データが存在しない場合には、ステップＳ１０８〜Ｓ１１８はスキップされてもよい。
【００８０】
一方、残り時間Ｔｒ２がゼロ以上であれば（ステップＳ１１２においてＹＥＳの場合）、制御装置１００は、情報系通信に要する処理時間ｔ３を算出する（ステップＳ１２０）とともに、ステップＳ１１０において算出した残り時間Ｔｒ２から処理時間ｔ３を除いた残り時間Ｔｒ３を算出する（ステップＳ１２２）。そして、残り時間Ｔｒ３が負の値であれば（ステップＳ１２４においてＮＯの場合）、システム周期Ｔｓ内に対象の情報系通信を追加できないことを意味するので、制御装置１００は、残り時間Ｔｒ３がゼロ以上となるように、通信対象の情報系データを分割する（ステップＳ１２６）。この分割されたデータは、次のシステム周期以降に再度割り当てられることになる。
【００８１】
これらのステップＳ１２０〜Ｓ１２６に係る処理は、ネットワークが有する通信帯域のうち、制御系データに向けられた通信帯域および制御情報系データに向けられた通信帯域のいずれにも設定されていない通信帯域内に、情報系データ（第３のデータ）を伝送するための通信帯域を確保するスケジューリング処理に相当する。つまり、これらのステップは、情報系通信に要する時間を確保する処理に相当する。なお、通信対象の情報系データが存在しない場合には、ステップＳ１２０〜Ｓ１２６はスキップされてもよい。
【００８２】
以上のような処理手順がシステム周期毎に繰返し実行されることで、通信時間管理モードでの動的スケジューリングが実現される。
【００８３】
図６に示す処理手順は、制御情報系通信の指定された時間（到着時間）に余裕があり、情報系通信が一定時間以上行われておらず、送信できていないフレームが溜まっているような状態を想定している。この場合、同一のシステム周期において、制御系データ、制御情報系データ、情報系データの３種類を送信または受信することができる。但し、情報系通信を行ったときの回線状況に基づいて、制御情報系通信についての指定された時間（到着時間）を保証できないと判断された場合には、情報系通信を行わないようにしてもよい。すなわち、情報系通信については、回線状況などに基づいて、余裕がある期間でのみ実行するようにしてもよい。
【００８４】
さらに、情報系データを制御情報系データよりも優先する例外を設けてもよい。例えば、情報系通信が一定時間以上行われておらず、送信できないフレームが溜まっているような状態がさらに長い時間に亘って継続して場合であって、かつ、制御情報系通信に余裕がある場合には、制御情報系通信の到着時間を保証する限りで、情報系通信を優先するようにしてもよい。つまり、先に、情報系通信に必要な通信帯域を先に割り当てるようなしてもよい。
【００８５】
（ｅ２．デバイス管理モード（その１））
次に、デバイス管理モード（その１）について説明する。デバイス管理モード（その１）では、受信側デバイスの特性に応じて、データサイズ／通信周期を最適化することを主旨とする。
【００８６】
図７は、本実施の形態に従う通信処理のデバイス管理モード（その１）の処理を説明するための模式図である。図７には、制御系データに加えて、特定のデバイスに対して制御情報系データを送信する場合の通信処理を示す。
【００８７】
図７に示すデバイス管理モード（その１）においても、基本的な通信帯域のスケジューリングは、上述の通信時間管理モードと同様である。例えば、図７（Ａ）に示すように、各システム周期において、制御系データに加えて、特定のデバイス向けの制御情報系データが送信される。そのため、上述の通信時間管理モードと同様の処理については、詳細な説明は繰返さない。
【００８８】
制御情報系データを受信するデバイスの受信バッファなどはデバイス固有の性能に影響されるので、１回に送信できるデータサイズが制限されることもある。このような場合、図７（Ｂ）に示すように、デバイス管理モード（その１）においては、送信される制御情報系データのデータサイズの送信単位を小さくする。すなわち、１回に送信する制御情報系データのデータサイズを小さくするとともに、より多くの送信回数に分けてデータ全体を送信する。このように、受信側デバイスの受信可能な最大サイズが小さい場合には、送信サイズの送信単位を小さくする。この送信単位の縮小によって、当初は制御情報系データの通信に用いられていた通信帯域が空くので、この空いた通信帯域については、別のデバイス向けの制御情報系データの通信などに活用されてもよい。
【００８９】
図８は、本実施の形態に従う通信処理のデバイス管理モード（その１）の処理手順（初期起動時）を示すフローチャートである。図８に示す処理手順は、典型的には、制御装置１００のプロセッサ１０２（図３）によって、通信処理の初期起動時に実行される。この処理において、通信相手となるデバイスの受信可能な最大サイズに応じて送信単位の変更が実行される。
【００９０】
図８を参照して、制御装置１００は、送信予定のデータサイズが送信先のデバイスでの受信可能な最大サイズ以下であるか否かを判断する（ステップＳ２００）。送信先のデバイスでの受信可能な最大サイズは、予め用意されている設定に基づいて判断してもよいし、送信先のデバイスに直接問い合わせて取得するようにしてもよい。
【００９１】
送信予定のデータサイズが送信先のデバイスでの受信可能な最大サイズを超えていれば（ステップＳ２００においてＮＯの場合）、制御装置１００は、送信予定のデータを送信先のデバイスでの受信可能な最大サイズに送信単位を変更する（ステップＳ２０２）。これに対して、送信予定のデータサイズが送信先のデバイスでの受信可能な最大サイズ以下であれば（ステップＳ２００においてＹＥＳの場合）、送信単位の変更は行われない。
【００９２】
このように、本実施の形態に従う通信処理のデバイス管理モード（その１）においては、送信先にて受信可能なデータサイズに応じて、制御情報系データ（第２のデータ）を分割した上で、分割後のそれぞれのデータを複数のシステム周期に割り当てる。
【００９３】
また、再度図７を参照して、制御情報系データを受信するデバイスの処理能力が低く、制御情報系データが許容可能なスループットが制限されることもある。このような場合、図７（Ｃ）に示すように、デバイス管理モード（その１）においては、制御情報系データの通信周期を長く変更する。すなわち、システム周期毎に制御情報系データを送信するのではなく、システム周期のＮ倍の通信周期で制御情報系データを送信するようにしてもよい。このように、受信側デバイスでの処理が指定時間内に完了できておらず、この結果、受信側デバイスが制御情報系データを受信できない場合には、システム周期ＴｓのＮ倍にするといった方法で、通信周期を長くするようにしてもよい。この通信周期の変更によって、当初は制御情報系データの通信に用いられていた通信帯域が空くので、この空いた通信帯域については、別のデバイス向けの制御情報系データの通信などに活用されてもよい。
【００９４】
図９は、本実施の形態に従う通信処理のデバイス管理モード（その１）の処理手順（通信処理の実行中）を示すフローチャートである。図９に示す処理手順は、典型的には、制御装置１００のプロセッサ１０２（図３）によって、通信処理の実行中に適宜実行される。具体的には、通信相手となるデバイスの受信可能な時間間隔に応じて通信周期が動的に設定される。
【００９５】
図９を参照して、制御装置１００は、デバイスの受信エラーが指定回数未満であるか否かを判断する（ステップＳ２１０）。送信先のデバイスの受信エラーの回数は、通信を管理する主体から取得してもよいし、送信先のデバイスからの応答メッセージに基づいて判断してもよい。デバイスの受信エラーが指定回数に到達していれば（ステップＳ２１０においてＹＥＳの場合）、ステップＳ２１４の処理が実行される。
【００９６】
デバイスの受信エラーが指定回数未満であれば（ステップＳ２１０においてＮＯの場合）、デバイスから受信応答を受信できない回数が指定回数未満であるか否かを判断する（ステップＳ２１２）。デバイスから受信応答を受信できない回数が指定回数に到達していれば（ステップＳ２１２においてＹＥＳの場合）、ステップＳ２１４の処理が実行される。
【００９７】
ステップＳ２１０またはＳ２１２において何らかのエラーの発生が検出されると、制御装置１００は、通信周期をシステム周期のＮ倍にするなどして、送信予定のデータの通信周期を長くする（ステップＳ２１４）。これに対して、ステップＳ２１０またはＳ２１２において何らのエラーの発生も検出されなければ、制御装置１００は、初期設定に従って通信を継続する。
【００９８】
このように、本実施の形態に従う通信処理のデバイス管理モード（その１）においては、制御情報系データ（第２のデータ）を分割した上で、分割後のそれぞれのデータを、送信先での受信データの処理状況に応じて、システム周期より長い周期で順次送信する。すなわち、制御装置１００は、通信処理の実行中に、送信先のデバイスでの受信処理が適切に実行できない場合に、通信周期を実質的に長くする。送信先での受信データの処理状況の判断方法として、送信先での受信エラーの回数、および、送信先から受信応答を受信できなかった回数を例示したが、これらに限られることなく、任意の情報を用いてもよい。
【００９９】
なお、図７または図９に示すように、制御情報系データの分割または通信周期の延長によって、制御情報系通信の指定された時間（到着時間）を保証できない場合には、適切な方法で通信異常を通知するようにしてもよい（上述の図６のステップＳ１１６などと同様）。このような通信異常の通知を受けて、ユーザは、指定された時間（到着時間）の要件を緩和するか、デバイス側のアプリケーション処理量を削減するなどの措置をとることができる。また、初期起動時において、送信予定のデータがシステム周期内で送信できないと判断された場合も同様に、通信異常を通知するようにしてもよい。
【０１００】
さらに、図７（Ｂ）に示す送信単位の変更と図７（Ｃ）に示す通信周期の増大とを組み合わせてもよい。
【０１０１】
（ｅ３．デバイス管理モード（その２））
次に、デバイス管理モード（その２）について説明する。デバイス管理モード（その２）では、受信側デバイスの特性に応じて、データサイズ／通信周期を最適化することを主旨とする。
【０１０２】
図１０は、本実施の形態に従う通信処理のデバイス管理モード（その２）の処理を説明するための模式図である。図１０には、制御系データに加えて、特定のデバイスに対して制御情報系データを送信する場合の通信処理を示す。
【０１０３】
図１０に示すデバイス管理モード（その２）においても、基本的な通信帯域のスケジューリングは、上述の通信時間管理モードと同様である。例えば、図１０（Ａ）に示すように、各システム周期において、制御系データに加えて、特定のデバイス向けの制御情報系データが送信される。そのため、上述の通信時間管理モードと同様の処理については、詳細な説明は繰返さない。
【０１０４】
上述のデバイス管理モード（その１）の場合とは逆に、制御情報系データを受信するデバイスの受信バッファが大きい場合や高速な受信処理が可能な場合には、同一のシステム周期内に、同一のデバイス向け制御情報系データまたは情報系データを複数送信するようにしてもよい。つまり、受信側デバイスの処理に余裕があり、システム周期内に複数回の受信が可能な場合には、図１０（Ｂ）に示すように、予め定められたシステム周期内に、制御情報系データまたは情報系データを複数回送信するようにしてもよい。すなわち、デバイス管理モード（その２）においては、同一のシステム周期において、同一のデバイス向けの制御情報系データまたは情報系データを複数個送信するようにしてもよい。
【０１０５】
この送信回数の増大によって、特定のデバイス向けの制御情報系データまたは情報系データの送信に要する時間を短縮できる。
【０１０６】
さらに、図１０（Ｂ）においてシステム周期内で複数回受信されるデータの合計サイズが受信側デバイスの受信可能な最大サイズより小さい場合には、図１０（Ｃ）に示すように、当該複数回分のデータをまとめてより大きな１つのデータとして送信するようにしてもよい。データの送信単位を大きくすることで、オーバヘッドを低減できる。
【０１０７】
図１１は、本実施の形態に従う通信処理のデバイス管理モード（その２）の処理手順（初期起動時）を示すフローチャートである。図１１に示す処理手順は、典型的には、制御装置１００のプロセッサ１０２（図３）によって、通信処理の初期起動時に実行される。この処理において、通信相手となるデバイスの受信可能な最大サイズに応じて送信単位の変更が実行される。
【０１０８】
図１１を参照して、制御装置１００は、システム周期内における受信側デバイスの空き時間が所定時間以上存在するか否かを判断する（ステップＳ２２０）。システム周期内における受信側デバイスの空き時間が所定時間以上存在すれば（ステップＳ２２０においてＹＥＳの場合）、制御装置１００は、同一のシステム周期内におけるデータの送信回数を１回分加算する（ステップＳ２２２）。そして、制御装置１００は、ステップＳ２２２において加算された後の送信回数に従ってデータを送信する場合において、同一のシステム周期内で複数回送信されるデータの合計サイズが受信側デバイスの受信可能な最大サイズより小さいか否かを判断する（ステップＳ２２４）。
【０１０９】
同一のシステム周期内で複数回送信されるデータの合計サイズが受信側デバイスの受信可能な最大サイズより小さければ（ステップＳ２２４においてＹＥＳの場合）、制御装置１００は、同一のシステム周期内で複数回送信されるデータを結合して１つのフレームを構成する（ステップＳ２２６）。
【０１１０】
一方、システム周期内における受信側デバイスの空き時間が所定時間以上存在しなければ（ステップＳ２２０においてＮＯの場合）、あるいは、同一のシステム周期内で複数回送信されるデータの合計サイズが受信側デバイスの受信可能な最大サイズより大きければ（ステップＳ２２４においてＮＯの場合）、各システム周期における送信予定のデータの割り当ては変更されない。
【０１１１】
（ｅ４．通信状況管理モード）
次に、通信状況管理モードについて説明する。通信状況管理モードでは、通信環境の状態に応じてデータサイズを動的に最適化することを主旨とする。
【０１１２】
図１２は、本実施の形態に従う通信処理の通信状況管理モードの処理を説明するための模式図である。図１２には、制御系データに加えて、特定のデバイスに対して制御情報系データを送信する場合の通信処理を示す。
【０１１３】
図１２に示す通信状況管理モードにおいても、基本的な通信帯域のスケジューリングは、上述の通信時間管理モードと同様である。そのため、上述の通信時間管理モードと同様の処理については、詳細な説明は繰返さない。
【０１１４】
図１２（Ａ）に示すように、制御系通信を最優先しつつ、残りの通信帯域を他の通信において最大限に活用するという方針に従って、制御情報系通信および情報系通信を割り当てると、制御情報系データおよび情報系データのデータサイズは比較的大きくなる。データサイズを大きくすることで、通信オーバヘッドが減り、ネットワークの利用効率を高めることができる。一方で、通信路に侵入する各種ノイズなどの影響によって、データの送受信が失敗すると、データの再送処理が実行される。このような再送処理を考えると、データサイズは可能な限り小さい方がよい。つまり、送受信に失敗した部分のみを再送すればよいので、リカバリを効率化できる。このように、データサイズが大きいと再送処理のデータサイズも大きくなるが、再送単位を小さくすることで、リカバリを容易化できる。
【０１１５】
したがって、通信状況が良好な場合には、再送処理が必要になる確率が低いので、データサイズを可能な限り大きくする一方で、通信状況が良好ではない場合には、再送処理が必要になる確率が高いので、データサイズ（単位サイズ）を適切な大きさまで小さくすることが好ましい。
【０１１６】
なお、送信単位の変更により通信オーバヘッドが発生するため、制御情報系通信および情報系通信には適用するものの、制御系通信には適用しないようにすることが好ましい。情報系通信については、基本的には、リアルタイム性が要求されないので、送信単位の変更を実施するか否かをユーザが適宜選択できるようにしてもよい。
【０１１７】
図１３は、本実施の形態に従う通信処理の通信状況管理モードの処理手順を示すフローチャートである。図１３に示す処理手順は、典型的には、制御装置１００のプロセッサ１０２（図３）によって、通信処理の実行中に適宜実行される。具体的には、通信相手となるデバイスの受信可能な時間間隔に応じて通信周期が動的に設定される。
【０１１８】
図１３を参照して、制御装置１００は、送信先からの受信応答のフレームが破損していた回数が指定回数未満であるか否かを判断する（ステップＳ３００）。送信先からの受信応答のフレームが破損していた回数は、制御装置１００にて送信先のデバイス毎にカウントしてもよいし、通信を管理する主体から取得してもよい。送信先からの受信応答のフレームが破損していた回数が指定回数に到達していれば（ステップＳ３００においてＹＥＳの場合）、ステップＳ３０４の処理が実行される。
【０１１９】
送信先からの受信応答のフレームが破損していた回数が指定回数未満であれば（ステップＳ３００においてＮＯの場合）、受信データが破損していたことを送信先のデバイスから通知された回数が指定回数未満であるか否かを判断する（ステップＳ３０２）。受信データが破損していたことを送信先のデバイスから通知された回数が指定回数に到達していれば（ステップＳ３０２においてＹＥＳの場合）、ステップＳ３０４の処理が実行される。
【０１２０】
ステップＳ３００またはＳ３０２において何らかのエラーの発生が検出されると、制御装置１００は、送信するデータの送信単位を小さくする（ステップＳ３０４）。
【０１２１】
これに対して、ステップＳ３００またはＳ３０２において何らのエラーの発生も検出されなければ、制御装置１００は、初期設定のデータサイズに従って通信を継続する。
【０１２２】
通信状況管理モードによれば、ノイズが多くて通信環境が悪い状況においては、送信単位を小さくすることで、再送処理を含めてトータルの伝送効率を高めることができる。一方で、オーバヘッドが増加するので、このオーバヘッドの増加により制御情報系通信の指定された時間（到着時間）を保証できない場合には、適切な方法で通信異常を通知するようにしてもよい。このような通信異常の通知を受けて、ユーザは、指定された時間（到着時間）の要件を緩和するか、デバイス側のアプリケーション処理量を削減するなどの措置をとることができる。
【０１２３】
このように、本実施の形態に従う通信処理の通信状況管理モードにおいては、ネットワークの通信状況に応じて、制御情報系データ（第２のデータ）を分割して送信する単位サイズを変化させる。併せて、本実施の形態に従う通信処理の通信状況管理モードにおいては、ネットワークの通信状況に応じて、情報系データ（第３のデータ）についても、分割して送信する単位サイズを変化させるようにしてもよい。ネットワークの通信状況の判断方法として、送信先からの受信応答のうち破損していたものの数、および、受信データの破損を示す送信先からの通知の数を例示したが、これらに限られることなく、任意の情報を用いてもよい。
【０１２４】
（ｅ５．その他）
上述の処理手順においては、説明の簡素化のため、制御情報系通信を一律に扱う処理例を示したが、制御情報系通信の各々に対して、異なる優先度または指定された時間（到着時間）を設定するようにしてもよい。例えば、後述するような異常情報の通知については、相対的に優先度を高く設定する一方で、パラメータ設定などについては、相対的に優先度を低くするようにしてもよい。
【０１２５】
このような優先度の設定に応じて、高い優先度が設定された制御情報系データをより有線して処理できるようにしてもよい。
【０１２６】
＜Ｆ：応用例＞
次に、本実施の形態に従う通信処理の応用例について説明する。
【０１２７】
（ｆ１：応用例１）
図１４は、本実施の形態に従う通信処理の応用例１を説明するための模式図である。図１４には、制御装置１００およびデバイスの運転中に、リモートでデバイスの状態監視や、パラメータの設定変更を行う応用例を示す。
【０１２８】
より具体的には、図１４を参照して、制御装置１００には、フィールドネットワーク１１０を介して、複数のデバイス１１２−１〜１１２−４が接続されている。制御装置１００とデバイス１１２−１〜１１２−４との間では、予め定められたシステム周期に従って制御系データが遣り取りされる。このような制御系データの遣り取りによって、制御装置１００およびデバイスの制御動作を実現できる。
【０１２９】
また、制御装置１００には、上位ネットワークを介してゲートウェイ２５０が接続されており、ゲートウェイ２５０が外部からのアクセスを仲介する。例えば、タブレット端末やスマートフォンなどからなるリモート保守端末４００は、ゲートウェイ２５０を介して、制御装置１００および制御装置１００のフィールドネットワーク１１０に接続されている各デバイスにアクセス可能になっている。
【０１３０】
上述したような制御系データに加えて、フィールドネットワーク１１０上では、制御情報系データが伝送される。例えば、デバイス１１２−１〜１１２−４では、各々が管理する情報へのアクセスを提供するために、ＨＴＴＰ（HyperText Transfer Protocol）ホストプログラム１１４−１〜１１４−４が実行されている。制御情報系データは、典型的には、リモート保守端末４００とＨＴＴＰホストプログラム１１４−１〜１１４−４の各々との遣り取りに係るデータを含む。
【０１３１】
本実施の形態に従う通信方法によれば、フィールドネットワーク１１０において、本来の制御系データの遣り取りを阻害することなく、制御情報系データについても遣り取りできるので、ユーザがリモート保守端末４００を介して特定のデバイスへアクセスし、当該デバイスの状態監視やパラメータの設定変更をリモート保守端末４００上で行うことができる。
【０１３２】
制御情報系データを伝送できない場合には、各デバイスが設置されている現場に赴いて、各デバイスに設けられているボタンなどの操作、または、各デバイスにパーソナルコンピュータなどを接続して設定ツールなどを介した操作、などが必要であったが、リモート保守端末４００を用いることで、遠隔で、かつ、複数のデバイスに対して、当該デバイスの状態監視やパラメータの設定変更を行うことができる。
【０１３３】
（ｆ２：応用例２）
図１５は、本実施の形態に従う通信処理の応用例２を説明するための模式図である。図１５には、制御装置１００およびデバイスの運転中に、いずれかのデバイスで何らかの異常が発生した場合の通知および状況確認を行う応用例を示す。
【０１３４】
より具体的には、図１５を参照して、制御装置１００には、フィールドネットワーク１１０を介して、複数のデバイス１１２−１〜１１２−４およびカメラ１１６が接続されている。制御装置１００とデバイス１１２−１〜１１２−４との間では、予め定められたシステム周期に従って制御系データが遣り取りされる。このような制御系データの遣り取りによって、制御装置１００およびデバイスの制御動作を実現できる。
【０１３５】
制御装置１００には、上位ネットワークを介してゲートウェイ２５０が接続されており、ゲートウェイ２５０が外部からのアクセスを仲介する。例えば、タブレット端末やスマートフォンなどからなるリモート保守端末４００は、ゲートウェイ２５０を介して、制御装置１００および制御装置１００のフィールドネットワーク１１０に接続されている各デバイスにアクセス可能になっている。
【０１３６】
例えば、デバイスの運転中（通常時）には、フィールドネットワーク１１０に接続されているカメラ１１６で撮像された画像が、制御装置１００およびゲートウェイ２５０の順で、リモート保守端末４００まで転送される。リモート保守端末４００のユーザ（保守員）は、リモート保守端末４００上に表示される画像により、遠隔で状況を監視することができる。
【０１３７】
通常時において撮像された画像は、情報系データとしてフィールドネットワーク１１０上を伝送させるようにしてもよい。
【０１３８】
例えば、デバイス１１２−２において何らかの異常が発生すると、デバイス１１２−２は、その異常情報の内容を、フィールドネットワーク１１０を介して送信する。そのメッセージは、制御装置１００およびゲートウェイ２５０の順で、リモート保守端末４００まで転送される。併せて、カメラ１１６で撮像された画像もリモート保守端末４００まで転送される。リモート保守端末４００では、カメラ１１６で撮像された画像と受信した異常情報とをリモート保守端末４００のユーザ（保守員）に呈示する。この呈示の一例として、図１５に示されるような、ＡＲ（Augmented Reality：拡張現実）を用いてもよい。すなわち、受信した異常情報に基づいて、実際に撮像された画像上の異常が発生した部位に関連付けて、その異常情報の内容を表示するようにしてもよい。
【０１３９】
このような異常情報は、制御情報系データとして、制御系データの通常の伝送を阻害することなく、フィールドネットワーク１１０上を伝送される。
【０１４０】
本実施の形態に従う通信方法によれば、異常発生時において、画像および異常情報を制御情報系データとして、到達時間を保証しつつ伝送することで、リモート保守端末４００上の表示（ＡＲ表示）において、撮像された画像と発生した異常を示す異常情報とを同期させることができる。このような同期された表示によって、ユーザ（保守員）は異常発生の内容を確実に遠隔で把握することができる。もし、通常時と同様に、画像を情報系データとして伝送すると、リモート保守端末４００に表示される画像と異常情報の時間とが一致せず、表示画面が不適切（例えば、異常情報は表示されているものの、撮像された画像は正常状態を示しているといった状態など）となる可能性もある。
【０１４１】
このような構成を採用することで、ユーザ（保守員）は、制御システムにおいて何らかの異常が発生したときに、下位のデバイスレベルでその異常が発生した箇所を特定できるとともに、遠隔でその状況も確認することができ、保守性を高めることができるともに、故障復旧までの時間を短縮できる。
【０１４２】
（ｆ３：応用例３）
図１６は、本実施の形態に従う通信処理の応用例３を説明するための模式図である。図１６には、制御装置１００の運転中に、いずれかのデバイスに対するファームウェアの更新を実行する応用例を示す。
【０１４３】
より具体的には、図１６を参照して、制御装置１００には、フィールドネットワーク１１０を介して、複数のデバイス１１２−１〜１１２−４が接続されている。制御装置１００とデバイス１１２−１〜１１２−４との間では、予め定められたシステム周期に従って制御系データが遣り取りされる。このような制御系データの遣り取りによって、制御装置１００およびデバイスの制御動作を実現できる。
【０１４４】
また、制御装置１００には、上位ネットワークを介して保守装置５００が接続されている。保守装置５００には、いずれかのデバイスに対するファームウェアが格納されており、ユーザ（保守員）は、保守装置５００を操作して、制御装置１００のフィールドネットワーク１１０に接続されているいずれかのデバイスを指定した上で、保守装置５００に格納されているファームウェアを当該指定したデバイスへ送信する。このようなファームウェアは、制御情報系データとして、制御系データの通常の伝送を阻害することなく、フィールドネットワーク１１０上を伝送される。
【０１４５】
制御情報系データを伝送できない場合には、各デバイスが設置されている現場に赴いて、対象のデバイスに保守装置を直接接続してファームウェアを更新する操作を行う必要があり、特に、対象のデバイスが制御盤内または装置内に配置されているような場合には、ファームウェアの更新に手間を要していた。これに対して、図１６に示すような構成を採用することで、複数のデバイスに対するファームウェアの更新を一ヶ所で集中して行うことができるので、保守性を高めることができるともに、保守に要するコストを低減できる。
【０１４６】
＜Ｇ：利点＞
本実施の形態に従う通信方法によれば、同一のネットワーク上において、製造装置または生産設備の制御に用いるデータ（制御系データ）を予め定められた周期毎に更新することを保証しつつ、指定された時間内に送信先へ到着させることが要求される制御情報系データ、および、よりデータサイズの大きな情報系データを並存して伝送することができる。このような通信方法を実装することで、下位デバイスを含めてネットワーク全体をより高機能化させることができる。
【０１４７】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０１４８】
１  ネットワーク化システム、１１，１２，１３，１４  ネットワーク、１００  制御装置、１０２  プロセッサ、１０４  メモリ、１０６  ストレージ、１０７  システムプログラム、１０８  ユーザアプリケーションプログラム、１１０，１２０  フィールドネットワーク、１１２，１２２  デバイス群、１１２−１〜１１２−４  デバイス、１１４−１〜１１４−４  ＨＴＴＰホストプログラム、１１６  カメラ、１３０  ネットワークコントローラ、１３１，１４１，１５１，１６１  受信回路、１３２，１４２，１５２，１６２  受信バッファ、１３３，１４３，１５３，１６３  送受信コントローラ、１３４，１４４，１５４，１６４  送信バッファ、１３５，１４５，１５５，１６５  送信回路、１４０，１５０  フィールドネットワークコントローラ、１６０  内部バスコントローラ、１７０  スケジューラ、１７２  管理モード、１７３  ユーザアプリケーション実行処理、１７４  周辺処理、１７５  制御系通信処理、１７６  制御情報系通信処理、１７７  情報系通信処理、１７８  通信ドライバ、１８０  表示装置、１９０  ライン管理装置、２００  製造管理装置、２１０  データベース装置、２５０  ゲートウェイ、３００  生産管理装置、４００  リモート保守端末、５００  保守装置、Ｔｓ  システム周期。
【図１】
2018064245.tif 000003
【図２】
2018064245.tif 000004
【図３】
2018064245.tif 000005
【図４】
2018064245.tif 000006
【図５】
2018064245.tif 000007
【図６】
2018064245.tif 000008
【図７】
2018064245.tif 000009
【図８】
2018064245.tif 000010
【図９】
2018064245.tif 000011
【図１０】
2018064245.tif 000012
【図１１】
2018064245.tif 000013
【図１２】
2018064245.tif 000014
【図１３】
2018064245.tif 000015
【図１４】
2018064245.tif 000016
【図１５】
2018064245.tif 000017
【図１６】
2018064245.tif 000018