(57)【要約】【課題】アプリケーションソフトの処理周期とネットワーク送受信周期とを切り離すことができ、伝送周期や伝送プロトコルの変更があった場合でも伝送ドライバとのインタフェースの変更を最小限にできるようにすることである。【解決手段】ユーザアプリケーションソフトウェア６がネットワーク３へデータを送受信する送信データ・受信データをネットワーク伝送制御基板２上の共有メモリ８と同じデータ構造にてＣＰＵ基板４のメモリ上に一時保存するためのバッファエリア７と、一定周期でバッファエリア上の送信データエリアのデータを読み込みバスを介してネットワーク伝送制御基板上の共有メモリの送信データエリアに書き込むと共に共有メモリの受信データエリアのデータを読み込みバッファエリアの受信データエリア上に書き込むための伝送ドライバ１１とを備える。【選択図】図１
2009141668.tif 000002
【特許請求の範囲】
【請求項１】
ＣＰＵ基板とネットワーク伝送制御基板とからなり、前記ＣＰＵ基板上に実装されたユーザアプリケーションソフトウェアから定周期あるいは不定期のデータ送受信を前記ネットワーク伝送制御基板を経由してネットワークに対して行い、ユーザアプリケーションソフトウェアにより定周期で画面更新して送受信データの表示を行うデータ伝送装置において、ユーザアプリケーションソフトウェアがネットワークへデータを送受信する送信データ・受信データをネットワーク伝送制御基板上の共有メモリと同じデータ構造にてＣＰＵ基板のメモリ上に一時保存するためのバッファエリアと、一定周期でバッファエリア上の送信データエリアのデータを読み込みバスを介してネットワーク伝送制御基板上の共有メモリの送信データエリアに書き込むと共に、共有メモリの受信データエリアのデータを読み込みバッファエリアの受信データエリア上に書き込むための伝送ドライバとを備えたことを特徴とするデータ伝送装置。
【請求項２】
請求項１において、定周期でデータ送信・受信するためのサイクリック送信・受信用ＡＰＩを設け、ユーザアプリケーションがバッファエリアに送受信データを読み書きする際にサイクリック送信・受信用ＡＰＩを使用し、新規のデータを送信する場合に伝送ドライバがこれを検知してバッファエリアと共有メモリとの間で新規のデータを読み書きすることを特徴とするデータ伝送装置。
【請求項３】
請求項２において、単発でデータ送受信するためのイベント送信・受信用ＡＰＩを設け、ユーザアプリケーションがバッファエリアに送受信データを読み書きする際に任意のタイミングで単発でイベント送信・受信用ＡＰＩを使用し、新規のデータを送信する場合及び受信する場合に、伝送ドライバがこれを検知してバッファエリアと共有メモリとの間で新規のデータを読み書きすることを特徴とするデータ伝送装置。
【請求項４】
請求項３において、前記ＣＰＵ基板上に複数のＯＳが実装され、複数のＯＳ上のユーザアプリケーションからデータ送受信が行えるように、各々の送信・受信用ＡＰＩ間のデータ変換用ソフトウェアを備えることを特徴とするデータ伝送装置。
【請求項５】
請求項３または４において、サイクリック送信用ＡＰＩまたはイベント送信用ＡＰＩは、バッファエリアに送信データを設定する前に送信データの整合性をチェックし、チェック結果をレスポンスとしてユーザアプリケーションに返すことを特徴とするデータ伝送装置。
【請求項６】
請求項３または４において、サイクリック受信用ＡＰＩまたはイベント受信用ＡＰＩは、バッファエリアからユーザアプリケーションに受信データを渡す前にデータの整合性をチェックし、チェック結果をレスポンスとしてユーザアプリケーションに返すことを特徴とするデータ伝送装置。
【請求項７】
請求項３または４において、アプリケーションソフトからサイクリック送信・受信用ＡＰＩやイベント送信・受信用ＡＰＩが同時期に呼ばれた場合は、バッファエリアのデータが上書きされないように最初に受け付けた要求を処理し、他はビジーレスポンスをアプリケーションソフトに返すことを特徴とするデータ伝送装置。
【請求項８】
請求項３または４において、前記ネットワーク伝送制御基板がネットワーク伝送上の異常を検出した場合は、これを共有メモリ上に記録し、伝送ドライバがこれを取得して送信・受信用ＡＰＩ経由で、ユーザアプリケーションに対してネットワーク異常情報を返すことを特徴とするデータ伝送装置。
【請求項９】
請求項８において、伝送ドライバが検出した異常について、ＯＳのイベントログに記録すると共に、伝送ドライバが検出した異常について別ファイルとして記録することを特徴とするデータ伝送装置。
【請求項１０】
請求項９において、伝送ドライバが検出した異常について、メモリ上に書き出し、ファイルへの異常情報書込みを伝送ドライバの空き時間に処理することを特徴とするデータ伝送装置。
【請求項１１】
請求項１０において、ユーザアプリケーションがデータ送受信ＡＰＩを使用する周期を変更すると、伝送ドライバがＣＰＵ基板上のバッファエリアからネットワーク伝送制御基板上の共有メモリへ、送受信データを読み書きする周期を自動的に変更することを特徴とするデータ伝送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＣＰＵ基板とネットワーク伝送制御基板とを有し、ネットワークを介してデータの送受信を行うデータ伝送装置に関する。
【背景技術】
【０００２】
ＣＰＵ基板とネットワーク伝送制御基板とを有し、ネットワークを介してデータの送受信を行うデータ伝送装置では、ＣＰＵ基板上に実装されたユーザアプリケーションソフトウェアから定周期あるいは不定期のデータ送受信をネットワーク伝送制御基板を経由してネットワークに対して行い、ユーザアプリケーションソフトウェアにより定周期で画面更新して送受信データの表示を行うようにしている。
【０００３】
このようなデータ伝送装置は、データの整合性の観点からＣＰＵ側とネットワーク伝送装置側との同期をとる方法に重点がおかれ、コントローラ等のＣＰＵ装置の演算処理およびネットワーク上の処理動作を同期して行うことができるようにしたものがある（例えば、特許文献１参照）。
【特許文献１】特開２０００−２１５１８８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、ＣＰＵ側のアプリケーションソフトの処理周期は、ネットワーク伝送装置のネットワーク送受信周期から切り離して任意に設定したい場合がある。また、ユーザアプリケーション側の処理としては、伝送周期や伝送プロトコルの変更があった場合でも、変更を最小限とすることが望ましく、伝送用のＡＰＩなどの伝送ドライバとのインタフェースは変更しないのが望ましい。
【０００５】
また、ＣＰＵ側から伝送装置側に誤ったデータを渡して、伝送装置のメモリ破壊や異常動作、通信先装置への誤ったデータの伝送を避けるため、伝送装置にデータを渡す前にチェックすることが重要となっている。
【０００６】
また、従来は、不適合発生時等に伝送装置のメモリ内容を調査する場合、伝送装置を停止して、専用のツールを使用して調査する必要があるが、伝送装置を停止せずに、なおかつ伝送装置側メモリに影響を与えずに、ＣＰＵ側で伝送装置のメモリの内容を調査できることが望ましい。
【０００７】
本発明の目的は、アプリケーションソフトの処理周期とネットワーク送受信周期とを切り離すことができ、伝送周期や伝送プロトコルの変更があった場合でも伝送ドライバとのインタフェースの変更を最小限にできるデータ伝送装置を提供することである。
【０００８】
また、伝送装置にデータを渡す前にデータをチェックでき、伝送装置の停止や伝送装置側メモリに影響を与えることなくＣＰＵ側で伝送装置のメモリの内容を調査できるデータ伝送装置を提供することである。
【課題を解決するための手段】
【０００９】
本発明のデータ伝送装置は、ＣＰＵ基板とネットワーク伝送制御基板とからなり、前記ＣＰＵ基板上に実装されたユーザアプリケーションソフトウェアから定周期あるいは不定期のデータ送受信を前記ネットワーク伝送制御基板を経由してネットワークに対して行い、ユーザアプリケーションソフトウェアにより定周期で画面更新して送受信データの表示を行うデータ伝送装置において、ユーザアプリケーションソフトウェアがネットワークへデータを送受信する送信データ・受信データをネットワーク伝送制御基板上の共有メモリと同じデータ構造にてＣＰＵ基板のメモリ上に一時保存するためのバッファエリアと、一定周期でバッファエリア上の送信データエリアのデータを読み込みバスを介してネットワーク伝送制御基板上の共有メモリの送信データエリアに書き込むと共に、共有メモリの受信データエリアのデータを読み込みバッファエリアの受信データエリア上に書き込むための伝送ドライバを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、アプリケーションソフトの処理周期とネットワーク送受信周期とを切り離すことができ、伝送周期や伝送プロトコルの変更があった場合でも伝送ドライバとのインタフェースの変更を最小限にできる。
【発明を実施するための最良の形態】
【００１１】
（第１の実施の形態）
図１は本発明の第１の実施の形態に係わるデータ伝送装置の構成図である。図１において、ＣＰＵ基板１とネットワーク伝送制御基板２とは、図示省略のバスでつながっている。ネットワーク伝送制御基板２はネットワーク３とつながり、ネットワーク３を介して図示省略の制御装置等とデータ送受信を行う。
【００１２】
主メモリ４はＣＰＵ基板上の主メモリであり、ＣＰＵ基板１の起動時に、ハードディスク１５から、ＯＳ−Ａ５、ユーザアプリケーション６、伝送ドライバ１１がロードされる。
【００１３】
伝送ドライバ１１は、主メモリ４上にバッファエリア７を確保する。バッファエリア７には、送信データエリア９と受信データアリア１０とがある。バッファエリア７の容量は、ネットワーク伝送制御基板２の共有メモリ８と同じである。送信データエリア９と受信データアリア１０の容量及びバッファエリア７上における配置は、共有メモリ８上における送信データエリア１２と受信データエリア１３の容量及び配置と同じである。
【００１４】
ユーザアプリケーション６は、ネットワーク３上へ送信したいデータをバッファエリア７上の送信データエリア９に書き込む。伝送ドライバ１１は、送信データエリア９上の内容全てを共有メモリ８上の送信データエリア１２に一定周期でコピーする。伝送ファームウェア１４は、送信データエリア１２上の送信データをネットワーク３の通信プロトコルに従い、一定周期でネットワーク３上にある送信先の制御装置等にデータ送信する。
【００１５】
また、伝送ファームウェア１４は、ネットワーク３上の制御装置等から一定周期で受信した受信データを、共有メモリ８上の受信データエリア１３に書き込む。伝送ドライバ１１は、受信データエリア１３の内容全てを、一定周期で、バッファエリア７上の受信データエリア１０へ書き込む。ユーザアプリケーション６は、受信データエリア１０上の受信データを一定周期で読み込むことで、データ受信を行う。この受信データは、ユーザアプリケーションにて画面表示等に使用される。画面表示は、受信データに基づき、一定周期で更新される。
【００１６】
第１の実施の形態によれば、バッファエリア７と共有メモリ８との間の送受信周期をネットワーク伝送装置のネットワーク送受信周期とは切り離して、ユーザアプリケーション６側の画面処理周期等に合わせて、設定可能とすることができる。
【００１７】
また、バッファエリア７上の送受信データは、共有メモリ８上の送受信データの内容と同じとなり、送受信データの異常時には、共有メモリ８を調査せずとも、ネットワークで伝送制御基板２を停止したり、共有メモリ８を破壊する懸念なく、主メモリ４上のバッファエリア７上の送受信データをＣＰＵ基板１側で閉じた操作にて調査することが可能となる。
【００１８】
（第２の実施の形態）
図２は本発明の第２の実施形態に係わるデータ伝送装置の構成図であり、図３は本発明の第２の実施の形態に係わるデータ伝送装置の送信データエリアの説明図である。この第２の実施の形態は、図１に示した第１の実施の形態に対し、定周期でデータ送信するためのサイクリック送信用ＡＰＩ２０１、データ受信するためのサイクリック受信用ＡＰＩ２０２を追加して設けたものである。図１と同一要素には同一符号を付し重複する説明は省略する。
【００１９】
データ送信する場合には、ユーザアプリケーション６がサイクリック送信用ＡＰＩ２０１を使用して、定周期(サイクリック)で送信するデータをバッファエリア７の送信データエリア９上に書き込む。具体的には、送信データエリア９の内容詳細を記載した図３において、サイクリック送信データ本体２０４を送信データエリア９上に書き込む。また、サイクリック送信用ＡＰＩ２０１は、新規に送信データを書き込んだことを示すため、サイクリック送信データ更新フラグ２０３を、送信データエリア９に書き込む。具体的には、０→１を設定する。
【００２０】
伝送ドライバ１１は、定周期にサイクリック送信データ更新フラグ２０３をチェックしており、これが０→１に変化した場合、新規のサイクリック送信データ有として、サイクリック送信データ本体２０４を共有メモリ８上の送信データエリア１２にサイクリック送信データ本体２０５として書き込む。書き込んだ後は、サイクリック送信データ更新フラグ２０３を０に戻す。
【００２１】
伝送ファームウェア１４では、ネットワーク３への伝送周期で送信データエリア１２上のサイクリック送信データ本体２０５を伝送周期にてネットワーク３上にサイクリック送信する。サイクリック送信では、サイクリック送信データに変化が無くとも伝送周期にて周期的に送信する。
【００２２】
また、サイクリック受信用ＡＰＩ２０２は、ユーザアプリケーション６から定周期で呼ばれ、受信データエリア１０の内容をユーザアプリケーション６に渡すことで、常に最新の受信データを、ユーザアプリケーション６に渡す。
【００２３】
これにより、ネットワーク３上に、定周期で送信する送信データについて、サイクリック送信用ＡＰＩ２０１にて、送信データの内容が更新された場合のみ、伝送ドライバ１１がバッファエリア７から共有メモリ８に書き込むので、伝送ドライバ１１の処理が軽減される。
【００２４】
また、バッファエリア７及び共有メモリ８を伝送ドライバ１１が送信データを読み書きするためにロックする時間が短くなり、サイクリック送信用ＡＰＩ２０１及び伝送ファームウェア１４の処理を停滞させる確率を削減することが可能となる。
【００２５】
また、ユーザアプリケーション６からサイクリック送信用ＡＰＩ２０１及びサイクリック受信用ＡＰＩ２０２を使用してデータ送受信を行うことにより、バッファエリア７をロックしてアドレスを指定してデータを設定・取得する処理をＡＰＩにて行うことが可能となり、ユーザアプリケーション６からのデータ送受信のプログラミングが容易となる。
【００２６】
（第３の実施の形態）
図４は本発明の第３の実施の形態に係わるデータ伝送装置の送信データエリアの説明図、図５は本発明の第３の実施の形態に係わるデータ伝送装置の受信データエリアの説明図である。図２、図３に示した第２の実施の形態に対し、この第３の実施の形態は、イベント送信用ＡＰＩ３０１及びイベント受信用ＡＰＩ３０２を追加して設けたものである。図１乃至図３と同一要素には同一符号を付し重複する説明は省略する。
【００２７】
図４では、ユーザアプリケーション６がイベント送信用ＡＰＩ３０１を使用して、任意のタイミングでの単発(イベント)で送信するデータをバッファエリア７の送信データエリア９上に書き込む。具体的には、送信データエリア９の内容詳細を記載した図４において、イベント送信データ本体３０４を送信データエリア９上に書き込む。また、イベント送信用ＡＰＩ３０１は、新規に送信データを書き込んだことを示すため、イベント送信データ更新フラグ３０３が０(イベント送信データ無し)の場合、送信データエリア９に書き込む。具体的には、０→１を設定する。イベント送信データ更新フラグ３０３が１(イベント送信データ中)の場合は、イベント送信用ＡＰＩ３０１は新規イベント送信を行わず、ビジーのレスポンスをユーザアプリケーション６へ返す。
【００２８】
伝送ドライバ１１は、定周期にイベント送信データ更新フラグ３０３をチェックしており、これが０→１に変化した場合、新規のイベント送信データ有として、イベント送信データ本体３０４を共有メモリ８上の送信データエリア１２にイベント送信データ本体３０５として書き込むと共に、イベント送信データ更新フラグ３０３をイベント送信データ更新フラグ３０５として書き込む。
【００２９】
伝送ファームウェア１４では、ネットワーク３への伝送周期で送信データエリア１２上のイベント送信データ更新フラグ３０５をチェックしており、これが０→１に変化した場合、新規のイベント送信データ有としてイベント送信データ本体３０６をネットワーク３上に送信する。ネットワーク３上に送信後、イベント送信データ更新フラグ３０５を１→０に戻す。
【００３０】
伝送ドライバ１１は、定周期で共有メモリ８の送信データエリア１２上のイベント送信データ更新フラグをバッファエリア７の送信データエリア９上のイベント送信データ更新フラグ３０３に書き戻している。このため、ネットワーク3上にイベント送信データ送信後は、イベント送信データ更新フラグ３０３は、１→０に書き換わり、次のイベント送信が可能となる。
【００３１】
これにより、ネットワーク３上に、イベント送信する送信データについて、イベント送信用ＡＰＩ３０１により新規に送信された場合のみ、伝送ドライバ１１がバッファエリア７から共有メモリ８に送信データを書き込むので、伝送ドライバ１１の処理が軽減される。
【００３２】
また、バッファエリア７及び共有メモリ８を、伝送ドライバ１１がイベント送信データを読み書きするためにロックする時間が短くなり、イベント送信用ＡＰＩ３０１及び伝送ファームウェア１４の処理を停滞させる確率を削減することが可能となる。
【００３３】
また、イベント送信がネットワーク３上に確実に行われてから、次のイベント送信をイベント送信用ＡＰＩ３０１にて可能となるので、未送信のイベント送信データが上書きされずに、イベント送信を取りこぼし無く、確実に実施可能となる。また、制御データの様に、起動時に１回ネットワーク３に対して送信する様なデータについても、本イベントデータ送信の手順にて可能となる。
【００３４】
図５では、ネットワーク３からイベント受信データがあると、伝送ファームウェア１４が共有メモリ８の受信データエリア１３上のイベント受信データ本体３１２として書き込み、イベント受信データ更新フラグ３１１を０→１に設定する。
【００３５】
伝送ドライバ１１は、定周期でイベント受信データ更新フラグ３１１をチェックしており、これが０→１に変化した場合、新規のイベント受信データ有として、イベント受信データ本体３１２をバッファエリア７上の受信データエリア１０にイベント受信データ本体３０９として書き込むと共に、イベント受信データ更新フラグ３１１をイベント受信データ更新フラグ３０８として書き込み、イベント受信データ更新フラグを３１１を１→０に戻す。
【００３６】
イベント受信用ＡＰＩ３０２は、ユーザアプリケーション６により、定周期で呼ばれており、イベント受信データ更新フラグ３０８をチェックし、ここが１ならばイベント受信データ有りとして、イベント受信データ本体３０９の内容を読み出し、ユーザアプリケーション６に渡し、イベント受信データ更新フラグ３０８を０とする。
【００３７】
これにより、ネットワーク３から、イベント受信する受信データについて、新規にイベント受信された場合のみ、伝送ドライバ１１が共有メモリ８からバッファエリア７に読み込むので、伝送ドライバ１１の処理が軽減される。
【００３８】
また、バッファエリア７及び共有メモリ８を、伝送ドライバ１１がイベント受信データを読み書きするためにロックする時間が短くなり、イベント受信用ＡＰＩ３０２及び伝送ファームウェア１４の処理を停滞させる確率を削減することが可能となる。また、イベント送信用ＡＰＩは、新規のイベント受信があった場合のみ、ユーザアプリケーション６に受信データを渡すことが可能となる。
【００３９】
第３の実施の形態によれば、ネットワーク３上にイベント送信する送信データについて、イベント送信用ＡＰＩ３０１により新規に送信された場合のみ、伝送ドライバ１１がバッファエリア７から共有メモリ８に送信データを書き込むので、伝送ドライバ１１の処理が軽減されるとともに、逆にネットワーク３からイベント受信する受信データについて、新規にイベント受信された場合のみ、伝送ドライバ１１が共有メモリ８からバッファエリア７に読み込むので、伝送ドライバ１１の処理が軽減される。
【００４０】
（第４の実施の形態）
図６は本発明の第４の実施の形態に係わるデータ伝送装置の構成図である。この第４の実施の形態は、図４及び図５に示した第３の実施の形態に対し、ＣＰＵ基板１上に複数のＯＳが実装され、複数のＯＳ上のユーザアプリケーションからデータ送受信が行えるように、各々の送信・受信用ＡＰＩ間のデータ変換用ソフトウェアを備えたものである。図１乃至図５と同一要素には同一符号を付し重複する説明は省略する。
【００４１】
ＯＳ−Ａ５上のＯＳ−Ａ送信用ＡＰＩ４０１は、サイクリック送信用ＡＰＩ２０１及びイベント送信用ＡＰＩ３０１の総称とする。また、ＯＳ−Ａ受信用ＡＰＩ４０２は、サイクリック受信用ＡＰＩ２０２及びイベント受信用ＡＰＩ３０２の総称とする。
【００４２】
ＯＳ−Ｂ４１５上のＯＳ−Ｂユーザアプリケーション４１６は、ＯＳ−Ｂ送信用ＡＰＩ４０３にて送信データを送信要求し、ＯＳ−Ｂ受信用ＡＰＩ４０４にて受信データを受信する。ＯＳ−Ｂ送信用ＡＰＩ４０３及びＯＳ−Ｂ受信用ＡＰＩ４０４は、ＯＳ−Ｂユーザアプリケーション４１６から呼ばれると、要求用メールボックス４０６に、ＡＰＩの種別(例えば、サイクリック送信・サイクリック受信・イベント送信・イベント受信)・要求時刻・ＡＰＩの引数の情報(要求情報)を渡す。
【００４３】
また、ＯＳ−Ｂ送信用ＡＰＩ４０３は、送信用共有メモリ４１３に要求時刻情報を付加した送信データ本体を書き込む。ここでは、要求情報の様な少量のデータはメールボックスで渡し、送受信データの様な大量のデータは共有メモリ渡しとしている。
【００４４】
変換サービス４０５の要求データ読み込み処理４１７は、要求用メールボックス４０６の内容を読み、ＡＰＩ種別情報に基づき、送信用メールボックス４０７または受信用メールボックス４０８に要求情報を渡す。
【００４５】
送信用スレッド４０９または受信用スレッド４１０は、それぞれ送信用メールボックス４０７または受信用メールボックス４０８から要求データを読み込み、ＡＰＩ種別に基づき、当該ＯＳ−Ａ送信用ＡＰＩ４０１またはＯＳ−Ａ受信用ＡＰＩ４０２を呼んで引数を渡す。また、送信用スレッド４０９は、送信用共有メモリ４１３から、送信データ本体を読み込み、ＯＳ−Ａ送信用ＡＰＩ４０１に、引数のポインタで渡す。その際、送信用メールボックス４０７の要求情報と一致する送信データ本体であることを、要求時刻情報にて確認する。これにより、ＯＳ−Ａ送信用ＡＰＩ４０１にてネットワーク３上への送信が可能となる。
【００４６】
ＯＳ−Ａ送信用ＡＰＩ４０１のレスポンス情報(出力引数)は、送信用スレッド４０９が受け取り、ＡＰＩの種別・要求時刻を付加して、送信用ＡＰＩ応答用メールボックス４１１に渡す。ＯＳ−Ｂ送信用ＡＰＩ４０３では、送信用ＡＰＩ応答用メールボックス４１１から、ＡＰＩ種別・要求時刻を確認し、要求に基づくレスポンス情報を受け取る。
【００４７】
ＯＳ−Ａ受信用ＡＰＩ４０２で受信したデータは受信用スレッド４１０にて受信され、要求時刻情報を付加して受信用共有メモリ４１４に書き込まれる。ＯＳ−Ａ受信用ＡＰＩ４０２のレスポンス情報(出力引数)は、受信用スレッド４１０が受け取り、ＡＰＩの種別・要求時刻情報を付加して、受信用ＡＰＩ応答用メールボックス４１２に渡す。ＯＳ−Ｂ受信用ＡＰＩ４０４では、受信用ＡＰＩ応答用メールボックス４１２からＡＰＩ種別・要求時刻を確認し、要求に基づくレスポンス情報を受け取る。また、ＯＳ−Ａ受信用ＡＰＩ４０２は、受信用共有メモリ４１４から、要求時刻と一致していることを確認して、受信データを読み込む。これにより、ＯＳ−Ｂ受信用ＡＰＩ４０４にて、ネットワーク３上からの受信が可能となる。
【００４８】
第４の実施の形態によれば、ＣＰＵ基板１の主メモリ４上に、複数のＯＳが存在し、各々のＯＳ用のユーザアプリケーションが動作している場合でも、異なったＯＳ上のＡＰＩから、ネットワーク３上へのデータ送受信が可能となる。
【００４９】
（第５の実施の形態）
図７は本発明の第５の実施の形態に係わるデータ伝送装置のサイクリック送信用ＡＰＩの処理内容の説明図であり、図７（ａ）は送信データエリア９におけるサイクリック送信データ本体２０４の送信データ及び送信データサイズの説明図、図７（ｂ）はハードディスク１５の送信データ上下限値の説明図である。この第５の実施の形態は、第４の実施の形態に対し、サイクリック送信用ＡＰＩまたはイベント送信用ＡＰＩは、バッファエリアに送信データを設定する前に送信データの整合性をチェックし、チェック結果をレスポンスとしてユーザアプリケーションに返すようにしたものである。
【００５０】
ユーザアプリケーション６にて、サイクリック送信用ＡＰＩ２０１を呼ぶ際、引数のポインタにて設定するサイクリック送信データ本体２０４に、送信データサイズ５０１を付加し、送信データ本体５０２のバイト数をここに記載する。図７の一例では、送信データ本体５０２が１０２４バイトの場合、送信データサイズ５０１には「0x400」が記載されるのが正しい。
【００５１】
サイクリック送信用ＡＰＩ２０１では、送信データサイズ５０１に記載のバイト数が送信データ本体５０２のバイト数と一致しているか確認し、不一致ならばユーザアプリケーション６にＡＰＩのレスポンス情報(引数)として、送信データサイズ５０１の値と送信データ本体５０２のバイトとが異なる旨のエラーを返す。一致していれば、次のチェック処理を行う。
【００５２】
次に、サイクリック送信用ＡＰＩ２０１は、ハードディスク１５上からサイクリック送信データの上限値５０３と下限値５０４とを読み込み、これと送信データ本体５０２を比較して、範囲内ならばバッファエリア７上にサイクリック送信データ本体２０４として書き込む。範囲外ならば、その旨のレスポンス情報をユーザアプリケーション６に返す。以上の処理はイベント送信用ＡＰＩ３０１や図６に示したＯＳ−Ｂ上のＯＳ−Ｂ送信用ＡＰＩ４０３についても同様に適用可能である。
【００５３】
第５の実施の形態の実施の形態によれば、バッファエリア７及び共有メモリ８に、送信データを書き込む前に、送信データの整合性をチェックすることが可能となり、実際の送信データが欠落や異常データ付加等により、ユーザアプリケーション６の意図するものと異なる場合のチェックが可能となる。また、送信データの上限値５０３と比較することで、バッファエリア７、共有メモリ８を破壊することが無くなり、メモリ破壊によるＣＰＵ基板１やネットワーク伝送制御基板２の動作異常を防止することが可能となる。
【００５４】
（第６の実施の形態）
図８は本発明の第６の実施の形態に係わるデータ伝送装置のサイクリック受信用ＡＰＩの処理内容の説明図であり、図８（ａ）は受信データエリア９におけるサイクリック受信データ３０７（３１０）の送信データ及び受信データサイズの説明図、図８（ｂ）はハードディスク１５の受信データ上下限値の説明図である。この第６の実施の形態は、第４の実施の形態に対し、サイクリック受信用ＡＰＩまたはイベント受信用ＡＰＩは、バッファエリアからユーザアプリケーションに受信データを渡す前にデータの整合性をチェックし、チェック結果をレスポンスとしてユーザアプリケーションに返すようにしたものである。
【００５５】
伝送ファームウェア１４により、ネットワーク３からのサイクリック受信データを共有メモリ８上にサイクリック受信データ３１０として書き込む際、受信データサイズ６０１を付加し、受信データ本体６０２のバイト数をここに記載する。図８の一例では、受信データ本体６０２が１０２４バイトの場合、受信データサイズ６０１には「0x400」が記載されるのが正しい。
【００５６】
伝送ドライバ１１により、サイクリック受信データ３１０の内容がバッファエリア７上のサイクリック受信データ３０７としてコピーされる。サイクリック受信用ＡＰＩ２０２では、受信データサイズ６０１に記載のバイト数が受信データ本体６０２のバイト数と一致しているか確認し、不一致ならば、ユーザアプリケーション６に、ＡＰＩのレスポンス情報(引数)として、受信データサイズ６０１の値と、受信データ本体６０２のバイトが異なる旨のエラーを返す。一致していれば次のチェック処理を行う。
【００５７】
次に、サイクリック受信用ＡＰＩ２０２は、ハードディスク１５上から、サイクリック受信データの上限値６０３と下限値６０４とを読み込み、これと受信データ本体６０２とを比較して、範囲内ならば、ユーザアプリケーション６に、サイクリック受信データとして渡す。範囲外ならば、その旨のレスポンス情報をユーザアプリケーション６に返す。以上の処理はイベント受信用ＡＰＩ３０２や図６に示したＯＳ−Ｂ上の送信用ＡＰＩ４０４でも可能である。
【００５８】
第６の実施の形態によれば、受信用ＡＰＩからユーザアプリケーション６へ受信データを渡す前に、受信データの整合性をチェックすることが可能となり、実際の受信データがネットワーク上、あるいはＣＰＵ基板１、あるいはネットワーク伝送制御基板２内の処理で欠落や異常データ付加等により、異常になっている場合のチェックが可能となる。
【００５９】
（第７の実施の形態）
図９は本発明の第７の実施の形態に係わるデータ伝送装置の送信・受信用ＡＰＩの処理内容の説明図である。この第７の実施の形態は、図４及び図５に示した第３の実施の形態に対し、サイクリック送信用セマフォ７０１、イベント送信用セマフォ７０２、サイクリック受信用セマフォ７０３、イベント受信用セマフォ７０４を追加して設けたものである。これらセマフォは、並行して動作しているプロセス間で同期を取ったり割り込み処理の制御を行うものであり、例えば、複数のプロセスでメモリ領域やディスク上のファイルを共有している場合に、同時にアクセスして内容の破壊や不整合が起きるのを防ぐために使われるものである。
【００６０】
例えば、ユーザアプリケーション６がサイクリック送信用ＡＰＩ２０１を呼んだ場合、サイクリック送信用ＡＰＩ２０１は、サイクリック送信用セマフォ７０１を取得する。サイクリック送信が終了するか、エラーレスポンスが返り、サイクリック送信ＡＰＩ２０１の処理が完了するまで、サイクリック送信用セマフォ７０１は占有される。サイクリック送信ＡＰＩ２０１の処理が完了する前に、ユーザアプリケーション６から、再度サイクリック送信ＡＰＩ２０１が呼ばれた場合は、サイクリック送信用セマフォ７０１が占有されているため、これを本ＡＰＩが検知して、ビジーレスポンスをユーザアプリケーション６へ返す。
【００６１】
イベント送信用セマフォ７０２、サイクリック受信用セマフォ７０３、イベント受信用セマフォ７０４についても同様に、イベント送信用セマフォ７０２はイベント送信用ＡＰＩ３０１に設けられ、サイクリック受信用セマフォ７０３はサイクリック受信用ＡＰＩ２０２に設けられ、イベント受信用セマフォ７０４はイベント受信用ＡＰＩ３０２に設けられる。このように、各ＡＰＩ種類毎に１つずつセマフォを設定し、同種類のＡＰＩは同時には１回のみ使用されることを許可する。
【００６２】
第７の実施の形態によれば、前回のＡＰＩ処理が完了する前に再度同種類のＡＰＩ処理が行われることが無くなり、ユーザアプリケーション６側の送受信処理の順番と実際のデータ送受信処理の順番とが入れ替わった、送受信データ抜けが防止可能となる。データ送信時には、送信データエリア９の内容を、伝送ドライバ１１が送信データエリア１２にコピーする前に、他の送信ＡＰＩにより上書きされる懸念が無くなり、送信データの抜けが無くなる。また、ＡＰＩ重複時に、ビジーレスポンスを即時に返すことにより、ＣＰＵ基板１のＣＰＵの処理負荷を下げることが可能となる。
【００６３】
（第８の実施の形態）
図１０は本発明の第８の実施の形態に係わるデータ伝送装置の受信データエリアの説明図である。この第８の実施の形態は、図４及び図５に示した第３の実施の形態に対し、エラー情報８０１、８０２、エラーログ８０４を設け、ネットワーク伝送制御基板がネットワーク伝送上の異常を検出した場合は、これを共有メモリ上に記録し、伝送ドライバがこれを取得して送信・受信用ＡＰＩ経由で、ユーザアプリケーションに対してネットワーク異常情報を返すようにしたものである。
【００６４】
伝送ファームウェア１４は、ネットワーク３から受信したネットワーク上若しくは送信先装置の故障情報等のエラー情報を共有メモリ８上の受信データエリア１３上に、エラー情報８０２としてエラー収集時に記録する。図１１はエラー情報のフォーマットの一例の説明図であり、伝送ファームウェア１４は、新規エラー収集時にエラー発生フラグ８０５を０→１にし、エラー内容に従って、エラーＩＤ８０６、エラー詳細情報８０７を記録する。エラー発生フラグ８０５が１の場合は、最新のエラー情報にて上書きする。
【００６５】
伝送ドライバ１１は、エラー情報８０２のエラー発生フラグ８０５が１ならば、新規エラー有として、エラー情報８０２の内容をバッファエリア７上の受信データエリア１０上にエラー情報８０１として書き込む。書込み後、伝送ドライバ１１は、エラー情報８０２のエラー発生フラグ８０５を１→０に戻す。また、伝送ドライバ１１は、新規エラーがある場合は、主メモリ４上のエラーログ８０４にエラー情報を追記する。
【００６６】
図１２はエラーログ８０４のフォーマットの一例を示す説明図であり、エラー情報総数は、エラーログ８０４に記録されたエラー情報総数であり、例えば、１０２４(400h)を上限とする。上限を超えた場合、新規エラー情報は循環して上書き記録されることとし、エラー情報総数は１０２４のままとなる。最新エラー情報インデクス８０９は、上から何番目のエラー情報が最新かを示し、例えば、２５６(100h)ならば、１から初めて２５６番目の内容が現状最新である事を示す。エラー総数が最大値で一巡している場合、２５７番目が最も古いエラー情報である。
【００６７】
発生時刻８１０は、伝送ドライバ１１がエラー情報８０２を読み込んだ時の時刻を記録したエラー発生時刻、エラーＩＤ８１１は、エラーＩＤ８０６と同じ、エラー詳細情報８１２は、エラー詳細情報８０７と同じであり、８１０〜８１２が一つのエラー情報を構成している。
【００６８】
サイクリック受信ＡＰＩ２０２は、定周期で、エラー情報８０１のエラー発生フラグ８０５を確認し、これが１ならば新規エラー情報ありとして、エラーＩＤ８０６、エラー詳細情報８０７をエラー情報８０１から読み込み、ユーザアプリケーション６に渡す。その後、エラー情報８０１のエラーＩＤ８０６を１→０に戻す。
【００６９】
また、伝送関係でエラー情報があることのみ知らせたい場合は、サイクリック受信ＡＰＩのレスポンス(出力引数)として、例えばエラーＩＤ８０６のみユーザアプリケーション６へ返すことも可能である。エラーログ受信用ＡＰＩ８０３は、エラーログ８０４の内容を読み込み、ユーザアプリケーション６へポインタ情報にて渡す。
【００７０】
第８の実施の形態によれば、サイクリック受信ＡＰＩ２０２にて、サイクリック受信データと同時にネットワーク３上の最新のエラー情報を取得可能となり、ユーザアプリケーション６側で、ネットワークの最新のエラー状況を随時把握可能となる。また、エラー発生時は、サイクリック受信ＡＰＩ２０２のレスポンス用引数にて把握可能となる。また、エラー発生時のみ、伝送ドライバ１１及びサイクリック受信ＡＰＩ２０２は、最新のデータを取得するので、ＣＰＵ基板１の処理負荷が低減可能となり、処理効率が向上する。
【００７１】
また、エラーログ受信用ＡＰＩにて、エラーの履歴を取得可能となり、エラー解析・原因究明が容易に行えるようになる。
【００７２】
（第９の実施の形態）
図１３は本発明の第９の実施の形態に係わるデータ伝送装置の異常検出処理部分の構成図である。この第９の実施の形態は、図１０乃至図１２に示した第８の実施の形態に対し、伝送ドライバが検出した異常について、ＯＳのイベントログに記録すると共に、伝送ドライバが検出した異常について別ファイルとして記録するようにしたものである。
【００７３】
本発明の第９の実施の形態では、第８の実施の形態にて伝送ドライバ１１が共有メモリ８上から取得したエラー情報をＯＳのイベントログファイル９０１にイベントログ形式に編集して記録する。また、伝送ドライバ１１は、エラー情報をハードディスク１５上のエラーログファイル９０２に記録する。そのフォーマットは、一例として、図１２に示した、主メモリ４上のエラーログ８０４と同じ型式とする。
【００７４】
第９の実施の形態によれば、ネットワーク３上の最新のエラー情報をＯＳのイベントログファイル９０１に記録して、ユーザが容易に参照可能となり、エラー発生時の原因究明が容易に可能となる。また、エラー情報履歴をハードディスク１５上のエラーログファイル９０２として記録するため、ＣＰＵ基板１を停止し再起動した後でも、エラー発生時の原因究明が容易に可能となる。
【００７５】
（第１０の実施の形態）
図１４は本発明の第１０の実施の形態に係わるデータ伝送装置の異常検出処理部分の構成図である。この第１０の実施の形態は、図１３に示した第９の実施の形態に対し、伝送ドライバが検出した異常について、メモリ上に書き出し、ファイルへの異常情報書込みを伝送ドライバの空き時間に処理するようにしたものである。
【００７６】
伝送ドライバ１１は、共有メモリ８上から取得したエラー情報を主メモリ４上のエラーログ８０４に出力すると共に、エラー通知用メールボックス１００２にエラー発生を通知する。エラーログプロセス１００１は、伝送ドライバ１１の起動時にエラー通知用メールボックス１００２を介して伝送ドライバ１１により起動されるものとする。エラーログプロセス１００１は、エラーログ８０４から最新のエラー情報を取得し、イベントログファイル９０１、エラーログファイル９０２に記録する。
【００７７】
伝送ドライバ１１からエラーログプロセス１００１へのエラー情報発生の通知を、複数のエラー情報をまとめて通知する場合は、エラーログプロセス１００１が、前回ファイルに記録したエラー情報の発生時刻８１０、エラーＩＤ８１１を記憶しておき、それ以降のエラー情報を、エラーログ８０４から読み出すことで可能となる。
【００７８】
第１０の実施の形態によれば、イベントログファイル９０１及びエラーログファイル９０２へエラー情報を記録する処理をエラーログプロセス１００１が実施することで、伝送ドライバ１１の処理を軽減し、伝送ドライバ１１の処理が、ファイル書込み処理で停滞することを回避可能となる。
【００７９】
（第１１の実施の形態）
図１５は本発明の第１１の実施の形態に係わるデータ伝送装置の異常検出処理部分の構成図である。この第１１の実施の形態は、第２の実施の形態や第３の実施の形態対に対し、ユーザアプリケーションがデータ送受信ＡＰＩを使用する周期を変更すると、伝送ドライバがＣＰＵ基板上のバッファエリアからネットワーク伝送制御基板上の共有メモリへ、送受信データを読み書きする周期を自動的に変更するようにしたものである。
【００８０】
ユーザアプリケーション６は、サイクリック送信用ＡＰＩ２０１及びサイクリック受信用ＡＰＩ２０２を定周期で呼びデータ送受信を行っている。この送信・受信ＡＰＩを呼ぶ周期をサイクリック送受信周期通知メールボックス１１０１に書き込み、伝送ドライバ１１へ通知する。サイクリック送信用ＡＰＩ２０１とサイクリック受信用ＡＰＩ２０２とを呼ぶ周期が異なる場合は、送信ＡＰＩ使用周期・受信ＡＰＩ使用周期の両方を通知する。通知タイミングは、ユーザアプリケーション６起動時(初回)及び、サイクリック送信用ＡＰＩ２０１またはサイクリック受信用ＡＰＩ２０２の使用周期を変更したときとする。
【００８１】
伝送ドライバ１１は、送信ＡＰＩまたは受信ＡＰＩの使用周期が変更されると、その短い方の周期を基にして、伝送ドライバ１１がバッファエリア７と共有メモリ８上の送受信データを読み書きする周期を、例えば、ＡＰＩ使用周期の１／２の周期に設定する。ここで伝送ドライバ１１の動作周期を、送受信ＡＰＩの使用周期の１／２等の幾つ(１倍以下)とするかは、伝送ドライバ１１の開発時に決定するものとする。
【００８２】
第１１の実施の形態によれば、送受信ＡＰＩの使用周期が変更となった場合、伝送ドライバ１１は、その使用周期に見合った動作周期で動作可能となり、送受信ＡＰＩからの送受信データを漏れなく共有メモリ８上に読み書きし、ネットワーク３上に伝送することが可能となる。
【図面の簡単な説明】
【００８３】
【図１】本発明の第１の実施の形態に係わるデータ伝送装置の構成図。
【図２】本発明の第２の実施形態に係わるデータ伝送装置の構成図。
【図３】本発明の第２の実施の形態に係わるデータ伝送装置の送信データエリアの説明図。
【図４】本発明の第３の実施の形態に係わるデータ伝送装置の送信データエリアの説明図。
【図５】本発明の第３の実施の形態に係わるデータ伝送装置の受信データエリアの説明図。
【図６】本発明の第４の実施の形態に係わるデータ伝送装置の構成図。
【図７】本発明の第５の実施の形態に係わるデータ伝送装置のサイクリック送信用ＡＰＩの処理内容の説明図。
【図８】本発明の第６の実施の形態に係わるデータ伝送装置のサイクリック受信用ＡＰＩの処理内容の説明図。
【図９】本発明の第７の実施の形態に係わるデータ伝送装置の送信・受信用ＡＰＩの処理内容の説明図。
【図１０】本発明の第８の実施の形態に係わるデータ伝送装置の受信データエリアの説明図。
【図１１】本発明の第８の実施の形態におけるエラー情報のフォーマットの一例の説明図。
【図１２】本発明の第８の実施の形態におけるエラーログのフォーマットの一例を示す説明図。
【図１３】本発明の第９の実施の形態に係わるデータ伝送装置の異常検出処理部分の構成図。
【図１４】本発明の第１０の実施の形態に係わるデータ伝送装置の異常検出処理部分の構成図。
【図１５】本発明の第１１の実施の形態に係わるデータ伝送装置の異常検出処理部分の構成図。
【符号の説明】
【００８４】
１…ＣＰＵ基板、２…ネットワーク伝送制御基板、３…ネットワーク、４…主メモリ、５…ＯＳ−Ａ、６…ユーザアプリケーション、７…バッファエリア、８…共有メモリ、９…送信データエリア、１０…受信データエリア、１１…伝送ドライバ、１２…送信データエリア、１３…受信データエリア、１４…伝送ファームウェア、１５…ハードディスク、２０１…サイクリック送信用ＡＰＩ、２０２…サイクリック受信用ＡＰＩ、２０３…サイクリック送信データ更新フラグ、２０４…サイクリック送信データ本体、２０５…サイクリック送信データ本体、３０１…イベント送信用ＡＰＩ、３０２…イベント受信用ＡＰＩ、３０３…イベント送信データ更新フラグ、３０４…イベント送信データ本体、３０５…イベント送信データ更新フラグ、３０６…イベント送信データ本体、３０７…サイクリック受信データ、３０８…イベント受信データ更新フラグ、３０９…イベント受信データ本体、３１０…サイクリック受信データ、３１１…イベント受信データ更新フラグ、３１２…イベント受信データ本体、４０１…ＯＳ−Ａ送信用ＡＰＩ、４０２…ＯＳ−Ａ受信用ＡＰＩ、４０３…ＯＳ−Ｂ送信用ＡＰＩ、４０４…ＯＳ−Ｂ受信用ＡＰＩ、４０５…変換サービス、４０６…要求用メールボックス、４０７…送信用メールボックス、４０８…受信用メールボックス、４０９…送信用スレッド、４１０…受信用スレッド、４１１…送信用ＡＰＩ応答用メールボックス、４１２…受信用ＡＰＩ応答用メールボックス、４１３…送信用共有メモリ、４１４…受信用共有メモリ、４１５…ＯＳ−Ｂ、４１６…ＯＳ−Ｂユーザアプリケーション、４１７…要求データ読み込み処理、５０１…送信データサイズ、５０２…送信データ本体、５０３…送信データ上限値、５０４…送信データ下限値、６０１…受信データサイズ、６０２…受信データ本体、６０３…受信データ上限値、６０４…受信データ下限値、７０１…サイクリック送信用セマフォ、７０２…イベント送信用セマフォ、７０３…サイクリック受信用セマフォ、７０４…イベント受信用セマフォ、８０１…エラー情報、８０２…エラー情報、８０３…エラーログ受信用ＡＰＩ、８０４…エラーログ、８０５…エラー発生フラグ、８０６…エラーＩＤ、８０７…エラー詳細情報、８０８…エラー情報総数、８０９…最新エラー情報インデクス、８１０…発生時刻、８１１…エラ
ーＩＤ、８１２…エラー詳細情報、９０１…イベントログファイル、９０２…エラーログファイル、１００１…エラーログプロセス、１００２…エラー通知用メールボックス、１１０１…サイクリック送受信周期通知メールボックス
【図１】
2009141668.tif 000003
【図２】
2009141668.tif 000004
【図３】
2009141668.tif 000005
【図４】
2009141668.tif 000006
【図５】
2009141668.tif 000007
【図６】
2009141668.tif 000008
【図７】
2009141668.tif 000009
【図８】
2009141668.tif 000010
【図９】
2009141668.tif 000011
【図１０】
2009141668.tif 000012
【図１１】
2009141668.tif 000013
【図１２】
2009141668.tif 000014
【図１３】
2009141668.tif 000015
【図１４】
2009141668.tif 000016
【図１５】
2009141668.tif 000017