特開2019-135580(P2019-135580A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ アズビル株式会社の特許一覧
<>
  • 特開2019135580-通信制御コントローラ 図000003
  • 特開2019135580-通信制御コントローラ 図000004
  • 特開2019135580-通信制御コントローラ 図000005
  • 特開2019135580-通信制御コントローラ 図000006
  • 特開2019135580-通信制御コントローラ 図000007
  • 特開2019135580-通信制御コントローラ 図000008
  • 特開2019135580-通信制御コントローラ 図000009
  • 特開2019135580-通信制御コントローラ 図000010
  • 特開2019135580-通信制御コントローラ 図000011
  • 特開2019135580-通信制御コントローラ 図000012
  • 特開2019135580-通信制御コントローラ 図000013
  • 特開2019135580-通信制御コントローラ 図000014
  • 特開2019135580-通信制御コントローラ 図000015
  • 特開2019135580-通信制御コントローラ 図000016
  • 特開2019135580-通信制御コントローラ 図000017
  • 特開2019135580-通信制御コントローラ 図000018
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2019-135580(P2019-135580A)
(43)【公開日】2019年8月15日
(54)【発明の名称】通信制御コントローラ
(51)【国際特許分類】
   G06F 13/10 20060101AFI20190719BHJP
【FI】
   G06F13/10 320A
【審査請求】未請求
【請求項の数】3
【出願形態】OL
【全頁数】21
(21)【出願番号】特願2018-17989(P2018-17989)
(22)【出願日】2018年2月5日
(71)【出願人】
【識別番号】000006666
【氏名又は名称】アズビル株式会社
(74)【代理人】
【識別番号】100098394
【弁理士】
【氏名又は名称】山川 茂樹
(74)【代理人】
【識別番号】100064621
【弁理士】
【氏名又は名称】山川 政樹
(72)【発明者】
【氏名】大澤 義孝
(57)【要約】
【課題】メモリなどの使用を抑え、また処理能力を小さくし、低コストの汎用の通信制御コントローラを提供する。
【解決手段】通信制御コントローラ3に、上位送受信部34と、下位送受信部35と、通信共通部33とを設ける。上位送受信部34は、通信共通部33への通信プロトコル固有のメッセージを送受信する個別通信機能部(メッセージ送受信部)31を通信プロトコル毎に備える。下位送受信部35は、通信共通部33からの下位デバイスへの通信プロトコル固有のメッセージおよび下位デバイスからの通信共通部33への通信プロトコル固有のメッセージを送受信する個別通信機能部(メッセージ送受信ドライバ部)32を通信プロトコル毎に備える。通信共通部33は、通信プロトコルによらない共通の構成として設けられ、上位送受信部34と下位送受信部35との間のメッセージの送受信を仲介する。
【選択図】 図1
【特許請求の範囲】
【請求項1】
上位装置と下位装置との間の通信の制御を行う通信制御コントローラにおいて、
前記上位装置との間で通信を行うように構成された上位送受信部と、
前記下位装置との間で通信を行うように構成された下位送受信部と、
前記上位送受信部と前記下位送受信部との間のメッセージの送受信を仲介するように構成された通信共通部とを備え、
前記上位送受信部は、
前記通信共通部への通信プロトコル固有のメッセージおよび前記通信共通部からの通信プロトコル固有のメッセージを送受信するように構成されたメッセージ送受信部を通信プロトコル毎に備え、
前記下位送受信部は、
前記通信共通部からの前記下位装置への通信プロトコル固有のメッセージおよび前記下位装置からの前記通信共通部への通信プロトコル固有のメッセージを送受信するように構成されたメッセージ送受信ドライバ部を通信プロトコル毎に備え、
前記通信共通部は、
前記通信プロトコルによらない共通の構成として設けられ、少なくとも、前記上位送受信部からの通信プロトコル固有のメッセージと関連づけて送られてくる前記通信プロトコルに依存しない共通のデータ構造とされた管理データを共通通信管理データとして記憶する共通通信管理データ記憶部を備える
ことを特徴とする通信制御コントローラ。
【請求項2】
請求項1に記載された通信制御コントローラにおいて、
前記通信共通部は、
前記下位装置へ送信中の通信プロトコル固有のメッセージに対応する前記共通通信管理データを記憶する送信中データ記憶部と、
前記下位装置へ送信中の通信プロトコル固有のメッセージに対するレスポンスが所定の時間内に返送されてきたか否かを監視するように構成されたタイムアウト監視部と
を備えることを特徴とする通信制御コントローラ。
【請求項3】
請求項1又は2に記載された通信制御コントローラにおいて、
前記共通通信管理データ記憶部に前記共通通信管理データをそのデータに付されている通信処理の優先度別に記憶させるように構成された優先度判断部
を備えることを特徴とする通信制御コントローラ。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、上位装置と下位装置との間の通信の制御を行う通信制御コントローラに関する。
【背景技術】
【0002】
一般に、ビルシステムやプロセス制御システムなどの自動制御システムでは、上位の統合コントローラ1台によって多数の下位デバイス(センサやアクチュエータなど)を制御することが求められる。この際、統合コントローラ(上位装置)と下位デバイス(下位装置)との間には、統合コントローラと下位デバイスとの間の通信の制御を行う通信制御コントローラが設けられる。
【0003】
ここで、各下位デバイスが全て同一の通信プロトコルを用いているのであれば良いが、例えばA社製品とB社製品とが混在するような通信システムにおいては、各々のデバイスが使用する通信プロトコルが異なる場合がある。
【0004】
例えば、ビルシステムのいては、同一システム内に、「BACnet」や「LonWorks」、「Modbus」などのオープンプロトコルに加えて、各社ローカルな専用通信プロトコルで通信する制御機器群が混在する。
【0005】
このように、同一システム内に複数の通信プロトコルが混在する場合、通信プロトコルによってデータ体系が異なるために、複数の通信プロトコルによって送受信されるデータを同じ制御アプリケーションから利用することができない点が大きな問題となる。
【0006】
このため、従来の通信システムでは、単一の通信プロトコルを使用する制御機器群で構成された「個別制御」の階層と、複数のそれらを統合し、プロトコル間のデータ体系の相違を吸収する「統合監視・制御」を行う階層にシステムを大きく分割することで、この問題を解決している。
【0007】
例えば、図11に示すように、A社製品とB社製品とが混在するような通信システムの場合、統合コントローラ1と通信プロトコルAを用いる下位デバイス2(2A1〜2A3)との間に通信プロトコルAに応じた通信制御コントローラ3Aを設け、統合コントローラ1と通信プロトコルBを用いる下位デバイス2(2B1〜2B3)との間に通信プロトコルBに応じた通信制御コントローラ3Bを設けるようにしている(例えば、特許文献1参照)。
【0008】
このような通信システムにおけるデータ通信には、どのようなプロトコルでも、大きく以下の3要素が存在する。
(1)データの読み出し
その通信プロトコルで定められたメッセージおよびデータ体系に沿って周期的なデータスキャンを行い、コントローラ内で使用されるデータの形に変換して取り込む 。
(2)データの書き込み
周期または特定のイベント(ユーザー操作やタイムスケジュール等のアプリケーション)により、コントローラ内部の最新データを、その通信プロトコルで定められたメッセージ体系に変換して書き込み出力を行う。
(3)通信トランザクションの実行管理
(1),(2)の通信の実行(リクエストの送信〜レスポンスの受信)を管理する。具体的には、リクエストとレスポンスの紐付けや、受信タイムアウトの監視、リトライ送信の実行などを行う。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開平5−67008号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
しかしながら、このような通信システムでは、通信プロトコルのみが異なる同種の通信制御コントローラが必要になり、開発投資の大きな増大要因となる。また、製造コスト面でも、多品種少量生産によるコストアップ原因となる。
【0011】
また、マルチ通信に対応していないため、異なる通信機器を接続しようとすると、通信を変換するためのゲートウェイが必要となってしまい、システムのコストアップとなる。
【0012】
例えば、図12に示すように、通信プロトコルAの通信制御コントローラ3Aに通信プロトコルBを用いた下位デバイス2(2B4)を接続する必要が生じたような場合、通信プロトコルBと通信プロトコルAを変換するためのゲートウェイとして通信変換器2(2A4)が必要となってしまい、システムのコストアップが発生する。
【0013】
このような問題を解決するためには、複数の通信プロトコルに対応可能な、汎用の通信制御コントローラを作ることが考えられる。図13に、通信制御コントローラ3Aの要部の構成を示し、図14に通信制御コントローラ3Bの要部の構成を示す。通信制御コントローラ3A,3Bともに、対応する通信プロトコルが異なるのみで、基本構成は同じである。この通信制御コントローラ3A,3Bの構成については後述する。
【0014】
図15に、図13図14に示した通信制御コントローラ3A,3Bの基本構成から考えられる、複数の通信プロトコルに対応可能な、汎用の通信制御コントローラ3’の構成を示す。この汎用の通信制御コントローラ3’では、通信制御コントローラ3A,3Bにおける制御アプリケーション301A,301Bを共通の制御アプリケーション301とし、通信制御コントローラ3A,3Bにおけるデータベース302A,302Bを共通のデータベース302とし、その他の構成はプロトコル固有の通信機能部(個別通信機能部)として設けるようにしている。
【0015】
しかし、このような構成とすると、ソフトウェアにおける通信機能の比率が大きくなり、大きなメモリと大きな処理能力(CPU能力)が必要となる。すなわち、上述した(1)データの読み出し、(2)データの書き込み、(3)通信トランザクションの実行管理の各機能を通信プロトコル毎に作成する必要があるため、大きな開発コストが必要となる他、ソフトウェアにおける通信機能の比率が大きくなり、大きなメモリとCPU能力が必要になり、高コストとなってしまう。
【0016】
本発明は、このような課題を解決するためになされたもので、その目的とするところは、複数の通信プロトコルを実装するにあたり、共通化できる要素をさらに共通化することで、メモリなどの使用を抑え、また処理能力を小さくし、低コストの汎用の通信制御コントローラを提供することにある。
【課題を解決するための手段】
【0017】
このような目的を達成するために本発明は、上位装置(1)と下位装置(2)との間の通信の制御を行う通信制御コントローラ(3)において、上位装置との間で通信を行うように構成された上位送受信部(34)と、下位装置との間で通信を行うように構成された下位送受信部(35)と、上位送受信部と下位送受信部との間のメッセージの送受信を仲介するように構成された通信共通部(33)とを備え、上位送受信部(34)は、通信共通部(33)への通信プロトコル固有のメッセージおよび通信共通部(33)からの通信プロトコル固有のメッセージを送受信するように構成されたメッセージ送受信部(31)を通信プロトコル毎に備え、下位送受信部(35)は、通信共通部(33)からの下位装置(2)への通信プロトコル固有のメッセージおよび下位装置(2)からの通信共通部(33)への通信プロトコル固有のメッセージを送受信するように構成されたメッセージ送受信ドライバ部(32)を通信プロトコル毎に備え、通信共通部(33)は、通信プロトコルによらない共通の構成として設けられ、少なくとも、上位送受信部(34)からの通信プロトコル固有のメッセージと関連づけて送られてくる通信プロトコルに依存しない共通のデータ構造とされた管理データを共通通信管理データとして記憶する共通通信管理データ記憶部(3131)を備えることを特徴とする。
【0018】
本発明において、通信制御コントローラは、通信プロトコルによらない共通の構成として通信共通部を備えており、この通信共通部の共通通信管理データ記憶部に通信プロトコルに依存しない共通のデータ構造とされた管理データが共通通信管理データとして記憶される。本発明では、このような通信共通部を設けることにより、複数の通信プロトコルに共通する3要素((1)データ読み出し、(2)データの書き込み、(3)通信トランザクション)を実現する機能を、通信プロトコル個別ではなく、特定の通信プロトコルに依存しない通信プロトコル共通の機能として設け、通信プロトコルに依存する差分の機能だけを通信プロトコル固有の機能として設けるための仕組みを提供することが可能となり、少ないメモリおよび小さい処理能力で、複数の通信プロトコルを実装することが可能となる。
【0019】
本発明において、通信共通部に、下位装置へ送信中の通信プロトコル固有のメッセージに対応する共通通信管理データを記憶する送信中データ記憶部(3141)と、下位装置へ送信中の通信プロトコル固有のメッセージに対するレスポンスが所定の時間内に返送されてきたか否かを監視するように構成されたタイムアウト監視部(316)とを設けるようにしてもよい。
【0020】
また、本発明において、優先度判断部(3122)を設け、共通通信管理データ記憶部に共通通信管理データをそのデータに付されている通信処理の優先度別に記憶させるようにしてもよい。ビルシステムなどは、リアルタイム性が低くてもよいため、冗長化して、優先度処理しても問題が起きにくい。
【0021】
なお、上記説明では、一例として、発明の構成要素に対応する図面上の構成要素を、括弧を付した参照符号によって示している。
【発明の効果】
【0022】
以上説明したように、本発明によれば、上位送受信部と下位送受信部との間に通信プロトコルによらない共通の構成として通信共通部を設け、この通信共通部に、少なくとも、通信プロトコルに依存しない共通のデータ構造とされた管理データを共通通信管理データとして記憶する共通通信管理データ記憶部を設けるようにしたので、少ないメモリおよび小さい処理能力で、複数の通信プロトコルを実装することができるようになり、汎用の通信制御コントローラの低コスト化を図ることが可能となる。
【図面の簡単な説明】
【0023】
図1図1は、本発明の実施の形態に係る通信制御コントローラの要部を示す図である。
図2図2は、この通信制御コントローラで用いられる共通通信管理データのデータ構造を例示する図である。
図3図3は、この通信制御コントローラで用いられる送信バッファの構造を例示する図である。
図4図4は、この通信制御コントローラにおけるタイムアウト検出&リトライ送信可能な場合の通信共通部における共通通信管理データの流れを示す図である。
図5図5は、この通信制御コントローラにおけるタイムアウト検出&リトライ送信不能な場合の通信共通部における共通通信管理データの流れを示す図である。
図6図6は、この通信制御コントローラにおける共通通信管理データ、リクエストメッセージおよびレスポンスメッセージの流れを示す図である。
図7図7は、この通信制御コントローラにおける上位送受信部内のさらに詳細な構成を示す図である。
図8図8は、この通信制御コントローラにおける上位送受信部内の構成を共通化した例を示す図である
図9図9は、個々の共通通信定義データをフラットに定義した例を示す図である。
図10図10は、共通通信定義データおよび固有通信定義データのデータ構造を例示する図である。
図11図11は、統合コントローラと下位デバイスとの間に通信プロトコル毎に固有の通信制御コントローラを設けた通信システムを例示する図である。
図12図12は、図11において通信プロトコルAの通信制御コントローラに通信プロトコルBを用いた下位デバイスを接続する必要が生じた場合の構成例を示す図である。
図13図13は、通信プロトコルAの通信制御コントローラの要部の構成を示す図である。
図14図14は、通信プロトコルBの通信制御コントローラの要部の構成を示す図である。
図15図15は、図13図14に示した通信制御コントローラの基本構成から考えられる汎用の通信制御コントローラの構成を示す図である。
図16図16は、図13図14に示した通信制御コントローラで用いられる送信バッファの構造を例示する図である。
【発明を実施するための形態】
【0024】
〔発明の経緯〕
本発明の実施の形態の説明に入る前に、先ず、図13図14に示した従来の通信制御コントローラ3A,3Bの基本構成について、通信制御コントローラ3Aを例にとって説明する。通信制御コントローラ3A,3Bともに、対応する通信プロトコルが異なるのみで、その基本構成は同じである。
【0025】
通信制御コントローラ3Aは、制御アプリケーション301Aと、データベース302Aと、プロトコル固有のリクエストメッセージ送信部303Aと、プロトコル固有のリクエスト送信バッファ管理部304Aと、プロトコル固有の送信ドライバ部305Aと、プロトコル固有のタイムアウト監視部306Aと、プロトコル固有の受信ドライバ部307Aと、プロトコル固有のレスポンス受信バッファ管理部308Aと、プロトコル固有のレスポンスメッセージ受信部309Aとを備えている。なお、この構成において、プロトコル固有の送信ドライバ部305Aと、プロトコル固有のタイムアウト監視部306Aと、プロトコル固有の受信ドライバ部307Aとは、通信ドライバ310Aを構成している。
【0026】
この通信制御コントローラ3Aにおいて、プロトコル固有のリクエストメッセージ送信部303Aは、下位デバイスからのデータの読み出しまたは下位デバイスへのデータの書き込みの通信処理を実行する契機を、何らかの規則(周期的な送信や、ユーザーからの手動操作を契機とするなど)によって決定し、その通信プロトコル毎の定めに従ってリクエストメッセージ(データの読み出しまたは書き込みメッセージ)を生成して、プロトコル固有のリクエスト送信バッファ管理部304Aに送る。送信するリクエストメッセージがデータの書き込みメッセージである場合、データベース302A内のデータ体系で管理されている書き込みデータを、その通信プロトコルで定められているデータ体系に変換して書き込みメッセージを生成する。
【0027】
プロトコル固有のリクエスト送信バッファ管理部304Aは、リクエスト送信要求の発生タイミングと、プロトコル固有の送信ドライバ部305Aによって実行される実際の送信処理との速度差を吸収するために一般的に設けられる。プロトコル固有のリクエスト送信バッファ管理部304Aは、プロトコル固有のリクエストメッセージ送信部303Aから送られてきたリクエストメッセージ(プロトコル固有のリクエストメッセージ)を送信バッファ304A1にバッファリングし、プロトコル固有の送信ドライバ部305Aが送信可能な状態になった場合、送信バッファ304A1にバッファリングされているリクエストメッセージをプロトコル固有の送信ドライバ部305Aに送る。
【0028】
一般的に、送信バッファ304A1の構造としては、図16に示すようなFIFO構造のキューが用いられる。このFIFO構造のキューでは、リクエストメッセージのキューイングがされると、最先にキューイングされたリクエストメッセージが取り出される。
【0029】
プロトコル固有の送信ドライバ部305Aは、その通信プロトコルでの定めに従い、プロトコル固有のリクエスト送信バッファ管理部304Aから渡されるリクエストメッセージを、下位デバイスへの通信幹線上に伝送する。
【0030】
プロトコル固有のタイムアウト監視部306Aは、送信したリクエストメッセージに対するレスポンスメッセージを受信するまでのタイムアウト監視を行い、タイムアウトを検出した場合には、規定されたリトライ回数に達するまでリトライ送信を行う。
【0031】
プロトコル固有の受信ドライバ部307Aは、その通信プロトコルでの定めに従って下位デバイスからのレスポンスメッセージ(プロトコル固有のレスポンスメッセージ)を受信したら、リクエストに対するレスポンスであるかどうかをチェックし、正常なレスポンスだと認められる場合には、受信したレスポンスメッセージをプロトコル固有のレスポンス受信バッファ管理部308Aに送る。
【0032】
プロトコル固有のレスポンス受信バッファ管理部308Aは、受信したレスポンスメッセージを受信バッファ308A1にバッファリングする。プロトコル固有のレスポンス受信バッファ管理部308Aでも、プロトコル固有のリクエスト送信バッファ管理部304Aにおける送信バッファ304A1と同じような構造の受信バッファ308A1が用いられる。プロトコル固有のレスポンス受信バッファ管理部308Aにバッファリングされたレスポンスメッセージはプロトコル固有のレスポンスメッセージ受信部309Aに送られる。
【0033】
プロトコル固有のレスポンスメッセージ受信部309Aは、その通信プロトコルが定めた手続きに従って、受信したレスポンスメッセージを処理する。受信レスポンスメッセージがデータ読み出しに対する応答である場合、その通信プロトコル固有のデータ体系で応答された読み出しデータを、データベース302A内で管理されるデータ体系に変換して、データの更新を行う。
【0034】
通信制御コントローラ3B(図14)も通信制御コントローラ3Aと同様の構成とされており、制御アプリケーション301Bと、データベース302Bと、プロトコル固有のリクエストメッセージ送信部303Bと、プロトコル固有のリクエスト送信バッファ管理部304Bと、プロトコル固有の送信ドライバ部305Bと、プロトコル固有のタイムアウト監視部306Bと、プロトコル固有の受信ドライバ部307Bと、プロトコル固有のレスポンス受信バッファ管理部308Bと、プロトコル固有のレスポンスメッセージ受信部309Bとを備えている。
【0035】
この通信制御コントローラ3A,3Bの基本構成から考えられる汎用の通信制御コントローラ3’(図15)では、通信制御コントローラ3A,3Bにおける制御アプリケーション301A,301Bを共通の制御アプリケーション301とし、通信制御コントローラ3A,3Bにおけるデータベース302A,302Bを共通のデータベース302とし、その他の構成はプロトコル固有の通信機能部(個別通信機能部)として設けるようにしている。
【0036】
すなわち、プロトコル固有のリクエストメッセージ送信部303Aと、プロトコル固有のリクエスト送信バッファ管理部304Aと、プロトコル固有の送信ドライバ部305Aと、プロトコル固有のタイムアウト監視部306Aと、プロトコル固有の受信ドライバ部307Aと、プロトコル固有のレスポンス受信バッファ管理部308Aと、プロトコル固有のレスポンスメッセージ受信部309Aとを通信プロトコルAの個別通信機能部30(30A)として設け、プロトコル固有のリクエストメッセージ送信部303Bと、プロトコル固有のリクエスト送信バッファ管理部304Bと、プロトコル固有の送信ドライバ部305Bと、プロトコル固有のタイムアウト監視部306Bと、プロトコル固有の受信ドライバ部307Bと、プロトコル固有のレスポンス受信バッファ管理部308Bと、プロトコル固有のレスポンスメッセージ受信部309Bとを通信プロトコルBの個別通信機能部30(30B)として設けている。
【0037】
本出願人は、この通信制御コントローラ3’において、さらに共通化することが可能な構成として、プロトコル固有のリクエスト送信バッファ管理部304A,304Bと、プロトコル固有のタイムアウト監視部306A,306Bと、プロトコル固有のレスポンス受信バッファ管理部308A,308Bに着目した。図15では、共通化することが可能な構成を太い線で囲んで示している。以下では、この通信制御コントローラ3’の構成を従来の構成として説明する。
【0038】
本発明は、この共通化することが可能な構成に着目し、共通化できる要素をさらに共通化することで、メモリなどの使用を抑え、また処理能力を小さくし、低コストの汎用の通信制御コントローラを提供しようとするものである。
【0039】
〔実施の形態1:基本構成〕
図1に本発明の実施の形態に係る通信制御コントローラ3の要部を示す。この通信制御コントローラ3は、プロセッサや記憶装置からなるハードウェアと、これらのハードウェアと協働して各種機能を実現させるプログラムとによって実現され、通信プロトコルA固有の通信機能部(個別通信機能部)31A,32Aと、通信プロトコルB固有の通信機能部(個別通信機能部)31B,32Bと、通信プロトコルA,Bに依存しない共通の通信機能部(通信共通部)33とを備えている。
【0040】
個別通信機能部31Aは、通信プロトコルA固有の要素として設けられた、プロトコル固有のリクエストメッセージ送信部303Aとプロトコル固有のレスポンスメッセージ受信部309Aとから構成され、個別通信機能部31Bは、通信プロトコルB固有の要素として設けられた、プロトコル固有のリクエストメッセージ送信部303Bとプロトコル固有のレスポンスメッセージ受信部309Bとから構成されている。この個別通信機能部31A,31Bが本発明でいうメッセージ送受信部に相当する。また、この個別通信機能部31A,31Bによって、上位送受信部34が構成されている。この上位送受信部34が本発明でいう上位送受信部に相当する。上位送受信部34は、その基本機能として、統合コントローラ(1)との間で通信を行う機能を備えている。
【0041】
個別通信機能部32Aは、通信プロトコルA固有の要素として設けられた、プロトコル固有の送信ドライバ部305Aとプロトコル固有の受信ドライバ部307Aとから構成され、個別通信機能部32Bは、通信プロトコルB固有の要素として設けられた、プロトコル固有の送信ドライバ部305Bとプロトコル固有の受信ドライバ部307Bとから構成されている。この個別通信機能部32A,32Bが本発明でいうメッセージ送受信ドライバ部に相当する。また、この個別通信機能部32A,32Bによって、下位送受信部35が構成されている。この下位送受信部35が本発明でいう下位送受信部に相当する。下位送受信部35は、下位デバイス(2)との間で通信を行う機能を備えている。
【0042】
通信共通部33は、通信プロトコルA,Bに依存しない共通要素として設けられ、共通リクエスト送信バッファ管理部313と、共通送信中バッファ管理部314と、共通レスポンス受信バッファ管理部315と、共通タイムアウト監視部316と、レスポンス関連付け部317とから構成されている。この通信共通部33が本発明でいう通信共通部に相当する。通信共通部33は、上位送受信部34と下位送受信部35との間のメッセージの送受信を仲介する機能を備えている。
【0043】
この通信制御コントローラ3において、プロトコル固有のリクエストメッセージ送信部303(303A,303B)は、通信処理の実行タイミングで、その通信プロトコルが定める手続きに従ってリクエストメッセージを生成し、共通リクエスト送信バッファ管理部313に送る。この手段については、基本的に従来の構成と変わりはないが、リクエストメッセージの送り先が、特定の通信プロトコルに依存しない共通のバッファ(送信バッファ3131)である点が異なる。
【0044】
そのために、図15に示した従来の構成では、送信バッファ304A1,304B1に受け渡すデータ構造は、その通信プロトコルにおけるリクエストメッセージそのもの、あるいはその通信プロトコルに依存した論理構成で定義されたデータの集合であったが、本実施の形態において、送信バッファ3131に受け渡すデータ構造は、少なくとも以下の情報を含む、特定の通信プロトコルに依存しない共通のデータ構造とされた管理データ(以降、共通通信管理データと呼ぶ)とする。
【0045】
〔共通通信管理データに含まれる情報〕
・通信プロトコル識別情報(通信プロトコルID)
この通信処理が行われる通信プロトコルを識別可能な、番号または何らかの識別子情報。
・トランザクション識別情報(トランザクションID)
この通信処理を、同一の通信プロトコルIDの中で一意に識別可能な、番号または何らかの識別子情報。
・リクエストメッセージまたはそのアドレス情報
・レスポンスメッセージまたはそのアドレス情報
図2に例示するように、共通通信管理データとの関連付けとして、データ構造内にそのまま含めても良いし(図2(a):データ構造例(1))、別途バッファを管理し、共通通信管理データ内にはそのアドレス情報のみを含むようにしても良い(図2(b):データ構造例(2))。
データ構造例(1)の場合、通信プロトコル毎にメッセージ最大サイズが異なるため、そのうちの最大のものに合わせる必要があり、メモリ効率は悪くなるが管理のためのソフトウェア構造が単純なもので済む利点がある。データ構造例(2)の場合、メモリ効率を高くすることができるが、より複雑なソフトウェア構造を必要とする。本実施の形態では、データ構造例(2)を採用するものとする。
・リクエストメッセージのサイズ
・レスポンスメッセージのサイズ
特定の通信プロトコルに依存しないようにするため、リクエストメッセージおよびレスポンスメッセージは単なるバイナリデータ列として扱う必要があり、そのため、リクエストメッセージおよびレスポンスメッセージのサイズ情報がそれぞれ必要となる。
・通信結果(レスポンス受信成功またはエラー終了)
【0046】
共通リクエスト送信バッファ管理部313は、プロトコル固有のリクエストメッセージ送信部303(303A,303B)から送られてくる共通通信管理データを通信プロトコル共通で設けられた送信バッファ3131にバッファリングする。送信バッファ3131の設置目的および基本的な構造は既知の構成と同等であるが、バッファリングするデータの構造を特定の通信に依存しない構造(共通通信管理データ)とすることで、各通信共通の送信バッファとして利用することができるようになる。
【0047】
また、送信バッファ3131の構造を、単純な単一のFIFO構造ではなく、例えば図3に示すように、優先度毎に定義したFIFOを並列配置することで、通信優先度管理を行うことができる。共通リクエスト送信バッファ管理部313は、優先度判断部3132を備え、プロトコル固有のリクエストメッセージ送信部303(303A,303B)から送られてくる共通通信管理データをそのデータに付されている通信処理の優先度別に、並列配置されたFIFOに送り込む。
【0048】
この構造自体は特に新規なものではなく、従来の構造でもしばしば利用されることがあるが、この構造を通信プロトコル共通の送信バッファ3131の構造とすることで、従来は不可能であった、異なる通信プロトコル間を統合した通信優先度制御を行うことができるようになる。
【0049】
すなわち、産業用制御システムにおける通信プロトコルには、リアルタイム性を保証するために、制御のために必要なデータ通信の優先度を高くし、外部からの監視やエンジニアリングなどを目的とした通信の優先度を低くした、通信優先度管理が必要とされる場合が多い。
【0050】
従来、この優先度管理は、同一の通信プロトコルの中でのみ適用可能なものであって、異なる通信プロトコル間の優先度管理を行うことはできなかった。従来の通信システム(図11)において、通信制御コントローラ3A,3Bは、一般にリアルタイム制御の要求が高いため、このことも、通信制御コントローラ3A,3Bが複数の通信プロトコルをサポートできない重要な要因となっている。本実施の形態では、送信バッファ3131の構造を、単純な単一のFIFO構造ではなく、優先度毎に定義したFIFOを並列配置することで、異なる通信プロトコル間における統合的な通信優先度管理を実現することができる。
【0051】
共通リクエスト送信バッファ管理部313は、送信バッファ3131にバッファリングされた共通通信管理データから、バイナリデータ列として関連付けられているリクエストメッセージとそのサイズ情報を取り出し、プロトコル固有の送信ドライバ部305(305A,305B)に送る。このとき、どの通信プロトコルの送信ドライバ部305に送るかは、共通通信管理データ内の「通信プロトコル識別情報」によって判断する。また、共通リクエスト送信バッファ管理部313は、リクエストメッセージとともに、共通通信管理データ内の「トランザクション情報」をプロトコル固有の送信ドライバ部305に引き渡す。
【0052】
プロトコル固有の送信ドライバ部305(305A,305B)は、従来の構成と同様に、そのプロトコルで規定された手続きに従って、渡されたリクエストメッセージを下位デバイスへの通信幹線上に送出する。
【0053】
共通リクエスト送信バッファ管理部313は、プロトコル固有の送信ドライバ部305(305A,305B)にリクエストメッセージを引き渡した後、送信バッファ3131から取り出した共通通信管理データ(送信中のリクエストメッセージと関連付けられている共通通信管理データ)を、共通送信中バッファ管理部314に送る。共通送信中バッファ管理部314は、通信プロトコル共通のタイムアウト監視を行うために、渡された共通通信管理データを通信プロトコル共通の送信中バッファ3141にバッファリングする。
【0054】
共通タイムアウト監視部316は、送信中バッファ3141に移されている全ての共通通信管理データについて、タイマー監視を行う。レスポンスメッセージの受信動作が行われた場合、その通信に対応する共通通信管理データは、送信中バッファ3141から受信バッファ3151に移される(後述)。そのため、それぞれの共通通信管理データについて、送信中バッファ3141内での滞留時間を計測することで、通信タイムアウト監視を行うことができる。
【0055】
共通タイムアウト監視部316は、タイムアウトを検出した場合、まだ規定回数に達するまでのリトライを行っていない場合には、タイムアウトを検出した共通通信管理データを共通リクエスト送信バッファ管理部313に送り、送信バッファ3131に再度バッファリングさせる(図4参照)。これにより、リトライ送信が行われる。
【0056】
共通タイムアウト監視部316は、規定回数のリトライを行った後にタイムアウトを検出した場合は、タイムアウトを検出した共通通信管理データを共通レスポンス受信バッファ管理部315に送り、受信バッファ3151にバッファリングさせる。このとき、共通通信管理データの「通信結果情報」を「エラー終了」とする(図5参照)。
【0057】
共通タイムアウト監視部316におけるタイムアウト時間およびリトライ回数は、固定値としても良いし、共通通信管理データの拡張情報として定義し、プロトコル固有のリクエストメッセージ送信部303(303A,303B)が、通信プロトコルの特徴に応じた値を指定するようにしても良い。
【0058】
プロトコル固有の受信ドライバ部307(307A,307B)は、その通信プロトコルで規定された手続きに従って下位デバイスからのレスポンスメッセージの受信を行う。受信が行われたら、リクエストに対するレスポンスであるかどうかをチェックし、正常なレスポンスだと認められる場合には、受信したレスポンスメッセージをレスポンス関連付け部317に送る。このとき、プロトコル固有の受信ドライバ部307(307A,307B)は、受信したレスポンスメッセージに対応する共通通信管理データの「通信プロトコル識別情報」と「トランザクション識別情報」を、レスポンスメッセージのバイナリデータ列と共にレスポンス関連付け部317に指定する(図6参照)。
【0059】
レスポンス関連付け部317は、指定された「通信プロトコル識別情報」と「トランザクション識別情報」から特定される共通通信管理データを、送信中バッファ3141内から検索する。発見した場合には当該共通通信管理データと、プロトコル固有の受信ドライバ部307(307A,307B)から渡されたレスポンスメッセージとの関連付を行い、さらに当該共通通信管理データの「通信結果情報」を「レスポンス受信成功」として、共通レスポンス受信バッファ管理部315に送る。共通レスポンス受信バッファ管理部315は、渡された共通通信管理データを受信バッファ3151にバッファリングする。
【0060】
なお、レスポンス関連付け部317は、送信中バッファ3141から当該共通通信管理データを発見できなかった場合は、リクエストメッセージに対するレスポンスではないか、受信タイムアウト後にレスポンスメッセージを受信したケースであるから、当該受信メッセージを破棄する。
【0061】
また、共通レスポンス受信バッファ管理部315における受信バッファ3151の構造は、共通リクエスト送信バッファ管理部313における送信バッファ3131の構造と同様のもので良い。
【0062】
プロトコル固有の受信ドライバ部307(307A,307B)は、レスポンスメッセージを受信したとき、そのレスポンスメッセージに対応する共通通信管理データの「トランザクション識別情報」を何らかの手段により知る必要がある。そのため、まず、プロトコル固有の送信ドライバ部305(305A,305B)は、送信するリクエストメッセージと共に、当該共通通信管理データの「トランザクション識別情報」を共通リクエスト送信バッファ管理部313から受け取る。
【0063】
例えば、「Modbus/RTU」や「BACnetMS/TP」のように、同時に1つのメッセージの送受信しか許容されないシリアル通信プロトコルの場合は、単純にレスポンスを受信するまで、プロトコル固有の送信ドライバ部305(305A,305B)がこの「トランザクション識別情報」を覚えておけば良い。また、「BACnet/IP」など、マルチ送信が可能な通信プロトコルの場合には、一般的に通信メッセージ内に「InvokeID」や「シーケンスID」等と呼ばれる、リクエストメッセージとレスポンスメッセージを紐づける情報を格納するフィールドが用意されるため、そのフィールド情報としてこの「トランザクション識別情報」を使用しても良い。
【0064】
共通レスポンス受信バッファ管理部315は、受信バッファ3151にバッファリングされた共通通信管理データを取り出し、プロトコル固有のレスポンスメッセージ受信部309(309A,309B)に送る。この時の各通信プロトコルへの分配は、リクエストメッセージの送信時と同じく、共通通信管理データ内の「通信プロトコル識別情報」によって判断する。
【0065】
プロトコル固有のレスポンスメッセージ受信部309(309A,309B)は、共通通信管理データ内の「通信結果情報」により今回の通信処理の成否を判断し、成功した場合には従来の構成と同様に、その通信プロトコルによって規定された手続きにより受信したレスポンスメッセージを処理する。このとき、どのリクエストメッセージに対応するレスポンスメッセージであるかは、共通通信管理データ内の「トランザクション識別情報」によって判断することができる。
【0066】
なお、この実施の形態では、簡単な例として通信プロトコルをA,Bの2つとしたが、2つに限られるものでないことは言うまでもない。通信プロトコルが増えても、通信共通部33の構成は同じである。
【0067】
〔実施の形態2:拡張構成〕
上述した実施の形態1(基本構成)によって、複数の通信プロトコル間における通信トランザクションの実行管理機能の共通化、異なる通信プロトコル間における統合的な優先度管理を実現することができる。これにより、本発明の目的を果たすことは可能であるが、実施の形態2(拡張構成)では、周期的なデータの読み出し、周期的なデータの書き込みについての通信機能の共通化を行うことで、より高い効果を得る。具体的には、図1に示した上位送受信部34を本拡張での共通化範囲とし、この上位送受信部34内の構成の共通化を図る。
【0068】
図7に、上位送受信部34内のさらに詳細な構成を示す。上位送受信部34において、個別通信機能部31Aは、プロトコル固有のリクエストメッセージ送信部303Aおよびプロトコル固有のレスポンスメッセージ受信部309Aに加え、通信スケジューリング部318Aと、エンジニアリング部319Aと、設定データ記憶部320Aとを備えている。個別通信機能部31Bも、個別通信機能部31Aと同様、プロトコル固有のリクエストメッセージ送信部303Bおよびプロトコル固有のレスポンスメッセージ受信部309Bに加え、通信スケジューリング部318Bと、エンジニアリング部319Bと、設定データ記憶部320Bとを備えている。
【0069】
図15に示した従来の構成では、この上位送受信部34における個別通信機能部31Aと個別通信機能部31Bとが完全に無関係な単独の機能として存在し、個別通信機能部31A,31Bのプロトコル固有のリクエストメッセージ送信部303A,303Bがリクエストメッセージを編集して、プロトコル固有のリクエスト送信バッファ管理部304A,304Bの送信バッファ304A1,304B1に送り、個別通信機能部31A,31Bのプロトコル固有のレスポンスメッセージ受信部309A,309Bがプロトコル固有のリクエスト受信バッファ管理部308A,308Bの受信バッファ308A1,308B1からレスポンスメッセージを取り出し、レスポンスメッセージを解析して処理する。通信スケジューリング部318A,318Bは、周期的な通信スキャン処理、あるいは周期的な通信出力処理の実行タイミングを 何らかの規則により決定し、リクエスト送信処理を開始する。エンジニアリング部319A,319Bおよび設定データ記憶部320A,320Bは、周期的なスキャンや出力の対象データの定義や実行周期などについて 何らかの設定がある場合、その設定パラメータと設定手段の提供を行う。
【0070】
この上位送受信部34において、共通化することが可能な構成は、通信スケジューリング部318A,318Bと、エンジニアリング部319A,319Bと、設定データ記憶部320A,320Bである。図7では、共通化(一部分、または全て)することが可能な構成を太い線で囲んで示している。
【0071】
図8に、図1に示した構成において、上位送受信部34内の構成を共通化した例を示す。このような構成とすることにより、その詳細については後述するが、周期的な通信スキャン機能、および周期的な通信出力機能について、通信プロトコル個別に、それぞれ単独で存在していた従来の構成から、データ構造および機能の殆どが正規化され、かつ共通化された構成とすることができる。これにより、新たな通信プロトコルを開発する際の開発コストを最小限とし、また必要なメモリおよびCPUリソースを抑えることができるようになる。
【0072】
さらに、構造が正規化されたことの暗黙的な効果として、
(1)エンジニアリングの手段が正規化されることにより、エンジニアリングの効率の向上が期待できる。
(2)通信プロトコルの上位層として規定される製品内部のデータ構造や、アプリケーションを通信プロトコルに完全に依存しない形で構築することが可能となる。
という点が期待できる。
【0073】
以下、図8に示した上位送受信部34の構成について、詳細に説明する。この上位送受信部34は、通信プロトコルA固有の通信機能部(個別通信機能部)36Aと、通信プロトコルB固有の通信機能部(個別通信機能部)36Bと、通信プロトコルA,Bに依存しない共通の通信機能部(通信共通機能部)37とを備えている。
【0074】
個別通信機能部36Aは、通信プロトコルA固有の要素として設けられた、プロトコル固有のエンジニアリング部321Aと、固有通信定義データ記憶部322Aと、プロトコル固有のリクエストメッセージ編集部323Aと、プロトコル固有のレスポンスメッセージ処理部324Aとから構成され、個別通信機能部36Bは、通信プロトコルB固有の要素として設けられた、プロトコル固有のエンジニアリング部321Bと、固有通信定義データ記憶部322Bと、プロトコル固有のリクエストメッセージ編集部323Bと、プロトコル固有のレスポンスメッセージ処理部324Bとから構成されている。
【0075】
通信共通機能部37は、通信プロトコルA,Bに依存しない共通要素として設けられた、共通エンジニアリング部325と、共通通信定義データ記憶部326と、共通スケジューリング部327と、共通送信部328と、共通受信部329とから構成されている。
【0076】
なお、この構成において、プロトコル固有のエンジニアリング部321A,321Bおよび共通エンジニアリング部325については、共通・固有の通信定義データを設定可能でない場合は必要ではない。また、具体的なエンジニアリング手段については本明細書では言及しない。
【0077】
この上位送受信部34において、共通通信定義データ記憶部326に記憶させる共通通信定義データは、周期的なスキャンや通信出力処理の実行単位で、その通信の実行内容を定義するためのデータであり、特定の通信プロトコルに依存した情報を含まない、少なくとも以下の情報を含んだデータとされている(図10(a)参照)。
【0078】
・通信プロトコル識別情報(通信プロトコルID)
この通信処理が行われる通信プロトコルを識別可能な、番号または何らかの識別子情報。
・トランザクション識別情報(トランザクションID)
この通信処理を、同一の通信プロトコルIDの中で一意に識別可能な、番号または何らかの識別子情報。
本実施の形態では、同一通信プロトコル内で通信トランザクションの宛先を一意に識別する番号と、同一宛先内で通信トランザクションを一意に識別するための番号の組み合わせで定義されている。
・実行周期
この通信処理を実行する周期を指定する(秒、ミリ秒などどのような単位でも良い)。
・読み出し/書き込み指定
この通信処理が読み出し(周期的なスキャン)であるか、書き込み(周期的な出力)であるかを指定する。
・内部データ構造の識別情報のリスト(内部データ構造のIDリスト)
この通信処理で扱う内部データ構造の何らかの識別子情報のリストを指定する。
読み出し通信処理の場合、読み出したデータを反映する内部データのリスト。
書き込み通信処理の場合、書き込み元となる内部データのリスト。
識別子情報はどのような体系でも良く、少なくとも1つの製品内部の範囲で、データとそのデータ型が一意に識別可能な体系であれば良い。
【0079】
個々の共通通信定義データは、図9に示す例のようにフラットに定義しても良いし、あるいはデータ構造[通信プロトコルID][宛先ID][宛先内トランザクションID]のように多次元配列構造で定義しても良く、その場合、個々のデータに含むべき情報を配列要素番号によって代替しても良い。
【0080】
また、共通通信定義データには、以下のような追加情報を含んでいても良い。
・通信優先度
実施の形態1(基本構成)で説明した通信優先度管理を行う場合は、共通データ構造にこの通信の優先度を含めておくことで、通信プロトコル間を統合した通信優先度管理を通信プロトコルに依存しない共通の仕組みとして行うことができる。
・受信タイムアウト時間
実施の形態1(基本構成)で説明した受信タイムアウト時間を通信処理毎に設定したい場合は、共通データ構造に受信タイムアウト時間を含めておいてもよい。
・リトライ回数
実施の形態1(基本構成)で説明したリトライ回数を通信処理毎に設定したい場合は、共通データ構造にリトライ回数を含めておいてもよい。
【0081】
この上位送受信部34において、固有通信定義データ記憶部322A,322Bに記憶される固有通信定義データは、個々の共通通信定義データに対応する形で特定することができる、少なくとも以下の2種類の情報を含んだ、通信プロトコル毎に任意の構成で定義されるデータとされている(図10(b)参照)。
【0082】
#A:通信の宛先を特定するためのアドレス情報
この通信処理の宛先を完全に特定できる、その通信プロトコルで規定された形式で記述されたアドレス情報。
例えば「BACnet通信」の場合、BACnetネットワーク番号と、BACnetMACアドレスの組であり、「Modbus/RTU通信」の場合は1〜の範囲で定義されるアドレスとなる。
#B:外部データ構造のIDリスト
共通通信定義データの「内部データ構造のIDリスト」と対応する、その通信プロトコルで採用されているデータ体系の識別子で定義されたデータのリスト。
読み出し通信処理の場合、指定した宛先の、読み出し対象となるデータのリスト。
書き込み通信処理の場合、指定した宛先の、書き込み先となるデータのリスト。
例えば、「BACnet通信」の場合であれば、BACnetオブジェクトのオブジェクト識別子の体系で定義された個々のプロパティの識別子であり、「Modbus通信」の場合であれば、1〜65535の範囲で定義されるModbusレジスタの番号で定義したデータとなる。
【0083】
通信共通機能部37において、共通スケジューリング部327は、共通通信定義データ記憶部326に記憶されている全ての共通通信定義データの「実行周期」を参照し、全ての通信プロトコルの、全ての通信処理の実行タイミングを決定する。このスケジューリングの仕組みはどのようなものであっても良く、従来から一般的に行われている何らかの仕組みによって実現すれば良い。
【0084】
共通スケジューリング部327は、通信処理の実行タイミングを検出したら、当該共通通信定義データを、指定された「通信プロトコル識別情報」から判別される通信プロトコルのリクエストメッセージ編集部323A,323Bに渡す。
【0085】
リクエストメッセージ編集部323A,323Bは、渡された共通通信定義データと、対になる固有通信定義データとから、その通信プロトコルにおける今回の送信リクエストメッセージを作成し、共通送信部328に送る。
【0086】
リクエストメッセージ編集部323A,323Bは、共通通信定義データの「読み出し/書き込み指定」が「読み出し」の場合、固有通信定義データの「外部データ構造のIDリスト」に定義されたデータの読み出しメッセージを生成する。
【0087】
リクエストメッセージ編集部323A,323Bは、共通通信定義データの「読み出し/書き込み指定」が「書き込み」の場合、「外部データ構造のIDリスト」に定義されたデータの書き込みメッセージを生成する。このとき、書き込み元となるデータは、それと対になる共通通信定義データの「内部データ構造のIDリスト」によって特定することができる内部データ群の現在の値を読み出すことで特定することができる。
【0088】
共通送信部328は、リクエストメッセージ編集部323A,323Bで生成されたリクエストメッセージを受け取ったら、実施の形態1(基本構成)で説明した共通通信管理データを生成し、渡されたリクエストメッセージとの関連付を行って、共通リクエスト送信バッファ管理部313に送る。このとき、共通通信管理データの各情報を以下のように設定する。
・ 通信プロトコル識別情報
共通通信定義データの通信プロトコル識別情報を設定する。
・ トランザクション識別情報
共通通信定義データのトランザクション識別情報を設定する。
【0089】
実施の形態1の「基本構成」により、リクエスト送信処理およびレスポンス受信処理が行われ、共通受信部329には、共通レスポンス受信バッファ管理部315から共通通信管理データが渡される。
【0090】
共通受信部329は、渡された共通通信管理データ内の「通信プロトコル識別情報」「トランザクション識別情報」から、共通通信定義データ記憶部326内の該当する共通通信定義データを検索する。共通通信定義データが発見されたら、共通受信部329は、共通通信管理データから取り出したレスポンス受信メッセージと共に共通通信定義データを、共通通信管理データの「通信プロトコル識別情報」によって特定される通信プロトコル固有のレスポンスメッセージ処理部324A,324Bに渡す。
【0091】
レスポンスメッセージ処理部324A,324Bは、渡された共通通信定義データと、それと対になる固有通信定義データの組を使って、渡されたレスポンス受信メッセージを解析する。
【0092】
〔読み出し通信の場合〕
共通通信定義データの「読み出し/書き込み指定」が「読み出し」の場合、レスポンスメッセージ処理部324A,324Bは、レスポンス受信メッセージから、固有通信定義データの「外部データ構造のIDリスト」の構成に基づいて応答されたデータを抽出し、対応する共通通信定義データ「内部データ構造のIDリスト」によって特定される内部データ構造を更新する。
【0093】
〔書き込み通信の場合〕
共通通信定義データの「読み出し/書き込み指定」が「書き込み」の場合、レスポンスメッセージ処理部324A,324Bは、レスポンス受信メッセージから、固有通信定義データの「外部データ構造のIDリスト」の構成に基づいて、個々のデータの書き込み成否を判定し、必要であれば、「内部データ構造のIDリスト」を参照して、対応する内部データに関するエラー処理を行う。
【0094】
この実施の形態2の構成(拡張構成)により、周期的な通信処理に関しては、通信プロトコル固有のデータおよびメッセージ体系に基づいてリクエストメッセージを生成する部分と、レスポンスメッセージを解析する部分を除き、大部分の機能およびデータ構造を共通化することができる。
【0095】
また、特に製品内部のデータ構造に対して、各通信プロトコル機能から行われるデータアクセスが同じインターフェースに統一されることになるため、内部データ構造およびその上位のアプリケーションの構造を通信プロトコルに依存しない形で構成することが可能となり、容易に新たな通信プロトコルの拡張を行うことが可能となる。
【0096】
〔実施の形態の拡張〕
以上、実施の形態を参照して本発明を説明したが、本発明は上記の実施の形態に限定されるものではない。本発明の構成や詳細には、本発明の技術思想の範囲内で当業者が理解し得る様々な変更をすることができる。
【符号の説明】
【0097】
1…統合コントローラ(上位装置)、2…下位デバイス(下位装置)、3…通信制御コントローラ、31(31A,31B)…個別通信機能部(メッセージ送受信部)、32(32A,32B)…個別通信機能部(メッセージ送受信ドライバ部)、33…通信共通部、34…上位送受信部、35…下位送受信部、301…制御アプリケーション、302…データベース、36(36A,36B)…個別通信機能部、37…通信共通機能部、303(303A,303B)…プロトコル固有のリクエストメッセージ送信部、305(305A,305B)…プロトコル固有の送信ドライバ部、307(307A,307B)…プロトコル固有の受信ドライバ部、309(309A,309B)…プロトコル固有のレスポンスメッセージ受信部、313…共通リクエスト送信バッファ管理部、3131…送信バッファ、3132…優先度判断部、314…共通送信中バッファ管理部、3141…送信中バッファ、315…共通レスポンス受信バッファ管理部、3151…受信バッファ、316…共通タイムアウト監視部、317…レスポンス関連付け部。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16