JP6769230B2 - 通信装置、制御装置および通信方法 - Google Patents

通信装置、制御装置および通信方法 Download PDF

Info

Publication number
JP6769230B2
JP6769230B2 JP2016202964A JP2016202964A JP6769230B2 JP 6769230 B2 JP6769230 B2 JP 6769230B2 JP 2016202964 A JP2016202964 A JP 2016202964A JP 2016202964 A JP2016202964 A JP 2016202964A JP 6769230 B2 JP6769230 B2 JP 6769230B2
Authority
JP
Japan
Prior art keywords
data
communication
network
communication band
destination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016202964A
Other languages
English (en)
Other versions
JP2018064245A (ja
Inventor
光宏 米田
光宏 米田
太雅 新實
太雅 新實
紘志 澤田
紘志 澤田
信幸 阪谷
信幸 阪谷
弘章 山田
弘章 山田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Omron Corp
Original Assignee
Omron Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Omron Corp filed Critical Omron Corp
Priority to JP2016202964A priority Critical patent/JP6769230B2/ja
Priority to US16/337,431 priority patent/US10999367B2/en
Priority to CN201780059783.2A priority patent/CN109792442B/zh
Priority to EP17859722.5A priority patent/EP3528448A4/en
Priority to KR1020197008855A priority patent/KR102181158B1/ko
Priority to PCT/JP2017/037173 priority patent/WO2018070518A1/ja
Publication of JP2018064245A publication Critical patent/JP2018064245A/ja
Application granted granted Critical
Publication of JP6769230B2 publication Critical patent/JP6769230B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/36Handling requests for interconnection or transfer for access to common bus or bus system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40058Isochronous transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40097Interconnection with other networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/36Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L2001/125Arrangements for preventing errors in the return channel

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Description

本発明は、予め定められた周期毎にデータが更新されるネットワークに接続される通信装置、当該通信装置を含む制御装置、および、通信方法に関する。
近年の情報通信技術(ICT:Information and Communication Technology)の進歩に伴って、生産ラインについても、現場の製造機器から上位の管理装置までを一体のネットワーク化するようなシステムが実現されつつある。
このようなネットワーク化されたシステムにおいて伝送されるデータには、その用途、目的などに応じた要件が課される。例えば、製造装置や生産設備などの制御に用いるデータ(制御系データ)は、そのデータサイズはそれほど大きくないものの、リアルタイム性が要求される。これに対して、上位の管理装置などが扱うデータ(情報系データ)は、リアルタイム性などは必要ないものの、比較的大きいサイズのデータを伝送しなければならない。これらの互いに相反する要件を同一のネットワーク上で満足させることは容易ではない。すなわち、制御機器の情報化を実現するためには、制御系通信と情報系通信とを融合することが重要である。
例えば、非特許文献1は、情報系通信と制御系通信との間の連携アーキテクチャを提案している。具体的には、非特許文献1は、制御系通信の周期に対して、情報系通信のパケットが大きく、送信が許可されない場合は、所定連続回数の失敗後に情報系通信のパケットを破棄してCPUへ割り込みを通知し、この通知に基づいて、ユーザが上位層でのフラグメンテーションの適用を可能にする構成を開示する。
また、特開2004−363782号公報(特許文献1)は、制御系通信のリアルタイム性を担保しつつ、情報系通信のスループットを向上させる構成を開示する。特許文献1は、情報系通信のサイズはできるだけ大きくするが、制御系通信の頻度が高い場合などには、フレームを小さくすることを開示する。
特開2004−363782号公報
丸山龍也、山田勉、「リアルタイムEthernet向け情報系・制御系通信の連携アーキテクチャの開発」、電子情報通信学会論文誌B Vol.J96−B,No.10,pp.1114−1121,2013年10月1日
例えば、製造装置または生産設備を制御する制御装置(典型的には、PLC(Programmable Logic Controller))の情報化および高機能化に伴って、制御装置は、制御系データに加えて、情報系データに分類され得るデータを遣り取りする場合も多い。このような制御装置が利用する情報系データは、一般的な情報系データのようなベストエフォート形式ではなく、データの到着時間を保証しなければならない場合がある。上述の先行技術は、このような課題に対して何ら解決手段を提供するものではない。
すなわち、製造装置または生産設備の制御に用いる制御装置を含むネットワークに適したデータ伝送を実現するための構成が要望されている。
本発明のある実施の形態に従えば、予め定められた周期毎にデータが更新されるネットワークに接続される通信装置が提供される。通信装置は、製造装置または生産設備の制御に用いる第1のデータを予め定められた周期毎に更新するのに必要な第1の通信帯域を確保する第1のスケジューリング手段と、ネットワークが有する通信帯域のうち第1の通信帯域以外の通信帯域内に、第2のデータを指定された時間内に送信先へ到着させるのに必要な第2の通信帯域を確保する第2のスケジューリング手段と、ネットワークが有する通信帯域のうち第1の通信帯域および第2の通信帯域のいずれにも設定されていない通信帯域内に、第3のデータを伝送するための第3の通信帯域を確保する第3のスケジューリング手段とを含む。
好ましくは、第2のスケジューリング手段は、第2のデータを、各周期において利用可能な通信帯域に応じたデータサイズに分割した上で、分割後のそれぞれのデータを複数の周期に割り当てる。
好ましくは、第2のスケジューリング手段は、送信先にて受信可能なデータサイズに応じて、第2のデータを分割した上で、分割後のそれぞれのデータを複数の周期に割り当てる。
好ましくは、第2のスケジューリング手段は、第2のデータを分割した上で、分割後のそれぞれのデータを、送信先での受信データの処理状況に応じて、予め定められた周期より長い周期で順次送信する。
好ましくは、第2のスケジューリング手段は、予め定められた周期において、第2のデータまたは第3のデータを複数回送信する。
好ましくは、第2のスケジューリング手段は、送信先での受信エラーの回数、および、送信先から受信応答を受信できなかった回数、の少なくとも一方に基づいて、送信先での受信データの処理状況を判断する。
好ましくは、第2のスケジューリング手段は、第2のデータの分割により、第2のデータを指定された時間内に送信先へ到着させることができない場合に、異常通知を行う。
好ましくは、第2のスケジューリング手段は、ネットワークの通信状況に応じて、第2のデータを分割して送信する単位サイズを変化させる。
好ましくは、第2のスケジューリング手段は、送信先からの受信応答のうち破損していたものの数、および、受信データの破損を示す送信先からの通知の数、の少なくとも一方に基づいて、ネットワークの通信状況を判断する。
好ましくは、第3のスケジューリング手段は、単位サイズを変化させることが指定されている場合に、ネットワークの通信状況に応じて、第3のデータを分割して送信する単位サイズを変化させる。
本発明の別の実施の形態に従えば、製造装置または生産設備を制御する制御装置が提供される。制御装置は、予め定められた周期毎にデータが更新されるネットワークに接続される通信インターフェイスと、製造装置または生産設備の制御に用いる第1のデータを予め定められた周期毎に更新するのに必要な第1の通信帯域を確保する第1のスケジューリング手段と、ネットワークが有する通信帯域のうち第1の通信帯域以外の通信帯域内に、第2のデータを指定された時間内に送信先へ到着させるのに必要な第2の通信帯域を確保する第2のスケジューリング手段と、ネットワークが有する通信帯域のうち第1の通信帯域および第2の通信帯域のいずれにも設定されていない通信帯域内に、第3のデータを伝送するための第3の通信帯域を確保する第3のスケジューリング手段とを含む。
本発明のさらに別の実施の形態に従えば、予め定められた周期毎にデータが更新されるネットワークでの通信方法が提供される。通信方法は、製造装置または生産設備の制御に用いる第1のデータを予め定められた周期毎に更新するのに必要な第1の通信帯域を確保するステップと、ネットワークが有する通信帯域のうち第1の通信帯域以外の通信帯域内に、第2のデータを指定された時間内に送信先へ到着させるのに必要な第2の通信帯域を確保するステップと、ネットワークが有する通信帯域のうち第1の通信帯域および第2の通信帯域のいずれにも設定されていない通信帯域内に、第3のデータを伝送するための第3の通信帯域を確保するステップとを含む。
本発明のある実施の形態によれば、製造装置または生産設備の制御に用いる制御装置を含むネットワークに適したデータ伝送を実現できる。
本実施の形態に従うネットワーク化システムの全体構成の一例を示す模式図である。 図1のネットワーク化システムにおいて伝送されるデータ種別を示す図である。 本実施の形態に従う通信装置を含む制御装置のハードウェア構成の一例を示す模式図である。 本実施の形態に従う通信処理を実現するための制御装置のソフトウェア構成の一例を示す模式図である。 本実施の形態に従う通信処理の通信時間管理モードの処理を説明するための模式図である。 本実施の形態に従う通信処理の通信時間管理モードの処理手順を示すフローチャートである。 本実施の形態に従う通信処理のデバイス管理モード(その1)の処理を説明するための模式図である。 本実施の形態に従う通信処理のデバイス管理モード(その1)の処理手順(初期起動時)を示すフローチャートである。 本実施の形態に従う通信処理のデバイス管理モード(その1)の処理手順(通信処理の実行中)を示すフローチャートである。 本実施の形態に従う通信処理のデバイス管理モード(その2)の処理を説明するための模式図である。 本実施の形態に従う通信処理のデバイス管理モード(その2)の処理手順(初期起動時)を示すフローチャートである。 本実施の形態に従う通信処理の通信状況管理モードの処理を説明するための模式図である。 本実施の形態に従う通信処理の通信状況管理モードの処理手順を示すフローチャートである。 本実施の形態に従う通信処理の応用例1を説明するための模式図である。 本実施の形態に従う通信処理の応用例2を説明するための模式図である。 本実施の形態に従う通信処理の応用例3を説明するための模式図である。
本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。
<A.ネットワーク化システム全体構成>
まず、本実施の形態に従う通信処理を採用したネットワーク化システムの全体構成について説明する。図1は、本実施の形態に従うネットワーク化システム1の全体構成の一例を示す模式図である。
図1を参照して、ネットワーク化システム1では、ネットワークが複数レベルに接続されており、各レベルのネットワークには、それぞれ異なる機能が割り当てられる。具体的には、4つのレベルのネットワーク11〜14が設けられている。
ネットワーク11は、コントロールレベルのネットワークであり、マシン制御機器である制御装置100と、装置/ライン管理機器である装置/ライン管理装置190およびSCADA(Supervisory Control And Data Acquisition)機能を提供する表示装置180とが接続されており、装置間でデータを交換できるリンクが形成される。ネットワーク11は、コントローラ(制御装置100)と管理機器(装置/ライン管理装置190および表示装置180)との間でデータリンクを構築する。
制御装置100には、センサ、アクチュエータといった各種デバイスが接続される。これらのデバイスは、制御装置100に装着される入出力ユニットを介して直接接続される場合もあるが、フィールドネットワークを介して接続されることもある。図1に示す構成例においては、制御装置100には、フィールドネットワーク110および120が接続されており、それぞれのフィールドネットワークには、デバイス群112および122が接続される。デバイス群は、フィールド信号を取得する入力デバイス、および、制御装置100からの指示に従ってフィールドに対して何らかのアクションを行う出力デバイスあるいはアクチュエータを含む。したがって、図1に示すネットワーク化システム1には、ネットワーク11〜14の4つのレベルに加えて、フィールドレベルのフィールドネットワークがさらに追加されることになる。フィールドレベルは、入力およびデバイス制御を主たる機能として提供する。
ネットワーク12は、管理レベルのネットワークであり、装置/ライン管理装置190および表示装置180と、製造管理装置200およびデータベース装置210とが接続されており、装置間でデータを交換できるリンクが形成される。ネットワーク12は、管理情報の遣り取りおよび装置/ラインの情報の伝送を主たる機能として提供する。
ネットワーク13は、コンピュータレベルのネットワークであり、製造管理装置200およびデータベース装置210と生産計画などを管理する生産管理装置300とが接続されており、装置間でデータを交換できるリンクが形成される。ネットワーク13は、生産管理および情報系のデータの伝送を主たる機能として提供する。
ネットワーク14は、インターネットなどの外部ネットワークであり、生産管理装置300とクラウドやサプライチェーンなどとが接続される。
図1に示すネットワーク化システム1において、ネットワーク12およびそれ以下のレベルは、「ファクトリーネットワーク」とも称され、機器を現実に制御するためのデータ(以下、「制御系データ」と総称することもある)を遣り取りする制御系通信を提供する。一方、ネットワーク13以上のレベルは、「コーポレートネットワーク」とも称され、生産ライン/工場での生産活動などを監視・管理・制御するためのデータ(以下、「情報系データ」と総称することもある)を遣り取りする情報系通信を提供する。
ネットワーク11〜14およびフィールドネットワーク110,120には、このような要求される特性の違いに応じたプロトコルおよびフレームワークが採用される。例えば、ファクトリーネットワークに属するネットワーク11および12ならびにフィールドネットワーク120のプロトコルとしては、汎用的なEthernet(登録商標)上に制御用プロトコルを実装した産業用オープンネットワークであるEtherNet/IP(登録商標)を用いてもよい。また、フィールドネットワーク110としては、マシンコントロール用ネットワークの一例であるEtherCAT(登録商標)を採用してもよい。
このようなマシンコントロールに適したネットワーク技術を採用することで、機器間の伝送に要する時間が保証されたリアルタイム性を提供できる。但し、1回の通信周期で伝送可能なデータ量には制限がある。
一方、コーポレートネットワークに属するネットワーク13および14のプロトコルとしては、接続先の多様性を担保するために、汎用的なEthernetなどが用いられる。汎用的なEthernetを採用することで、リアルタイム性は実現できないものの、送信可能なデータ量などの制限は存在しない。
<B.要求される通信性能>
図1に示すファクトリーネットワークにおいては、基本的には、上述したような制御系データが周期的に伝送されることになるが、コーポレートネットワークに含まれる製造管理装置200、データベース装置210、生産管理装置300などが要求する情報系データも伝送する必要がある。なお、以下の説明においては、ファクトリーネットワークとの対比において、コーポレートネットワークに含まれる装置の全部または一部を「上位管理システム」とも総称する。
さらに、制御系データのような高速なリアルタイム性は要求されないものの、ある程度の到着時刻の保証が必要なデータ(例えば、機器の設定および管理に関するデータ)も存在する。以下では、説明の便宜上、このようなデータを「制御情報系データ」とも称す。
図2は、図1のネットワーク化システム1において伝送されるデータ種別を示す図である。図2を参照して、ネットワーク化システム1においては、主として、(1)制御系データ、(2)制御情報系データ、(3)情報系データ、が伝送される。なお、これらのいずれにも分類されないデータが伝送されることを排除するものではなく、さらに別の種類のデータを伝送するようにしてもよい。
(1)制御系データは、その主旨として、機器を現実に制御するためのデータを含む。すなわち、制御系データは、製造装置または生産設備の制御に用いるデータに相当する。制御系データの一例としては、サーボ指令値、エンコーダ値、センサのON/OFF値などが挙げられる。このような制御系データの通信周期は10msec以下に設定されることが好ましい。そして、この通信周期を確実に保証する必要がある。一方で、ネットワーク上で伝送される制御系データの内容は予め設定されているため、データサイズとしては、固定的で比較的小さい。
(2)制御情報系データは、情報系通信において用いられるデータのうち、制御に必要な情報に分類されるものであり、その主旨として、機器の設定・管理に関するデータを含む。すなわち、制御情報系データは、指定された時間内に送信先へ到着させるのに必要なデータに相当する。制御情報系データの一例としては、センサデバイスに対するしきい値といった各種パラメータの設定、各機器に格納されている異常情報(ログ)の収集、各機器に対する更新用のファームウェアなどが挙げられる。このようなネットワーク上で伝送される制御情報系データの内容は多種多様であるが、基本的には、機器の設定・管理に関するデータであるので、データサイズとしては、数kbyte程度が想定される。そのため、制御情報系データの通信周期は100msec未満に設定されることが好ましい。通信周期は比較的長くてもよいが、データの到達時間は保証される必要がある。なお、到着時間の指定は、ユーザが任意に行ってもよいし、データを生成または要求するアプリケーションもしくは装置が予め定められたルールに従って行ってもよい。
(3)情報系データは、情報系通信において用いられるデータのうち、上位管理システムに必要な情報に分類されるものであり、その主旨として、上位管理システムで利用されるデータを含む。情報系データの一例としては、ある期間に亘るセンサでの収集情報といった統計的データや、何らかの条件で撮像された監視画像(静止画像/動画像)などが挙げられる。このようなネットワーク上で伝送される制御系データの内容は多種多様であり、データサイズとしても多種多様である。典型的には、情報系データのデータサイズは、制御情報系データのデータサイズより大きいことが想定される。また、機器の制御には直接関係しないので、情報系データはベストエフォート形式で伝送されることが想定される。この場合、リアルタイム性(すなわち、指定された時間にデータが到着すること)ではなく、スループットの大きさが重視される。
なお、データ毎に、制御系、制御情報系、情報系のいずれに分類されるのかを一意に決定するようにしてもよいし、同じデータであっても、その用途に応じて、制御系、制御情報系、情報系のいずれに分類されるのかが変化するようにしてもよい。後者の場合には、典型的には、各データが対象となるレイヤでどのように使われるかによって、いずれの種別に分類されるのかが決定されることになる。このような分類は、データ毎に予め設定されていてもよい。
このように、制御系データについては高速高精度の通信が要求され、情報系データについては大容量の通信が要求される。そして、制御情報系データについては、制御系データと情報系データとの間の中間的な特性が要求される。
本実施の形態に従う通信処理は、これらの互いに異なる3種類の要件をそれぞれ満たしつつデータ伝送を行うための構成および処理を提供する。すなわち、本実施の形態に従う通信処理は、要求される特性の異なる3種類のデータを単一ネットワーク上で統合した通信を実現する。
より具体的には、予め定められたシステム周期を維持しつつ、3種類のデータを適宜パケットに格納するという動的スケジューリングの機能を提供する。
<C.ハードウェア構成>
本実施の形態に従う通信装置は、予め定められた周期毎にデータが更新されるネットワークに接続される。その上で、本実施の形態に従う通信装置は、制御系データ、制御情報系データ、情報系データのそれぞれを適切にスケジューリングする。本実施の形態に従う通信装置は、これらの3種類のデータが伝送される経路上に配置されるものであれば、特に、その実装形態については限定されるものではない。
以下では、ネットワーク11に接続される制御装置100の通信機能の一部として実装された場合を想定して説明する。但し、制御装置100に限定されることなく、例えば、ネットワーク11に接続される装置/ライン管理装置190または表示装置180に係る通信機能の一部として実装してもよいし、フィールド上の各種機器をネットワーク化するためのリモート入出力装置に係る通信機能の一部として実装してもよい。
図3は、本実施の形態に従う通信装置を含む制御装置100のハードウェア構成の一例を示す模式図である。制御装置100は、典型的には、PLCをベースとして構成されてもよい。図3を参照して、制御装置100は、主たるコンポーネントとして、プロセッサ102と、メモリ104と、ストレージ106と、ネットワークコントローラ130と、フィールドネットワークコントローラ140,150と、内部バスコントローラ160とを含む。
プロセッサ102は、ストレージ106に格納されているシステムプログラム107およびユーザアプリケーションプログラム108をメモリ104に読み出して実行することで、後述するような処理を含む各種処理を実現する。メモリ104は、DRAM(Dynamic Random Access Memory)やSRAM(Static Random Access Memory)などの揮発性記憶装置からなる。ストレージ106は、ハードディスクやフラッシュメモリなどの不揮発性記憶装置からなる。ストレージ106には、制御装置100の各部を制御するためのシステムプログラム107に加えて、制御対象などに応じて設計されるユーザアプリケーションプログラム108が格納される。
ネットワークコントローラ130は、制御装置100がネットワーク11を介して他の装置との間でデータを遣り取りするためのインターフェイスを提供する。ネットワークコントローラ130は、主たるコンポーネントとして、受信回路(RX)131と、受信バッファ132と、送受信コントローラ133と、送信バッファ134と、送信回路(TX)135とを含む。
受信回路131は、ネットワークコントローラ130上を定周期で伝送されるパケットを受信して、その受信したパケットに格納されているデータを受信バッファ132に書込む。送受信コントローラ133は、受信バッファ132に書込まれた受信パケットを順次読出すとともに、当該読出したデータのうち制御装置100での処理に必要なデータのみをプロセッサ102へ出力する。送受信コントローラ133は、プロセッサ102からの指令に従って、他の装置へ送信すべきデータあるいはパケットを送信バッファ134へ順次書込む。送信回路135は、ネットワークコントローラ130上をパケットが転送される周期に応じて、送信バッファ134に格納されているデータを順次送出する。
フィールドネットワークコントローラ140は、制御装置100がフィールドネットワーク110を介して各種デバイス(図1に示すデバイス群112)との間でデータを遣り取りするためのインターフェイスを提供する。フィールドネットワークコントローラ140は、主たるコンポーネントとして、受信回路(RX)141と、受信バッファ142と、送受信コントローラ143と、送信バッファ144と、送信回路(TX)145とを含む。これらのコンポーネントの機能は、ネットワークコントローラ130の対応するコンポーネントの機能と同様であるので、詳細な説明は繰返さない。
同様に、フィールドネットワークコントローラ150は、制御装置100がフィールドネットワーク120を介して各種デバイス(図1に示すデバイス群122)との間でデータを遣り取りするためのインターフェイスを提供する。フィールドネットワークコントローラ150は、主たるコンポーネントとして、受信回路(RX)151と、受信バッファ152と、送受信コントローラ153と、送信バッファ154と、送信回路(TX)155とを含む。これらのコンポーネントの機能は、ネットワークコントローラ130およびフィールドネットワークコントローラ140の対応するコンポーネントの機能と同様であるので、詳細な説明は繰返さない。
内部バスコントローラ160は、制御装置100に装着される入出力ユニットと間で、が内部バス(図示しない)を介してデータを遣り取りするためのインターフェイスを提供する。内部バスコントローラ160は、主たるコンポーネントとして、受信回路(RX)161と、受信バッファ162と、送受信コントローラ163と、送信バッファ164と、送信回路(TX)165とを含む。これらのコンポーネントの機能は、ネットワークコントローラ130の対応するコンポーネントの機能と同様であるので、詳細な説明は繰返さない。
<D.ソフトウェア構成>
次に、本実施の形態に従う通信処理(動的スケジューリング)を実現するためのソフトウェア構成の一例について説明する。図4は、本実施の形態に従う通信処理を実現するための制御装置100のソフトウェア構成の一例を示す模式図である。
図4を参照して、制御装置100のプロセッサ102ではスケジューラ170が実行される。スケジューラ170は、予め定められたシステム周期に従って、複数の処理の実行順序や実行中断などを決定する。より具体的には、スケジューラ170は、ユーザアプリケーション実行処理173と、各種処理を含む周辺処理174と、制御系通信処理175と、制御情報系通信処理176と、情報系通信処理177に対して、予め定められた優先度およびシステム周期などに従って、処理リソース(プロセッサ時間およびメモリなど)を割り当てる。
ユーザアプリケーション実行処理173は、ユーザアプリケーションプログラム108の実行に係る処理を含む。
制御系通信処理175は、制御系データに係る処理、例えば、データ作成、エンコーディング、デコーディング、抽出、加工編集などを含む。同様に、制御情報系通信処理176は、制御情報系データに係る処理を含み、情報系通信処理177は、情報系データに係る処理を含む。
さらに、制御装置100のプロセッサ102には、通信ドライバ178が実装されており、通信ドライバ178がネットワークコントローラ130(図3参照)などを制御する。
スケジューラ170は、3種類のデータ(制御系データ、制御情報系データ、情報系データ)を互いに異なる要求特性を満足できるように、動的スケジューリングを行う。この動的スケジューリングとしては、典型的には、通信時間管理モード、デバイス管理モード、通信状況管理モードの3つの管理モード172が用意されている。これらの3つの管理モードのすべてを実装する必要はなく、制御装置100を含むネットワーク化システム1での処理全体を考慮して、必要な管理モードのみを実装するようにしてもよい。3つの管理モード172に加えて、あるいは、3つの管理モード172に代えて、3つの管理モード172以外の管理モードを採用してもよい。
<E:動的スケジューリング>
本実施の形態に従う通信処理(動的スケジューリング)は、要求されるデータの特性および各種状況に対して、動的に最適化する手法を含む。より具体的には、本実施の形態に従う動的スケジューリングは、予め定められた周期毎にデータが更新されるネットワークに適用されるものであり、基本的には、制御系通信を最優先しつつ、残りの通信帯域を他の通信において最大限に活用する。
本明細書において、「通信帯域」とは、ネットワーク上でデータを伝送するためのリソースを意味し、時間分割方式でデータを伝送する場合には、データを伝送するために割り当てられる時間幅を意味する。あるいは、周波数分割方式または符号分割方式でデータを伝送する場合には、データを伝送するために割り当てられる周波数または符号系列(論理的なチャネル)を意味し得る。本実施の形態に従う動的スケジューリングは、対象のネットワークが有している有限の通信帯域に制約の下、各データに対して必要な通信帯域をどのように割り当てるのかという問題に向けられている。
また、本実施の形態に従う動的スケジューリングの実装については、任意の形態を採用できる。例えば、ネットワークを管理するホストと、当該ホストからの指示に従って通信処理を実行する1または複数のクライエントとからなる構成においては、本実施の形態に従う動的スケジューリングは、ホストに実装されてもよい。あるいは、クライエントにその一部の機能が実装されるとともに、ネットワーク全体として、本実施の形態に従う動的スケジューリングを実現するようにしてもよい。さらに、マスターと1または複数のスレーブとから構成されるネットワークについても同様の方法で実装するようにしてもよい。
すなわち、本実施の形態に従う動的スケジューリングの実装形態については、対象となるネットワークの構成や機能に応じて、一括または分散して適宜実装することができる。
以下、本実施の形態に従う通信処理(動的スケジューリング)に関して、いくつかの具体例を示す。すなわち、図4に示す3つの管理モード((1)通信時間管理モード、(2)デバイス管理モード、(3)通信状況管理モード)の観点から、動的スケジューリングの具体的な処理を例示する。
(1)通信時間管理モードは、主として、各通信処理の優先度を考慮したスケジューリングである。(2)デバイス管理モードは、主として、通信先デバイスの状態を考慮したスケジューリングである。(3)通信状況管理モードは、主として、通信環境を考慮したスケジューリングである。
(e1.通信時間管理モード)
まず、通信時間管理モードについて説明する。通信時間管理モードでは、制御系通信を最優先し、残りの通信帯域を最大限に活用することを主旨とする。
図5は、本実施の形態に従う通信処理の通信時間管理モードの処理を説明するための模式図である。図5を参照して、本実施の形態に従う通信処理においては、予め定められたシステム周期Tsに従って、制御系データ、制御情報系データ、情報系データの送受信(それぞれ、制御系通信、制御情報系通信、情報系通信と記す)がスケジューリングされる。
通信時間管理モードにおいては、まず、制御系通信が優先的に割り当てられる。図5(A)に示すように、システム周期Tsに対して、制御系通信に要する処理時間t1が先に割り当てられる。図5(B)に示すように、必要に応じて、制御系通信を行っていない空帯域で制御情報系通信が行われる。すなわち、システム周期Tsのうち、制御系通信に要する処理時間t1を除いた残り時間に対して、制御情報系通信に要する処理時間t2が割り当てられる。
制御情報系通信は、すべてのシステム周期で発生するものではないので、図5(C)に示すように、システム周期Tsのうち、制御系通信に要する処理時間t1を除いた残り時間に対して、情報系通信に要する処理時間t3が割り当てられることもある。すなわち、情報系通信は、制御系通信および制御情報系通信のいずれもが存在しない通信帯域で行われる。
また、図5(D)に示すように、システム周期Tsに対して、制御系通信に要する処理時間t1、制御情報系通信に要する処理時間t2、および、情報系通信に要する処理時間t3のすべてが割り当てられてもよい。
図6は、本実施の形態に従う通信処理の通信時間管理モードの処理手順を示すフローチャートである。図6に示す処理手順は、典型的には、制御装置100のプロセッサ102(図3)によってシステム周期毎に繰返し実行される。
図6を参照して、制御装置100は、制御系通信に要する処理時間t1を算出する(ステップS100)とともに、システム周期Tsから算出した処理時間t1を除いた残り時間Tr1を算出する(ステップS102)。そして、残り時間Tr1が負の値であれば(ステップS104においてNOの場合)、制御系通信に要する処理時間t1がシステム周期Tsを超えることを意味するので、制御装置100はエラー処理を実行し(ステップS106)、当該システム周期での処理は終了する。
これらのステップS100〜S106に係る処理は、製造装置または生産設備の制御に用いる制御系データ(第1のデータ)を予め定められた周期毎に更新するのに必要な第1の通信帯域を確保するスケジューリング処理に相当する。つまり、これらのステップにおいて、制御系通信に要する時間が確保される。
一方、残り時間Tr1がゼロ以上であれば(ステップS104においてYESの場合)、制御装置100は、制御情報系通信に要する処理時間t2を算出する(ステップS108)とともに、ステップS102において算出した残り時間Tr1から処理時間t2を除いた残り時間Tr2を算出する(ステップS110)。そして、残り時間Tr2が負の値であれば(ステップS112においてNOの場合)、システム周期Ts内に対象の制御情報系通信を追加できないことを意味するので、制御装置100は、残り時間Tr2がゼロ以上となるように、通信対象の制御情報系データを分割する(ステップS114)。すなわち、制御情報系データに関するスケジューリングにおいては、対象の制御情報系データを、各システム周期において利用可能な通信帯域に応じたデータサイズに分割した上で、分割後のそれぞれのデータを複数のシステム周期に割り当てる。
そして、通信対象の制御情報系データの分割後のデータ数(すなわち、必要なシステム周期の数)に基づいて、対象の制御情報系データを指定された時間内に送信先へ到着させることができるか否かを判断する(ステップS116)。対象の制御情報系データを指定された時間内に送信先へ到着させることができれば(ステップS116においてYESの場合)、ステップS108以下の処理が繰返される。これらの分割されたデータは、次のシステム周期以降に再度割り当てられることになる。
これに対して、対象の制御情報系データを指定された時間内に送信先へ到着させることができなければ(ステップS116においてNOの場合)、通信異常が通知される(ステップS118)。制御情報系データに関する到着時間は、予めユーザまたはアプリケーションによって指定されていてもよい。
この通信異常の通知は、システムフラグをオンするなどの方法を用いてもよいし、制御装置100の表示面にあるインジケータを点灯させるなどの方法を採用してもよい。このように、制御情報系データの分割によって、制御情報系データの指定された時間(到着時間)を保証できない場合には、適切な方法で通信異常を通知するようにしてもよい。このような通信異常の通知を受けて、ユーザは、指定された時間(到着時間)の要件を緩和するか、デバイス側のアプリケーション処理量を削減するなどの措置をとることができる。このように、ステップS116およびS118は、制御情報系データの分割により、制御情報系データを指定された時間内に送信先へ到着させることができない場合に、異常通知を行う処理に相当する。
上述のステップS108〜S118に係る処理は、ネットワークが有する通信帯域のうち制御系データに向けられた通信帯域以外の通信帯域内に、制御情報系データ(第2のデータ)を指定された時間内に送信先へ到着させるのに必要な通信帯域を確保するスケジューリング処理に相当する。つまり、これらのステップにおいて、制御情報系通信に要する時間が確保される。なお、通信対象の制御情報系データが存在しない場合には、ステップS108〜S118はスキップされてもよい。
一方、残り時間Tr2がゼロ以上であれば(ステップS112においてYESの場合)、制御装置100は、情報系通信に要する処理時間t3を算出する(ステップS120)とともに、ステップS110において算出した残り時間Tr2から処理時間t3を除いた残り時間Tr3を算出する(ステップS122)。そして、残り時間Tr3が負の値であれば(ステップS124においてNOの場合)、システム周期Ts内に対象の情報系通信を追加できないことを意味するので、制御装置100は、残り時間Tr3がゼロ以上となるように、通信対象の情報系データを分割する(ステップS126)。この分割されたデータは、次のシステム周期以降に再度割り当てられることになる。
これらのステップS120〜S126に係る処理は、ネットワークが有する通信帯域のうち、制御系データに向けられた通信帯域および制御情報系データに向けられた通信帯域のいずれにも設定されていない通信帯域内に、情報系データ(第3のデータ)を伝送するための通信帯域を確保するスケジューリング処理に相当する。つまり、これらのステップは、情報系通信に要する時間を確保する処理に相当する。なお、通信対象の情報系データが存在しない場合には、ステップS120〜S126はスキップされてもよい。
以上のような処理手順がシステム周期毎に繰返し実行されることで、通信時間管理モードでの動的スケジューリングが実現される。
図6に示す処理手順は、制御情報系通信の指定された時間(到着時間)に余裕があり、情報系通信が一定時間以上行われておらず、送信できていないフレームが溜まっているような状態を想定している。この場合、同一のシステム周期において、制御系データ、制御情報系データ、情報系データの3種類を送信または受信することができる。但し、情報系通信を行ったときの回線状況に基づいて、制御情報系通信についての指定された時間(到着時間)を保証できないと判断された場合には、情報系通信を行わないようにしてもよい。すなわち、情報系通信については、回線状況などに基づいて、余裕がある期間でのみ実行するようにしてもよい。
さらに、情報系データを制御情報系データよりも優先する例外を設けてもよい。例えば、情報系通信が一定時間以上行われておらず、送信できないフレームが溜まっているような状態がさらに長い時間に亘って継続して場合であって、かつ、制御情報系通信に余裕がある場合には、制御情報系通信の到着時間を保証する限りで、情報系通信を優先するようにしてもよい。つまり、先に、情報系通信に必要な通信帯域を先に割り当てるようなしてもよい。
(e2.デバイス管理モード(その1))
次に、デバイス管理モード(その1)について説明する。デバイス管理モード(その1)では、受信側デバイスの特性に応じて、データサイズ/通信周期を最適化することを主旨とする。
図7は、本実施の形態に従う通信処理のデバイス管理モード(その1)の処理を説明するための模式図である。図7には、制御系データに加えて、特定のデバイスに対して制御情報系データを送信する場合の通信処理を示す。
図7に示すデバイス管理モード(その1)においても、基本的な通信帯域のスケジューリングは、上述の通信時間管理モードと同様である。例えば、図7(A)に示すように、各システム周期において、制御系データに加えて、特定のデバイス向けの制御情報系データが送信される。そのため、上述の通信時間管理モードと同様の処理については、詳細な説明は繰返さない。
制御情報系データを受信するデバイスの受信バッファなどはデバイス固有の性能に影響されるので、1回に送信できるデータサイズが制限されることもある。このような場合、図7(B)に示すように、デバイス管理モード(その1)においては、送信される制御情報系データのデータサイズの送信単位を小さくする。すなわち、1回に送信する制御情報系データのデータサイズを小さくするとともに、より多くの送信回数に分けてデータ全体を送信する。このように、受信側デバイスの受信可能な最大サイズが小さい場合には、送信サイズの送信単位を小さくする。この送信単位の縮小によって、当初は制御情報系データの通信に用いられていた通信帯域が空くので、この空いた通信帯域については、別のデバイス向けの制御情報系データの通信などに活用されてもよい。
図8は、本実施の形態に従う通信処理のデバイス管理モード(その1)の処理手順(初期起動時)を示すフローチャートである。図8に示す処理手順は、典型的には、制御装置100のプロセッサ102(図3)によって、通信処理の初期起動時に実行される。この処理において、通信相手となるデバイスの受信可能な最大サイズに応じて送信単位の変更が実行される。
図8を参照して、制御装置100は、送信予定のデータサイズが送信先のデバイスでの受信可能な最大サイズ以下であるか否かを判断する(ステップS200)。送信先のデバイスでの受信可能な最大サイズは、予め用意されている設定に基づいて判断してもよいし、送信先のデバイスに直接問い合わせて取得するようにしてもよい。
送信予定のデータサイズが送信先のデバイスでの受信可能な最大サイズを超えていれば(ステップS200においてNOの場合)、制御装置100は、送信予定のデータを送信先のデバイスでの受信可能な最大サイズに送信単位を変更する(ステップS202)。これに対して、送信予定のデータサイズが送信先のデバイスでの受信可能な最大サイズ以下であれば(ステップS200においてYESの場合)、送信単位の変更は行われない。
このように、本実施の形態に従う通信処理のデバイス管理モード(その1)においては、送信先にて受信可能なデータサイズに応じて、制御情報系データ(第2のデータ)を分割した上で、分割後のそれぞれのデータを複数のシステム周期に割り当てる。
また、再度図7を参照して、制御情報系データを受信するデバイスの処理能力が低く、制御情報系データが許容可能なスループットが制限されることもある。このような場合、図7(C)に示すように、デバイス管理モード(その1)においては、制御情報系データの通信周期を長く変更する。すなわち、システム周期毎に制御情報系データを送信するのではなく、システム周期のN倍の通信周期で制御情報系データを送信するようにしてもよい。このように、受信側デバイスでの処理が指定時間内に完了できておらず、この結果、受信側デバイスが制御情報系データを受信できない場合には、システム周期TsのN倍にするといった方法で、通信周期を長くするようにしてもよい。この通信周期の変更によって、当初は制御情報系データの通信に用いられていた通信帯域が空くので、この空いた通信帯域については、別のデバイス向けの制御情報系データの通信などに活用されてもよい。
図9は、本実施の形態に従う通信処理のデバイス管理モード(その1)の処理手順(通信処理の実行中)を示すフローチャートである。図9に示す処理手順は、典型的には、制御装置100のプロセッサ102(図3)によって、通信処理の実行中に適宜実行される。具体的には、通信相手となるデバイスの受信可能な時間間隔に応じて通信周期が動的に設定される。
図9を参照して、制御装置100は、デバイスの受信エラーが指定回数未満であるか否かを判断する(ステップS210)。送信先のデバイスの受信エラーの回数は、通信を管理する主体から取得してもよいし、送信先のデバイスからの応答メッセージに基づいて判断してもよい。デバイスの受信エラーが指定回数に到達していれば(ステップS210においてYESの場合)、ステップS214の処理が実行される。
デバイスの受信エラーが指定回数未満であれば(ステップS210においてNOの場合)、デバイスから受信応答を受信できない回数が指定回数未満であるか否かを判断する(ステップS212)。デバイスから受信応答を受信できない回数が指定回数に到達していれば(ステップS212においてYESの場合)、ステップS214の処理が実行される。
ステップS210またはS212において何らかのエラーの発生が検出されると、制御装置100は、通信周期をシステム周期のN倍にするなどして、送信予定のデータの通信周期を長くする(ステップS214)。これに対して、ステップS210またはS212において何らのエラーの発生も検出されなければ、制御装置100は、初期設定に従って通信を継続する。
このように、本実施の形態に従う通信処理のデバイス管理モード(その1)においては、制御情報系データ(第2のデータ)を分割した上で、分割後のそれぞれのデータを、送信先での受信データの処理状況に応じて、システム周期より長い周期で順次送信する。すなわち、制御装置100は、通信処理の実行中に、送信先のデバイスでの受信処理が適切に実行できない場合に、通信周期を実質的に長くする。送信先での受信データの処理状況の判断方法として、送信先での受信エラーの回数、および、送信先から受信応答を受信できなかった回数を例示したが、これらに限られることなく、任意の情報を用いてもよい。
なお、図7または図9に示すように、制御情報系データの分割または通信周期の延長によって、制御情報系通信の指定された時間(到着時間)を保証できない場合には、適切な方法で通信異常を通知するようにしてもよい(上述の図6のステップS116などと同様)。このような通信異常の通知を受けて、ユーザは、指定された時間(到着時間)の要件を緩和するか、デバイス側のアプリケーション処理量を削減するなどの措置をとることができる。また、初期起動時において、送信予定のデータがシステム周期内で送信できないと判断された場合も同様に、通信異常を通知するようにしてもよい。
さらに、図7(B)に示す送信単位の変更と図7(C)に示す通信周期の増大とを組み合わせてもよい。
(e3.デバイス管理モード(その2))
次に、デバイス管理モード(その2)について説明する。デバイス管理モード(その2)では、受信側デバイスの特性に応じて、データサイズ/通信周期を最適化することを主旨とする。
図10は、本実施の形態に従う通信処理のデバイス管理モード(その2)の処理を説明するための模式図である。図10には、制御系データに加えて、特定のデバイスに対して制御情報系データを送信する場合の通信処理を示す。
図10に示すデバイス管理モード(その2)においても、基本的な通信帯域のスケジューリングは、上述の通信時間管理モードと同様である。例えば、図10(A)に示すように、各システム周期において、制御系データに加えて、特定のデバイス向けの制御情報系データが送信される。そのため、上述の通信時間管理モードと同様の処理については、詳細な説明は繰返さない。
上述のデバイス管理モード(その1)の場合とは逆に、制御情報系データを受信するデバイスの受信バッファが大きい場合や高速な受信処理が可能な場合には、同一のシステム周期内に、同一のデバイス向け制御情報系データまたは情報系データを複数送信するようにしてもよい。つまり、受信側デバイスの処理に余裕があり、システム周期内に複数回の受信が可能な場合には、図10(B)に示すように、予め定められたシステム周期内に、制御情報系データまたは情報系データを複数回送信するようにしてもよい。すなわち、デバイス管理モード(その2)においては、同一のシステム周期において、同一のデバイス向けの制御情報系データまたは情報系データを複数個送信するようにしてもよい。
この送信回数の増大によって、特定のデバイス向けの制御情報系データまたは情報系データの送信に要する時間を短縮できる。
さらに、図10(B)においてシステム周期内で複数回受信されるデータの合計サイズが受信側デバイスの受信可能な最大サイズより小さい場合には、図10(C)に示すように、当該複数回分のデータをまとめてより大きな1つのデータとして送信するようにしてもよい。データの送信単位を大きくすることで、オーバヘッドを低減できる。
図11は、本実施の形態に従う通信処理のデバイス管理モード(その2)の処理手順(初期起動時)を示すフローチャートである。図11に示す処理手順は、典型的には、制御装置100のプロセッサ102(図3)によって、通信処理の初期起動時に実行される。この処理において、通信相手となるデバイスの受信可能な最大サイズに応じて送信単位の変更が実行される。
図11を参照して、制御装置100は、システム周期内における受信側デバイスの空き時間が所定時間以上存在するか否かを判断する(ステップS220)。システム周期内における受信側デバイスの空き時間が所定時間以上存在すれば(ステップS220においてYESの場合)、制御装置100は、同一のシステム周期内におけるデータの送信回数を1回分加算する(ステップS222)。そして、制御装置100は、ステップS222において加算された後の送信回数に従ってデータを送信する場合において、同一のシステム周期内で複数回送信されるデータの合計サイズが受信側デバイスの受信可能な最大サイズより小さいか否かを判断する(ステップS224)。
同一のシステム周期内で複数回送信されるデータの合計サイズが受信側デバイスの受信可能な最大サイズより小さければ(ステップS224においてYESの場合)、制御装置100は、同一のシステム周期内で複数回送信されるデータを結合して1つのフレームを構成する(ステップS226)。
一方、システム周期内における受信側デバイスの空き時間が所定時間以上存在しなければ(ステップS220においてNOの場合)、あるいは、同一のシステム周期内で複数回送信されるデータの合計サイズが受信側デバイスの受信可能な最大サイズより大きければ(ステップS224においてNOの場合)、各システム周期における送信予定のデータの割り当ては変更されない。
(e4.通信状況管理モード)
次に、通信状況管理モードについて説明する。通信状況管理モードでは、通信環境の状態に応じてデータサイズを動的に最適化することを主旨とする。
図12は、本実施の形態に従う通信処理の通信状況管理モードの処理を説明するための模式図である。図12には、制御系データに加えて、特定のデバイスに対して制御情報系データを送信する場合の通信処理を示す。
図12に示す通信状況管理モードにおいても、基本的な通信帯域のスケジューリングは、上述の通信時間管理モードと同様である。そのため、上述の通信時間管理モードと同様の処理については、詳細な説明は繰返さない。
図12(A)に示すように、制御系通信を最優先しつつ、残りの通信帯域を他の通信において最大限に活用するという方針に従って、制御情報系通信および情報系通信を割り当てると、制御情報系データおよび情報系データのデータサイズは比較的大きくなる。データサイズを大きくすることで、通信オーバヘッドが減り、ネットワークの利用効率を高めることができる。一方で、通信路に侵入する各種ノイズなどの影響によって、データの送受信が失敗すると、データの再送処理が実行される。このような再送処理を考えると、データサイズは可能な限り小さい方がよい。つまり、送受信に失敗した部分のみを再送すればよいので、リカバリを効率化できる。このように、データサイズが大きいと再送処理のデータサイズも大きくなるが、再送単位を小さくすることで、リカバリを容易化できる。
したがって、通信状況が良好な場合には、再送処理が必要になる確率が低いので、データサイズを可能な限り大きくする一方で、通信状況が良好ではない場合には、再送処理が必要になる確率が高いので、データサイズ(単位サイズ)を適切な大きさまで小さくすることが好ましい。
なお、送信単位の変更により通信オーバヘッドが発生するため、制御情報系通信および情報系通信には適用するものの、制御系通信には適用しないようにすることが好ましい。情報系通信については、基本的には、リアルタイム性が要求されないので、送信単位の変更を実施するか否かをユーザが適宜選択できるようにしてもよい。
図13は、本実施の形態に従う通信処理の通信状況管理モードの処理手順を示すフローチャートである。図13に示す処理手順は、典型的には、制御装置100のプロセッサ102(図3)によって、通信処理の実行中に適宜実行される。具体的には、通信相手となるデバイスの受信可能な時間間隔に応じて通信周期が動的に設定される。
図13を参照して、制御装置100は、送信先からの受信応答のフレームが破損していた回数が指定回数未満であるか否かを判断する(ステップS300)。送信先からの受信応答のフレームが破損していた回数は、制御装置100にて送信先のデバイス毎にカウントしてもよいし、通信を管理する主体から取得してもよい。送信先からの受信応答のフレームが破損していた回数が指定回数に到達していれば(ステップS300においてYESの場合)、ステップS304の処理が実行される。
送信先からの受信応答のフレームが破損していた回数が指定回数未満であれば(ステップS300においてNOの場合)、受信データが破損していたことを送信先のデバイスから通知された回数が指定回数未満であるか否かを判断する(ステップS302)。受信データが破損していたことを送信先のデバイスから通知された回数が指定回数に到達していれば(ステップS302においてYESの場合)、ステップS304の処理が実行される。
ステップS300またはS302において何らかのエラーの発生が検出されると、制御装置100は、送信するデータの送信単位を小さくする(ステップS304)。
これに対して、ステップS300またはS302において何らのエラーの発生も検出されなければ、制御装置100は、初期設定のデータサイズに従って通信を継続する。
通信状況管理モードによれば、ノイズが多くて通信環境が悪い状況においては、送信単位を小さくすることで、再送処理を含めてトータルの伝送効率を高めることができる。一方で、オーバヘッドが増加するので、このオーバヘッドの増加により制御情報系通信の指定された時間(到着時間)を保証できない場合には、適切な方法で通信異常を通知するようにしてもよい。このような通信異常の通知を受けて、ユーザは、指定された時間(到着時間)の要件を緩和するか、デバイス側のアプリケーション処理量を削減するなどの措置をとることができる。
このように、本実施の形態に従う通信処理の通信状況管理モードにおいては、ネットワークの通信状況に応じて、制御情報系データ(第2のデータ)を分割して送信する単位サイズを変化させる。併せて、本実施の形態に従う通信処理の通信状況管理モードにおいては、ネットワークの通信状況に応じて、情報系データ(第3のデータ)についても、分割して送信する単位サイズを変化させるようにしてもよい。ネットワークの通信状況の判断方法として、送信先からの受信応答のうち破損していたものの数、および、受信データの破損を示す送信先からの通知の数を例示したが、これらに限られることなく、任意の情報を用いてもよい。
(e5.その他)
上述の処理手順においては、説明の簡素化のため、制御情報系通信を一律に扱う処理例を示したが、制御情報系通信の各々に対して、異なる優先度または指定された時間(到着時間)を設定するようにしてもよい。例えば、後述するような異常情報の通知については、相対的に優先度を高く設定する一方で、パラメータ設定などについては、相対的に優先度を低くするようにしてもよい。
このような優先度の設定に応じて、高い優先度が設定された制御情報系データをより有線して処理できるようにしてもよい。
<F:応用例>
次に、本実施の形態に従う通信処理の応用例について説明する。
(f1:応用例1)
図14は、本実施の形態に従う通信処理の応用例1を説明するための模式図である。図14には、制御装置100およびデバイスの運転中に、リモートでデバイスの状態監視や、パラメータの設定変更を行う応用例を示す。
より具体的には、図14を参照して、制御装置100には、フィールドネットワーク110を介して、複数のデバイス112−1〜112−4が接続されている。制御装置100とデバイス112−1〜112−4との間では、予め定められたシステム周期に従って制御系データが遣り取りされる。このような制御系データの遣り取りによって、制御装置100およびデバイスの制御動作を実現できる。
また、制御装置100には、上位ネットワークを介してゲートウェイ250が接続されており、ゲートウェイ250が外部からのアクセスを仲介する。例えば、タブレット端末やスマートフォンなどからなるリモート保守端末400は、ゲートウェイ250を介して、制御装置100および制御装置100のフィールドネットワーク110に接続されている各デバイスにアクセス可能になっている。
上述したような制御系データに加えて、フィールドネットワーク110上では、制御情報系データが伝送される。例えば、デバイス112−1〜112−4では、各々が管理する情報へのアクセスを提供するために、HTTP(HyperText Transfer Protocol)ホストプログラム114−1〜114−4が実行されている。制御情報系データは、典型的には、リモート保守端末400とHTTPホストプログラム114−1〜114−4の各々との遣り取りに係るデータを含む。
本実施の形態に従う通信方法によれば、フィールドネットワーク110において、本来の制御系データの遣り取りを阻害することなく、制御情報系データについても遣り取りできるので、ユーザがリモート保守端末400を介して特定のデバイスへアクセスし、当該デバイスの状態監視やパラメータの設定変更をリモート保守端末400上で行うことができる。
制御情報系データを伝送できない場合には、各デバイスが設置されている現場に赴いて、各デバイスに設けられているボタンなどの操作、または、各デバイスにパーソナルコンピュータなどを接続して設定ツールなどを介した操作、などが必要であったが、リモート保守端末400を用いることで、遠隔で、かつ、複数のデバイスに対して、当該デバイスの状態監視やパラメータの設定変更を行うことができる。
(f2:応用例2)
図15は、本実施の形態に従う通信処理の応用例2を説明するための模式図である。図15には、制御装置100およびデバイスの運転中に、いずれかのデバイスで何らかの異常が発生した場合の通知および状況確認を行う応用例を示す。
より具体的には、図15を参照して、制御装置100には、フィールドネットワーク110を介して、複数のデバイス112−1〜112−4およびカメラ116が接続されている。制御装置100とデバイス112−1〜112−4との間では、予め定められたシステム周期に従って制御系データが遣り取りされる。このような制御系データの遣り取りによって、制御装置100およびデバイスの制御動作を実現できる。
制御装置100には、上位ネットワークを介してゲートウェイ250が接続されており、ゲートウェイ250が外部からのアクセスを仲介する。例えば、タブレット端末やスマートフォンなどからなるリモート保守端末400は、ゲートウェイ250を介して、制御装置100および制御装置100のフィールドネットワーク110に接続されている各デバイスにアクセス可能になっている。
例えば、デバイスの運転中(通常時)には、フィールドネットワーク110に接続されているカメラ116で撮像された画像が、制御装置100およびゲートウェイ250の順で、リモート保守端末400まで転送される。リモート保守端末400のユーザ(保守員)は、リモート保守端末400上に表示される画像により、遠隔で状況を監視することができる。
通常時において撮像された画像は、情報系データとしてフィールドネットワーク110上を伝送させるようにしてもよい。
例えば、デバイス112−2において何らかの異常が発生すると、デバイス112−2は、その異常情報の内容を、フィールドネットワーク110を介して送信する。そのメッセージは、制御装置100およびゲートウェイ250の順で、リモート保守端末400まで転送される。併せて、カメラ116で撮像された画像もリモート保守端末400まで転送される。リモート保守端末400では、カメラ116で撮像された画像と受信した異常情報とをリモート保守端末400のユーザ(保守員)に呈示する。この呈示の一例として、図15に示されるような、AR(Augmented Reality:拡張現実)を用いてもよい。すなわち、受信した異常情報に基づいて、実際に撮像された画像上の異常が発生した部位に関連付けて、その異常情報の内容を表示するようにしてもよい。
このような異常情報は、制御情報系データとして、制御系データの通常の伝送を阻害することなく、フィールドネットワーク110上を伝送される。
本実施の形態に従う通信方法によれば、異常発生時において、画像および異常情報を制御情報系データとして、到達時間を保証しつつ伝送することで、リモート保守端末400上の表示(AR表示)において、撮像された画像と発生した異常を示す異常情報とを同期させることができる。このような同期された表示によって、ユーザ(保守員)は異常発生の内容を確実に遠隔で把握することができる。もし、通常時と同様に、画像を情報系データとして伝送すると、リモート保守端末400に表示される画像と異常情報の時間とが一致せず、表示画面が不適切(例えば、異常情報は表示されているものの、撮像された画像は正常状態を示しているといった状態など)となる可能性もある。
このような構成を採用することで、ユーザ(保守員)は、制御システムにおいて何らかの異常が発生したときに、下位のデバイスレベルでその異常が発生した箇所を特定できるとともに、遠隔でその状況も確認することができ、保守性を高めることができるともに、故障復旧までの時間を短縮できる。
(f3:応用例3)
図16は、本実施の形態に従う通信処理の応用例3を説明するための模式図である。図16には、制御装置100の運転中に、いずれかのデバイスに対するファームウェアの更新を実行する応用例を示す。
より具体的には、図16を参照して、制御装置100には、フィールドネットワーク110を介して、複数のデバイス112−1〜112−4が接続されている。制御装置100とデバイス112−1〜112−4との間では、予め定められたシステム周期に従って制御系データが遣り取りされる。このような制御系データの遣り取りによって、制御装置100およびデバイスの制御動作を実現できる。
また、制御装置100には、上位ネットワークを介して保守装置500が接続されている。保守装置500には、いずれかのデバイスに対するファームウェアが格納されており、ユーザ(保守員)は、保守装置500を操作して、制御装置100のフィールドネットワーク110に接続されているいずれかのデバイスを指定した上で、保守装置500に格納されているファームウェアを当該指定したデバイスへ送信する。このようなファームウェアは、制御情報系データとして、制御系データの通常の伝送を阻害することなく、フィールドネットワーク110上を伝送される。
制御情報系データを伝送できない場合には、各デバイスが設置されている現場に赴いて、対象のデバイスに保守装置を直接接続してファームウェアを更新する操作を行う必要があり、特に、対象のデバイスが制御盤内または装置内に配置されているような場合には、ファームウェアの更新に手間を要していた。これに対して、図16に示すような構成を採用することで、複数のデバイスに対するファームウェアの更新を一ヶ所で集中して行うことができるので、保守性を高めることができるともに、保守に要するコストを低減できる。
<G:利点>
本実施の形態に従う通信方法によれば、同一のネットワーク上において、製造装置または生産設備の制御に用いるデータ(制御系データ)を予め定められた周期毎に更新することを保証しつつ、指定された時間内に送信先へ到着させることが要求される制御情報系データ、および、よりデータサイズの大きな情報系データを並存して伝送することができる。このような通信方法を実装することで、下位デバイスを含めてネットワーク全体をより高機能化させることができる。
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
1 ネットワーク化システム、11,12,13,14 ネットワーク、100 制御装置、102 プロセッサ、104 メモリ、106 ストレージ、107 システムプログラム、108 ユーザアプリケーションプログラム、110,120 フィールドネットワーク、112,122 デバイス群、112−1〜112−4 デバイス、114−1〜114−4 HTTPホストプログラム、116 カメラ、130 ネットワークコントローラ、131,141,151,161 受信回路、132,142,152,162 受信バッファ、133,143,153,163 送受信コントローラ、134,144,154,164 送信バッファ、135,145,155,165 送信回路、140,150 フィールドネットワークコントローラ、160 内部バスコントローラ、170 スケジューラ、172 管理モード、173 ユーザアプリケーション実行処理、174 周辺処理、175 制御系通信処理、176 制御情報系通信処理、177 情報系通信処理、178 通信ドライバ、180 表示装置、190 ライン管理装置、200 製造管理装置、210 データベース装置、250 ゲートウェイ、300 生産管理装置、400 リモート保守端末、500 保守装置、Ts システム周期。

Claims (10)

  1. 予め定められた周期毎にデータが更新されるネットワークに接続される通信装置であって、
    製造装置または生産設備の制御に用いる第1のデータを前記予め定められた周期毎に更新するのに必要な第1の通信帯域を確保する第1のスケジューリング手段と、
    前記ネットワークが有する通信帯域のうち前記第1の通信帯域以外の通信帯域内に、第2のデータを指定された時間内に送信先へ到着させるのに必要な第2の通信帯域を確保する第2のスケジューリング手段と、
    前記ネットワークが有する通信帯域のうち前記第1の通信帯域および前記第2の通信帯域のいずれにも設定されていない通信帯域内に、第3のデータを伝送するための第3の通信帯域を確保する第3のスケジューリング手段とを備え、
    前記第2のスケジューリング手段は、
    前記第2のデータを、前記送信先にて受信可能なデータサイズに応じて、各周期において利用可能な通信帯域に応じたデータサイズに分割した上で、分割後のそれぞれのデータを複数の周期に割り当て、
    前記第2のデータの分割により、前記第2のデータを前記指定された時間内に送信先へ到着させるスケジューリングができない場合に、異常通知を行う、通信装置。
  2. 前記異常通知は、前記通信装置が管理するシステムフラグをオンする、および、前記通信装置の表示面にあるインジケータを点灯させる、の少なくとも一方によって行われる、請求項1に記載の通信装置。
  3. 前記第2のスケジューリング手段は、前記第2のデータを分割した上で、分割後のそれぞれのデータを、前記送信先での受信データの処理状況に応じて、前記予め定められた周期より長い周期で順次送信する、請求項1または2に記載の通信装置。
  4. 前記第2のスケジューリング手段は、前記送信先での受信エラーの回数、および、前記送信先から受信応答を受信できなかった回数、の少なくとも一方に基づいて、前記送信先での受信データの処理状況を判断する、請求項3に記載の通信装置。
  5. 前記第2のスケジューリング手段は、前記予め定められた周期において、前記第2のデータまたは前記第3のデータを複数回送信する、請求項1〜4のいずれか1項に記載の通信装置。
  6. 前記第2のスケジューリング手段は、前記ネットワークの通信状況に応じて、前記第2のデータを分割して送信する単位サイズを変化させる、請求項1〜5のいずれか1項に記載の通信装置。
  7. 前記第2のスケジューリング手段は、前記送信先からの受信応答のうち破損していたものの数、および、受信データの破損を示す前記送信先からの通知の数、の少なくとも一方に基づいて、前記ネットワークの通信状況を判断する、請求項6に記載の通信装置。
  8. 前記第3のスケジューリング手段は、単位サイズを変化させることが指定されている場合に、前記ネットワークの通信状況に応じて、前記第3のデータを分割して送信する単位サイズを変化させる、請求項6または7に記載の通信装置。
  9. 製造装置または生産設備を制御する制御装置であって、
    予め定められた周期毎にデータが更新されるネットワークに接続される通信インターフェイスと、
    前記製造装置または生産設備の制御に用いる第1のデータを前記予め定められた周期毎に更新するのに必要な第1の通信帯域を確保する第1のスケジューリング手段と、
    前記ネットワークが有する通信帯域のうち前記第1の通信帯域以外の通信帯域内に、第2のデータを指定された時間内に送信先へ到着させるのに必要な第2の通信帯域を確保する第2のスケジューリング手段と、
    前記ネットワークが有する通信帯域のうち前記第1の通信帯域および前記第2の通信帯域のいずれにも設定されていない通信帯域内に、第3のデータを伝送するための第3の通信帯域を確保する第3のスケジューリング手段とを備え、
    前記第2のスケジューリング手段は、
    前記第2のデータを、前記送信先にて受信可能なデータサイズに応じて、各周期において利用可能な通信帯域に応じたデータサイズに分割した上で、分割後のそれぞれのデータを複数の周期に割り当て、
    前記第2のデータの分割により、前記第2のデータを前記指定された時間内に送信先へ到着させるスケジューリングができない場合に、異常通知を行う、制御装置。
  10. 予め定められた周期毎にデータが更新されるネットワークでの通信方法であって、
    製造装置または生産設備の制御に用いる第1のデータを前記予め定められた周期毎に更新するのに必要な第1の通信帯域を確保するステップと、
    前記ネットワークが有する通信帯域のうち前記第1の通信帯域以外の通信帯域内に、第2のデータを指定された時間内に送信先へ到着させるのに必要な第2の通信帯域を確保するステップと、
    前記ネットワークが有する通信帯域のうち前記第1の通信帯域および前記第2の通信帯域のいずれにも設定されていない通信帯域内に、第3のデータを伝送するための第3の通信帯域を確保するステップと、
    前記第2のデータを、前記送信先にて受信可能なデータサイズに応じて、各周期において利用可能な通信帯域に応じたデータサイズに分割した上で、分割後のそれぞれのデータを複数の周期に割り当てるステップと、
    前記第2のデータの分割により、前記第2のデータを前記指定された時間内に送信先へ到着させるスケジューリングができない場合に、異常通知を行うステップとを備える、通信方法。
JP2016202964A 2016-10-14 2016-10-14 通信装置、制御装置および通信方法 Active JP6769230B2 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2016202964A JP6769230B2 (ja) 2016-10-14 2016-10-14 通信装置、制御装置および通信方法
US16/337,431 US10999367B2 (en) 2016-10-14 2017-10-13 Communication apparatus, control device, and communication method
CN201780059783.2A CN109792442B (zh) 2016-10-14 2017-10-13 通信装置、控制装置以及通信方法
EP17859722.5A EP3528448A4 (en) 2016-10-14 2017-10-13 COMMUNICATION DEVICE, CONTROL DEVICE, AND COMMUNICATION METHOD
KR1020197008855A KR102181158B1 (ko) 2016-10-14 2017-10-13 통신 장치, 제어 장치 및 통신 방법
PCT/JP2017/037173 WO2018070518A1 (ja) 2016-10-14 2017-10-13 通信装置、制御装置および通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016202964A JP6769230B2 (ja) 2016-10-14 2016-10-14 通信装置、制御装置および通信方法

Publications (2)

Publication Number Publication Date
JP2018064245A JP2018064245A (ja) 2018-04-19
JP6769230B2 true JP6769230B2 (ja) 2020-10-14

Family

ID=61905430

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016202964A Active JP6769230B2 (ja) 2016-10-14 2016-10-14 通信装置、制御装置および通信方法

Country Status (6)

Country Link
US (1) US10999367B2 (ja)
EP (1) EP3528448A4 (ja)
JP (1) JP6769230B2 (ja)
KR (1) KR102181158B1 (ja)
CN (1) CN109792442B (ja)
WO (1) WO2018070518A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6376229B2 (ja) * 2017-02-09 2018-08-22 オムロン株式会社 通信システム、通信装置および通信方法
JP6897462B2 (ja) 2017-09-27 2021-06-30 オムロン株式会社 制御システムおよび通信方法
JP6859914B2 (ja) * 2017-10-05 2021-04-14 オムロン株式会社 通信システム、通信装置および通信方法
JP7014091B2 (ja) * 2018-08-06 2022-02-01 オムロン株式会社 通信システム、通信装置および通信方法
JP7155727B2 (ja) * 2018-08-07 2022-10-19 富士通株式会社 情報処理装置、情報処理装置の制御方法及び情報処理装置の制御プログラム
JP7003952B2 (ja) * 2019-03-14 2022-01-21 オムロン株式会社 制御システム、サポート装置およびサポート装置用のプログラム
KR20220117289A (ko) 2019-12-25 2022-08-23 파나소닉 아이피 매니지먼트 가부시키가이샤 통신 장치, 통신 시스템, 통신 제어 방법 및 프로그램
JP7229957B2 (ja) * 2020-02-19 2023-02-28 株式会社安川電機 生産システム、通信方法、及びプログラム
JP7167072B2 (ja) 2020-02-19 2022-11-08 株式会社安川電機 生産システム、通信方法、及びプログラム
JP6878705B1 (ja) * 2020-04-24 2021-06-02 三菱電機株式会社 通信装置、通信システム、通信方法、およびプログラム
CN116137951A (zh) * 2020-07-22 2023-05-19 松下知识产权经营株式会社 通信装置、通信***、通信控制方法以及程序
JP2022108621A (ja) * 2021-01-13 2022-07-26 キヤノン株式会社 制御装置、システム、リソグラフィ装置、物品の製造方法、制御方法及びプログラム
JP2024000591A (ja) * 2022-06-21 2024-01-09 オムロン株式会社 制御システム、中継装置および通信方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6940831B1 (en) * 1999-11-29 2005-09-06 Matsushita Electric Industrial Co., Ltd Wireless communications system
JP3515079B2 (ja) * 2001-03-06 2004-04-05 松下電器産業株式会社 通信端末収容装置
WO2003028320A1 (de) * 2001-09-26 2003-04-03 Siemens Aktiengesellschaft Verfahren zum betrieb eines isochronen, zyklischen kommunikationssystems
US7353299B2 (en) * 2003-05-29 2008-04-01 International Business Machines Corporation Method and apparatus for managing autonomous third party data transfers
JP2004363782A (ja) 2003-06-03 2004-12-24 Hitachi High-Technologies Corp 通信制御装置および通信制御方法
JP2006005646A (ja) * 2004-06-17 2006-01-05 Yaskawa Electric Corp ネットワーク通信方法
CN101248611A (zh) 2005-08-24 2008-08-20 艾利森电话股份有限公司 数据单元传送方法
CN102246466B (zh) * 2008-12-12 2015-04-15 三菱电机株式会社 数据发送接收方法、数据发送接收***、主机装置以及从机装置
US20120002633A1 (en) 2009-03-17 2012-01-05 Mitsubishi Electric Corporation Communication system, communication apparatus, and frequency allocation method
DE102009032843A1 (de) * 2009-07-13 2011-01-27 Continental Automotive Gmbh Verfahren zum Übertragen von Kontrollsignalen und Datensignalen, Schaltungsanordnung zum Übertragen und Empfangen
CN102484607B (zh) * 2009-09-29 2014-10-29 西门子公司 一种profinet通信***中的通信方法
JP5772132B2 (ja) 2011-03-25 2015-09-02 富士通株式会社 データ転送装置、データ転送方法および情報処理装置
JP5667097B2 (ja) * 2012-01-24 2015-02-12 日本電信電話株式会社 通信装置、通信方法、及び通信プログラム
JP5637193B2 (ja) * 2012-09-06 2014-12-10 株式会社デンソー 通信システム
CN104202774A (zh) 2014-09-18 2014-12-10 东南大学 一种可靠实时的工业无线局域网传输方法

Also Published As

Publication number Publication date
KR20190050998A (ko) 2019-05-14
WO2018070518A1 (ja) 2018-04-19
KR102181158B1 (ko) 2020-11-20
CN109792442A (zh) 2019-05-21
US20200036786A1 (en) 2020-01-30
CN109792442B (zh) 2021-07-16
EP3528448A1 (en) 2019-08-21
EP3528448A4 (en) 2019-12-04
JP2018064245A (ja) 2018-04-19
US10999367B2 (en) 2021-05-04

Similar Documents

Publication Publication Date Title
JP6769230B2 (ja) 通信装置、制御装置および通信方法
US9628384B2 (en) Adaptive industrial network
JP6897462B2 (ja) 制御システムおよび通信方法
EP3582459B1 (en) Communication system, communication device, and communication method
JP7073624B2 (ja) 通信システム、通信装置および通信方法
JP2019036313A (ja) 高パフォーマンス制御サーバシステム
US10356014B2 (en) Method of processing bus data
US20130318260A1 (en) Data transfer device
EP3297208A1 (en) Processing apparatus for bus data
US20130145025A1 (en) Programmable controller
JP6494586B2 (ja) 通信端末及び通信システム
JP6483592B2 (ja) コントローラおよび制御システム
JP4548126B2 (ja) 登録サーバ装置及び遠隔監視制御システム
JP2013250632A (ja) 通信装置
WO2021089139A1 (en) Redundancy control for data traffic through a wireless link
JP6757653B2 (ja) 通信システム
JP2023078514A (ja) プラント監視制御システム
WO2015099142A1 (ja) 無線通信装置、無線通信システム、および無線通信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190806

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200519

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200608

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200623

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200806

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200825

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200907

R150 Certificate of patent or registration of utility model

Ref document number: 6769230

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150