制御装置及び通信管理方法
【課題】通信異常発生時、プロセスデータを取得できるまでの遅延時間を短縮できるよう
にすると共に、分散型制御システムにおける制御動作の安定化を実現できるようにする。
【解決手段】２つの通信バスα及びβに接続され、バス切り換え機能を有して通信バスを
監視し、当該通信バスの一時異常及び正常を判別するＣＰＵ１０と、通信バスを介してＣ
ＰＵ１０に接続され、フィールド機器から入力したプロセスデータを通信バスを介してＣ
ＰＵ１０に出力すると共に、通信バスを介して当該ＣＰＵ１０から入力した制御データを
フィールド機器に出力する１つ以上のＩＯＭ部１４等とを備え、ＣＰＵ１０は、一方の通
信バスの状態が一時異常であると判別したとき、一時異常と判別された通信バスから正常
な状態の通信バスにＩＯＭ部１４等の接続を切り換えるものである。
にすると共に、分散型制御システムにおける制御動作の安定化を実現できるようにする。
【解決手段】２つの通信バスα及びβに接続され、バス切り換え機能を有して通信バスを
監視し、当該通信バスの一時異常及び正常を判別するＣＰＵ１０と、通信バスを介してＣ
ＰＵ１０に接続され、フィールド機器から入力したプロセスデータを通信バスを介してＣ
ＰＵ１０に出力すると共に、通信バスを介して当該ＣＰＵ１０から入力した制御データを
フィールド機器に出力する１つ以上のＩＯＭ部１４等とを備え、ＣＰＵ１０は、一方の通
信バスの状態が一時異常であると判別したとき、一時異常と判別された通信バスから正常
な状態の通信バスにＩＯＭ部１４等の接続を切り換えるものである。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、電気や、機械、化学工場等のプラントにおけるフィールド機器を分散制御
するフィールドコントロールステーション（ＦＣＳ部）や、ＦＣＳ部を有する分散型制御
システム（ＤＣＳ）、ＦＣＳ部におけるＣＰＵ（中央処理装置）と通信対象となる入出力
通信モジュール（ＩＯＭ部）との間の通信を管理するアクセス管理等に適用可能な制御装
置及び通信管理方法に関するものである。
【背景技術】
【０００２】
近年、電気や、機械、化学工場等のプラントにおいて分散型制御システム（Dispersion
Control System：ＤＣＳ）が採用される場合が多くなってきた。分散型制御システムに
よれば、ＦＣＳ部内に実装されたＩＯ通信機能部（ＩＯコプロセッサ）が、あらかじめ定
義された周期（スキャン周期）でＩＯＭ部へ通信を行うことにより、フィールド機器を構
成するバルブ等へ制御データを出力したり、そのセンサからプロセスデータを取得してい
る（ＩＯＭ通信）。
【０００３】
図８は従来例に係るＦＣＳ部１０５の内部構成例を示すブロック図である。図８に示す
ＦＣＳ部１０５は、ＣＰＵ３０を有している。ＣＰＵ３０は、ＩＯ通信機能部３１の他に
、メモリ部３２、命令演算部３３及びＣＰＵバス１８を有している。ＩＯ通信機能部３１
、メモリ部３２及び命令演算部３３はＣＰＵバス１８に接続されている。ＩＯ通信機能部
３１には、２系統の通信バスα，βを介して４個のＩＯＭ部１４，１５，１６，１７が接
続されている。ＩＯＭ部１４，１５，１６，１７には、図示しない電気や、機械、化学工
場等のプラントにおけるバルブやセンサ等のフィールド機器が接続される。
【０００４】
命令演算部３３は、図示しない制御バスを介して上位のパーソナルコンピュータ（以下
パソコンという）からデータパケットを受信し、データパケットをデコードしてＩＯ通信
機能部３１及びＩＯＭ部１４，１５，１６，１７の間における通信処理（以下ＩＯＭ通信
処理という）を実行するための命令（コマンド）を演算する。命令演算部３３はプロセス
データを用いて制御演算を実行する。
【０００５】
ＩＯ通信機能部３１にはメモリ部３２が接続される。ＩＯ通信機能部３１は命令演算部
３３から発行されるコマンドを受信して、メモリ部３２内に状態管理テーブル１３２を作
成する。状態管理テーブル１３２は、ＩＯＭ部１４，１５，１６，１７等の状態を管理す
るためであり、通信の是非や、使用する通信バスα，βの判断のために参照される。
【０００６】
メモリ部３２はＩＯ通信機能部３１によって制御され監視される通信バスα，βの状態
を正常及び異常の２種類に区分してＩＯＭ部１４，１５，１６，１７毎に記憶する。状態
管理テーブル１３２には、例えば、５個の識別子ＩＯＭ１〜ＩＯＭ５が割り当てられ、通
信バスα，βの状態に対応して正常又は異常が設定される。
【０００７】
ＩＯ通信機能部３１は、２つの通信バスα，βを切り換える機能を有して、当該通信バ
スα，βに接続され、通信バスα，βを監視し、当該通信バスα，βの異常及び正常を判
別する。ＩＯ通信機能部３１はリトライ通信機能を有している。ここにリトライ通信機能
とは、トランジェントエラーやＩＯＭ異常、通信バスα、βの異常等、何らかの通信異常
を引き起こす原因によりＩＯＭ通信を失敗した場合、再度、ＩＯＭ通信を試みる動作をい
う。
【０００８】
図９Ａ〜Ｃは、ＩＯ通信機能部３１とＩＯＭ部１４等との通信例を示すシーケンス図及
び通信バスα，βの状態例を示す説明図である。図９Ａに示すＩＯ通信機能部３１とＩＯ
Ｍ部１４等との通信例によれば、黒△印は、ＩＯ通信機能部３１からＩＯＭ部１４への通
信時刻τ１，τ３，τ５，τ７，τ８，τ９，τ１１，τ１３（例）である。白△印は、
ＩＯＭ部１４からＩＯ通信機能部３１への通信時刻τ２，τ４，τ６，τ１０，τ１２，
τ１４（例）である。
【０００９】
図９Ｂに示す通信バスα（図中αバスと表示する）の状態例によれば、通信時刻τ１〜
τ８のαバス異常が確定する時刻まで正常となされ、通信時刻τ９以降は、異常な状態で
ある。
【００１０】
これに対して、図９Ｃに示す通信バスβ（図中βバスと表示する）の状態例によれば、
通信時刻τ１以降ずっと正常な状態となっている。
【００１１】
この例では、黒△印の通信時刻τ１で、まず、通信バスαを使用して、ＩＯ通信機能部
３１からＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の
通信時刻τ２でＩＯＭ部１５からＩＯ通信機能部３１へプロセスデータが出力され、ＩＯ
通信が成功する（○印）。同様にしてスキャン周期Ｔ（Ｅｘ．τ３−τ１）毎に、図９Ｂ
，Ｃに示す通信バスα，βを切り換えて、黒△印の通信時刻τ３，τ５で、ＩＯ通信機能
部３１からＩＯＭ部１４へＩＯ通信が実行され、白△印の通信時刻τ４，τ６で、ＩＯＭ
部１４からＩＯ通信機能部３１へのＩＯ通信が成功している（αバス通信）。
【００１２】
しかし、黒△印の通信時刻τ７で、通信バスαを使用して、ＩＯ通信機能部３１からＩ
ＯＭ部１４へＩＯ通信が実行されても、ＩＯＭ部１５はＩＯ通信機能部３１に対して無応
答であり、ＩＯ通信が失敗している（×印：通信異常）。この時点から、ＩＯ通信機能部
３１はリトライ通信処理を実行する。このリトライ通信処理によれば、他のＩＯＭ通信を
中断し、真の通信異常であるか否かを確定するために、何回かのリトライ通信を試みるよ
うになされる。
【００１３】
同様にして、黒△印の通信時刻τ８で、通信バスαを使用して、ＩＯ通信機能部３１か
らＩＯＭ部１４へＩＯ通信が実行されても、ＩＯＭ部１５はＩＯ通信機能部３１に対して
無応答であり、ＩＯ通信が失敗している（×印）。このリトライ通信の結果、通信異常が
確定されると、黒△印の通信時刻τ９で、通信バスαから通信バスβへ接続を切り換える
。
【００１４】
そして、通信バスβを使用して、ＩＯ通信機能部３１からＩＯＭ部１４へ制御データを
出力するＩＯ通信が実行されると、白△印の通信時刻τ１０でＩＯＭ部１５からＩＯ通信
機能部３１へプロセスデータが出力され、ＩＯ通信が成功する（○印）。同様にして通信
バスβを使用して、黒△印の通信時刻τ１１，τ１３で、ＩＯ通信機能部３１からＩＯＭ
部１４へＩＯ通信が実行され、白△印の通信時刻τ１２，τ１４で、ＩＯＭ部１４からＩ
Ｏ通信機能部３１へのＩＯ通信が成功している（βバス通信）。
【００１５】
この種のＩＯＭ通信機能を備えたフィールドコントロールステーションに関連して、特
許文献１には二重化通信装置が開示されている。この二重化通信装置によれば、二重化さ
れた通信カードに基づいて、上位装置からの通信要求に応じて機器と通信する場合に、ア
プリケーションプログラム実行部、エラー処理手段、通信要求処理手段及び再通信要求処
理手段を備える。アプリケーションプログラム実行部は、二重化された通信カードの制御
権を切り替えるデバイスドライバを介して、上位装置からの通信要求に応じて機器と通信
する。
【００１６】
エラー処理手段はデバイスドライバ内に設けられ、制御権の切り替えに起因する通信エ
ラーに対して特有のエラーコードを生成する。通信要求手段は、エラー処理手段からエラ
ーコードを受け取り、制御権の切り替え時の通信要求にエラーコードを付加してアプリケ
ーションプログラム実行部に通知する。これを前提にして、アプリケーションプログラム
実行部内には再通信要求処理手段が設けられ、エラーコードを取得したとき、上位装置か
らの通信要求を通信要求処理手段に再送するようになされる。このように装置を構成する
と、エラーとなった通信要求に対する煩雑なキャンセル処理を必要としないために、デバ
イスドライバの通信機能をシンプルに設計できるというものである。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】特開２００８−１５８７２８号公報（第４頁 図１）
【発明の概要】
【発明が解決しようとする課題】
【００１８】
ところで、従来例に係るフィールドコントロールステーション（ＦＣＳ部１０５）によ
れば、次のような問題がある。
【００１９】
ｉ．特許文献１に見られるような二重化通信方式を導入したＦＣＳ部１０５によれば、
通信異常が発生した場合に、ＩＯ通信機能部が他のＩＯＭ通信を中断し、通信バスの切り
替えを行わず、当該通信バスが『異常』であると判断されるまで、直前に使用した通信バ
スを再度使用して、リトライ通信処理を繰り返している。このため、通信異常発生時、フ
ィールド機器からプロセスデータを取得できるまでの遅延時間が長くなるという問題があ
る。
【００２０】
ii．因みに、一定回数以上の通信異常が生じた場合に、ＩＯ通信機能部が当該通信バス
の状態を『異常』と判断しているが、トランジェントエラー以外の通信異常が生じた場合
に、直前に使用した通信バスと同一の通信バスを使用しても、再度、ＩＯＭ通信を失敗す
る可能性が高い。
【００２１】
iii．しかも、通信対象の状態を通信空き時間等を利用して、”異常”の確認に取りか
かるのではなく、他のＩＯＭ通信を中断してリトライ通信処理を実行するので、局所的な
通信負荷が集中してしまう。これにより、分割型制御システムにおける安定した制御動作
を妨げる原因になっている。
【００２２】
そこで、この発明は上述した課題を解決したものであって、通信異常発生時、プロセス
データを取得できるまでの遅延時間を短縮できるようにすると共に、分散型制御システム
における制御動作の安定化を実現できるようにした制御装置及び通信管理方法を提供する
ことを目的とする。
【課題を解決するための手段】
【００２３】
上記課題を解決するために、制御装置は、少なくとも、通信要求を実行して一定時間以
内に応答がなかった場合を一時異常としたとき、２つの通信路に接続され、当該通信路を
切り換える機能を有して前記通信路を監視し、当該通信路の一時異常及び正常を判別する
制御部と、前記通信路を介して前記制御部に接続され、被制御機器から入力した処理デー
タを前記通信路を介して前記制御部に出力すると共に、前記通信路を介して当該制御部か
ら入力した制御データを前記被制御機器に出力する１つ以上のデータ入出力部とを備え、
前記制御部は、一方の前記通信路の状態が一時異常であると判別したとき、一時異常と判
別された前記通信路から正常な状態の通信路に前記データ入出力部の接続を切り換えるこ
とを特徴とするものである。
【００２４】
本発明に係る制御装置によれば、制御部は２つの通信路に接続され、当該通信路を切り
換える機能を有して通信路を監視する。制御部は、当該通信路の一時異常及び正常を判別
する。１つ以上のデータ入出力部が通信路を介して制御部に接続される。データ入出力部
は、被制御機器から入力した処理データを通信路を介して制御部に出力すると共に、通信
路を介して当該制御部から入力した制御データを被制御機器に出力する。
【００２５】
これを前提にして、制御部は、一方の通信路の状態が一時異常であると判別したとき、
一時異常と判別された通信路から正常な状態の通信路にデータ入出力部の接続を切り換え
るようになる。従って、一時異常と判別された時点で、データ入出力部の接続が切り換え
られた正常な状態の通信路を介して被制御機器から制御部へ処理データを出力したり、正
常な状態の通信路を介して当該制御部から被制御機器へ制御データを出力できるようにな
る。
【００２６】
本発明に係る通信管理方法は、少なくとも、通信要求を実行して一定時間以内に応答が
なかった場合を一時異常としたとき、２つの通信路に接続され、当該通信路を切り換える
機能を有して前記通信路を監視し当該通信路の一時異常及び正常を判別する制御部と、前
記通信路を介して前記制御部に接続され、被制御機器から入力した処理データを前記通信
路を介して前記制御部に出力すると共に、前記通信路を介して当該制御部から入力した制
御データを前記被制御機器に出力する１つ以上のデータ入出力部とを備えた制御装置が、
前記通信路の状態が一時異常であるか否かを判別するステップと、一方の前記通信路の状
態が一時異常であると判別されたとき、一時異常と判別された前記通信路から正常な状態
の通信路に前記データ入出力部の接続を切り換えるステップを有するものである。
【発明の効果】
【００２７】
本発明に係る制御装置及び通信管理方法によれば、２つの通信路を介して１つ以上のデ
ータ入出力部に接続され、当該通信路を切り換える機能を有して通信路を監視し、当該通
信路の一時異常及び正常を判別する制御部を備え、この制御部は、一方の通信路の状態が
一時異常であると判別したとき、一時異常と判別された通信路から正常な状態の通信路に
データ入出力部の接続を切り換えるものである。
【００２８】
この構成によって、一時異常と判別された時点で、データ入出力部の接続が切り換えら
れた正常な状態の通信路を介して被制御機器から制御部へ処理データを出力したり、正常
な状態の通信路を介して当該制御部から被制御機器へ制御データを出力できるようになる
。従って、一時異常と判別された通信路への通信可否の確認を行うリトライ通信を省略す
ることができるので、従来方式のようなリトライ通信を実行する場合に比べて、制御部が
被制御機器から処理データを取得する際の遅延時間を短縮することができる。
【図面の簡単な説明】
【００２９】
【図１】本発明に係る制御装置及び通信管理方法を応用した実施形態としての分散型制御システム＃１の構成例を示すブロック図である。
【図２】ＦＣＳ部１０１の内部構成例を示すブロック図である。
【図３】状態管理テーブル１２１における各フラグの記述例を示す概念図である。
【図４】（Ａ）〜（Ｃ）は、ＩＯ通信機能部１１とＩＯＭ部１４等との通信例を示すシーケンス図及び通信バスα，βの状態例を示す説明図である。
【図５】ＦＣＳ部１０１における通信管理例（その１）を示すフローチャートである。
【図６】ＦＣＳ部１０１における通信管理例（その２）を示すフローチャートである。
【図７】ＦＣＳ部１０１における通信管理例（その３）を示すフローチャートである。
【図８】従来例に係るＦＣＳ部１０５の内部構成例を示すブロック図である。
【図９】（Ａ）〜（Ｃ）は、ＩＯ通信機能部３１とＩＯＭ部１４等との通信例を示すシーケンス図及び通信バスα，βの状態例を示す説明図である。
【発明を実施するための形態】
【００３０】
以下、図面を参照しながら、この発明の実施の形態に係る制御装置及び通信管理方法に
ついて説明をする。図１に示す分散型制御システム＃１は、本発明に係る制御装置及び通
信管理方法を応用したシステムであり、電気や、機械、化学工場等のプラントにおける複
数の被制御機器（以下でフィールド機器という）を分散して制御するシステムである。
【００３１】
分散型制御システム＃１は、例えば、デスクトップ型や、ノートブック型等のパーソナ
ルコンピュータ（以下単にパソコン１０４という）、制御バス１０３、２系統のフィール
ドコントロールステーション（以下ＦＣＳ部１０１，１０２という）を有して構成される
。ＦＣＳ部１０１や、ＦＣＳ部１０２は、制御装置の一例を構成し、電気や、機械、化学
工場等のプラントにおいて、例えば、複数のセンサから得られるプロセスデータに基づい
て複数のバルブ等のフィールド機器を分散制御するようになされる。
【００３２】
パソコン１０４（ＨＩＳ）には、Ｖｎｅｔ／ＩＰ等の制御バス１０３が接続され、分散
制御用のパケットデータが転送される。ここにＶｎｅｔ／ＩＰとは、データ転送速度が１
Ｇｂｐｓ程度のイーサネット（登録商標）をベースとしたプロセス・オートメーション用
のリアルタイム・プラント・ネットワークシステムをいう。
【００３３】
この例で制御バス１０３には、２系統のＦＣＳ部１０１及びＦＣＳ部１０２が接続され
る。第１のＦＣＳ部１０１は、例えば、制御側のＣＰＵ１０、待機側のＣＰＵ２０及び４
個のＩＯＭ部１４，１５，１６，１７を備え、これらのＣＰＵ１０，２０及びＩＯＭ部１
４，１５，１６，１７が、冗長化された２系統の入出力通信モジュール（ＩＯＭ）用の通
信バスα，βに接続される。ＩＯＭ部１４，１５，１６，１７は、各々がデータ入出力部
の一例を構成する。
【００３４】
制御側のＣＰＵ１０は、入出力通信機能部（以下ＩＯ通信機能部１１という）を有して
おり、従来方式と同様にして、予め定義された周期（スキャン周期）でＩＯＭ入力処理を
実行し、上位のパソコン１０４等からの要求に応じてＩＯＭ入出力処理を実行する。ＩＯ
通信機能部１１にはＣＰＵ１０内の命令演算機能を補助するＩＯコプロセッサが使用され
る。ＩＯ通信機能部１１には２系統の通信バスα，βを介して、例えば、４個のＩＯＭ部
１４，１５，１６，１７が接続される。通信バスα，βはスキャン周期に基づき、交互に
切り換えられて使用される。
【００３５】
ＩＯ通信機能部１１は、例えば、通信バスα又はβを介して、ＩＯＭ部１４へ制御デー
タＤ１４を出力し、及び、ＩＯＭ部１６へ制御データＤ１６を出力したり、ＩＯＭ部１５
から処理データ（以下プロセスデータＤ３５という）を入力し、及び、ＩＯＭ部１７から
処理データ（以下プロセスデータＤ３７という）を入力して通信処理を実行する。
【００３６】
ＩＯＭ部１４には第１のバルブ３４が接続される。バルブ３４は、図示しないプラント
内の配管に取り付けられ、制御データＤ１４に基づいて流量を調整する。ＩＯＭ部１５に
はフィールド機器の一例を構成する第１のセンサ３５が接続される。センサ３５は上述の
配管内の流量を検知して流量検知時のプロセスデータＤ３５を発生する。
【００３７】
ＩＯＭ部１６には第２のバルブ３６が接続される。バルブ３６は、図示しないプラント
内の他の配管に取り付けられ、制御データＤ１６に基づいて流量を調整する。ＩＯＭ部１
７には第２のセンサ３７が接続される。センサ３７は上述の他の配管内の流量を検知して
流量検知時のプロセスデータＤ３７を発生する。
【００３８】
待機側のＣＰＵ２０も、入出力通信機能部（以下ＩＯ通信機能部２１という）を有して
いる。ＩＯ通信機能部２１には命令演算機能を補助するＩＯコプロセッサが使用される。
ＩＯ通信機能部２１も、上述の４個のＩＯＭ部１４，１５，１６，１７が接続された２系
統の通信バスα，βに並列に接続される。
【００３９】
例えば、ＩＯ通信機能部２１は、制御側のＣＰＵ１０に故障が生じたとき、通信バスα
又はβを介して、ＣＰＵ２０はＣＰＵ１０に代わってＩＯＭ部１４へ制御データＤ１４を
出力し、及び、ＩＯＭ部１６へ制御データＤ１６を出力したり、ＩＯＭ部１５から処理デ
ータ（以下プロセスデータＤ３５という）を入力し、及び、ＩＯＭ部１７から処理データ
（以下プロセスデータＤ３７という）を入力して通信処理を実行する。
【００４０】
第２のＦＣＳ部１０２も制御側のＣＰＵ１０、待機側のＣＰＵ２０及び４個のＩＯＭ部
２４，２５，２６，２７を備え、これらのＣＰＵ１０，２０及びＩＯＭ部２４，２５，２
６，２７が、冗長化された他の２系統の入出力通信モジュール（ＩＯＭ）用の通信バスα
，βに接続される。なお、ＦＣＳ部１０２もＦＣＳ部１０１と同様に構成され、同様な部
分は同じ機能を有するので、その説明を省略する。
【００４１】
ＩＯＭ部２４には第３のバルブ４４が接続される。バルブ４４は、図示しないプラント
内の配管に取り付けられ、制御データＤ２４に基づいて流量を調整する。ＩＯＭ部２５に
は第３のセンサ４５が接続される。センサ４５は上述の配管内の流量を検知して流量検知
時のプロセスデータＤ４５を発生する。
【００４２】
ＩＯＭ部２６には第４のバルブ４６が接続される。バルブ４６は、図示しないプラント
内の他の配管に取り付けられ、制御データＤ２６に基づいて流量を調整する。ＩＯＭ部２
７には第４のセンサ４７が接続される。センサ４７は上述の他の配管内の流量を検知して
流量検知時のプロセスデータＤ４７を発生する。なお、バルブ３４，３６，４４，４６及
びセンサ３５，３７，４５，４７はフィールド機器の一例を構成する。これらのＦＣＳ部
１０１，１０２により、分散型制御システム＃１を構成する。
【００４３】
続いて、図２を参照して、ＦＣＳ部１０１の内部構成例について説明する。図２に示す
ＦＣＳ部１０１は、ある規定回数の通信異常発生時、状態管理テーブル１２１に一時異常
フラグＦＧ２をセットすることで、通信バスα，βの状態を『一時異常』の状態に設定す
る機能を有している。この機能を以下でＩＯＭ状態管理機能という。
【００４４】
ＦＣＳ部１０１内のＣＰＵ１０は、ＩＯ通信機能部１１の他に、メモリ部１２、命令演
算部１３及びＣＰＵバス１８を有している。ＩＯ通信機能部１１、メモリ部１２及び命令
演算部１３はＣＰＵバス１８に接続されている。
【００４５】
命令演算部１３は制御バス１０３を介して上位のパソコン１０４からデータパケットを
受信し、データパケットをデコードしてＩＯ通信機能部１１と入出力通信モジュール（Ｉ
ＯＭ）との間における通信処理（以下ＩＯＭ通信処理という）を実行するための命令（コ
マンド）を演算する。命令演算部１３はプロセスデータＤ３５，Ｄ３７等を用いて制御演
算を実行する。命令や制御データＤ１４，Ｄ１６は、ＣＰＵバス１８を介してＩＯ通信機
能部１１やメモリ部１２等に転送される。
【００４６】
ＩＯ通信機能部１１には記憶部の一例を構成するメモリ部１２が接続され、ＩＯＭ状態
管理機能を実現するようになされる。ＩＯ通信機能部１１は命令演算部１３から発行され
るコマンドを受信して、メモリ部１２内に状態管理テーブル１２１を作成する。状態管理
テーブル１２１は、ＩＯＭ部１４，１５，１６，１７等の状態を管理するためであり、通
信の是非や、使用する通信バスα，βの判断のために参照される。メモリ部１２には随時
アクセス可能な不揮発性や、バックアップ付きの揮発性の記憶装置が使用される。
【００４７】
メモリ部１２はＩＯ通信機能部１１又は命令演算部１３によって制御され監視される通
信バスα，βの状態を正常、一時異常及び異常の３種類に区分してＩＯＭ部１４，１５，
１６，１７毎に記憶する。例えば、メモリ部１２内には状態管理テーブル１２１が作成さ
れる。状態管理テーブル１２１には、例えば、５個の識別子ＩＯＭ１〜ＩＯＭ５が割り当
てられ、通信バスα，βの状態に対応して一時異常フラグＦＧ２等が設定される（図３参
照）。
【００４８】
ＩＯ通信機能部１１は、少なくとも、２つの通信バスα，βを切り換える機能を有して
、当該通信バスα，βに接続され、通信バスα，βを監視し、当該通信バスα，βの一時
異常及び正常を判別する。一時異常とは、通信要求（ＩＯＭ通信）を実行して一定時間以
内に応答がなかった状態をいう（診断復旧確認処理）。
【００４９】
ＩＯ通信機能部１１は、ＩＯＭ入出力機能１１１及び診断復旧確認機能１１２を有して
いる。ＩＯ通信機能部１１は、ＩＯＭ入出力処理において、状態管理テーブル１２１で『
正常』となった通信バスα又はβから優先的に接続を切り換えて使用する機能を有してい
る。例えば、ＩＯ通信機能部１１は、メモリ部１２を参照し、正常な状態の通信バスα又
はβを優先してＩＯＭ部１４等に接続し、センサ３５からプロセスデータＤ３５を入力し
、及び、当該正常な状態の通信バスα又はβを介してバルブ３４へ制御データＤ１５等を
出力する（ＩＯＭ入出力処理）。
【００５０】
ＩＯＭ入出力機能１１１にはＩＯＭ入出力処理の他に正常な通信バスαに接続を切り換
えるバス選択切り換え機能が含まれる。例えば、ＩＯ通信機能部１１は、一方の通信バス
α又はβの状態が一時異常であると判別したとき、一時異常と判別された通信バスα又は
βから正常な状態の通信バスα→β（β→α）にＩＯＭ部１４等の接続を切り換えるよう
になされる。
【００５１】
このようなバス選択切り換え機能によって、一時異常フラグＦＧ２や異常フラグＦＧ３
等がメモリ部１２に記憶されている通信バスα及びβを介してのＩＯＭ部１４，１５，１
６，１７の接続を回避できるので、バルブ３４，３６，４４，４６へ確実に制御データＤ
１４，Ｄ１６，Ｄ２４，Ｄ２６を出力すること、及び、センサ３５，３７，４５，４７か
らのプロセスデータＤ３５，Ｄ３７，Ｄ４５，Ｄ４７を確実に取得することができる。
【００５２】
また、ＩＯ通信機能部１１は、ＩＯＭ入出力処理及び診断復旧確認処理（ＩＯＭ通信）
の成否から通信バスα，βの状態を『正常』／『一時異常』／『異常』のいずれかに設定
するＩＯＭ状態管理機能を有している。ＩＯ通信機能部１１は、『一時異常』となったＩ
ＯＭ部１４等に、一時異常フラグＦＧ２をセットする。つまり、ＩＯ通信機能部１１は、
何らかの通信異常を引き起こす原因（トランジェントエラーや、ＩＯＭ部自体の異常、通
信バスαやβ等の異常）により、ＩＯＭ通信処理を失敗した場合、ＩＯＭ状態管理機能に
より、状態管理テーブル１２１に一時異常フラグＦＧ２をセットする。
【００５３】
この例で、ＩＯ通信機能部１１は、通信バスα，βの一時異常を判別する毎に当該通信
バスα，βに対して一時異常フラグを立ち上げ、フラグ立ち上げ回数と基準回数とを比較
する。ここにフラグ立ち上げ回数とは一時異常フラグを立ち上げた回数をいう。基準回数
とは一時異常又は異常を判別するための設定データをいう。
【００５４】
ＩＯ通信機能部１１は、基準回数を越えるフラグ立ち上げ回数が検出されたとき、当該
通信バスの状態を異常と判別する。このような判別機能によって、例えば、基準回数＝１
を設定して、一時異常フラグＦＧ２が一回立ち上がると、当該通信バスα又はβの一時異
常フラグＦＧ２をメモリ部１２に記憶することができ、一時異常フラグＦＧ２が二回以上
立ち上がると、当該通信バスα又はβの異常フラグＦＧ３をメモリ部１２に記憶できるよ
うになる。
【００５５】
ＩＯ通信機能部１１は、一時異常又は異常と判別された通信バスα又はβから正常な状
態の通信バスα又はβに接続を切り換えた後の通信空き時間に、一時異常又は異常と判別
された通信バスα又はβを介して診断通信を含む診断復旧確認処理を実行する。ここに診
断復旧確認処理とは、プロセスデータＤ３５等の取得を目的とせずに、診断通信の成否の
みを確認する機能をいい、換言するとＩＯ通信機能部１１はＩＯＭ部１４，１５，１６，
１７を呼び出せるか否かの通信復旧を確認する動作をいう。
【００５６】
診断復旧確認処理は、『一時異常』となった通信バスαやβ等に対し行われる。その成
否に基づいて通信バスαやβ等の状態を『正常』または『異常』状態に遷移させるように
なる。例えば、診断復旧確認処理を行った結果、ＩＯＭ部１４や，１５，１６，１７等か
らＩＯ通信機能部１１に応答が有った場合、ＩＯ通信機能部１１は、一時異常又は異常と
判別された通信バスα又はβの状態を一時異常又は異常から正常へ書き換える。ＩＯＭ部
１４や，１５，１６，１７等からＩＯ通信機能部１１に応答が無かった場合、ＩＯ通信機
能部１１は、一時異常と判別された通信バスα又はβの状態を異常へ書き換え、通信バス
α又はβの状態が元々異常であった場合は、当該通信バスα又はβの異常をそのまま保持
するようになされる。
【００５７】
この例で、一時異常と判別された、通信バスαの状態を一時異常フラグＦＧ２から正常
フラグＦＧ１へ書き換える。同様にして、一時異常と判別された、通信バスβの状態を一
時異常フラグＦＧ２から正常フラグＦＧ１へ書き換える。このような診断復旧確認機能に
よって、ＩＯＭ部１４，１５，１６，１７からＩＯ通信機能部１１に応答がなかった場合
に、ＩＯＭ部１４，１５，１６，１７自体の異常や、通信バスα又はβ自体の異常等を早
期に発見できるようになる。
【００５８】
上述の説明では、ＣＰＵ１０内で、命令演算部１３の動作を補助するＩＯ通信機能部１
１（ＩＯコプロセッサ）が診断復旧確認処理を実行する場合について説明したが、これに
限られることはなく、命令演算部１３で診断復旧確認処理を実行させてもよい。
【００５９】
続いて、図３を参照して、状態管理テーブル１２１における各フラグの記述例について
説明する。図３に示す状態管理テーブル１２１には、例えば、３個の識別子ＩＯＭ１，Ｉ
ＯＭ２，ＩＯＭ３と共に、通信バスα，βの状態を記述するメモリ領域が割り当てられて
いる。
【００６０】
この例で、状態管理テーブル１２１には、ＩＯＭ部１４に対してＩＯＭ１の識別子と共
に、通信バスαの『正常』及び通信バスβの『異常』に対応して、正常フラグＦＧ１及び
異常フラグＦＧ３が設定（登録）される。ＩＯＭ部１５に対してはＩＯＭ２の識別子と共
に、通信バスαの『一時異常』及び通信バスβの『正常』に対応して、一時異常フラグＦ
Ｇ２及び正常フラグＦＧ１が設定（登録）される。
【００６１】
ＩＯＭ部１６に対してはＩＯＭ３の識別子と共に、通信バスαの『正常』及び通信バス
βの『正常』に対応して、各々正常フラグＦＧ１が設定（登録）される。このような状態
管理テーブル１２１をメモリ部１２を備えると、ＩＯ通信機能部１１は、正常フラグＦＧ
１、一時異常フラグＦＧ２及び異常ＦフラグＧ３に区分して記述された通信バスα，βの
状態を参照して、当該通信バスα，βに接続されるＩＯＭ部１４，１５，１６，１７をア
クセス管理できるようになる。
【００６２】
続いて、図４Ａ〜Ｃを参照して、ＩＯ通信機能部１１（ＩＯコプロセッサ）とＩＯＭ部
１４等との通信例について説明する。図４Ａに示すＩＯ通信機能部１１とＩＯＭ部１４等
との通信例によれば、黒△印は、ＩＯ通信機能部１１からＩＯＭ部１４への通信時刻ｔ１
，ｔ３，ｔ５，ｔ７，ｔ８，ｔ１０，ｔ１２，ｔ１４，ｔ１５，ｔ１７（例）である。白
△印は、ＩＯＭ部１４からＩＯ通信機能部１１への通信時刻ｔ２，ｔ４，ｔ６，ｔ９，ｔ
１１，ｔ１３，ｔ１６，ｔ１８（例）である。
【００６３】
図４Ｂに示す通信バスα（図中αバスと表示する）の状態例によれば、通信時刻ｔ１〜
ｔ７において正常であり、通信時刻ｔ８〜ｔ１５において、一時異常な状態であり、通信
時刻ｔ１５以降が異常な状態となっている。これに対して、図４Ｃに示す通信バスβ（図
中βバスと表示する）の状態例によれば、通信時刻ｔ１以降ずっと正常な状態となってい
る。
【００６４】
この例では、黒△印の通信時刻ｔ１で、まず、通信バスαを使用して、ＩＯ通信機能部
１１からＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の
通信時刻ｔ２でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力され
、ＩＯ通信が成功する（○印）。同様にしてスキャン周期Ｔ（Ｅｘ．ｔ３−ｔ１）毎に、
図４Ｂ，Ｃに示す通信バスα，βを切り換えて、黒△印の通信時刻ｔ３，ｔ５で、ＩＯ通
信機能部１１からＩＯＭ部１４へＩＯ通信が実行され、白△印の通信時刻ｔ４，ｔ６で、
ＩＯＭ部１４からＩＯ通信機能部１１へのＩＯ通信が成功している（αバス通信）。
【００６５】
しかし、黒△印の通信時刻ｔ７で、通信バスαを使用して、ＩＯ通信機能部１１からＩ
ＯＭ部１４へＩＯ通信が実行されても、ＩＯＭ部１５はＩＯ通信機能部１１に対して無応
答であり、ＩＯ通信が失敗している（×印）。このとき、ＩＯ通信機能部１１は一時異常
フラグＦＧ２を状態管理テーブル１２１に設定する。
【００６６】
その後、黒△印の通信時刻ｔ８で、通信バスβを使用して、ＩＯ通信機能部１１からＩ
ＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の通信時刻ｔ
９でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力され、ＩＯ通信
が成功する（○印）。同様にして通信バスβを使用して、黒△印の通信時刻ｔ１０，ｔ１
２で、ＩＯ通信機能部１１からＩＯＭ部１４へＩＯ通信が実行され、白△印の通信時刻ｔ
１１，ｔ１３で、ＩＯＭ部１４からＩＯ通信機能部１１へのＩＯ通信が成功している（β
バス通信）。
【００６７】
この例でＩＯ通信機能部１１は、状態管理テーブル１２１に一時異常フラグＦＧ２が設
定された通信バスαに対して、ＩＯＭ通信の空き時間（合間）となる、例えば、黒△印の
通信時刻ｔ１４でαバス診断通信を実行する。αバス診断通信では、一時異常と判別され
た通信バスαに対して、プロセスデータＤ３５等の取得を目的とせずに、ＩＯＭ通信の成
否のみを確認するようになされる（診断復旧確認処理）。
【００６８】
診断復旧確認処理はＩＯＭ入出力処理以外の処理時間で、かつ、スキャン周期とは異な
る長い周期で実行される。このため、スキャン周期でのＩＯＭ入出力処理を妨げることが
なく、局所的な通信負荷を軽減することができる。αバス診断通信の結果、ＩＯＭ部１５
からＩＯ通信機能部１１への応答が無く、ＩＯ通信が失敗したことが見出される（判別さ
れる）と、ＩＯ通信機能部１１は状態管理テーブル１２１における一時異常フラグＦＧ２
を異常フラグＦＧ３に書き換えるようになされる。
【００６９】
その後、黒△印の通信時刻ｔ１５で、通信バスβを使用して、ＩＯ通信機能部１１から
ＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の通信時刻
ｔ１６でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力され、ＩＯ
通信が成功している（○印）。同様にして通信バスβを使用して、黒△印の通信時刻ｔ１
７で、ＩＯ通信機能部１１からＩＯＭ部１４へＩＯ通信が実行され、白△印の通信時刻ｔ
１８で、ＩＯＭ部１４からＩＯ通信機能部１１へのＩＯ通信が成功している（βバス通信
）。
【００７０】
続いて、図５〜図７に示すフローチャートを参照して、本発明に係る通信管理方法につ
いて説明する。図５は、ＣＰＵ１０における通信管理例を示すメインルーチンである。図
６は、ＩＯ通信機能部１１におけるＩＯ通信例を示すサブルーチンである。図７は、ＩＯ
通信機能部１１における診断復旧確認例を示すサブルーチンである。
【００７１】
この実施例では、制御開始時の２つの通信バスα及びβの初期状態が共に正常である場
合を例に挙げる。通信バスα，βは交互に切り換えて使用する場合である。診断復旧確認
処理は、ＩＯＭ入出力処理以外の処理時間であって、スキャン周期とは異なった長い周期
で一時異常フラグＦＧ２が立った通信バスα（又はβ）を介してＩＯＭ部１４等との間で
診断通信を実行する場合を例に採る。
【００７２】
これらを管理条件にして、図５に示すフローチャートのステップＳＴ１でＩＯ通信機能
部１１は、状態管理テーブル１２１を参照して通信バスα及びβの状態を入力する。初期
状態で状態管理テーブル１２１には、２つの通信バスα及びβの状態が共に正常であるこ
とを示す正常フラグＦＧ１が記述されている。
【００７３】
次に、ステップＳＴ２で、ＩＯ通信機能部１１は、通信バスα，βの両方が異常である
場合（Ｘ）と、少なくとも、通信バスα又はβの一方が正常、及び、通信バスα，βの両
方が正常である場合（Ｙ）に対応して制御を分岐する。
【００７４】
通信バスα又はβの一方が正常、及び、通信バスα，βの両方が正常である場合（Ｙ）
は、ステップＳＴ３でＩＯ通信機能部１１は、通信バスα又はβへ接続を切り換える。例
えば、最初に通信バスαを使用する場合は、ステップＳＴ４で、ＩＯ通信機能部１１は、
通信バスαをＩＯＭ部１４，１５，１６，１７に接続してＩＯＭ通信処理を実行する（α
バス通信）。
【００７５】
この例のＩＯＭ通信処理によれば、図６のサブルーチンをコールしてそのステップＳＴ
４１でＩＯ通信機能部１１は、ＩＯＭ通信を実行する。例えば、図４に示したように、黒
△印の通信時刻ｔ１で、通信バスαを使用して、ＩＯ通信機能部１１からＩＯＭ部１４へ
制御データＤ１４を出力するＩＯ通信が実行されると、白△印の通信時刻ｔ２でＩＯＭ部
１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力される。
【００７６】
その後、ステップＳＴ４２でＩＯ通信機能部１１は、ＩＯＭ通信に成功したか否かを判
別する。この際の判別基準は、ＩＯ通信機能部１１からＩＯＭ部１４等へ通信要求を実行
してから所定の時間内に返信が有ったか否かで、通信バスαの状態が一時異常であるか否
かを判別する。
【００７７】
ＩＯＭ通信に成功しなかった場合は、ステップＳＴ４３に移行して、ＩＯ通信機能部１
１はＩＯＭ通信を実行する規定回数（例えば基準回数＝１）を設定して、ＩＯＭ通信に失
敗したか否かを判別する。例えば、一時異常フラグＦＧ２が一回立ち上がると、当該通信
バスαの一時異常フラグＦＧ２をメモリ部１２に記憶する。
【００７８】
ＩＯＭ部１４等の接続を規定回数だけ実行してＩＯＭ通信を失敗した場合は、ステップ
ＳＴ４４に移行して、ＩＯ通信機能部１１は状態管理テーブル１２１に現在使用中の通信
バスαを一時異常に設定する。その後、ステップＳＴ４にリターンする。なお、ステップ
ＳＴ４２でＩＯＭ通信に成功した場合及びステップＳＴ４４で状態管理テーブル１２１に
一時異常フラグＦＧ２を設定した後は、ステップＳＴ４にリターンする。
【００７９】
次に、ステップＳＴ５でＩＯ通信機能部１１は、バス切り換えコマンドをデコード（判
別）して制御を分岐する。例えば、両方の通信バスα及びβが正常で、状態管理テーブル
１２１には一時異常フラグＦＧ２や異常フラグが設定されていない場合であって、αバス
からβバスへ通信バスを切り換えるコマンドが発行されている場合は、ＩＯＭ部１４等の
接続を通信バスαから通信バスβに切り換えた後に、ステップＳＴ６でＩＯ通信機能部１
１は、βバス通信を実行する。
【００８０】
例えば、図４に示したように、黒△印の通信時刻ｔ３で、通信バスαを使用して、ＩＯ
通信機能部１１からＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると
、白△印の通信時刻ｔ４でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５
が出力される。
【００８１】
また、状態管理テーブル１２１に、既に、一時異常フラグＦＧ２が設定されていて、α
バスからβバスへ通信バスを切り換えるコマンドが発行されている場合は、ＩＯＭ部１４
等の接続を通信バスαから通信バスβに切り換える。このとき、ＩＯ通信機能部１１は、
一時異常と判別された通信バスαから正常な状態の通信バスβにＩＯＭ部１４，１５，１
６，１７の接続を切り換える。
【００８２】
その後、ステップＳＴ６でＩＯ通信機能部１１は、βバス通信を実行する。例えば、図
４に示したように、黒△印の通信時刻ｔ８で、通信バスβを使用して、ＩＯ通信機能部１
１からＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の通
信時刻ｔ９でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力される
。
【００８３】
αバスからβバスへ通信バスを切り換えるコマンドが発行されていない場合は、例えば
、片側の通信バスα又はβのみを使用してＩＯＭ通信を実行する場合は、ステップＳＴ８
に移行してＩＯ通信機能部１１が終了を判別する。この際の判別基準は、例えば、上位の
パソコン１０４からの終了データを検出し、終了データに基づいてＩＯＭ通信を終了有無
を判断する。
【００８４】
終了データが検出されない場合はステップＳＴ９に移行して診断要否を判別する。この
際の判別基準は、例えば、状態管理テーブル１２１を参照し、一時異常フラグＦＧ２が設
定されているか否かでＩＯ通信機能部１１が診断要否を判断する。この例で、一時異常フ
ラグＦＧ２が検出された場合は、ステップＳＴ１０に移行してＩＯ通信機能部１１は、診
断通信処理を実行する。
【００８５】
この例の診断通信処理によれば、図７のサブルーチンをコールしてそのステップＳＴ１
０１でＩＯ通信機能部１１は、診断通信を実行する。この診断通信の対象は、一時異常又
は異常となった通信バスα又はβであるので、正常の場合は、診断通信をパスする。例え
ば、図４に示したように、黒△印の通信時刻ｔ１４で、通信バスαを使用して、ＩＯ通信
機能部１１からＩＯＭ部１４を呼び出す診断通信が実行される。しかし、通信バスαに異
常が発生していると、ＩＯＭ部１４等からＩＯ通信機能部１１への応答は無い（無応答）
。
【００８６】
そして、ステップＳＴ１０２でＩＯ通信機能部１１は、診断通信が成功したか否かを判
別する。この際の判別基準は、ＩＯ通信機能部１１からＩＯＭ部１４等へ所定の時間内に
通信要求を規定回数だけ実行し、その応答が一回でも有ったか否かで、通信バスαの状態
が一時異常でなく異常又は正常であるか否かを判別する。
【００８７】
診断通信に成功した場合は、ステップＳＴ１０４に移行して、ＩＯ通信機能部１１は状
態管理テーブル１２１における一時異常フラグＦＧ２を正常フラグＦＧ１に書き換える（
設定する）ようにメモリ部１２を制御する。その後、ステップＳＴ１０にリターンする。
【００８８】
上述のステップＳＴ１０３で診断通信に成功しなかった場合は、ステップＳＴ１０５に
移行して、ＩＯ通信機能部１１は、診断通信を実行する規定回数（例えば基準回数＝５）
を設定して、規定回数を越える失敗回数を検出したか否かを判別する。規定回数を越える
失敗回数を検出していない場合は、ステップＳＴ１０２に戻って診断通信を繰り返す。
【００８９】
ステップＳＴ１０５で規定回数を越える失敗回数を検出した場合は、ステップＳＴ１０
６に移行してＩＯ通信機能部１１は、状態管理テーブル１２１における一時異常フラグＦ
Ｇ２を異常フラグＦＧ３に書き換える（設定する）ようにメモリ部１２を制御する。
【００９０】
この例で、ＩＯ通信機能部１１には、再度、ＩＯＭ通信を試みる機能が備えられており
、一時異常フラグＦＧ２がセットされた、例えば、通信バスαとは異なる他方の通信バス
βに切り替えて再度、ＩＯＭ通信を実行する（バス切り換えを伴うリトライ通信機能）。
このリトライ通信機能の結果、ＩＯＭ部自体の故障か、通信バスαのある一部分的な区間
が故障となっているかを判別できるようになる。
【００９１】
上述の診断通信処理後は、ステップＳＴ１０にリターンする。このような診断復旧確認
処理の成否によって、通信バスα又はβを『正常』または『異常』に遷移させることがで
き、先の例で示した一時異常の通信バスαを異常に設定できるようになる。このような診
断復旧確認処理が終了した場合は、ステップＳＴ８に戻る。上述のステップＳＴ１０で診
断通信処理が終了し、ステップＳＴ８で終了データが検出された場合はＩＯＭ通信処理を
終了する。
【００９２】
このように、実施形態としてのＦＣＳ部１０１によれば、ＩＯ通信機能部１１が、一方
の例えば通信バスαの状態が一時異常であると判別したとき、一時異常と判別された通信
バスαから正常な状態の通信バスβにＩＯＭ部１４，１５，１６，１７の接続を切り換え
るようになる。
【００９３】
従って、一時異常と判別された時点で、ＩＯＭ部１４，１５，１６，１７の接続が切り
換えられた正常な状態の通信バスβを介して当該ＩＯ通信機能部１１からＩＯＭ部１４を
介して制御データＤ１４をバルブ３４に出力したり、正常な状態の通信バスβを介してセ
ンサ３５からＩＯ通信機能部１１へプロセスデータＤ３５を出力したりすることができる
。
【００９４】
これにより、一時異常と判別された通信バスαへの通信可否の確認を行うバス切り換え
を伴わないリトライ通信処理を省略することができるので、従来方式のようなリトライ通
信処理を実行する場合に比べて、ＩＯ通信機能部１１がセンサ３５，３７からプロセスデ
ータＤ３５，Ｄ３７を取得する際の遅延時間を短縮することができる。
【００９５】
上述した例では、トランジェントエラー以外の通信異常の場合、直前に使用していた通
信バスαと同一の通信バスαを使用しても、再度、リトライ通信を失敗する可能性が高い
ので、『一時異常』なった通信バスαは使用せずに、即座に通信バスβを切り替えて通信
を行っている。このことで、特に片側のみの通信バスα又はβの異常のような通信異常状
態では、通信バスβからのＩＯＭ通信成功により、プロセスデータＤ３５，Ｄ３７を即座
に取得できるメリットがある。
【００９６】
なお、ＩＯＭ通信後のスキャン周期Ｔでは、一時異常フラグＦＧ２がセットされた通信
バスαは、ＩＯＭ入出力処理では、積極的に使用することを避け、正常な通信バスβを優
先的に使用し続けるようにした。ただし、両通信バスα，βが異常の場合は、一時異常で
も使用する。しかも、通信空き時間に、スキャン周期Ｔとは異なる長い周期により診断復
旧確認処理を実行することにより、局所的な通信負荷を軽減できるようになった。
【産業上の利用可能性】
【００９７】
この発明は、電気や、機械、化学工場等のプラントにおけるフィールド機器を分散制御
するフィールドコントロールステーション（ＦＣＳ部）や、ＦＣＳ部を有する分散型制御
システムや、ＦＣＳ部におけるＣＰＵとＩＯＭとの間の通信を管理するアクセス管理等に
適用して極めて好適である。
【符号の説明】
【００９８】
１ 分散型制御システム
１０ 制御側のＣＰＵ（制御部）
１１，２１ ＩＯ通信機能部
１２ メモリ部（記憶部）
１３ 命令演算部
１４，１５，１６，１７ ＩＯＭ部（データ入出力部）
１８ ＣＰＵバス
２０ 待機側のＣＰＵ（制御部）
２４，２５，２６，２７ ＩＯＭ部（データ入出力部）
１０１，１０２ フィールドコントロールステーション（ＦＣＳ部：制御装置）
１０３ 制御バス
１１１ ＩＯＭ入出力機能
１１２ 診断回復機能
α，β 通信バス
【技術分野】
【０００１】
この発明は、電気や、機械、化学工場等のプラントにおけるフィールド機器を分散制御
するフィールドコントロールステーション（ＦＣＳ部）や、ＦＣＳ部を有する分散型制御
システム（ＤＣＳ）、ＦＣＳ部におけるＣＰＵ（中央処理装置）と通信対象となる入出力
通信モジュール（ＩＯＭ部）との間の通信を管理するアクセス管理等に適用可能な制御装
置及び通信管理方法に関するものである。
【背景技術】
【０００２】
近年、電気や、機械、化学工場等のプラントにおいて分散型制御システム（Dispersion
Control System：ＤＣＳ）が採用される場合が多くなってきた。分散型制御システムに
よれば、ＦＣＳ部内に実装されたＩＯ通信機能部（ＩＯコプロセッサ）が、あらかじめ定
義された周期（スキャン周期）でＩＯＭ部へ通信を行うことにより、フィールド機器を構
成するバルブ等へ制御データを出力したり、そのセンサからプロセスデータを取得してい
る（ＩＯＭ通信）。
【０００３】
図８は従来例に係るＦＣＳ部１０５の内部構成例を示すブロック図である。図８に示す
ＦＣＳ部１０５は、ＣＰＵ３０を有している。ＣＰＵ３０は、ＩＯ通信機能部３１の他に
、メモリ部３２、命令演算部３３及びＣＰＵバス１８を有している。ＩＯ通信機能部３１
、メモリ部３２及び命令演算部３３はＣＰＵバス１８に接続されている。ＩＯ通信機能部
３１には、２系統の通信バスα，βを介して４個のＩＯＭ部１４，１５，１６，１７が接
続されている。ＩＯＭ部１４，１５，１６，１７には、図示しない電気や、機械、化学工
場等のプラントにおけるバルブやセンサ等のフィールド機器が接続される。
【０００４】
命令演算部３３は、図示しない制御バスを介して上位のパーソナルコンピュータ（以下
パソコンという）からデータパケットを受信し、データパケットをデコードしてＩＯ通信
機能部３１及びＩＯＭ部１４，１５，１６，１７の間における通信処理（以下ＩＯＭ通信
処理という）を実行するための命令（コマンド）を演算する。命令演算部３３はプロセス
データを用いて制御演算を実行する。
【０００５】
ＩＯ通信機能部３１にはメモリ部３２が接続される。ＩＯ通信機能部３１は命令演算部
３３から発行されるコマンドを受信して、メモリ部３２内に状態管理テーブル１３２を作
成する。状態管理テーブル１３２は、ＩＯＭ部１４，１５，１６，１７等の状態を管理す
るためであり、通信の是非や、使用する通信バスα，βの判断のために参照される。
【０００６】
メモリ部３２はＩＯ通信機能部３１によって制御され監視される通信バスα，βの状態
を正常及び異常の２種類に区分してＩＯＭ部１４，１５，１６，１７毎に記憶する。状態
管理テーブル１３２には、例えば、５個の識別子ＩＯＭ１〜ＩＯＭ５が割り当てられ、通
信バスα，βの状態に対応して正常又は異常が設定される。
【０００７】
ＩＯ通信機能部３１は、２つの通信バスα，βを切り換える機能を有して、当該通信バ
スα，βに接続され、通信バスα，βを監視し、当該通信バスα，βの異常及び正常を判
別する。ＩＯ通信機能部３１はリトライ通信機能を有している。ここにリトライ通信機能
とは、トランジェントエラーやＩＯＭ異常、通信バスα、βの異常等、何らかの通信異常
を引き起こす原因によりＩＯＭ通信を失敗した場合、再度、ＩＯＭ通信を試みる動作をい
う。
【０００８】
図９Ａ〜Ｃは、ＩＯ通信機能部３１とＩＯＭ部１４等との通信例を示すシーケンス図及
び通信バスα，βの状態例を示す説明図である。図９Ａに示すＩＯ通信機能部３１とＩＯ
Ｍ部１４等との通信例によれば、黒△印は、ＩＯ通信機能部３１からＩＯＭ部１４への通
信時刻τ１，τ３，τ５，τ７，τ８，τ９，τ１１，τ１３（例）である。白△印は、
ＩＯＭ部１４からＩＯ通信機能部３１への通信時刻τ２，τ４，τ６，τ１０，τ１２，
τ１４（例）である。
【０００９】
図９Ｂに示す通信バスα（図中αバスと表示する）の状態例によれば、通信時刻τ１〜
τ８のαバス異常が確定する時刻まで正常となされ、通信時刻τ９以降は、異常な状態で
ある。
【００１０】
これに対して、図９Ｃに示す通信バスβ（図中βバスと表示する）の状態例によれば、
通信時刻τ１以降ずっと正常な状態となっている。
【００１１】
この例では、黒△印の通信時刻τ１で、まず、通信バスαを使用して、ＩＯ通信機能部
３１からＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の
通信時刻τ２でＩＯＭ部１５からＩＯ通信機能部３１へプロセスデータが出力され、ＩＯ
通信が成功する（○印）。同様にしてスキャン周期Ｔ（Ｅｘ．τ３−τ１）毎に、図９Ｂ
，Ｃに示す通信バスα，βを切り換えて、黒△印の通信時刻τ３，τ５で、ＩＯ通信機能
部３１からＩＯＭ部１４へＩＯ通信が実行され、白△印の通信時刻τ４，τ６で、ＩＯＭ
部１４からＩＯ通信機能部３１へのＩＯ通信が成功している（αバス通信）。
【００１２】
しかし、黒△印の通信時刻τ７で、通信バスαを使用して、ＩＯ通信機能部３１からＩ
ＯＭ部１４へＩＯ通信が実行されても、ＩＯＭ部１５はＩＯ通信機能部３１に対して無応
答であり、ＩＯ通信が失敗している（×印：通信異常）。この時点から、ＩＯ通信機能部
３１はリトライ通信処理を実行する。このリトライ通信処理によれば、他のＩＯＭ通信を
中断し、真の通信異常であるか否かを確定するために、何回かのリトライ通信を試みるよ
うになされる。
【００１３】
同様にして、黒△印の通信時刻τ８で、通信バスαを使用して、ＩＯ通信機能部３１か
らＩＯＭ部１４へＩＯ通信が実行されても、ＩＯＭ部１５はＩＯ通信機能部３１に対して
無応答であり、ＩＯ通信が失敗している（×印）。このリトライ通信の結果、通信異常が
確定されると、黒△印の通信時刻τ９で、通信バスαから通信バスβへ接続を切り換える
。
【００１４】
そして、通信バスβを使用して、ＩＯ通信機能部３１からＩＯＭ部１４へ制御データを
出力するＩＯ通信が実行されると、白△印の通信時刻τ１０でＩＯＭ部１５からＩＯ通信
機能部３１へプロセスデータが出力され、ＩＯ通信が成功する（○印）。同様にして通信
バスβを使用して、黒△印の通信時刻τ１１，τ１３で、ＩＯ通信機能部３１からＩＯＭ
部１４へＩＯ通信が実行され、白△印の通信時刻τ１２，τ１４で、ＩＯＭ部１４からＩ
Ｏ通信機能部３１へのＩＯ通信が成功している（βバス通信）。
【００１５】
この種のＩＯＭ通信機能を備えたフィールドコントロールステーションに関連して、特
許文献１には二重化通信装置が開示されている。この二重化通信装置によれば、二重化さ
れた通信カードに基づいて、上位装置からの通信要求に応じて機器と通信する場合に、ア
プリケーションプログラム実行部、エラー処理手段、通信要求処理手段及び再通信要求処
理手段を備える。アプリケーションプログラム実行部は、二重化された通信カードの制御
権を切り替えるデバイスドライバを介して、上位装置からの通信要求に応じて機器と通信
する。
【００１６】
エラー処理手段はデバイスドライバ内に設けられ、制御権の切り替えに起因する通信エ
ラーに対して特有のエラーコードを生成する。通信要求手段は、エラー処理手段からエラ
ーコードを受け取り、制御権の切り替え時の通信要求にエラーコードを付加してアプリケ
ーションプログラム実行部に通知する。これを前提にして、アプリケーションプログラム
実行部内には再通信要求処理手段が設けられ、エラーコードを取得したとき、上位装置か
らの通信要求を通信要求処理手段に再送するようになされる。このように装置を構成する
と、エラーとなった通信要求に対する煩雑なキャンセル処理を必要としないために、デバ
イスドライバの通信機能をシンプルに設計できるというものである。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】特開２００８−１５８７２８号公報（第４頁 図１）
【発明の概要】
【発明が解決しようとする課題】
【００１８】
ところで、従来例に係るフィールドコントロールステーション（ＦＣＳ部１０５）によ
れば、次のような問題がある。
【００１９】
ｉ．特許文献１に見られるような二重化通信方式を導入したＦＣＳ部１０５によれば、
通信異常が発生した場合に、ＩＯ通信機能部が他のＩＯＭ通信を中断し、通信バスの切り
替えを行わず、当該通信バスが『異常』であると判断されるまで、直前に使用した通信バ
スを再度使用して、リトライ通信処理を繰り返している。このため、通信異常発生時、フ
ィールド機器からプロセスデータを取得できるまでの遅延時間が長くなるという問題があ
る。
【００２０】
ii．因みに、一定回数以上の通信異常が生じた場合に、ＩＯ通信機能部が当該通信バス
の状態を『異常』と判断しているが、トランジェントエラー以外の通信異常が生じた場合
に、直前に使用した通信バスと同一の通信バスを使用しても、再度、ＩＯＭ通信を失敗す
る可能性が高い。
【００２１】
iii．しかも、通信対象の状態を通信空き時間等を利用して、”異常”の確認に取りか
かるのではなく、他のＩＯＭ通信を中断してリトライ通信処理を実行するので、局所的な
通信負荷が集中してしまう。これにより、分割型制御システムにおける安定した制御動作
を妨げる原因になっている。
【００２２】
そこで、この発明は上述した課題を解決したものであって、通信異常発生時、プロセス
データを取得できるまでの遅延時間を短縮できるようにすると共に、分散型制御システム
における制御動作の安定化を実現できるようにした制御装置及び通信管理方法を提供する
ことを目的とする。
【課題を解決するための手段】
【００２３】
上記課題を解決するために、制御装置は、少なくとも、通信要求を実行して一定時間以
内に応答がなかった場合を一時異常としたとき、２つの通信路に接続され、当該通信路を
切り換える機能を有して前記通信路を監視し、当該通信路の一時異常及び正常を判別する
制御部と、前記通信路を介して前記制御部に接続され、被制御機器から入力した処理デー
タを前記通信路を介して前記制御部に出力すると共に、前記通信路を介して当該制御部か
ら入力した制御データを前記被制御機器に出力する１つ以上のデータ入出力部とを備え、
前記制御部は、一方の前記通信路の状態が一時異常であると判別したとき、一時異常と判
別された前記通信路から正常な状態の通信路に前記データ入出力部の接続を切り換えるこ
とを特徴とするものである。
【００２４】
本発明に係る制御装置によれば、制御部は２つの通信路に接続され、当該通信路を切り
換える機能を有して通信路を監視する。制御部は、当該通信路の一時異常及び正常を判別
する。１つ以上のデータ入出力部が通信路を介して制御部に接続される。データ入出力部
は、被制御機器から入力した処理データを通信路を介して制御部に出力すると共に、通信
路を介して当該制御部から入力した制御データを被制御機器に出力する。
【００２５】
これを前提にして、制御部は、一方の通信路の状態が一時異常であると判別したとき、
一時異常と判別された通信路から正常な状態の通信路にデータ入出力部の接続を切り換え
るようになる。従って、一時異常と判別された時点で、データ入出力部の接続が切り換え
られた正常な状態の通信路を介して被制御機器から制御部へ処理データを出力したり、正
常な状態の通信路を介して当該制御部から被制御機器へ制御データを出力できるようにな
る。
【００２６】
本発明に係る通信管理方法は、少なくとも、通信要求を実行して一定時間以内に応答が
なかった場合を一時異常としたとき、２つの通信路に接続され、当該通信路を切り換える
機能を有して前記通信路を監視し当該通信路の一時異常及び正常を判別する制御部と、前
記通信路を介して前記制御部に接続され、被制御機器から入力した処理データを前記通信
路を介して前記制御部に出力すると共に、前記通信路を介して当該制御部から入力した制
御データを前記被制御機器に出力する１つ以上のデータ入出力部とを備えた制御装置が、
前記通信路の状態が一時異常であるか否かを判別するステップと、一方の前記通信路の状
態が一時異常であると判別されたとき、一時異常と判別された前記通信路から正常な状態
の通信路に前記データ入出力部の接続を切り換えるステップを有するものである。
【発明の効果】
【００２７】
本発明に係る制御装置及び通信管理方法によれば、２つの通信路を介して１つ以上のデ
ータ入出力部に接続され、当該通信路を切り換える機能を有して通信路を監視し、当該通
信路の一時異常及び正常を判別する制御部を備え、この制御部は、一方の通信路の状態が
一時異常であると判別したとき、一時異常と判別された通信路から正常な状態の通信路に
データ入出力部の接続を切り換えるものである。
【００２８】
この構成によって、一時異常と判別された時点で、データ入出力部の接続が切り換えら
れた正常な状態の通信路を介して被制御機器から制御部へ処理データを出力したり、正常
な状態の通信路を介して当該制御部から被制御機器へ制御データを出力できるようになる
。従って、一時異常と判別された通信路への通信可否の確認を行うリトライ通信を省略す
ることができるので、従来方式のようなリトライ通信を実行する場合に比べて、制御部が
被制御機器から処理データを取得する際の遅延時間を短縮することができる。
【図面の簡単な説明】
【００２９】
【図１】本発明に係る制御装置及び通信管理方法を応用した実施形態としての分散型制御システム＃１の構成例を示すブロック図である。
【図２】ＦＣＳ部１０１の内部構成例を示すブロック図である。
【図３】状態管理テーブル１２１における各フラグの記述例を示す概念図である。
【図４】（Ａ）〜（Ｃ）は、ＩＯ通信機能部１１とＩＯＭ部１４等との通信例を示すシーケンス図及び通信バスα，βの状態例を示す説明図である。
【図５】ＦＣＳ部１０１における通信管理例（その１）を示すフローチャートである。
【図６】ＦＣＳ部１０１における通信管理例（その２）を示すフローチャートである。
【図７】ＦＣＳ部１０１における通信管理例（その３）を示すフローチャートである。
【図８】従来例に係るＦＣＳ部１０５の内部構成例を示すブロック図である。
【図９】（Ａ）〜（Ｃ）は、ＩＯ通信機能部３１とＩＯＭ部１４等との通信例を示すシーケンス図及び通信バスα，βの状態例を示す説明図である。
【発明を実施するための形態】
【００３０】
以下、図面を参照しながら、この発明の実施の形態に係る制御装置及び通信管理方法に
ついて説明をする。図１に示す分散型制御システム＃１は、本発明に係る制御装置及び通
信管理方法を応用したシステムであり、電気や、機械、化学工場等のプラントにおける複
数の被制御機器（以下でフィールド機器という）を分散して制御するシステムである。
【００３１】
分散型制御システム＃１は、例えば、デスクトップ型や、ノートブック型等のパーソナ
ルコンピュータ（以下単にパソコン１０４という）、制御バス１０３、２系統のフィール
ドコントロールステーション（以下ＦＣＳ部１０１，１０２という）を有して構成される
。ＦＣＳ部１０１や、ＦＣＳ部１０２は、制御装置の一例を構成し、電気や、機械、化学
工場等のプラントにおいて、例えば、複数のセンサから得られるプロセスデータに基づい
て複数のバルブ等のフィールド機器を分散制御するようになされる。
【００３２】
パソコン１０４（ＨＩＳ）には、Ｖｎｅｔ／ＩＰ等の制御バス１０３が接続され、分散
制御用のパケットデータが転送される。ここにＶｎｅｔ／ＩＰとは、データ転送速度が１
Ｇｂｐｓ程度のイーサネット（登録商標）をベースとしたプロセス・オートメーション用
のリアルタイム・プラント・ネットワークシステムをいう。
【００３３】
この例で制御バス１０３には、２系統のＦＣＳ部１０１及びＦＣＳ部１０２が接続され
る。第１のＦＣＳ部１０１は、例えば、制御側のＣＰＵ１０、待機側のＣＰＵ２０及び４
個のＩＯＭ部１４，１５，１６，１７を備え、これらのＣＰＵ１０，２０及びＩＯＭ部１
４，１５，１６，１７が、冗長化された２系統の入出力通信モジュール（ＩＯＭ）用の通
信バスα，βに接続される。ＩＯＭ部１４，１５，１６，１７は、各々がデータ入出力部
の一例を構成する。
【００３４】
制御側のＣＰＵ１０は、入出力通信機能部（以下ＩＯ通信機能部１１という）を有して
おり、従来方式と同様にして、予め定義された周期（スキャン周期）でＩＯＭ入力処理を
実行し、上位のパソコン１０４等からの要求に応じてＩＯＭ入出力処理を実行する。ＩＯ
通信機能部１１にはＣＰＵ１０内の命令演算機能を補助するＩＯコプロセッサが使用され
る。ＩＯ通信機能部１１には２系統の通信バスα，βを介して、例えば、４個のＩＯＭ部
１４，１５，１６，１７が接続される。通信バスα，βはスキャン周期に基づき、交互に
切り換えられて使用される。
【００３５】
ＩＯ通信機能部１１は、例えば、通信バスα又はβを介して、ＩＯＭ部１４へ制御デー
タＤ１４を出力し、及び、ＩＯＭ部１６へ制御データＤ１６を出力したり、ＩＯＭ部１５
から処理データ（以下プロセスデータＤ３５という）を入力し、及び、ＩＯＭ部１７から
処理データ（以下プロセスデータＤ３７という）を入力して通信処理を実行する。
【００３６】
ＩＯＭ部１４には第１のバルブ３４が接続される。バルブ３４は、図示しないプラント
内の配管に取り付けられ、制御データＤ１４に基づいて流量を調整する。ＩＯＭ部１５に
はフィールド機器の一例を構成する第１のセンサ３５が接続される。センサ３５は上述の
配管内の流量を検知して流量検知時のプロセスデータＤ３５を発生する。
【００３７】
ＩＯＭ部１６には第２のバルブ３６が接続される。バルブ３６は、図示しないプラント
内の他の配管に取り付けられ、制御データＤ１６に基づいて流量を調整する。ＩＯＭ部１
７には第２のセンサ３７が接続される。センサ３７は上述の他の配管内の流量を検知して
流量検知時のプロセスデータＤ３７を発生する。
【００３８】
待機側のＣＰＵ２０も、入出力通信機能部（以下ＩＯ通信機能部２１という）を有して
いる。ＩＯ通信機能部２１には命令演算機能を補助するＩＯコプロセッサが使用される。
ＩＯ通信機能部２１も、上述の４個のＩＯＭ部１４，１５，１６，１７が接続された２系
統の通信バスα，βに並列に接続される。
【００３９】
例えば、ＩＯ通信機能部２１は、制御側のＣＰＵ１０に故障が生じたとき、通信バスα
又はβを介して、ＣＰＵ２０はＣＰＵ１０に代わってＩＯＭ部１４へ制御データＤ１４を
出力し、及び、ＩＯＭ部１６へ制御データＤ１６を出力したり、ＩＯＭ部１５から処理デ
ータ（以下プロセスデータＤ３５という）を入力し、及び、ＩＯＭ部１７から処理データ
（以下プロセスデータＤ３７という）を入力して通信処理を実行する。
【００４０】
第２のＦＣＳ部１０２も制御側のＣＰＵ１０、待機側のＣＰＵ２０及び４個のＩＯＭ部
２４，２５，２６，２７を備え、これらのＣＰＵ１０，２０及びＩＯＭ部２４，２５，２
６，２７が、冗長化された他の２系統の入出力通信モジュール（ＩＯＭ）用の通信バスα
，βに接続される。なお、ＦＣＳ部１０２もＦＣＳ部１０１と同様に構成され、同様な部
分は同じ機能を有するので、その説明を省略する。
【００４１】
ＩＯＭ部２４には第３のバルブ４４が接続される。バルブ４４は、図示しないプラント
内の配管に取り付けられ、制御データＤ２４に基づいて流量を調整する。ＩＯＭ部２５に
は第３のセンサ４５が接続される。センサ４５は上述の配管内の流量を検知して流量検知
時のプロセスデータＤ４５を発生する。
【００４２】
ＩＯＭ部２６には第４のバルブ４６が接続される。バルブ４６は、図示しないプラント
内の他の配管に取り付けられ、制御データＤ２６に基づいて流量を調整する。ＩＯＭ部２
７には第４のセンサ４７が接続される。センサ４７は上述の他の配管内の流量を検知して
流量検知時のプロセスデータＤ４７を発生する。なお、バルブ３４，３６，４４，４６及
びセンサ３５，３７，４５，４７はフィールド機器の一例を構成する。これらのＦＣＳ部
１０１，１０２により、分散型制御システム＃１を構成する。
【００４３】
続いて、図２を参照して、ＦＣＳ部１０１の内部構成例について説明する。図２に示す
ＦＣＳ部１０１は、ある規定回数の通信異常発生時、状態管理テーブル１２１に一時異常
フラグＦＧ２をセットすることで、通信バスα，βの状態を『一時異常』の状態に設定す
る機能を有している。この機能を以下でＩＯＭ状態管理機能という。
【００４４】
ＦＣＳ部１０１内のＣＰＵ１０は、ＩＯ通信機能部１１の他に、メモリ部１２、命令演
算部１３及びＣＰＵバス１８を有している。ＩＯ通信機能部１１、メモリ部１２及び命令
演算部１３はＣＰＵバス１８に接続されている。
【００４５】
命令演算部１３は制御バス１０３を介して上位のパソコン１０４からデータパケットを
受信し、データパケットをデコードしてＩＯ通信機能部１１と入出力通信モジュール（Ｉ
ＯＭ）との間における通信処理（以下ＩＯＭ通信処理という）を実行するための命令（コ
マンド）を演算する。命令演算部１３はプロセスデータＤ３５，Ｄ３７等を用いて制御演
算を実行する。命令や制御データＤ１４，Ｄ１６は、ＣＰＵバス１８を介してＩＯ通信機
能部１１やメモリ部１２等に転送される。
【００４６】
ＩＯ通信機能部１１には記憶部の一例を構成するメモリ部１２が接続され、ＩＯＭ状態
管理機能を実現するようになされる。ＩＯ通信機能部１１は命令演算部１３から発行され
るコマンドを受信して、メモリ部１２内に状態管理テーブル１２１を作成する。状態管理
テーブル１２１は、ＩＯＭ部１４，１５，１６，１７等の状態を管理するためであり、通
信の是非や、使用する通信バスα，βの判断のために参照される。メモリ部１２には随時
アクセス可能な不揮発性や、バックアップ付きの揮発性の記憶装置が使用される。
【００４７】
メモリ部１２はＩＯ通信機能部１１又は命令演算部１３によって制御され監視される通
信バスα，βの状態を正常、一時異常及び異常の３種類に区分してＩＯＭ部１４，１５，
１６，１７毎に記憶する。例えば、メモリ部１２内には状態管理テーブル１２１が作成さ
れる。状態管理テーブル１２１には、例えば、５個の識別子ＩＯＭ１〜ＩＯＭ５が割り当
てられ、通信バスα，βの状態に対応して一時異常フラグＦＧ２等が設定される（図３参
照）。
【００４８】
ＩＯ通信機能部１１は、少なくとも、２つの通信バスα，βを切り換える機能を有して
、当該通信バスα，βに接続され、通信バスα，βを監視し、当該通信バスα，βの一時
異常及び正常を判別する。一時異常とは、通信要求（ＩＯＭ通信）を実行して一定時間以
内に応答がなかった状態をいう（診断復旧確認処理）。
【００４９】
ＩＯ通信機能部１１は、ＩＯＭ入出力機能１１１及び診断復旧確認機能１１２を有して
いる。ＩＯ通信機能部１１は、ＩＯＭ入出力処理において、状態管理テーブル１２１で『
正常』となった通信バスα又はβから優先的に接続を切り換えて使用する機能を有してい
る。例えば、ＩＯ通信機能部１１は、メモリ部１２を参照し、正常な状態の通信バスα又
はβを優先してＩＯＭ部１４等に接続し、センサ３５からプロセスデータＤ３５を入力し
、及び、当該正常な状態の通信バスα又はβを介してバルブ３４へ制御データＤ１５等を
出力する（ＩＯＭ入出力処理）。
【００５０】
ＩＯＭ入出力機能１１１にはＩＯＭ入出力処理の他に正常な通信バスαに接続を切り換
えるバス選択切り換え機能が含まれる。例えば、ＩＯ通信機能部１１は、一方の通信バス
α又はβの状態が一時異常であると判別したとき、一時異常と判別された通信バスα又は
βから正常な状態の通信バスα→β（β→α）にＩＯＭ部１４等の接続を切り換えるよう
になされる。
【００５１】
このようなバス選択切り換え機能によって、一時異常フラグＦＧ２や異常フラグＦＧ３
等がメモリ部１２に記憶されている通信バスα及びβを介してのＩＯＭ部１４，１５，１
６，１７の接続を回避できるので、バルブ３４，３６，４４，４６へ確実に制御データＤ
１４，Ｄ１６，Ｄ２４，Ｄ２６を出力すること、及び、センサ３５，３７，４５，４７か
らのプロセスデータＤ３５，Ｄ３７，Ｄ４５，Ｄ４７を確実に取得することができる。
【００５２】
また、ＩＯ通信機能部１１は、ＩＯＭ入出力処理及び診断復旧確認処理（ＩＯＭ通信）
の成否から通信バスα，βの状態を『正常』／『一時異常』／『異常』のいずれかに設定
するＩＯＭ状態管理機能を有している。ＩＯ通信機能部１１は、『一時異常』となったＩ
ＯＭ部１４等に、一時異常フラグＦＧ２をセットする。つまり、ＩＯ通信機能部１１は、
何らかの通信異常を引き起こす原因（トランジェントエラーや、ＩＯＭ部自体の異常、通
信バスαやβ等の異常）により、ＩＯＭ通信処理を失敗した場合、ＩＯＭ状態管理機能に
より、状態管理テーブル１２１に一時異常フラグＦＧ２をセットする。
【００５３】
この例で、ＩＯ通信機能部１１は、通信バスα，βの一時異常を判別する毎に当該通信
バスα，βに対して一時異常フラグを立ち上げ、フラグ立ち上げ回数と基準回数とを比較
する。ここにフラグ立ち上げ回数とは一時異常フラグを立ち上げた回数をいう。基準回数
とは一時異常又は異常を判別するための設定データをいう。
【００５４】
ＩＯ通信機能部１１は、基準回数を越えるフラグ立ち上げ回数が検出されたとき、当該
通信バスの状態を異常と判別する。このような判別機能によって、例えば、基準回数＝１
を設定して、一時異常フラグＦＧ２が一回立ち上がると、当該通信バスα又はβの一時異
常フラグＦＧ２をメモリ部１２に記憶することができ、一時異常フラグＦＧ２が二回以上
立ち上がると、当該通信バスα又はβの異常フラグＦＧ３をメモリ部１２に記憶できるよ
うになる。
【００５５】
ＩＯ通信機能部１１は、一時異常又は異常と判別された通信バスα又はβから正常な状
態の通信バスα又はβに接続を切り換えた後の通信空き時間に、一時異常又は異常と判別
された通信バスα又はβを介して診断通信を含む診断復旧確認処理を実行する。ここに診
断復旧確認処理とは、プロセスデータＤ３５等の取得を目的とせずに、診断通信の成否の
みを確認する機能をいい、換言するとＩＯ通信機能部１１はＩＯＭ部１４，１５，１６，
１７を呼び出せるか否かの通信復旧を確認する動作をいう。
【００５６】
診断復旧確認処理は、『一時異常』となった通信バスαやβ等に対し行われる。その成
否に基づいて通信バスαやβ等の状態を『正常』または『異常』状態に遷移させるように
なる。例えば、診断復旧確認処理を行った結果、ＩＯＭ部１４や，１５，１６，１７等か
らＩＯ通信機能部１１に応答が有った場合、ＩＯ通信機能部１１は、一時異常又は異常と
判別された通信バスα又はβの状態を一時異常又は異常から正常へ書き換える。ＩＯＭ部
１４や，１５，１６，１７等からＩＯ通信機能部１１に応答が無かった場合、ＩＯ通信機
能部１１は、一時異常と判別された通信バスα又はβの状態を異常へ書き換え、通信バス
α又はβの状態が元々異常であった場合は、当該通信バスα又はβの異常をそのまま保持
するようになされる。
【００５７】
この例で、一時異常と判別された、通信バスαの状態を一時異常フラグＦＧ２から正常
フラグＦＧ１へ書き換える。同様にして、一時異常と判別された、通信バスβの状態を一
時異常フラグＦＧ２から正常フラグＦＧ１へ書き換える。このような診断復旧確認機能に
よって、ＩＯＭ部１４，１５，１６，１７からＩＯ通信機能部１１に応答がなかった場合
に、ＩＯＭ部１４，１５，１６，１７自体の異常や、通信バスα又はβ自体の異常等を早
期に発見できるようになる。
【００５８】
上述の説明では、ＣＰＵ１０内で、命令演算部１３の動作を補助するＩＯ通信機能部１
１（ＩＯコプロセッサ）が診断復旧確認処理を実行する場合について説明したが、これに
限られることはなく、命令演算部１３で診断復旧確認処理を実行させてもよい。
【００５９】
続いて、図３を参照して、状態管理テーブル１２１における各フラグの記述例について
説明する。図３に示す状態管理テーブル１２１には、例えば、３個の識別子ＩＯＭ１，Ｉ
ＯＭ２，ＩＯＭ３と共に、通信バスα，βの状態を記述するメモリ領域が割り当てられて
いる。
【００６０】
この例で、状態管理テーブル１２１には、ＩＯＭ部１４に対してＩＯＭ１の識別子と共
に、通信バスαの『正常』及び通信バスβの『異常』に対応して、正常フラグＦＧ１及び
異常フラグＦＧ３が設定（登録）される。ＩＯＭ部１５に対してはＩＯＭ２の識別子と共
に、通信バスαの『一時異常』及び通信バスβの『正常』に対応して、一時異常フラグＦ
Ｇ２及び正常フラグＦＧ１が設定（登録）される。
【００６１】
ＩＯＭ部１６に対してはＩＯＭ３の識別子と共に、通信バスαの『正常』及び通信バス
βの『正常』に対応して、各々正常フラグＦＧ１が設定（登録）される。このような状態
管理テーブル１２１をメモリ部１２を備えると、ＩＯ通信機能部１１は、正常フラグＦＧ
１、一時異常フラグＦＧ２及び異常ＦフラグＧ３に区分して記述された通信バスα，βの
状態を参照して、当該通信バスα，βに接続されるＩＯＭ部１４，１５，１６，１７をア
クセス管理できるようになる。
【００６２】
続いて、図４Ａ〜Ｃを参照して、ＩＯ通信機能部１１（ＩＯコプロセッサ）とＩＯＭ部
１４等との通信例について説明する。図４Ａに示すＩＯ通信機能部１１とＩＯＭ部１４等
との通信例によれば、黒△印は、ＩＯ通信機能部１１からＩＯＭ部１４への通信時刻ｔ１
，ｔ３，ｔ５，ｔ７，ｔ８，ｔ１０，ｔ１２，ｔ１４，ｔ１５，ｔ１７（例）である。白
△印は、ＩＯＭ部１４からＩＯ通信機能部１１への通信時刻ｔ２，ｔ４，ｔ６，ｔ９，ｔ
１１，ｔ１３，ｔ１６，ｔ１８（例）である。
【００６３】
図４Ｂに示す通信バスα（図中αバスと表示する）の状態例によれば、通信時刻ｔ１〜
ｔ７において正常であり、通信時刻ｔ８〜ｔ１５において、一時異常な状態であり、通信
時刻ｔ１５以降が異常な状態となっている。これに対して、図４Ｃに示す通信バスβ（図
中βバスと表示する）の状態例によれば、通信時刻ｔ１以降ずっと正常な状態となってい
る。
【００６４】
この例では、黒△印の通信時刻ｔ１で、まず、通信バスαを使用して、ＩＯ通信機能部
１１からＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の
通信時刻ｔ２でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力され
、ＩＯ通信が成功する（○印）。同様にしてスキャン周期Ｔ（Ｅｘ．ｔ３−ｔ１）毎に、
図４Ｂ，Ｃに示す通信バスα，βを切り換えて、黒△印の通信時刻ｔ３，ｔ５で、ＩＯ通
信機能部１１からＩＯＭ部１４へＩＯ通信が実行され、白△印の通信時刻ｔ４，ｔ６で、
ＩＯＭ部１４からＩＯ通信機能部１１へのＩＯ通信が成功している（αバス通信）。
【００６５】
しかし、黒△印の通信時刻ｔ７で、通信バスαを使用して、ＩＯ通信機能部１１からＩ
ＯＭ部１４へＩＯ通信が実行されても、ＩＯＭ部１５はＩＯ通信機能部１１に対して無応
答であり、ＩＯ通信が失敗している（×印）。このとき、ＩＯ通信機能部１１は一時異常
フラグＦＧ２を状態管理テーブル１２１に設定する。
【００６６】
その後、黒△印の通信時刻ｔ８で、通信バスβを使用して、ＩＯ通信機能部１１からＩ
ＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の通信時刻ｔ
９でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力され、ＩＯ通信
が成功する（○印）。同様にして通信バスβを使用して、黒△印の通信時刻ｔ１０，ｔ１
２で、ＩＯ通信機能部１１からＩＯＭ部１４へＩＯ通信が実行され、白△印の通信時刻ｔ
１１，ｔ１３で、ＩＯＭ部１４からＩＯ通信機能部１１へのＩＯ通信が成功している（β
バス通信）。
【００６７】
この例でＩＯ通信機能部１１は、状態管理テーブル１２１に一時異常フラグＦＧ２が設
定された通信バスαに対して、ＩＯＭ通信の空き時間（合間）となる、例えば、黒△印の
通信時刻ｔ１４でαバス診断通信を実行する。αバス診断通信では、一時異常と判別され
た通信バスαに対して、プロセスデータＤ３５等の取得を目的とせずに、ＩＯＭ通信の成
否のみを確認するようになされる（診断復旧確認処理）。
【００６８】
診断復旧確認処理はＩＯＭ入出力処理以外の処理時間で、かつ、スキャン周期とは異な
る長い周期で実行される。このため、スキャン周期でのＩＯＭ入出力処理を妨げることが
なく、局所的な通信負荷を軽減することができる。αバス診断通信の結果、ＩＯＭ部１５
からＩＯ通信機能部１１への応答が無く、ＩＯ通信が失敗したことが見出される（判別さ
れる）と、ＩＯ通信機能部１１は状態管理テーブル１２１における一時異常フラグＦＧ２
を異常フラグＦＧ３に書き換えるようになされる。
【００６９】
その後、黒△印の通信時刻ｔ１５で、通信バスβを使用して、ＩＯ通信機能部１１から
ＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の通信時刻
ｔ１６でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力され、ＩＯ
通信が成功している（○印）。同様にして通信バスβを使用して、黒△印の通信時刻ｔ１
７で、ＩＯ通信機能部１１からＩＯＭ部１４へＩＯ通信が実行され、白△印の通信時刻ｔ
１８で、ＩＯＭ部１４からＩＯ通信機能部１１へのＩＯ通信が成功している（βバス通信
）。
【００７０】
続いて、図５〜図７に示すフローチャートを参照して、本発明に係る通信管理方法につ
いて説明する。図５は、ＣＰＵ１０における通信管理例を示すメインルーチンである。図
６は、ＩＯ通信機能部１１におけるＩＯ通信例を示すサブルーチンである。図７は、ＩＯ
通信機能部１１における診断復旧確認例を示すサブルーチンである。
【００７１】
この実施例では、制御開始時の２つの通信バスα及びβの初期状態が共に正常である場
合を例に挙げる。通信バスα，βは交互に切り換えて使用する場合である。診断復旧確認
処理は、ＩＯＭ入出力処理以外の処理時間であって、スキャン周期とは異なった長い周期
で一時異常フラグＦＧ２が立った通信バスα（又はβ）を介してＩＯＭ部１４等との間で
診断通信を実行する場合を例に採る。
【００７２】
これらを管理条件にして、図５に示すフローチャートのステップＳＴ１でＩＯ通信機能
部１１は、状態管理テーブル１２１を参照して通信バスα及びβの状態を入力する。初期
状態で状態管理テーブル１２１には、２つの通信バスα及びβの状態が共に正常であるこ
とを示す正常フラグＦＧ１が記述されている。
【００７３】
次に、ステップＳＴ２で、ＩＯ通信機能部１１は、通信バスα，βの両方が異常である
場合（Ｘ）と、少なくとも、通信バスα又はβの一方が正常、及び、通信バスα，βの両
方が正常である場合（Ｙ）に対応して制御を分岐する。
【００７４】
通信バスα又はβの一方が正常、及び、通信バスα，βの両方が正常である場合（Ｙ）
は、ステップＳＴ３でＩＯ通信機能部１１は、通信バスα又はβへ接続を切り換える。例
えば、最初に通信バスαを使用する場合は、ステップＳＴ４で、ＩＯ通信機能部１１は、
通信バスαをＩＯＭ部１４，１５，１６，１７に接続してＩＯＭ通信処理を実行する（α
バス通信）。
【００７５】
この例のＩＯＭ通信処理によれば、図６のサブルーチンをコールしてそのステップＳＴ
４１でＩＯ通信機能部１１は、ＩＯＭ通信を実行する。例えば、図４に示したように、黒
△印の通信時刻ｔ１で、通信バスαを使用して、ＩＯ通信機能部１１からＩＯＭ部１４へ
制御データＤ１４を出力するＩＯ通信が実行されると、白△印の通信時刻ｔ２でＩＯＭ部
１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力される。
【００７６】
その後、ステップＳＴ４２でＩＯ通信機能部１１は、ＩＯＭ通信に成功したか否かを判
別する。この際の判別基準は、ＩＯ通信機能部１１からＩＯＭ部１４等へ通信要求を実行
してから所定の時間内に返信が有ったか否かで、通信バスαの状態が一時異常であるか否
かを判別する。
【００７７】
ＩＯＭ通信に成功しなかった場合は、ステップＳＴ４３に移行して、ＩＯ通信機能部１
１はＩＯＭ通信を実行する規定回数（例えば基準回数＝１）を設定して、ＩＯＭ通信に失
敗したか否かを判別する。例えば、一時異常フラグＦＧ２が一回立ち上がると、当該通信
バスαの一時異常フラグＦＧ２をメモリ部１２に記憶する。
【００７８】
ＩＯＭ部１４等の接続を規定回数だけ実行してＩＯＭ通信を失敗した場合は、ステップ
ＳＴ４４に移行して、ＩＯ通信機能部１１は状態管理テーブル１２１に現在使用中の通信
バスαを一時異常に設定する。その後、ステップＳＴ４にリターンする。なお、ステップ
ＳＴ４２でＩＯＭ通信に成功した場合及びステップＳＴ４４で状態管理テーブル１２１に
一時異常フラグＦＧ２を設定した後は、ステップＳＴ４にリターンする。
【００７９】
次に、ステップＳＴ５でＩＯ通信機能部１１は、バス切り換えコマンドをデコード（判
別）して制御を分岐する。例えば、両方の通信バスα及びβが正常で、状態管理テーブル
１２１には一時異常フラグＦＧ２や異常フラグが設定されていない場合であって、αバス
からβバスへ通信バスを切り換えるコマンドが発行されている場合は、ＩＯＭ部１４等の
接続を通信バスαから通信バスβに切り換えた後に、ステップＳＴ６でＩＯ通信機能部１
１は、βバス通信を実行する。
【００８０】
例えば、図４に示したように、黒△印の通信時刻ｔ３で、通信バスαを使用して、ＩＯ
通信機能部１１からＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると
、白△印の通信時刻ｔ４でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５
が出力される。
【００８１】
また、状態管理テーブル１２１に、既に、一時異常フラグＦＧ２が設定されていて、α
バスからβバスへ通信バスを切り換えるコマンドが発行されている場合は、ＩＯＭ部１４
等の接続を通信バスαから通信バスβに切り換える。このとき、ＩＯ通信機能部１１は、
一時異常と判別された通信バスαから正常な状態の通信バスβにＩＯＭ部１４，１５，１
６，１７の接続を切り換える。
【００８２】
その後、ステップＳＴ６でＩＯ通信機能部１１は、βバス通信を実行する。例えば、図
４に示したように、黒△印の通信時刻ｔ８で、通信バスβを使用して、ＩＯ通信機能部１
１からＩＯＭ部１４へ制御データＤ１４を出力するＩＯ通信が実行されると、白△印の通
信時刻ｔ９でＩＯＭ部１５からＩＯ通信機能部１１へプロセスデータＤ３５が出力される
。
【００８３】
αバスからβバスへ通信バスを切り換えるコマンドが発行されていない場合は、例えば
、片側の通信バスα又はβのみを使用してＩＯＭ通信を実行する場合は、ステップＳＴ８
に移行してＩＯ通信機能部１１が終了を判別する。この際の判別基準は、例えば、上位の
パソコン１０４からの終了データを検出し、終了データに基づいてＩＯＭ通信を終了有無
を判断する。
【００８４】
終了データが検出されない場合はステップＳＴ９に移行して診断要否を判別する。この
際の判別基準は、例えば、状態管理テーブル１２１を参照し、一時異常フラグＦＧ２が設
定されているか否かでＩＯ通信機能部１１が診断要否を判断する。この例で、一時異常フ
ラグＦＧ２が検出された場合は、ステップＳＴ１０に移行してＩＯ通信機能部１１は、診
断通信処理を実行する。
【００８５】
この例の診断通信処理によれば、図７のサブルーチンをコールしてそのステップＳＴ１
０１でＩＯ通信機能部１１は、診断通信を実行する。この診断通信の対象は、一時異常又
は異常となった通信バスα又はβであるので、正常の場合は、診断通信をパスする。例え
ば、図４に示したように、黒△印の通信時刻ｔ１４で、通信バスαを使用して、ＩＯ通信
機能部１１からＩＯＭ部１４を呼び出す診断通信が実行される。しかし、通信バスαに異
常が発生していると、ＩＯＭ部１４等からＩＯ通信機能部１１への応答は無い（無応答）
。
【００８６】
そして、ステップＳＴ１０２でＩＯ通信機能部１１は、診断通信が成功したか否かを判
別する。この際の判別基準は、ＩＯ通信機能部１１からＩＯＭ部１４等へ所定の時間内に
通信要求を規定回数だけ実行し、その応答が一回でも有ったか否かで、通信バスαの状態
が一時異常でなく異常又は正常であるか否かを判別する。
【００８７】
診断通信に成功した場合は、ステップＳＴ１０４に移行して、ＩＯ通信機能部１１は状
態管理テーブル１２１における一時異常フラグＦＧ２を正常フラグＦＧ１に書き換える（
設定する）ようにメモリ部１２を制御する。その後、ステップＳＴ１０にリターンする。
【００８８】
上述のステップＳＴ１０３で診断通信に成功しなかった場合は、ステップＳＴ１０５に
移行して、ＩＯ通信機能部１１は、診断通信を実行する規定回数（例えば基準回数＝５）
を設定して、規定回数を越える失敗回数を検出したか否かを判別する。規定回数を越える
失敗回数を検出していない場合は、ステップＳＴ１０２に戻って診断通信を繰り返す。
【００８９】
ステップＳＴ１０５で規定回数を越える失敗回数を検出した場合は、ステップＳＴ１０
６に移行してＩＯ通信機能部１１は、状態管理テーブル１２１における一時異常フラグＦ
Ｇ２を異常フラグＦＧ３に書き換える（設定する）ようにメモリ部１２を制御する。
【００９０】
この例で、ＩＯ通信機能部１１には、再度、ＩＯＭ通信を試みる機能が備えられており
、一時異常フラグＦＧ２がセットされた、例えば、通信バスαとは異なる他方の通信バス
βに切り替えて再度、ＩＯＭ通信を実行する（バス切り換えを伴うリトライ通信機能）。
このリトライ通信機能の結果、ＩＯＭ部自体の故障か、通信バスαのある一部分的な区間
が故障となっているかを判別できるようになる。
【００９１】
上述の診断通信処理後は、ステップＳＴ１０にリターンする。このような診断復旧確認
処理の成否によって、通信バスα又はβを『正常』または『異常』に遷移させることがで
き、先の例で示した一時異常の通信バスαを異常に設定できるようになる。このような診
断復旧確認処理が終了した場合は、ステップＳＴ８に戻る。上述のステップＳＴ１０で診
断通信処理が終了し、ステップＳＴ８で終了データが検出された場合はＩＯＭ通信処理を
終了する。
【００９２】
このように、実施形態としてのＦＣＳ部１０１によれば、ＩＯ通信機能部１１が、一方
の例えば通信バスαの状態が一時異常であると判別したとき、一時異常と判別された通信
バスαから正常な状態の通信バスβにＩＯＭ部１４，１５，１６，１７の接続を切り換え
るようになる。
【００９３】
従って、一時異常と判別された時点で、ＩＯＭ部１４，１５，１６，１７の接続が切り
換えられた正常な状態の通信バスβを介して当該ＩＯ通信機能部１１からＩＯＭ部１４を
介して制御データＤ１４をバルブ３４に出力したり、正常な状態の通信バスβを介してセ
ンサ３５からＩＯ通信機能部１１へプロセスデータＤ３５を出力したりすることができる
。
【００９４】
これにより、一時異常と判別された通信バスαへの通信可否の確認を行うバス切り換え
を伴わないリトライ通信処理を省略することができるので、従来方式のようなリトライ通
信処理を実行する場合に比べて、ＩＯ通信機能部１１がセンサ３５，３７からプロセスデ
ータＤ３５，Ｄ３７を取得する際の遅延時間を短縮することができる。
【００９５】
上述した例では、トランジェントエラー以外の通信異常の場合、直前に使用していた通
信バスαと同一の通信バスαを使用しても、再度、リトライ通信を失敗する可能性が高い
ので、『一時異常』なった通信バスαは使用せずに、即座に通信バスβを切り替えて通信
を行っている。このことで、特に片側のみの通信バスα又はβの異常のような通信異常状
態では、通信バスβからのＩＯＭ通信成功により、プロセスデータＤ３５，Ｄ３７を即座
に取得できるメリットがある。
【００９６】
なお、ＩＯＭ通信後のスキャン周期Ｔでは、一時異常フラグＦＧ２がセットされた通信
バスαは、ＩＯＭ入出力処理では、積極的に使用することを避け、正常な通信バスβを優
先的に使用し続けるようにした。ただし、両通信バスα，βが異常の場合は、一時異常で
も使用する。しかも、通信空き時間に、スキャン周期Ｔとは異なる長い周期により診断復
旧確認処理を実行することにより、局所的な通信負荷を軽減できるようになった。
【産業上の利用可能性】
【００９７】
この発明は、電気や、機械、化学工場等のプラントにおけるフィールド機器を分散制御
するフィールドコントロールステーション（ＦＣＳ部）や、ＦＣＳ部を有する分散型制御
システムや、ＦＣＳ部におけるＣＰＵとＩＯＭとの間の通信を管理するアクセス管理等に
適用して極めて好適である。
【符号の説明】
【００９８】
１ 分散型制御システム
１０ 制御側のＣＰＵ（制御部）
１１，２１ ＩＯ通信機能部
１２ メモリ部（記憶部）
１３ 命令演算部
１４，１５，１６，１７ ＩＯＭ部（データ入出力部）
１８ ＣＰＵバス
２０ 待機側のＣＰＵ（制御部）
２４，２５，２６，２７ ＩＯＭ部（データ入出力部）
１０１，１０２ フィールドコントロールステーション（ＦＣＳ部：制御装置）
１０３ 制御バス
１１１ ＩＯＭ入出力機能
１１２ 診断回復機能
α，β 通信バス
【特許請求の範囲】
【請求項１】
少なくとも、通信要求を実行して一定時間以内に応答がなかった場合を一時異常とした
とき、２つの通信路に接続され、当該通信路を切り換える機能を有して前記通信路を監視
し、当該通信路の一時異常及び正常を判別する制御部と、
前記通信路を介して前記制御部に接続され、被制御機器から入力した処理データを前記
通信路を介して前記制御部に出力すると共に、前記通信路を介して当該制御部から入力し
た制御データを前記被制御機器に出力する１つ以上のデータ入出力部とを備え、
前記制御部は、
一方の前記通信路の状態が一時異常であると判別したとき、
一時異常と判別された前記通信路から正常な状態の通信路に前記データ入出力部の接続
を切り換えることを特徴とする制御装置。
【請求項２】
前記制御部によって制御され、
前記通信路の状態を一時異常、異常及び正常に区分して前記データ入出力部毎に記憶す
る記憶部を備えることを特徴とする請求項１に記載の制御装置。
【請求項３】
前記制御部は、
前記記憶部を参照し、
前記正常な状態の通信路を優先して前記データ入出力部に接続し、被制御機器から処理
データを入力し、及び、当該正常な状態の通信路を介して被制御機器へ制御データを出力
することを特徴とする請求項２に記載の制御装置。
【請求項４】
前記制御部は、
一時異常又は異常と判別された前記通信路から正常な状態の通信路に接続を切り換えた
後の通信空き時間に、前記一時異常又は異常と判別された通信路を介して前記データ入出
力部を呼び出す診断通信を実行することを特徴とする請求項３に記載の制御装置。
【請求項５】
前記診断通信を行った結果、
前記データ入出力部から前記制御部に応答が有った場合は、
前記制御部は、
前記通信路の一時異常を判別する毎に当該通信路に対して一時異常フラグを立ち上げ、
前記一時異常フラグを立ち上げた回数をフラグ立ち上げ回数としたとき、前記フラグ立
ち上げ回数と、前記一時異常又は異常を判別するための基準回数とを比較し、
前記基準回数を越えるフラグ立ち上げ回数が検出されたとき、当該通信路の状態を異常
と判別し、
前記制御部が、
前記一時異常又は異常と判別された通信路の状態を一時異常又は異常から正常へ書き換
え、
前記データ入出力部から前記制御部に応答が無かった場合は、
前記制御部が、
前記一時異常と判別された通信路の状態を異常へ書き換え、
前記通信路の状態が元々異常であった場合は、当該通信路の異常をそのまま保持するこ
とを特徴とする請求項４に記載の制御装置。
【請求項６】
少なくとも、通信要求を実行して一定時間以内に応答がなかった場合を一時異常とした
とき、２つの通信路に接続され、当該通信路を切り換える機能を有して前記通信路を監視
し当該通信路の一時異常及び正常を判別する制御部と、
前記通信路を介して前記制御部に接続され、被制御機器から入力した処理データを前記
通信路を介して前記制御部に出力すると共に、前記通信路を介して当該制御部から入力し
た制御データを前記被制御機器に出力する１つ以上のデータ入出力部とを備えた制御装置
が、
前記通信路の状態が一時異常であるか否かを判別するステップと、
一方の前記通信路の状態が一時異常であると判別されたとき、一時異常と判別された前記
通信路から正常な状態の通信路に前記データ入出力部の接続を切り換えるステップを有す
ることを特徴とする通信管理方法。
【請求項１】
少なくとも、通信要求を実行して一定時間以内に応答がなかった場合を一時異常とした
とき、２つの通信路に接続され、当該通信路を切り換える機能を有して前記通信路を監視
し、当該通信路の一時異常及び正常を判別する制御部と、
前記通信路を介して前記制御部に接続され、被制御機器から入力した処理データを前記
通信路を介して前記制御部に出力すると共に、前記通信路を介して当該制御部から入力し
た制御データを前記被制御機器に出力する１つ以上のデータ入出力部とを備え、
前記制御部は、
一方の前記通信路の状態が一時異常であると判別したとき、
一時異常と判別された前記通信路から正常な状態の通信路に前記データ入出力部の接続
を切り換えることを特徴とする制御装置。
【請求項２】
前記制御部によって制御され、
前記通信路の状態を一時異常、異常及び正常に区分して前記データ入出力部毎に記憶す
る記憶部を備えることを特徴とする請求項１に記載の制御装置。
【請求項３】
前記制御部は、
前記記憶部を参照し、
前記正常な状態の通信路を優先して前記データ入出力部に接続し、被制御機器から処理
データを入力し、及び、当該正常な状態の通信路を介して被制御機器へ制御データを出力
することを特徴とする請求項２に記載の制御装置。
【請求項４】
前記制御部は、
一時異常又は異常と判別された前記通信路から正常な状態の通信路に接続を切り換えた
後の通信空き時間に、前記一時異常又は異常と判別された通信路を介して前記データ入出
力部を呼び出す診断通信を実行することを特徴とする請求項３に記載の制御装置。
【請求項５】
前記診断通信を行った結果、
前記データ入出力部から前記制御部に応答が有った場合は、
前記制御部は、
前記通信路の一時異常を判別する毎に当該通信路に対して一時異常フラグを立ち上げ、
前記一時異常フラグを立ち上げた回数をフラグ立ち上げ回数としたとき、前記フラグ立
ち上げ回数と、前記一時異常又は異常を判別するための基準回数とを比較し、
前記基準回数を越えるフラグ立ち上げ回数が検出されたとき、当該通信路の状態を異常
と判別し、
前記制御部が、
前記一時異常又は異常と判別された通信路の状態を一時異常又は異常から正常へ書き換
え、
前記データ入出力部から前記制御部に応答が無かった場合は、
前記制御部が、
前記一時異常と判別された通信路の状態を異常へ書き換え、
前記通信路の状態が元々異常であった場合は、当該通信路の異常をそのまま保持するこ
とを特徴とする請求項４に記載の制御装置。
【請求項６】
少なくとも、通信要求を実行して一定時間以内に応答がなかった場合を一時異常とした
とき、２つの通信路に接続され、当該通信路を切り換える機能を有して前記通信路を監視
し当該通信路の一時異常及び正常を判別する制御部と、
前記通信路を介して前記制御部に接続され、被制御機器から入力した処理データを前記
通信路を介して前記制御部に出力すると共に、前記通信路を介して当該制御部から入力し
た制御データを前記被制御機器に出力する１つ以上のデータ入出力部とを備えた制御装置
が、
前記通信路の状態が一時異常であるか否かを判別するステップと、
一方の前記通信路の状態が一時異常であると判別されたとき、一時異常と判別された前記
通信路から正常な状態の通信路に前記データ入出力部の接続を切り換えるステップを有す
ることを特徴とする通信管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１０−２４４１５８（Ｐ２０１０−２４４１５８Ａ）
【公開日】平成２２年１０月２８日（２０１０．１０．２８）
【国際特許分類】
【出願番号】特願２００９−８９７８２（Ｐ２００９−８９７８２）
【出願日】平成２１年４月２日（２００９．４．２）
【出願人】（０００００６５０７）横河電機株式会社 (4,443)
【Ｆターム（参考）】
【公開日】平成２２年１０月２８日（２０１０．１０．２８）
【国際特許分類】
【出願日】平成２１年４月２日（２００９．４．２）
【出願人】（０００００６５０７）横河電機株式会社 (4,443)
【Ｆターム（参考）】
[ Back to top ]