(57)【要約】【課題】  各種データ送受信機能にアクセスするためのインタフェース関数の簡素化を図ることができ、各種オペレーティングシステムにも対応可能とするプロトコル変換装置を提供することである。【解決手段】  ホスト計算機１２から汎用通信のソケットインタフェース関数であるSendtoによって要求された送信要求を制御用データ伝送装置１３が受けて処理できる形に変換するSendto／送信要求変換のデータ変換プログラム２３と、制御用データ伝送装置１３から渡され受信キュー２８にキューイングされた受信応答を汎用通信のソケットインタフェース関数であるRecvfromに変換する受信応答／Recvfrom変換のデータ変換プログラム２９とを備える。【選択図】  図１
2007116615.tif 000002
【特許請求の範囲】
【請求項１】
データ送受信機能を提供する制御用データ伝送装置と前記制御用データ伝送装置に対してデータ送受信機能をアクセスするホスト計算機との間に配置され、前記ホスト計算機から汎用通信のソケットインタフェース関数であるSendtoによって要求された送信要求を制御用データ伝送装置が受けて処理できる形に変換するSendto／送信要求変換のデータ変換プログラムと、前記制御用データ伝送装置から渡され受信キューにキューイングされた受信応答を汎用通信のソケットインタフェース関数であるRecvfromに変換する受信応答／Recvfrom変換のデータ変換プログラムとを備えたことを特徴とするプロトコル変換装置。
【請求項２】
前記ホスト計算機でSendtoされたテキストをSendto／送信要求変換のデータ変換プログラムにてデコードし、前記制御用データ伝送装置が提供する多種データ送受信機能に対応した要求に変換して、前記制御用データ伝送装置に渡すことを特徴とした請求項１記載のプロトコル変換装置。
【請求項３】
前記制御用データ伝送装置の提供する多種データ送受信機能に対応した各種受信データを受信キューにキューイングし、受信応答／Recvfrom変換のデータ変換プログラムにてエンコードして、ホスト計算機のRecvfromに応答受信させることを特徴とする請求項１記載のプロトコル変換装置。
【請求項４】
前記ホスト計算機からSendtoによって要求するとき、データ送受信機能とは別のシステム管理機能である各種設定機能などにも対応した要求をSendto／送信要求変換のデータ変換プログラムにてデコードし、前記制御用データ伝送装置のシステム管理機能に渡し、システム管理機能から受け渡された応答受信を受信応答／Recvfrom変換のデータ変換プログラムでエンコードしてホスト計算機はRecvfromにて応答受信することを特徴とする請求項１記載のプロトコル変換装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホスト計算機と制御用データ伝送装置との間でデータ送受信を行う際の通信プロトコルを変換するプロトコル変換装置に関する。
【背景技術】
【０００２】
一般に、ホスト計算機が制御用データ伝送装置にてデータ送受信を行う場合、多種データ送受信機能のそれぞれに対して、別々のインタフェースが準備されていた。たとえばデータ読出しサービスを行うなら、データ読出しインタフェースを使用してデータ読出しを行い、データ書込みサービスを行うなら、データ書込みインタフェースを使用してデータ書込みを行うというやり方である。また、このインタフェースは使用する制御用データ伝送装置ごとに異なるのが普通であった。
【０００３】
多種データ送受信機能のためにインタフェース関数を開発する工数は、莫大なものとなる傾向があった。また異なる制御用データ伝送装置では、このインタフェース関数が使えないので、さらに別のインタフェース関数を開発する必要があり工数がさらに増加する。
【０００４】
制御用データ伝送装置は、データ送受信機能の他にシステム管理機能を持つものが多い。システム管理機能は、各種設定やRAS情報アクセスなど多くの機能を提供する。ホスト計算機がこのシステム管理機能をアクセスする場合にもインタフェース関数を開発する必要があり開発工数を増加させる要因となっていた。
【０００５】
一般に、ホスト計算機は、いろいろなオペレーティングシステムを搭載している。例えばWindows（登録商標）NT、Windows2000、WindowsXP、Linux、Solarisなど多種ある。Linuxについては、多くのディストリビューションがあり、さらにいくつかのバージョンが存在する。Solarisについても、いくつかのバージョンが存在する。従って、例えばWindows2000に対応したインタフェース関数を開発しても、Linuxではまた別に開発が必要となる。さらにディストリビューションやバージョンの違いによって、動作しない場合も発生し、インタフェース関数を開発するまではいかなくとも、動作検証やソフト変更が生じる可能性がある。特にバージョンが違うと32ビット対応や64ビット対応などの違いがある場合があり、この場合はインタフェース関数の全面見直しが必要となる。
【０００６】
特に、近年オペレーティングシステムのバージョンアップサイクルは非常に短くなっており、せっかく開発したインタフェース関数がバージョンアップのためにすぐに使えなくなり、バージョンアップ対応開発が次々と必要になる。
【０００７】
第１通信装置により通信された第１通信プロトコルに従ってデータ信号を受信するための１つまたは複数の第１インタフェース装置、受信されたデータ信号を第２通信プロトコルに従ってデータ信号にオン・ザ・フライで変換するフォーマット・コンバータ装置、および第２プロトコルに従ってデータ信号を第２通信装置に出力するための１つまたは複数の第２インタフェース装置を含み、様々な通信技術およびプロトコルを実施する多数の装置間の効率的通信を可能にしたものがある（例えば、特許文献１参照）。
【特許文献１】特開２００２−６４５８６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、従来のものではホスト計算機が制御用データ伝送装置にてデータ送受信を行う場合に、各種データ送受信機能にアクセスするため、それぞれ別々のインタフェースを開発する必要があり、また、異なる制御用データ伝送装置では、このインタフェース関数が使えないので、さらに別のインタフェース関数を開発する必要があった。
【０００９】
制御用データ伝送装置は、データ送受信機能の他にシステム管理機能を持つものが多く、ホスト計算機がこのシステム管理機能をアクセスする場合にもインタフェース関数を開発する必要があり開発工数を増加させる要因となっていた。
【００１０】
ホスト計算機のオペレーティングシステムは多くの種類があり、かつバージョンアップも頻繁である。いずれかのオペレーティングシステムにて動作するインタフェース関数を開発しても、他オペレーティングシステムで使いたい場合、また開発が必要になる。また同じオペレーティングシステムでもバージョンアップされると、動作検証やバージョンアップ対応の開発が必要となる場合があった。
【００１１】
本発明の目的は、ホスト計算機が制御用データ伝送装置にデータ送受信を行う場合、各種データ送受信機能にアクセスするためのインタフェース関数の簡素化を図ることができ、各種オペレーティングシステムにも対応可能とするプロトコル変換装置を提供することである。
【課題を解決するための手段】
【００１２】
本発明のプロトコル変換装置は、データ送受信機能を提供する制御用データ伝送装置と前記制御用データ伝送装置に対してデータ送受信機能をアクセスするホスト計算機との間に配置され、前記ホスト計算機から汎用通信のソケットインタフェース関数であるSendtoによって要求された送信要求を制御用データ伝送装置が受けて処理できる形に変換するSendto／送信要求変換のデータ変換プログラムと、前記制御用データ伝送装置から渡され受信キューにキューイングされた受信応答を汎用通信のソケットインタフェース関数であるRecvfromに変換する受信応答／Recvfrom変換のデータ変換プログラムとを備えたことを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ホスト計算機から制御用データ伝送装置アクセスする際、汎用通信のソケットインタフェースで制御用データ伝送装置のデータ送受信機能やシステム管理機能が使用できるので、多種ある機能が全てSendto/Recvfromのみでアクセスでき開発・保守が容易になる。
【００１４】
異なる制御用データ伝送装置についても、汎用通信のソケットインタフェースでアクセスできる。またホスト計算機のオペレーティングシステムが多種ある場合でも、汎用通信のソケットインタフェースは標準サポートされており、バージョンアップの場合も必ずサポートされるので、ユーザアプリケーションに対して制御用データ伝送装置のサービス提供にあたり、開発・保守負荷の低減を実現できる。
【発明を実施するための最良の形態】
【００１５】
図１は本発明の第１の実施の形態に係わるプロトコル変換装置の構成図である。プロトコル変換装置１１はホスト計算機１２と制御用データ伝送装置１３との間に配置される。すなわち、プロトコル変換装置１１とホスト計算機１２とは、汎用バス（PCI、VME、SBUS）１４で接続されている。プロトコル変換装置１１と制御用データ伝送装置１３は、制御用データ伝送装置１３がサポートするI/Fバス１５にて接続されている。制御用データ伝送装置１３は伝送路１６に接続されており、他の制御用データ伝送装置１３とデータの送受信を行うことができるようになっている。
【００１６】
ホスト計算機１２にはユーザソフト１８が実装され、ユーザソフト１８は、Sendto関数１９にて要求送信を、Recvfrom関数２０にて応答受信を行う。Sendto関数１９からの要求送信は、UDP/IPスタック２１、NICドライバ２２を通って、プロトコル変換装置１１へ渡される。このように、ホスト計算機１２は汎用通信のソケットインタフェース関数の送信関数であるSendto関数１９と受信関数であるRecvfrom関数２０とを利用する。Sendto関数１９でユーザから制御用データ伝送装置１３へのデータ送信機能にアクセスするテキストを作成してプロトコル変換装置１１に送信する。
【００１７】
プロトコル変換装置１１では、Sendto／送信要求変換データ変換プログラム２３にてデータ変換が行われる。これにより、制御用データ伝送装置１３が判読できる要求送信テキストに変換し、送信要求処理手段２４を介して制御用データ伝送装置１３のデータ送受信機能２５やシステム管理機能２６に引き渡す。
【００１８】
一方、制御用データ伝送装置１３で受信したテキストは、プロトコル変換装置１１の応答受信処理手段２７を介して受信キュー２８ａ〜２８ｎに一旦キューされる。プロトコル変換装置１１は、この受信キュー２８ａ〜２８ｎの応答受信テキストを受信応答／Recvform変換データ変換プログラム２９でRecvformテキストに変換してホスト計算機１２に引き渡す。
【００１９】
このように、ホスト計算機１２のユーザソフト１８は、汎用通信のソケットインタフェース関数（Sendto関数１９、Recvfrom関数２０）を使用して送受信することで、制御用データ伝送装置１３のデータ送受信機能２５やシステム管理機能２６をアクセスできるようになる。これにより、インタフェース関数の簡素化を図ることができ、各種オペレーティングシステムにも対応可能とすることができる。
【００２０】
図２は、ホスト装置１２のSendto関数１９にて要求送信される制御用データ伝送装置通信サービスの説明図である。Sendto関数１９にて要求送信される制御用データ伝送装置通信サービスは、図２で示すように、データ読出しサービスＴ１、データ書込みサービスＴ２、インフォメーションリポートサービスＴ３、アップロード開始サービスＴｉ…など、多種の通信サービスがある。これらは集約されてUDP/IPサービスとして出力される。
【００２１】
図３は、Sendto要求送信／Recvfrom応答受信テキストの説明図である。Sendto関数１９にて要求送信される制御用データ伝送装置通信サービスのテキストやRecvfrom関数２０にて応答受信される制御用データ伝送装置通信サービスのテキストは、図３に示すように、ヘッダー３０と制御用データ伝送装置の標準テキスト３１から構成されている。
【００２２】
図４はヘッダーの詳細図である。ヘッダー３０は、図４に示すように制御用データ伝送装置１３の名前が入る機種識別３０ａと、サービス種別が入るサービス識別３０ｂ、そして要求／応答識別３０ｃから構成される。つまりSendto関数１９にて要求送信するとき、図２で示される多種の通信サービスは、識別子としてヘッダー３０にセットすることで全てUDP/IPサービスのSendtoで送信できる形に集約されている。従って、Sendto／送信要求変換データ変換プログラム２３は、ヘッダー３０を見て制御用データ伝送装置１３が判読できるテキストに変換する機能を実装する。
【００２３】
図５は、Sendto／送信要求変換データ変換プログラム２３の機能を示すフローチャートである。まず、Sendto要求送信テキストのヘッダー３０を取り出し（Ｓ１）、機種識別３０ａのデータに基づき機種識別が正しいか否かを判定し（Ｓ２）、要求／応答識別３０ｃのデータに基づき要求テキストか否かを判定し（Ｓ３）、サービス識別３０ｂのデータに基づき該当サービスは存在するか否かを判定する（Ｓ４）。そして、サービスの内容により分岐する（Ｓ５）。
【００２４】
サービスの内容は図２に示した内容である。例えば、データ読み出しサービスＴ１であるときは、制御用データ伝送装置データ読み出しサービスのテキストを作成し（Ｓ６）、データ書き込みサービスＴ２であるときは、制御用データ伝送装置データ書き込みサービスのテキストを作成し（Ｓ７）、インフォメーションリポートサービスＴ３であるときは、制御用データ伝送装置インフォメーションリポートサービスのテキストを作成する（Ｓ８）。同様に、ダウンロード開始サービスＴｌであるときは、制御用データ伝送装置ダウンロード開始サービスのテキストを作成し（Ｓｌ）、ダウンロードセグメントサービスＴｍであるときは、制御用データ伝送装置ダウンロードセグメントサービスのテキストを作成し（Ｓｍ）、ダウンロード終了サービスＴｎであるときは、制御用データ伝送装置ダウンロード終了サービスのテキストを作成する（Ｓｎ）。そして、送信要求処理手段２４に作成したテキストを引き渡す（Ｓ９）。
【００２５】
このように、Sendtoテキストのヘッダー３０を取り出して、機種や要求／応答種別、該当サービス有無のチェックを行った後に、サービスで分岐して制御用データ伝送装置１３の仕様のテキスト作成する。このテキストを送信要求処理手段２４に渡す。
【００２６】
プロトコル変換装置１１の送信要求処理手段２４は、制御用データ伝送装置１３のバスを経由して制御用データ装置１３のデータ送受信機能２５をアクセスする。これにより伝送路１６へデータ送信を行うことができる。送信要求処理手段２４は、システム管理機能２６をアクセスすることもできる。この場合、伝送路１６へデータ送信はないが、制御用データ伝送装置１３内の設定やRAS情報アクセスを行うことができる。
【００２７】
制御用データ伝送装置１３は伝送路１６よりデータ受信すると、データ送受信機能２５で受信されたテキストをI/Fバス１５を経由してプロトコル変換装置１１の応答受信処理手段２７により、受信キュー２８ａ〜２８ｎにキューイングする。
【００２８】
また、システム管理機能２６からの応答テキストも、同様の動作で受信キュー２８ａ〜２８ｎにキューイングされる。この受信キュー２８ａ〜２８ｎにキューイングされたテキストは、ユーザソフト１８がRecvform関数２０にて応答受信を行おうとしたとき、受信キュー２８ａ〜２８ｎから取り出され、受信応答／Recvfrom変換データ変換プログラム２９により、図３で示されたRecvfrom応答受信テキストに変換される。
【００２９】
図６は、受信応答／Recvfrom変換データ変換プログラム２３の機能を示すフローチャートである。まず、応答受信処理手段２７から受信キュー２８ａ〜２８ｎに格納されたテキストを取り出す（Ｓ１）。そして該当サービスが存在するか否かを判定し（Ｓ２）、該当サービスが存在する場合にはサービスの内容により分岐する（Ｓ３）。
【００３０】
サービスの内容は図２に示した内容である。例えば、データ読み出しサービスＴ１であるときは、Recvfrom応答受信テキストのヘッダー３０のサービス識別３０ｂにデータ読み出しサービスをセットし（Ｓ４）、データ書き込みサービスＴ２であるときは、ヘッダー３０のサービス識別３０ｂにデータ書き込みサービスをセットし（Ｓ５）、インフォメーションリポートサービスＴ３であるときは、ヘッダー３０のサービス識別３０ｂにインフォメーションリポートサービスをセットする（Ｓ６）。
【００３１】
同様に、ダウンロード開始サービスＴｌであるときは、ヘッダー３０のサービス識別３０ｂにダウンロード開始サービスをセットし（Ｓｌ）、ダウンロードセグメントサービスＴｍであるときは、ヘッダー３０のサービス識別３０ｂにダウンロードセグメントサービスをセットし（Ｓｍ）、ダウンロード終了サービスＴｎであるときは、ヘッダー３０のサービス識別３０ｂにダウンロード終了サービスをセットする（Ｓｎ）。
【００３２】
そして、ヘッダー３０の機種識別３０ａに制御用データ伝送装置１３の名前をセットし（Ｓ７）、ヘッダー３０の要求／応答識別３０ｃに応答識別をセットする（Ｓ８）。その後に、ホスト計算機１２にヘッダー３０と制御用データ伝送装置１３の標準テキストからなる応答テキストを引き渡す（Ｓ９）。
【００３３】
このように、受信キュー２８ａ〜２８ｎのテキストを取り出して、該当サービス有無のチェックを行った後、サービスで分岐して図４に示されるヘッダー３０を生成する。機種識別（制御用データ伝送装置の名前）３０ａ、サービス識別３０ｂ、要求／応答識別（応答識別）３０ｃをセットする。このRecvfrom応答受信テキストは、汎用バス１４を経由して、ホスト計算機１２のNICドライバ２２とUDP/IP２１を通って、Recvfrom関数２０からユーザソフト１８へ渡される。
【００３４】
つまり、図２で示すように多種ある制御用データ伝送装置通信サービスは、送信時UDP/IPサービスのSendtoに集約して送信するので、送信インタフェース関数は、この一つの関数のみで全ての送信要求を行うことができる。また制御用データ伝送装置１３で受信された多種のデータは、全てRecvformに集約してユーザは受信するので、受信インタフェース関数はこの一つの関数のみで全ての応答受信を行うことができる。
【００３５】
従って、ホスト計算機１２が制御用データ伝送装置１３にてデータ送受信を行う場合、各種データ送受信機能にアクセスするためのインタフェース関数をできるだけ少なくでき、開発・保守の負荷を低減することができる。異なる制御用データ伝送装置１３に対しても同じインタフェース関数を使用できるので、別々のインタフェース関数を開発する負荷を低減することができる。制御用データ伝送装置１３のシステム管理機能にアクセスする場合も、同じインタフェース関数が使用できるので、別々のインタフェース関数を開発する負荷を低減することができる。
【００３６】
本発明の第１の実施の形態によれば、ホスト計算機１２の多種オペレーティングシステムにおいて、本発明の第１の実施の形態で適用した汎用ソケットインタフェース関数は標準でサポートされているので、インタフェース関数を新たに開発する手間がなくなる。すなわち、汎用ソケットインタフェース関数は、Windows、Solaris、Linuxいずれにおいても標準でサポートされており、さらにバージョンアップ等が行われた場合においても標準でサポートされるので、インタフェース関数を新たに開発する手間がなくなる。また、制御用データ伝送装置１３へのホスト計算機１２の接続サポートを行うにあたり、開発・サポートの手間を大きく低減することができる。
【００３７】
図７は本発明の第２の実施の形態に係わるプロトコル変換装置の構成図である。この第２の実施の形態は、図１に示した第１の実施の形態に対し、プロトコル変換装置１１を制御用データ伝送装置１３の中に組み込んで形成したものである。すなわち、プロトコル変換装置１１を構成するSendto／送信要求変換データ変換プログラム２３、送信要求処理手段２４、受信応答／Recvform変換データ変換プログラム２９、受信キュー２８、応答受信処理手段２７を制御用データ伝送装置１３の中に組み込んで形成する。
【００３８】
この場合、プロトコル変換装置１１を構成するSendto／送信要求変換データ変換プログラム２３や受信応答／Recvform変換データ変換プログラム２９は、制御用データ伝送装置１３の演算制御装置で実行することが可能である。
【００３９】
第２の実施の形態によれば、第１の実施の形態と同様に、ホスト計算機１２から汎用通信のソケットインタフェース関数であるSendtoによって要求送信し、汎用通信のソケットインタフェース関数であるRecvfromによって応答受信するので、ホスト計算機１２が汎用通信ソケットインタフェースのサポートをするならば、オペレーティングシステムやそのバージョンによらずに適用することができる。
【図面の簡単な説明】
【００４０】
【図１】本発明の第１の実施の形態に係わるプロトコル変換装置の構成図。
【図２】本発明の第１の実施の形態におけるホスト装置のSendto関数にて要求送信される制御用データ伝送装置通信サービスの説明図。
【図３】本発明の第１の実施の形態におけるSendto要求送信／Recvfrom応答受信テキストの説明図。
【図４】本発明の第１の実施の形態におけるヘッダーの詳細図。
【図５】本発明の第１の実施の形態におけるSendto／送信要求変換データ変換プログラムの機能を示すフローチャート。
【図６】本発明の第１の実施の形態における受信応答／Recvfrom変換データ変換プログラムの機能を示すフローチャート。
【図７】本発明の第２の実施の形態に係わるプロトコル変換装置の構成図。
【符号の説明】
【００４１】
１１…プロトコル変換装置、１２…ホスト計算機、１３…制御用データ伝送装置、１４…汎用バス、１５…I/Fバス、１６…伝送路、１７…、１８…ユーザソフト、１９…Sendto関数、２０…Recvfrom関数、２１…UDP/IPスタック、２２…NICドライバ、２３…Sendto／送信要求変換データ変換プログラム、２４…送信要求処理手段、２５…データ送受信機能、２６…システム管理機能、２７…応答受信処理手段、２８…受信キュー、２９…受信応答／Recvform変換データ変換プログラム、３０…ヘッダー、３１…標準テキスト
【図１】
2007116615.tif 000003
【図２】
2007116615.tif 000004
【図３】
2007116615.tif 000005
【図４】
2007116615.tif 000006
【図５】
2007116615.tif 000007
【図６】
2007116615.tif 000008
【図７】
2007116615.tif 000009