(57)【要約】【課題】メモリなどの使用を抑え、また処理能力を小さくし、低コストの汎用の通信制御コントローラを提供する。【解決手段】通信制御コントローラ３に、上位送受信部３４と、下位送受信部３５と、通信共通部３３とを設ける。上位送受信部３４は、通信共通部３３への通信プロトコル固有のメッセージを送受信する個別通信機能部（メッセージ送受信部）３１を通信プロトコル毎に備える。下位送受信部３５は、通信共通部３３からの下位デバイスへの通信プロトコル固有のメッセージおよび下位デバイスからの通信共通部３３への通信プロトコル固有のメッセージを送受信する個別通信機能部（メッセージ送受信ドライバ部）３２を通信プロトコル毎に備える。通信共通部３３は、通信プロトコルによらない共通の構成として設けられ、上位送受信部３４と下位送受信部３５との間のメッセージの送受信を仲介する。【選択図】  図１
2019135580.tif 000002
【特許請求の範囲】
【請求項１】
上位装置と下位装置との間の通信の制御を行う通信制御コントローラにおいて、
前記上位装置との間で通信を行うように構成された上位送受信部と、
前記下位装置との間で通信を行うように構成された下位送受信部と、
前記上位送受信部と前記下位送受信部との間のメッセージの送受信を仲介するように構成された通信共通部とを備え、
前記上位送受信部は、
前記通信共通部への通信プロトコル固有のメッセージおよび前記通信共通部からの通信プロトコル固有のメッセージを送受信するように構成されたメッセージ送受信部を通信プロトコル毎に備え、
前記下位送受信部は、
前記通信共通部からの前記下位装置への通信プロトコル固有のメッセージおよび前記下位装置からの前記通信共通部への通信プロトコル固有のメッセージを送受信するように構成されたメッセージ送受信ドライバ部を通信プロトコル毎に備え、
前記通信共通部は、
前記通信プロトコルによらない共通の構成として設けられ、少なくとも、前記上位送受信部からの通信プロトコル固有のメッセージと関連づけて送られてくる前記通信プロトコルに依存しない共通のデータ構造とされた管理データを共通通信管理データとして記憶する共通通信管理データ記憶部を備える
ことを特徴とする通信制御コントローラ。
【請求項２】
請求項１に記載された通信制御コントローラにおいて、
前記通信共通部は、
前記下位装置へ送信中の通信プロトコル固有のメッセージに対応する前記共通通信管理データを記憶する送信中データ記憶部と、
前記下位装置へ送信中の通信プロトコル固有のメッセージに対するレスポンスが所定の時間内に返送されてきたか否かを監視するように構成されたタイムアウト監視部と
を備えることを特徴とする通信制御コントローラ。
【請求項３】
請求項１又は２に記載された通信制御コントローラにおいて、
前記共通通信管理データ記憶部に前記共通通信管理データをそのデータに付されている通信処理の優先度別に記憶させるように構成された優先度判断部
を備えることを特徴とする通信制御コントローラ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、上位装置と下位装置との間の通信の制御を行う通信制御コントローラに関する。
【背景技術】
【０００２】
一般に、ビルシステムやプロセス制御システムなどの自動制御システムでは、上位の統合コントローラ１台によって多数の下位デバイス（センサやアクチュエータなど）を制御することが求められる。この際、統合コントローラ（上位装置）と下位デバイス（下位装置）との間には、統合コントローラと下位デバイスとの間の通信の制御を行う通信制御コントローラが設けられる。
【０００３】
ここで、各下位デバイスが全て同一の通信プロトコルを用いているのであれば良いが、例えばＡ社製品とＢ社製品とが混在するような通信システムにおいては、各々のデバイスが使用する通信プロトコルが異なる場合がある。
【０００４】
例えば、ビルシステムのいては、同一システム内に、「BACnet」や「LonWorks」、「Modbus」などのオープンプロトコルに加えて、各社ローカルな専用通信プロトコルで通信する制御機器群が混在する。
【０００５】
このように、同一システム内に複数の通信プロトコルが混在する場合、通信プロトコルによってデータ体系が異なるために、複数の通信プロトコルによって送受信されるデータを同じ制御アプリケーションから利用することができない点が大きな問題となる。
【０００６】
このため、従来の通信システムでは、単一の通信プロトコルを使用する制御機器群で構成された「個別制御」の階層と、複数のそれらを統合し、プロトコル間のデータ体系の相違を吸収する「統合監視・制御」を行う階層にシステムを大きく分割することで、この問題を解決している。
【０００７】
例えば、図１１に示すように、Ａ社製品とＢ社製品とが混在するような通信システムの場合、統合コントローラ１と通信プロトコルＡを用いる下位デバイス２（２Ａ１〜２Ａ３）との間に通信プロトコルＡに応じた通信制御コントローラ３Ａを設け、統合コントローラ１と通信プロトコルＢを用いる下位デバイス２（２Ｂ１〜２Ｂ３）との間に通信プロトコルＢに応じた通信制御コントローラ３Ｂを設けるようにしている（例えば、特許文献１参照）。
【０００８】
このような通信システムにおけるデータ通信には、どのようなプロトコルでも、大きく以下の３要素が存在する。
(１)データの読み出し
その通信プロトコルで定められたメッセージおよびデータ体系に沿って周期的なデータスキャンを行い、コントローラ内で使用されるデータの形に変換して取り込む  。
(２)データの書き込み
周期または特定のイベント（ユーザー操作やタイムスケジュール等のアプリケーション）により、コントローラ内部の最新データを、その通信プロトコルで定められたメッセージ体系に変換して書き込み出力を行う。
(３)通信トランザクションの実行管理
(１)，(２)の通信の実行（リクエストの送信〜レスポンスの受信）を管理する。具体的には、リクエストとレスポンスの紐付けや、受信タイムアウトの監視、リトライ送信の実行などを行う。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開平５−６７００８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、このような通信システムでは、通信プロトコルのみが異なる同種の通信制御コントローラが必要になり、開発投資の大きな増大要因となる。また、製造コスト面でも、多品種少量生産によるコストアップ原因となる。
【００１１】
また、マルチ通信に対応していないため、異なる通信機器を接続しようとすると、通信を変換するためのゲートウェイが必要となってしまい、システムのコストアップとなる。
【００１２】
例えば、図１２に示すように、通信プロトコルＡの通信制御コントローラ３Ａに通信プロトコルＢを用いた下位デバイス２（２Ｂ４）を接続する必要が生じたような場合、通信プロトコルＢと通信プロトコルＡを変換するためのゲートウェイとして通信変換器２（２Ａ４）が必要となってしまい、システムのコストアップが発生する。
【００１３】
このような問題を解決するためには、複数の通信プロトコルに対応可能な、汎用の通信制御コントローラを作ることが考えられる。図１３に、通信制御コントローラ３Ａの要部の構成を示し、図１４に通信制御コントローラ３Ｂの要部の構成を示す。通信制御コントローラ３Ａ，３Ｂともに、対応する通信プロトコルが異なるのみで、基本構成は同じである。この通信制御コントローラ３Ａ，３Ｂの構成については後述する。
【００１４】
図１５に、図１３，図１４に示した通信制御コントローラ３Ａ，３Ｂの基本構成から考えられる、複数の通信プロトコルに対応可能な、汎用の通信制御コントローラ３’の構成を示す。この汎用の通信制御コントローラ３’では、通信制御コントローラ３Ａ，３Ｂにおける制御アプリケーション３０１Ａ，３０１Ｂを共通の制御アプリケーション３０１とし、通信制御コントローラ３Ａ，３Ｂにおけるデータベース３０２Ａ，３０２Ｂを共通のデータベース３０２とし、その他の構成はプロトコル固有の通信機能部（個別通信機能部）として設けるようにしている。
【００１５】
しかし、このような構成とすると、ソフトウェアにおける通信機能の比率が大きくなり、大きなメモリと大きな処理能力（ＣＰＵ能力）が必要となる。すなわち、上述した(１)データの読み出し、(２)データの書き込み、(３)通信トランザクションの実行管理の各機能を通信プロトコル毎に作成する必要があるため、大きな開発コストが必要となる他、ソフトウェアにおける通信機能の比率が大きくなり、大きなメモリとＣＰＵ能力が必要になり、高コストとなってしまう。
【００１６】
本発明は、このような課題を解決するためになされたもので、その目的とするところは、複数の通信プロトコルを実装するにあたり、共通化できる要素をさらに共通化することで、メモリなどの使用を抑え、また処理能力を小さくし、低コストの汎用の通信制御コントローラを提供することにある。
【課題を解決するための手段】
【００１７】
このような目的を達成するために本発明は、上位装置（１）と下位装置（２）との間の通信の制御を行う通信制御コントローラ（３）において、上位装置との間で通信を行うように構成された上位送受信部（３４）と、下位装置との間で通信を行うように構成された下位送受信部（３５）と、上位送受信部と下位送受信部との間のメッセージの送受信を仲介するように構成された通信共通部（３３）とを備え、上位送受信部（３４）は、通信共通部（３３）への通信プロトコル固有のメッセージおよび通信共通部（３３）からの通信プロトコル固有のメッセージを送受信するように構成されたメッセージ送受信部（３１）を通信プロトコル毎に備え、下位送受信部（３５）は、通信共通部（３３）からの下位装置（２）への通信プロトコル固有のメッセージおよび下位装置（２）からの通信共通部（３３）への通信プロトコル固有のメッセージを送受信するように構成されたメッセージ送受信ドライバ部（３２）を通信プロトコル毎に備え、通信共通部（３３）は、通信プロトコルによらない共通の構成として設けられ、少なくとも、上位送受信部（３４）からの通信プロトコル固有のメッセージと関連づけて送られてくる通信プロトコルに依存しない共通のデータ構造とされた管理データを共通通信管理データとして記憶する共通通信管理データ記憶部（３１３1）を備えることを特徴とする。
【００１８】
本発明において、通信制御コントローラは、通信プロトコルによらない共通の構成として通信共通部を備えており、この通信共通部の共通通信管理データ記憶部に通信プロトコルに依存しない共通のデータ構造とされた管理データが共通通信管理データとして記憶される。本発明では、このような通信共通部を設けることにより、複数の通信プロトコルに共通する３要素（（１）データ読み出し、（２）データの書き込み、（３）通信トランザクション）を実現する機能を、通信プロトコル個別ではなく、特定の通信プロトコルに依存しない通信プロトコル共通の機能として設け、通信プロトコルに依存する差分の機能だけを通信プロトコル固有の機能として設けるための仕組みを提供することが可能となり、少ないメモリおよび小さい処理能力で、複数の通信プロトコルを実装することが可能となる。
【００１９】
本発明において、通信共通部に、下位装置へ送信中の通信プロトコル固有のメッセージに対応する共通通信管理データを記憶する送信中データ記憶部（３１４1）と、下位装置へ送信中の通信プロトコル固有のメッセージに対するレスポンスが所定の時間内に返送されてきたか否かを監視するように構成されたタイムアウト監視部（３１６）とを設けるようにしてもよい。
【００２０】
また、本発明において、優先度判断部（３１２2）を設け、共通通信管理データ記憶部に共通通信管理データをそのデータに付されている通信処理の優先度別に記憶させるようにしてもよい。ビルシステムなどは、リアルタイム性が低くてもよいため、冗長化して、優先度処理しても問題が起きにくい。
【００２１】
なお、上記説明では、一例として、発明の構成要素に対応する図面上の構成要素を、括弧を付した参照符号によって示している。
【発明の効果】
【００２２】
以上説明したように、本発明によれば、上位送受信部と下位送受信部との間に通信プロトコルによらない共通の構成として通信共通部を設け、この通信共通部に、少なくとも、通信プロトコルに依存しない共通のデータ構造とされた管理データを共通通信管理データとして記憶する共通通信管理データ記憶部を設けるようにしたので、少ないメモリおよび小さい処理能力で、複数の通信プロトコルを実装することができるようになり、汎用の通信制御コントローラの低コスト化を図ることが可能となる。
【図面の簡単な説明】
【００２３】
【図１】図１は、本発明の実施の形態に係る通信制御コントローラの要部を示す図である。
【図２】図２は、この通信制御コントローラで用いられる共通通信管理データのデータ構造を例示する図である。
【図３】図３は、この通信制御コントローラで用いられる送信バッファの構造を例示する図である。
【図４】図４は、この通信制御コントローラにおけるタイムアウト検出＆リトライ送信可能な場合の通信共通部における共通通信管理データの流れを示す図である。
【図５】図５は、この通信制御コントローラにおけるタイムアウト検出＆リトライ送信不能な場合の通信共通部における共通通信管理データの流れを示す図である。
【図６】図６は、この通信制御コントローラにおける共通通信管理データ、リクエストメッセージおよびレスポンスメッセージの流れを示す図である。
【図７】図７は、この通信制御コントローラにおける上位送受信部内のさらに詳細な構成を示す図である。
【図８】図８は、この通信制御コントローラにおける上位送受信部内の構成を共通化した例を示す図である
【図９】図９は、個々の共通通信定義データをフラットに定義した例を示す図である。
【図１０】図１０は、共通通信定義データおよび固有通信定義データのデータ構造を例示する図である。
【図１１】図１１は、統合コントローラと下位デバイスとの間に通信プロトコル毎に固有の通信制御コントローラを設けた通信システムを例示する図である。
【図１２】図１２は、図１１において通信プロトコルＡの通信制御コントローラに通信プロトコルＢを用いた下位デバイスを接続する必要が生じた場合の構成例を示す図である。
【図１３】図１３は、通信プロトコルＡの通信制御コントローラの要部の構成を示す図である。
【図１４】図１４は、通信プロトコルＢの通信制御コントローラの要部の構成を示す図である。
【図１５】図１５は、図１３，図１４に示した通信制御コントローラの基本構成から考えられる汎用の通信制御コントローラの構成を示す図である。
【図１６】図１６は、図１３，図１４に示した通信制御コントローラで用いられる送信バッファの構造を例示する図である。
【発明を実施するための形態】
【００２４】
〔発明の経緯〕
本発明の実施の形態の説明に入る前に、先ず、図１３，図１４に示した従来の通信制御コントローラ３Ａ，３Ｂの基本構成について、通信制御コントローラ３Ａを例にとって説明する。通信制御コントローラ３Ａ，３Ｂともに、対応する通信プロトコルが異なるのみで、その基本構成は同じである。
【００２５】
通信制御コントローラ３Ａは、制御アプリケーション３０１Ａと、データベース３０２Ａと、プロトコル固有のリクエストメッセージ送信部３０３Ａと、プロトコル固有のリクエスト送信バッファ管理部３０４Ａと、プロトコル固有の送信ドライバ部３０５Ａと、プロトコル固有のタイムアウト監視部３０６Ａと、プロトコル固有の受信ドライバ部３０７Ａと、プロトコル固有のレスポンス受信バッファ管理部３０８Ａと、プロトコル固有のレスポンスメッセージ受信部３０９Ａとを備えている。なお、この構成において、プロトコル固有の送信ドライバ部３０５Ａと、プロトコル固有のタイムアウト監視部３０６Ａと、プロトコル固有の受信ドライバ部３０７Ａとは、通信ドライバ３１０Ａを構成している。
【００２６】
この通信制御コントローラ３Ａにおいて、プロトコル固有のリクエストメッセージ送信部３０３Ａは、下位デバイスからのデータの読み出しまたは下位デバイスへのデータの書き込みの通信処理を実行する契機を、何らかの規則（周期的な送信や、ユーザーからの手動操作を契機とするなど）によって決定し、その通信プロトコル毎の定めに従ってリクエストメッセージ（データの読み出しまたは書き込みメッセージ）を生成して、プロトコル固有のリクエスト送信バッファ管理部３０４Ａに送る。送信するリクエストメッセージがデータの書き込みメッセージである場合、データベース３０２Ａ内のデータ体系で管理されている書き込みデータを、その通信プロトコルで定められているデータ体系に変換して書き込みメッセージを生成する。
【００２７】
プロトコル固有のリクエスト送信バッファ管理部３０４Ａは、リクエスト送信要求の発生タイミングと、プロトコル固有の送信ドライバ部３０５Ａによって実行される実際の送信処理との速度差を吸収するために一般的に設けられる。プロトコル固有のリクエスト送信バッファ管理部３０４Ａは、プロトコル固有のリクエストメッセージ送信部３０３Ａから送られてきたリクエストメッセージ（プロトコル固有のリクエストメッセージ）を送信バッファ３０４Ａ1にバッファリングし、プロトコル固有の送信ドライバ部３０５Ａが送信可能な状態になった場合、送信バッファ３０４Ａ1にバッファリングされているリクエストメッセージをプロトコル固有の送信ドライバ部３０５Ａに送る。
【００２８】
一般的に、送信バッファ３０４Ａ1の構造としては、図１６に示すようなＦＩＦＯ構造のキューが用いられる。このＦＩＦＯ構造のキューでは、リクエストメッセージのキューイングがされると、最先にキューイングされたリクエストメッセージが取り出される。
【００２９】
プロトコル固有の送信ドライバ部３０５Ａは、その通信プロトコルでの定めに従い、プロトコル固有のリクエスト送信バッファ管理部３０４Ａから渡されるリクエストメッセージを、下位デバイスへの通信幹線上に伝送する。
【００３０】
プロトコル固有のタイムアウト監視部３０６Ａは、送信したリクエストメッセージに対するレスポンスメッセージを受信するまでのタイムアウト監視を行い、タイムアウトを検出した場合には、規定されたリトライ回数に達するまでリトライ送信を行う。
【００３１】
プロトコル固有の受信ドライバ部３０７Ａは、その通信プロトコルでの定めに従って下位デバイスからのレスポンスメッセージ（プロトコル固有のレスポンスメッセージ）を受信したら、リクエストに対するレスポンスであるかどうかをチェックし、正常なレスポンスだと認められる場合には、受信したレスポンスメッセージをプロトコル固有のレスポンス受信バッファ管理部３０８Ａに送る。
【００３２】
プロトコル固有のレスポンス受信バッファ管理部３０８Ａは、受信したレスポンスメッセージを受信バッファ３０８Ａ1にバッファリングする。プロトコル固有のレスポンス受信バッファ管理部３０８Ａでも、プロトコル固有のリクエスト送信バッファ管理部３０４Ａにおける送信バッファ３０４Ａ1と同じような構造の受信バッファ３０８Ａ1が用いられる。プロトコル固有のレスポンス受信バッファ管理部３０８Ａにバッファリングされたレスポンスメッセージはプロトコル固有のレスポンスメッセージ受信部３０９Ａに送られる。
【００３３】
プロトコル固有のレスポンスメッセージ受信部３０９Ａは、その通信プロトコルが定めた手続きに従って、受信したレスポンスメッセージを処理する。受信レスポンスメッセージがデータ読み出しに対する応答である場合、その通信プロトコル固有のデータ体系で応答された読み出しデータを、データベース３０２Ａ内で管理されるデータ体系に変換して、データの更新を行う。
【００３４】
通信制御コントローラ３Ｂ（図１４）も通信制御コントローラ３Ａと同様の構成とされており、制御アプリケーション３０１Ｂと、データベース３０２Ｂと、プロトコル固有のリクエストメッセージ送信部３０３Ｂと、プロトコル固有のリクエスト送信バッファ管理部３０４Ｂと、プロトコル固有の送信ドライバ部３０５Ｂと、プロトコル固有のタイムアウト監視部３０６Ｂと、プロトコル固有の受信ドライバ部３０７Ｂと、プロトコル固有のレスポンス受信バッファ管理部３０８Ｂと、プロトコル固有のレスポンスメッセージ受信部３０９Ｂとを備えている。
【００３５】
この通信制御コントローラ３Ａ，３Ｂの基本構成から考えられる汎用の通信制御コントローラ３’（図１５）では、通信制御コントローラ３Ａ，３Ｂにおける制御アプリケーション３０１Ａ，３０１Ｂを共通の制御アプリケーション３０１とし、通信制御コントローラ３Ａ，３Ｂにおけるデータベース３０２Ａ，３０２Ｂを共通のデータベース３０２とし、その他の構成はプロトコル固有の通信機能部（個別通信機能部）として設けるようにしている。
【００３６】
すなわち、プロトコル固有のリクエストメッセージ送信部３０３Ａと、プロトコル固有のリクエスト送信バッファ管理部３０４Ａと、プロトコル固有の送信ドライバ部３０５Ａと、プロトコル固有のタイムアウト監視部３０６Ａと、プロトコル固有の受信ドライバ部３０７Ａと、プロトコル固有のレスポンス受信バッファ管理部３０８Ａと、プロトコル固有のレスポンスメッセージ受信部３０９Ａとを通信プロトコルＡの個別通信機能部３０（３０Ａ）として設け、プロトコル固有のリクエストメッセージ送信部３０３Ｂと、プロトコル固有のリクエスト送信バッファ管理部３０４Ｂと、プロトコル固有の送信ドライバ部３０５Ｂと、プロトコル固有のタイムアウト監視部３０６Ｂと、プロトコル固有の受信ドライバ部３０７Ｂと、プロトコル固有のレスポンス受信バッファ管理部３０８Ｂと、プロトコル固有のレスポンスメッセージ受信部３０９Ｂとを通信プロトコルＢの個別通信機能部３０（３０Ｂ）として設けている。
【００３７】
本出願人は、この通信制御コントローラ３’において、さらに共通化することが可能な構成として、プロトコル固有のリクエスト送信バッファ管理部３０４Ａ，３０４Ｂと、プロトコル固有のタイムアウト監視部３０６Ａ，３０６Ｂと、プロトコル固有のレスポンス受信バッファ管理部３０８Ａ，３０８Ｂに着目した。図１５では、共通化することが可能な構成を太い線で囲んで示している。以下では、この通信制御コントローラ３’の構成を従来の構成として説明する。
【００３８】
本発明は、この共通化することが可能な構成に着目し、共通化できる要素をさらに共通化することで、メモリなどの使用を抑え、また処理能力を小さくし、低コストの汎用の通信制御コントローラを提供しようとするものである。
【００３９】
〔実施の形態１：基本構成〕
図１に本発明の実施の形態に係る通信制御コントローラ３の要部を示す。この通信制御コントローラ３は、プロセッサや記憶装置からなるハードウェアと、これらのハードウェアと協働して各種機能を実現させるプログラムとによって実現され、通信プロトコルＡ固有の通信機能部（個別通信機能部）３１Ａ，３２Ａと、通信プロトコルＢ固有の通信機能部（個別通信機能部）３１Ｂ，３２Ｂと、通信プロトコルＡ，Ｂに依存しない共通の通信機能部（通信共通部）３３とを備えている。
【００４０】
個別通信機能部３１Ａは、通信プロトコルＡ固有の要素として設けられた、プロトコル固有のリクエストメッセージ送信部３０３Ａとプロトコル固有のレスポンスメッセージ受信部３０９Ａとから構成され、個別通信機能部３１Ｂは、通信プロトコルＢ固有の要素として設けられた、プロトコル固有のリクエストメッセージ送信部３０３Ｂとプロトコル固有のレスポンスメッセージ受信部３０９Ｂとから構成されている。この個別通信機能部３１Ａ，３１Ｂが本発明でいうメッセージ送受信部に相当する。また、この個別通信機能部３１Ａ，３１Ｂによって、上位送受信部３４が構成されている。この上位送受信部３４が本発明でいう上位送受信部に相当する。上位送受信部３４は、その基本機能として、統合コントローラ（１）との間で通信を行う機能を備えている。
【００４１】
個別通信機能部３２Ａは、通信プロトコルＡ固有の要素として設けられた、プロトコル固有の送信ドライバ部３０５Ａとプロトコル固有の受信ドライバ部３０７Ａとから構成され、個別通信機能部３２Ｂは、通信プロトコルＢ固有の要素として設けられた、プロトコル固有の送信ドライバ部３０５Ｂとプロトコル固有の受信ドライバ部３０７Ｂとから構成されている。この個別通信機能部３２Ａ，３２Ｂが本発明でいうメッセージ送受信ドライバ部に相当する。また、この個別通信機能部３２Ａ，３２Ｂによって、下位送受信部３５が構成されている。この下位送受信部３５が本発明でいう下位送受信部に相当する。下位送受信部３５は、下位デバイス（２）との間で通信を行う機能を備えている。
【００４２】
通信共通部３３は、通信プロトコルＡ，Ｂに依存しない共通要素として設けられ、共通リクエスト送信バッファ管理部３１３と、共通送信中バッファ管理部３１４と、共通レスポンス受信バッファ管理部３１５と、共通タイムアウト監視部３１６と、レスポンス関連付け部３１７とから構成されている。この通信共通部３３が本発明でいう通信共通部に相当する。通信共通部３３は、上位送受信部３４と下位送受信部３５との間のメッセージの送受信を仲介する機能を備えている。
【００４３】
この通信制御コントローラ３において、プロトコル固有のリクエストメッセージ送信部３０３（３０３Ａ，３０３Ｂ）は、通信処理の実行タイミングで、その通信プロトコルが定める手続きに従ってリクエストメッセージを生成し、共通リクエスト送信バッファ管理部３１３に送る。この手段については、基本的に従来の構成と変わりはないが、リクエストメッセージの送り先が、特定の通信プロトコルに依存しない共通のバッファ（送信バッファ３１３1）である点が異なる。
【００４４】
そのために、図１５に示した従来の構成では、送信バッファ３０４Ａ1，３０４Ｂ1に受け渡すデータ構造は、その通信プロトコルにおけるリクエストメッセージそのもの、あるいはその通信プロトコルに依存した論理構成で定義されたデータの集合であったが、本実施の形態において、送信バッファ３１３1に受け渡すデータ構造は、少なくとも以下の情報を含む、特定の通信プロトコルに依存しない共通のデータ構造とされた管理データ（以降、共通通信管理データと呼ぶ）とする。
【００４５】
〔共通通信管理データに含まれる情報〕
・通信プロトコル識別情報（通信プロトコルＩＤ）
この通信処理が行われる通信プロトコルを識別可能な、番号または何らかの識別子情報。
・トランザクション識別情報（トランザクションＩＤ）
この通信処理を、同一の通信プロトコルＩＤの中で一意に識別可能な、番号または何らかの識別子情報。
・リクエストメッセージまたはそのアドレス情報
・レスポンスメッセージまたはそのアドレス情報
図２に例示するように、共通通信管理データとの関連付けとして、データ構造内にそのまま含めても良いし（図２（ａ）：データ構造例（１））、別途バッファを管理し、共通通信管理データ内にはそのアドレス情報のみを含むようにしても良い（図２（ｂ）：データ構造例（２））。
データ構造例（１）の場合、通信プロトコル毎にメッセージ最大サイズが異なるため、そのうちの最大のものに合わせる必要があり、メモリ効率は悪くなるが管理のためのソフトウェア構造が単純なもので済む利点がある。データ構造例（２）の場合、メモリ効率を高くすることができるが、より複雑なソフトウェア構造を必要とする。本実施の形態では、データ構造例（２）を採用するものとする。
・リクエストメッセージのサイズ
・レスポンスメッセージのサイズ
特定の通信プロトコルに依存しないようにするため、リクエストメッセージおよびレスポンスメッセージは単なるバイナリデータ列として扱う必要があり、そのため、リクエストメッセージおよびレスポンスメッセージのサイズ情報がそれぞれ必要となる。
・通信結果（レスポンス受信成功またはエラー終了）
【００４６】
共通リクエスト送信バッファ管理部３１３は、プロトコル固有のリクエストメッセージ送信部３０３（３０３Ａ，３０３Ｂ）から送られてくる共通通信管理データを通信プロトコル共通で設けられた送信バッファ３１３1にバッファリングする。送信バッファ３１３1の設置目的および基本的な構造は既知の構成と同等であるが、バッファリングするデータの構造を特定の通信に依存しない構造（共通通信管理データ）とすることで、各通信共通の送信バッファとして利用することができるようになる。
【００４７】
また、送信バッファ３１３1の構造を、単純な単一のＦＩＦＯ構造ではなく、例えば図３に示すように、優先度毎に定義したＦＩＦＯを並列配置することで、通信優先度管理を行うことができる。共通リクエスト送信バッファ管理部３１３は、優先度判断部３１３2を備え、プロトコル固有のリクエストメッセージ送信部３０３（３０３Ａ，３０３Ｂ）から送られてくる共通通信管理データをそのデータに付されている通信処理の優先度別に、並列配置されたＦＩＦＯに送り込む。
【００４８】
この構造自体は特に新規なものではなく、従来の構造でもしばしば利用されることがあるが、この構造を通信プロトコル共通の送信バッファ３１３1の構造とすることで、従来は不可能であった、異なる通信プロトコル間を統合した通信優先度制御を行うことができるようになる。
【００４９】
すなわち、産業用制御システムにおける通信プロトコルには、リアルタイム性を保証するために、制御のために必要なデータ通信の優先度を高くし、外部からの監視やエンジニアリングなどを目的とした通信の優先度を低くした、通信優先度管理が必要とされる場合が多い。
【００５０】
従来、この優先度管理は、同一の通信プロトコルの中でのみ適用可能なものであって、異なる通信プロトコル間の優先度管理を行うことはできなかった。従来の通信システム（図１１）において、通信制御コントローラ３Ａ，３Ｂは、一般にリアルタイム制御の要求が高いため、このことも、通信制御コントローラ３Ａ，３Ｂが複数の通信プロトコルをサポートできない重要な要因となっている。本実施の形態では、送信バッファ３１３1の構造を、単純な単一のＦＩＦＯ構造ではなく、優先度毎に定義したＦＩＦＯを並列配置することで、異なる通信プロトコル間における統合的な通信優先度管理を実現することができる。
【００５１】
共通リクエスト送信バッファ管理部３１３は、送信バッファ３１３1にバッファリングされた共通通信管理データから、バイナリデータ列として関連付けられているリクエストメッセージとそのサイズ情報を取り出し、プロトコル固有の送信ドライバ部３０５（３０５Ａ，３０５Ｂ）に送る。このとき、どの通信プロトコルの送信ドライバ部３０５に送るかは、共通通信管理データ内の「通信プロトコル識別情報」によって判断する。また、共通リクエスト送信バッファ管理部３１３は、リクエストメッセージとともに、共通通信管理データ内の「トランザクション情報」をプロトコル固有の送信ドライバ部３０５に引き渡す。
【００５２】
プロトコル固有の送信ドライバ部３０５（３０５Ａ，３０５Ｂ）は、従来の構成と同様に、そのプロトコルで規定された手続きに従って、渡されたリクエストメッセージを下位デバイスへの通信幹線上に送出する。
【００５３】
共通リクエスト送信バッファ管理部３１３は、プロトコル固有の送信ドライバ部３０５（３０５Ａ，３０５Ｂ）にリクエストメッセージを引き渡した後、送信バッファ３１３1から取り出した共通通信管理データ（送信中のリクエストメッセージと関連付けられている共通通信管理データ）を、共通送信中バッファ管理部３１４に送る。共通送信中バッファ管理部３１４は、通信プロトコル共通のタイムアウト監視を行うために、渡された共通通信管理データを通信プロトコル共通の送信中バッファ３１４1にバッファリングする。
【００５４】
共通タイムアウト監視部３１６は、送信中バッファ３１４1に移されている全ての共通通信管理データについて、タイマー監視を行う。レスポンスメッセージの受信動作が行われた場合、その通信に対応する共通通信管理データは、送信中バッファ３１４1から受信バッファ３１５1に移される（後述）。そのため、それぞれの共通通信管理データについて、送信中バッファ３１４1内での滞留時間を計測することで、通信タイムアウト監視を行うことができる。
【００５５】
共通タイムアウト監視部３１６は、タイムアウトを検出した場合、まだ規定回数に達するまでのリトライを行っていない場合には、タイムアウトを検出した共通通信管理データを共通リクエスト送信バッファ管理部３１３に送り、送信バッファ３１３1に再度バッファリングさせる（図４参照）。これにより、リトライ送信が行われる。
【００５６】
共通タイムアウト監視部３１６は、規定回数のリトライを行った後にタイムアウトを検出した場合は、タイムアウトを検出した共通通信管理データを共通レスポンス受信バッファ管理部３１５に送り、受信バッファ３１５1にバッファリングさせる。このとき、共通通信管理データの「通信結果情報」を「エラー終了」とする（図５参照）。
【００５７】
共通タイムアウト監視部３１６におけるタイムアウト時間およびリトライ回数は、固定値としても良いし、共通通信管理データの拡張情報として定義し、プロトコル固有のリクエストメッセージ送信部３０３（３０３Ａ，３０３Ｂ）が、通信プロトコルの特徴に応じた値を指定するようにしても良い。
【００５８】
プロトコル固有の受信ドライバ部３０７（３０７Ａ，３０７Ｂ）は、その通信プロトコルで規定された手続きに従って下位デバイスからのレスポンスメッセージの受信を行う。受信が行われたら、リクエストに対するレスポンスであるかどうかをチェックし、正常なレスポンスだと認められる場合には、受信したレスポンスメッセージをレスポンス関連付け部３１７に送る。このとき、プロトコル固有の受信ドライバ部３０７（３０７Ａ，３０７Ｂ）は、受信したレスポンスメッセージに対応する共通通信管理データの「通信プロトコル識別情報」と「トランザクション識別情報」を、レスポンスメッセージのバイナリデータ列と共にレスポンス関連付け部３１７に指定する（図６参照）。
【００５９】
レスポンス関連付け部３１７は、指定された「通信プロトコル識別情報」と「トランザクション識別情報」から特定される共通通信管理データを、送信中バッファ３１４1内から検索する。発見した場合には当該共通通信管理データと、プロトコル固有の受信ドライバ部３０７（３０７Ａ，３０７Ｂ）から渡されたレスポンスメッセージとの関連付を行い、さらに当該共通通信管理データの「通信結果情報」を「レスポンス受信成功」として、共通レスポンス受信バッファ管理部３１５に送る。共通レスポンス受信バッファ管理部３１５は、渡された共通通信管理データを受信バッファ３１５1にバッファリングする。
【００６０】
なお、レスポンス関連付け部３１７は、送信中バッファ３１４1から当該共通通信管理データを発見できなかった場合は、リクエストメッセージに対するレスポンスではないか、受信タイムアウト後にレスポンスメッセージを受信したケースであるから、当該受信メッセージを破棄する。
【００６１】
また、共通レスポンス受信バッファ管理部３１５における受信バッファ３１５1の構造は、共通リクエスト送信バッファ管理部３１３における送信バッファ３１３1の構造と同様のもので良い。
【００６２】
プロトコル固有の受信ドライバ部３０７（３０７Ａ，３０７Ｂ）は、レスポンスメッセージを受信したとき、そのレスポンスメッセージに対応する共通通信管理データの「トランザクション識別情報」を何らかの手段により知る必要がある。そのため、まず、プロトコル固有の送信ドライバ部３０５（３０５Ａ，３０５Ｂ）は、送信するリクエストメッセージと共に、当該共通通信管理データの「トランザクション識別情報」を共通リクエスト送信バッファ管理部３１３から受け取る。
【００６３】
例えば、「Modbus/RTU」や「BACnetMS/TP」のように、同時に１つのメッセージの送受信しか許容されないシリアル通信プロトコルの場合は、単純にレスポンスを受信するまで、プロトコル固有の送信ドライバ部３０５（３０５Ａ，３０５Ｂ）がこの「トランザクション識別情報」を覚えておけば良い。また、「BACnet/IP」など、マルチ送信が可能な通信プロトコルの場合には、一般的に通信メッセージ内に「InvokeID」や「シーケンスID」等と呼ばれる、リクエストメッセージとレスポンスメッセージを紐づける情報を格納するフィールドが用意されるため、そのフィールド情報としてこの「トランザクション識別情報」を使用しても良い。
【００６４】
共通レスポンス受信バッファ管理部３１５は、受信バッファ３１５1にバッファリングされた共通通信管理データを取り出し、プロトコル固有のレスポンスメッセージ受信部３０９（３０９Ａ，３０９Ｂ）に送る。この時の各通信プロトコルへの分配は、リクエストメッセージの送信時と同じく、共通通信管理データ内の「通信プロトコル識別情報」によって判断する。
【００６５】
プロトコル固有のレスポンスメッセージ受信部３０９（３０９Ａ，３０９Ｂ）は、共通通信管理データ内の「通信結果情報」により今回の通信処理の成否を判断し、成功した場合には従来の構成と同様に、その通信プロトコルによって規定された手続きにより受信したレスポンスメッセージを処理する。このとき、どのリクエストメッセージに対応するレスポンスメッセージであるかは、共通通信管理データ内の「トランザクション識別情報」によって判断することができる。
【００６６】
なお、この実施の形態では、簡単な例として通信プロトコルをＡ，Ｂの２つとしたが、２つに限られるものでないことは言うまでもない。通信プロトコルが増えても、通信共通部３３の構成は同じである。
【００６７】
〔実施の形態２：拡張構成〕
上述した実施の形態１（基本構成）によって、複数の通信プロトコル間における通信トランザクションの実行管理機能の共通化、異なる通信プロトコル間における統合的な優先度管理を実現することができる。これにより、本発明の目的を果たすことは可能であるが、実施の形態２（拡張構成）では、周期的なデータの読み出し、周期的なデータの書き込みについての通信機能の共通化を行うことで、より高い効果を得る。具体的には、図１に示した上位送受信部３４を本拡張での共通化範囲とし、この上位送受信部３４内の構成の共通化を図る。
【００６８】
図７に、上位送受信部３４内のさらに詳細な構成を示す。上位送受信部３４において、個別通信機能部３１Ａは、プロトコル固有のリクエストメッセージ送信部３０３Ａおよびプロトコル固有のレスポンスメッセージ受信部３０９Ａに加え、通信スケジューリング部３１８Ａと、エンジニアリング部３１９Ａと、設定データ記憶部３２０Ａとを備えている。個別通信機能部３１Ｂも、個別通信機能部３１Ａと同様、プロトコル固有のリクエストメッセージ送信部３０３Ｂおよびプロトコル固有のレスポンスメッセージ受信部３０９Ｂに加え、通信スケジューリング部３１８Ｂと、エンジニアリング部３１９Ｂと、設定データ記憶部３２０Ｂとを備えている。
【００６９】
図１５に示した従来の構成では、この上位送受信部３４における個別通信機能部３１Ａと個別通信機能部３１Ｂとが完全に無関係な単独の機能として存在し、個別通信機能部３１Ａ，３１Ｂのプロトコル固有のリクエストメッセージ送信部３０３Ａ，３０３Ｂがリクエストメッセージを編集して、プロトコル固有のリクエスト送信バッファ管理部３０４Ａ，３０４Ｂの送信バッファ３０４Ａ1，３０４Ｂ1に送り、個別通信機能部３１Ａ，３１Ｂのプロトコル固有のレスポンスメッセージ受信部３０９Ａ，３０９Ｂがプロトコル固有のリクエスト受信バッファ管理部３０８Ａ，３０８Ｂの受信バッファ３０８Ａ1，３０８Ｂ1からレスポンスメッセージを取り出し、レスポンスメッセージを解析して処理する。通信スケジューリング部３１８Ａ，３１８Ｂは、周期的な通信スキャン処理、あるいは周期的な通信出力処理の実行タイミングを  何らかの規則により決定し、リクエスト送信処理を開始する。エンジニアリング部３１９Ａ，３１９Ｂおよび設定データ記憶部３２０Ａ，３２０Ｂは、周期的なスキャンや出力の対象データの定義や実行周期などについて  何らかの設定がある場合、その設定パラメータと設定手段の提供を行う。
【００７０】
この上位送受信部３４において、共通化することが可能な構成は、通信スケジューリング部３１８Ａ，３１８Ｂと、エンジニアリング部３１９Ａ，３１９Ｂと、設定データ記憶部３２０Ａ，３２０Ｂである。図７では、共通化（一部分、または全て）することが可能な構成を太い線で囲んで示している。
【００７１】
図８に、図１に示した構成において、上位送受信部３４内の構成を共通化した例を示す。このような構成とすることにより、その詳細については後述するが、周期的な通信スキャン機能、および周期的な通信出力機能について、通信プロトコル個別に、それぞれ単独で存在していた従来の構成から、データ構造および機能の殆どが正規化され、かつ共通化された構成とすることができる。これにより、新たな通信プロトコルを開発する際の開発コストを最小限とし、また必要なメモリおよびＣＰＵリソースを抑えることができるようになる。
【００７２】
さらに、構造が正規化されたことの暗黙的な効果として、
（１）エンジニアリングの手段が正規化されることにより、エンジニアリングの効率の向上が期待できる。
（２）通信プロトコルの上位層として規定される製品内部のデータ構造や、アプリケーションを通信プロトコルに完全に依存しない形で構築することが可能となる。
という点が期待できる。
【００７３】
以下、図８に示した上位送受信部３４の構成について、詳細に説明する。この上位送受信部３４は、通信プロトコルＡ固有の通信機能部（個別通信機能部）３６Ａと、通信プロトコルＢ固有の通信機能部（個別通信機能部）３６Ｂと、通信プロトコルＡ，Ｂに依存しない共通の通信機能部（通信共通機能部）３７とを備えている。
【００７４】
個別通信機能部３６Ａは、通信プロトコルＡ固有の要素として設けられた、プロトコル固有のエンジニアリング部３２１Ａと、固有通信定義データ記憶部３２２Ａと、プロトコル固有のリクエストメッセージ編集部３２３Ａと、プロトコル固有のレスポンスメッセージ処理部３２４Ａとから構成され、個別通信機能部３６Ｂは、通信プロトコルＢ固有の要素として設けられた、プロトコル固有のエンジニアリング部３２１Ｂと、固有通信定義データ記憶部３２２Ｂと、プロトコル固有のリクエストメッセージ編集部３２３Ｂと、プロトコル固有のレスポンスメッセージ処理部３２４Ｂとから構成されている。
【００７５】
通信共通機能部３７は、通信プロトコルＡ，Ｂに依存しない共通要素として設けられた、共通エンジニアリング部３２５と、共通通信定義データ記憶部３２６と、共通スケジューリング部３２７と、共通送信部３２８と、共通受信部３２９とから構成されている。
【００７６】
なお、この構成において、プロトコル固有のエンジニアリング部３２１Ａ，３２１Ｂおよび共通エンジニアリング部３２５については、共通・固有の通信定義データを設定可能でない場合は必要ではない。また、具体的なエンジニアリング手段については本明細書では言及しない。
【００７７】
この上位送受信部３４において、共通通信定義データ記憶部３２６に記憶させる共通通信定義データは、周期的なスキャンや通信出力処理の実行単位で、その通信の実行内容を定義するためのデータであり、特定の通信プロトコルに依存した情報を含まない、少なくとも以下の情報を含んだデータとされている（図１０（ａ）参照）。
【００７８】
・通信プロトコル識別情報（通信プロトコルＩＤ）
この通信処理が行われる通信プロトコルを識別可能な、番号または何らかの識別子情報。
・トランザクション識別情報（トランザクションＩＤ）
この通信処理を、同一の通信プロトコルＩＤの中で一意に識別可能な、番号または何らかの識別子情報。
本実施の形態では、同一通信プロトコル内で通信トランザクションの宛先を一意に識別する番号と、同一宛先内で通信トランザクションを一意に識別するための番号の組み合わせで定義されている。
・実行周期
この通信処理を実行する周期を指定する（秒、ミリ秒などどのような単位でも良い）。
・読み出し／書き込み指定
この通信処理が読み出し（周期的なスキャン）であるか、書き込み（周期的な出力）であるかを指定する。
・内部データ構造の識別情報のリスト（内部データ構造のＩＤリスト）
この通信処理で扱う内部データ構造の何らかの識別子情報のリストを指定する。
読み出し通信処理の場合、読み出したデータを反映する内部データのリスト。
書き込み通信処理の場合、書き込み元となる内部データのリスト。
識別子情報はどのような体系でも良く、少なくとも１つの製品内部の範囲で、データとそのデータ型が一意に識別可能な体系であれば良い。
【００７９】
個々の共通通信定義データは、図９に示す例のようにフラットに定義しても良いし、あるいはデータ構造［通信プロトコルＩＤ］［宛先ＩＤ］［宛先内トランザクションＩＤ］のように多次元配列構造で定義しても良く、その場合、個々のデータに含むべき情報を配列要素番号によって代替しても良い。
【００８０】
また、共通通信定義データには、以下のような追加情報を含んでいても良い。
・通信優先度
実施の形態１（基本構成）で説明した通信優先度管理を行う場合は、共通データ構造にこの通信の優先度を含めておくことで、通信プロトコル間を統合した通信優先度管理を通信プロトコルに依存しない共通の仕組みとして行うことができる。
・受信タイムアウト時間
実施の形態１（基本構成）で説明した受信タイムアウト時間を通信処理毎に設定したい場合は、共通データ構造に受信タイムアウト時間を含めておいてもよい。
・リトライ回数
実施の形態１（基本構成）で説明したリトライ回数を通信処理毎に設定したい場合は、共通データ構造にリトライ回数を含めておいてもよい。
【００８１】
この上位送受信部３４において、固有通信定義データ記憶部３２２Ａ，３２２Ｂに記憶される固有通信定義データは、個々の共通通信定義データに対応する形で特定することができる、少なくとも以下の２種類の情報を含んだ、通信プロトコル毎に任意の構成で定義されるデータとされている（図１０（ｂ）参照）。
【００８２】
＃Ａ：通信の宛先を特定するためのアドレス情報
この通信処理の宛先を完全に特定できる、その通信プロトコルで規定された形式で記述されたアドレス情報。
例えば「BACnet通信」の場合、BACnetネットワーク番号と、BACnetMACアドレスの組であり、「Modbus/RTU通信」の場合は１〜の範囲で定義されるアドレスとなる。
＃Ｂ：外部データ構造のＩＤリスト
共通通信定義データの「内部データ構造のＩＤリスト」と対応する、その通信プロトコルで採用されているデータ体系の識別子で定義されたデータのリスト。
読み出し通信処理の場合、指定した宛先の、読み出し対象となるデータのリスト。
書き込み通信処理の場合、指定した宛先の、書き込み先となるデータのリスト。
例えば、「BACnet通信」の場合であれば、ＢＡＣｎｅｔオブジェクトのオブジェクト識別子の体系で定義された個々のプロパティの識別子であり、「Ｍｏｄｂｕｓ通信」の場合であれば、１〜６５５３５の範囲で定義されるＭｏｄｂｕｓレジスタの番号で定義したデータとなる。
【００８３】
通信共通機能部３７において、共通スケジューリング部３２７は、共通通信定義データ記憶部３２６に記憶されている全ての共通通信定義データの「実行周期」を参照し、全ての通信プロトコルの、全ての通信処理の実行タイミングを決定する。このスケジューリングの仕組みはどのようなものであっても良く、従来から一般的に行われている何らかの仕組みによって実現すれば良い。
【００８４】
共通スケジューリング部３２７は、通信処理の実行タイミングを検出したら、当該共通通信定義データを、指定された「通信プロトコル識別情報」から判別される通信プロトコルのリクエストメッセージ編集部３２３Ａ，３２３Ｂに渡す。
【００８５】
リクエストメッセージ編集部３２３Ａ，３２３Ｂは、渡された共通通信定義データと、対になる固有通信定義データとから、その通信プロトコルにおける今回の送信リクエストメッセージを作成し、共通送信部３２８に送る。
【００８６】
リクエストメッセージ編集部３２３Ａ，３２３Ｂは、共通通信定義データの「読み出し／書き込み指定」が「読み出し」の場合、固有通信定義データの「外部データ構造のＩＤリスト」に定義されたデータの読み出しメッセージを生成する。
【００８７】
リクエストメッセージ編集部３２３Ａ，３２３Ｂは、共通通信定義データの「読み出し／書き込み指定」が「書き込み」の場合、「外部データ構造のＩＤリスト」に定義されたデータの書き込みメッセージを生成する。このとき、書き込み元となるデータは、それと対になる共通通信定義データの「内部データ構造のＩＤリスト」によって特定することができる内部データ群の現在の値を読み出すことで特定することができる。
【００８８】
共通送信部３２８は、リクエストメッセージ編集部３２３Ａ，３２３Ｂで生成されたリクエストメッセージを受け取ったら、実施の形態１（基本構成）で説明した共通通信管理データを生成し、渡されたリクエストメッセージとの関連付を行って、共通リクエスト送信バッファ管理部３１３に送る。このとき、共通通信管理データの各情報を以下のように設定する。
・  通信プロトコル識別情報
共通通信定義データの通信プロトコル識別情報を設定する。
・  トランザクション識別情報
共通通信定義データのトランザクション識別情報を設定する。
【００８９】
実施の形態１の「基本構成」により、リクエスト送信処理およびレスポンス受信処理が行われ、共通受信部３２９には、共通レスポンス受信バッファ管理部３１５から共通通信管理データが渡される。
【００９０】
共通受信部３２９は、渡された共通通信管理データ内の「通信プロトコル識別情報」「トランザクション識別情報」から、共通通信定義データ記憶部３２６内の該当する共通通信定義データを検索する。共通通信定義データが発見されたら、共通受信部３２９は、共通通信管理データから取り出したレスポンス受信メッセージと共に共通通信定義データを、共通通信管理データの「通信プロトコル識別情報」によって特定される通信プロトコル固有のレスポンスメッセージ処理部３２４Ａ，３２４Ｂに渡す。
【００９１】
レスポンスメッセージ処理部３２４Ａ，３２４Ｂは、渡された共通通信定義データと、それと対になる固有通信定義データの組を使って、渡されたレスポンス受信メッセージを解析する。
【００９２】
〔読み出し通信の場合〕
共通通信定義データの「読み出し／書き込み指定」が「読み出し」の場合、レスポンスメッセージ処理部３２４Ａ，３２４Ｂは、レスポンス受信メッセージから、固有通信定義データの「外部データ構造のＩＤリスト」の構成に基づいて応答されたデータを抽出し、対応する共通通信定義データ「内部データ構造のＩＤリスト」によって特定される内部データ構造を更新する。
【００９３】
〔書き込み通信の場合〕
共通通信定義データの「読み出し／書き込み指定」が「書き込み」の場合、レスポンスメッセージ処理部３２４Ａ，３２４Ｂは、レスポンス受信メッセージから、固有通信定義データの「外部データ構造のＩＤリスト」の構成に基づいて、個々のデータの書き込み成否を判定し、必要であれば、「内部データ構造のＩＤリスト」を参照して、対応する内部データに関するエラー処理を行う。
【００９４】
この実施の形態２の構成（拡張構成）により、周期的な通信処理に関しては、通信プロトコル固有のデータおよびメッセージ体系に基づいてリクエストメッセージを生成する部分と、レスポンスメッセージを解析する部分を除き、大部分の機能およびデータ構造を共通化することができる。
【００９５】
また、特に製品内部のデータ構造に対して、各通信プロトコル機能から行われるデータアクセスが同じインターフェースに統一されることになるため、内部データ構造およびその上位のアプリケーションの構造を通信プロトコルに依存しない形で構成することが可能となり、容易に新たな通信プロトコルの拡張を行うことが可能となる。
【００９６】
〔実施の形態の拡張〕
以上、実施の形態を参照して本発明を説明したが、本発明は上記の実施の形態に限定されるものではない。本発明の構成や詳細には、本発明の技術思想の範囲内で当業者が理解し得る様々な変更をすることができる。
【符号の説明】
【００９７】
１…統合コントローラ（上位装置）、２…下位デバイス（下位装置）、３…通信制御コントローラ、３１（３１Ａ，３１Ｂ）…個別通信機能部（メッセージ送受信部）、３２（３２Ａ，３２Ｂ）…個別通信機能部（メッセージ送受信ドライバ部）、３３…通信共通部、３４…上位送受信部、３５…下位送受信部、３０１…制御アプリケーション、３０２…データベース、３６（３６Ａ，３６Ｂ）…個別通信機能部、３７…通信共通機能部、３０３（３０３Ａ，３０３Ｂ）…プロトコル固有のリクエストメッセージ送信部、３０５（３０５Ａ，３０５Ｂ）…プロトコル固有の送信ドライバ部、３０７（３０７Ａ，３０７Ｂ）…プロトコル固有の受信ドライバ部、３０９（３０９Ａ，３０９Ｂ）…プロトコル固有のレスポンスメッセージ受信部、３１３…共通リクエスト送信バッファ管理部、３１３1…送信バッファ、３１３2…優先度判断部、３１４…共通送信中バッファ管理部、３１４1…送信中バッファ、３１５…共通レスポンス受信バッファ管理部、３１５1…受信バッファ、３１６…共通タイムアウト監視部、３１７…レスポンス関連付け部。
【図１】
2019135580.tif 000003
【図２】
2019135580.tif 000004
【図３】
2019135580.tif 000005
【図４】
2019135580.tif 000006
【図５】
2019135580.tif 000007
【図６】
2019135580.tif 000008
【図７】
2019135580.tif 000009
【図８】
2019135580.tif 000010
【図９】
2019135580.tif 000011
【図１０】
2019135580.tif 000012
【図１１】
2019135580.tif 000013
【図１２】
2019135580.tif 000014
【図１３】
2019135580.tif 000015
【図１４】
2019135580.tif 000016
【図１５】
2019135580.tif 000017
【図１６】
2019135580.tif 000018