JP6711339B2 - 通信処理装置、プログラム、および通信処理方法 - Google Patents

Description

本発明は、通信処理装置、プログラム、および通信処理方法に関する。

プロセス制御システム等においては、通信のリアルタイム性が特に求められる。イーサネットやＩＰ（インターネットプロトコル）といった標準的な通信技術を用いつつ、その上でリアルタイムな通信を行う仕組みが、従来技術として構築されている。
非特許文献１に記載の技術では、リアルタイム性の実現のために、送信局ごとに時間スロットを割り当てるなどといった工夫をしてパケット損失を防いでいる。また、非特許文献１に記載の技術では、オープンな標準プロトコルを採用して、マルチベンダー機器によるネットワーク構成を可能としている（非特許文献１の図４等を参照）。

出町公二，外３名，「リアルタイム・プラント・ネットワーク・システム Ｖｎｅｔ／ＩＰ」，横河技報，Ｖｏｌ．４９，Ｎｏ．２，２００５年

プラント制御等の目的で構成するネットワークシステムにおいて、そのネットワークに属する機器を、より汎用的な製品を用いて実現したいという要求がある。リアルタイム性を確保しつつ、機器に汎用製品を組み込むことで、機器の低コスト化および供給の安定化を期待することができる。そういった要素の一つがＯＳ（オペレーティングシステム）である。例えば、リアルタイム通信を行う通信処理装置としてコンピューターを用い、そのコンピューター上で稼働する機能（プログラム）をコントロールするために汎用ＯＳを使うことが考えられる。ここで、リアルタイム性とは、システムにおいて、所定の処理等が設定時間内に完了すること、および当該処理等が設定時間内に完了することを保証することである。より具体的には、リアルタイム性は、システム内部における処理が設定時間内に完了することや、システム外部からの応答が設定時間内に得られることを含む。また、リアルタイム性は、処理等が設定時間内に完了しない場合に、その事象を検知して当該処理等を強制的に完了させることを含んでもよい。

しかしながら、汎用ＯＳには、次のような問題があった。即ち、同時並行的に稼働する複数のプログラムに対してＣＰＵ時間を割り当てるＯＳのスケジューラーが、そのままでは、必ずしも目的とする通信処理装置に向いていないという問題である。より具体的には、例えばプラント制御のための処理を行う機能（便宜的に「アプリケーション」と呼ぶ）と、そのアプリケーションからの通信要求をリアルタイムに処理する機能（便宜的に「リアルタイム通信部」と呼ぶ）とをスケジューリングする際に、従来の汎用ＯＳのスケジューラーでは、適切な計算資源の配分を行えない場合がある。通信処理装置を上記のようにアプリケーション（複数のアプリケーションが１台の通信処理装置上で同時並行的に稼働することもある）とリアルタイム通信部とで構成するとき、スケジューリングにおいて、アプリケーションの優先度よりもリアルタイム通信部の優先度のほうを高く設定する。つまり、リアルタイム性を確保するためには、アプリケーションの処理できる能力を犠牲にしても、リアルタイム通信部には充分に計算資源が与えられることが望ましい。ところが、ある汎用ＯＳのスケジューラーは、高い優先度が与えられたタスクのＣＰＵ消費率がある所定の基準を超えたとき、相対的に低い優先度を与えられているタスクに計算資源を割り当てるために、高優先度のタスクに対して計算資源を与えなくなるというロジックで動作する。すると、充分な計算資源をもって処理を進めるべきリアルタイム通信部が充分に処理を行いきれず、結果として、その通信処理装置の処理のリアルタイム性が損なわれるという事象が発生し得る。

本発明は、上記の課題認識に基づいて行なわれたものである。即ち、本発明は、汎用ＯＳのスケジューラーを用いながら、プロセス制御システムにおけるアプリケーションからの通信要求をリアルタイムに処理するためのリアルタイム通信部に必要な計算資源を与えて、リアルタイム性を確保することのできる通信処理装置、プログラム、および通信処理方法を提供しようとするものである。

さらに、本発明は、リアルタイム通信部にアクセスするためにデバイスドライバを用いる必要がなく、ＣＰＵコアの固定的な割り当てなしで実現可能であり、仮想化部がプロプライエタリ・ソフトウェアの場合にも使用可能な通信機能を有する通信処理装置、プログラム、および通信処理方法を提供する。

［１］上記の課題を解決するため、本発明の一態様による通信処理装置は、アプリケーションソフトウェアを稼働させるアプリケーション部と、前記アプリケーションソフトウェアからの通信要求を受け、前記通信要求に基づいてデータの送受信を行うリアルタイム通信部と、を具備し、プロセス制御システムにおける通信処理を行う通信処理装置であって、前記リアルタイム通信部は、前記アプリケーションソフトウェアからの前記通信要求を少なくとも一時的に蓄積する要求バッファーと、前記通信要求がデータの送信要求である場合に、前記要求バッファーから前記送信要求を取り出して送信処理を行うリアルタイム通信部インターフェース部と、前記リアルタイム通信部の処理に関する診断指標を検知し、前記診断指標が所定範囲にある場合にはその動作状況を前記リアルタイム通信部インターフェース部に対して通知する自己診断部と、を具備し、前記リアルタイム通信部インターフェース部は、前記自己診断部から前記動作状況の通知を受けた場合には、前記要求バッファーから前記送信要求を取り出す時間間隔を調整する、ことを特徴とする。

［２］また、本発明の一態様は、上記の通信処理装置において、前記リアルタイム通信部インターフェース部は、前記自己診断部から前記動作状況の前記通知を所定時間継続して受けた場合には、前記通知を所定時間継続して受けない場合よりも前記要求バッファーから前記送信要求を取り出す前記時間間隔をさらに調整する、ことを特徴とする。

［３］また、本発明の一態様は、上記の通信処理装置において、前記アプリケーション部は、複数の前記アプリケーションソフトウェアを同時並行的に稼働させるものであり、各々の前記アプリケーションソフトウェアからの前記通信要求を、前記複数のアプリケーションソフトウェア間で共有される記憶部であるリアルタイム通信要求共有メモリーに一旦格納してから、前記リアルタイム通信要求共有メモリーから取り出した前記通信要求を前記リアルタイム通信部に渡す、ことを特徴とする。

［４］また、本発明の一態様は、上記の通信処理装置において、前記アプリケーション部から独立のタスクとして稼働し、前記アプリケーションソフトウェアからの前記通信要求を受け付け、受け付けた前記通信要求を当該タスク内の専用の記憶部であるリアルタイム通信要求タスク内メモリーに一旦格納してから、前記リアルタイム通信要求タスク内メモリーから取り出した前記通信要求を前記リアルタイム通信部に渡すアプリケーション代理部、をさらに具備することを特徴とする。

［５］また、本発明の一態様は、上記の通信処理装置において、前記リアルタイム通信部は、前記アプリケーション部から独立のタスクとして稼働する、ことを特徴とする。

［６］また、本発明の一態様は、上記の通信処理装置において、前記アプリケーション部と前記リアルタイム通信部とは、汎用オペレーティングシステム上で稼働するものであり、前記汎用オペレーティングシステム内のスケジューラーの制御によって中央処理装置資源を与えられる、ことを特徴とする。

［７］また、本発明の一態様は、上記の通信処理装置において、前記汎用オペレーティングシステムは、仮想化部を有するコンピューターの仮想ハードウェア上で稼働するものであり、複数の前記仮想ハードウェアが、前記仮想ハードウェアに対して個々に割り当てられる中央処理装置資源を共有しないよう構成した、ことを特徴とする。

［８］また、本発明の一態様は、コンピューターを、上記［１］から［７］までのいずれか一項に記載の通信処理装置として機能させるためのプログラムである。

［９］また、本発明の一態様は、プロセス制御システムにおける通信処理を行う通信処理装置において、アプリケーション部が、アプリケーションソフトウェアを稼働させ、リアルタイム通信部が、前記アプリケーションソフトウェアからの通信要求を受け、前記通信要求に基づいてデータの送受信を行い、前記リアルタイム通信部において、要求バッファーが、前記アプリケーションソフトウェアからの前記通信要求を少なくとも一時的に蓄積し、リアルタイム通信部インターフェース部が、前記通信要求がデータの送信要求である場合に、前記要求バッファーから前記送信要求を取り出して送信処理を行い、自己診断部が、前記リアルタイム通信部の処理に関する診断指標検知し、前記診断指標が所定範囲にある場合にはその動作状況を前記リアルタイム通信部インターフェース部に対して通知し、前記リアルタイム通信部インターフェース部は、前記自己診断部から前記動作状況の通知を受けた場合には、前記要求バッファーから前記送信要求を取り出す時間間隔を調整する、通信処理方法である。

本発明によれば、リアルタイム処理部の処理負荷が所定レベル以上に高まることはない。これにより、リアルタイム処理部には充分な計算資源が与えられる。したがって、優先的に処理されるべきリアルタイム処理部の処理は、滞ることがない。よって、通信処理装置のリアルタイム性が確保される。

本発明の第１実施形態による通信処理装置の概略機能構成を示すブロック図である。 同実施形態による通信処理装置の機能構成を別の側面から示すブロック図である。 同実施形態によるリアルタイム通信部インターフェースの処理手順を示すフローチャートである。 同実施形態によるリアルタイム通信部の処理手順を示すフローチャートである。 本発明の第２実施形態による通信処理装置の機能構成の一部を示す機能ブロック図である。 同実施形態により、ＰＣを仮想化し、複数の仮想ハードウェア上でそれぞれゲストＯＳを稼働させるための機能を中心として示した通信処理装置１全体のブロック図である。 本発明の第３実施形態による通信処理装置の一部の機能構成を示す機能ブロック図である。 同実施形態による通信処理装置の機能構成の一部を示す機能ブロック図である。

次に、図面を参照しながら、複数の実施形態について説明する。

［第１実施形態］
図１は、本実施形態による通信処理装置３の概略機能構成を示すブロック図である。本実施形態による通信処理装置３は、ＰＣ・３１上で構成される。ＰＣ・３１（ハードウェア）は、物理ＣＰＵ・３１０と、物理ＮＩＣ・３１２と、ＮＩＣインターフェース３１３とを含む。また、ＰＣ・３１は、メモリー等、不図示の他の構成要素を含む。ＰＣは、「パーソナルコンピューター」の略である。ＣＰＵは、「中央処理装置（Central Processing Unit）」である。ＮＩＣは、「ネットワークインターフェースカード」の略である。ＮＩＣは、単に「ネットワークカード」と呼ばれる場合もある。また、「インターフェース」は、「ＩＦ」と略記される場合がある。

ＰＣ・３１上では、汎用ＯＳ・３６が稼働する。ＯＳは、「オペレーティングシステム」の略である。汎用ＯＳ・３６を用いて通信処理装置３を構成することにより、通信処理装置３を低コスト化し、且つ安定的に供給することが可能となる。汎用ＯＳ・３６の一例としては、マイクロソフト社（Microsoft Corporation，米国）のＰＣ用ＯＳであるWindows（登録商標）系のＯＳを用いることができる。

物理ＣＰＵ・３１０は、メモリーにロードされたプログラムに含まれる命令を逐次フェッチして実行するものである。なお、物理ＣＰＵ・３１０は、複数のコアを含むものであってもよい。また、ＰＣ・３１が複数の物理ＣＰＵ・３１０を備える構成としてもよい。物理ＣＰＵ３１０のＣＰＵ時間がユーザー空間３８内の各機能に割り当てられる。
物理ＮＩＣ・３１２は、当該ＰＣ・３１内の各機能が外部のネットワークを介して通信するためのインターフェース機能を有するものである。
ＮＩＣインターフェース３１３は、ユーザー空間３８内で稼働する機能と、物理ＮＩＣ・３１２との間を仲介する機能を有するものである。

汎用ＯＳ・３６は、汎用ＯＳスケジューラー３７を含む。汎用ＯＳ・３６が管理するユーザー空間３８においては、種々の機能が同時並列的に稼働することができる。汎用ＯＳスケジューラー３７は、ユーザー空間３８内において稼働する各機能（タスク、プログラム）の優先度にしたがって、適宜、計算資源を割当て、それらの機能の稼働を管理する。ここで、計算資源とは、典型的にはＣＰＵ時間（ＣＰＵ資源，中央処理装置資源）である。また、計算資源として、ＣＰＵ時間以外のものを含んでもよい。計算資源は、例えば、割り当てられるメモリーや、入出力処理手段等を含む。汎用ＯＳスケジューラー３７はリアルタイムスケジューラーではない。なお、同図では１つのユーザー空間３８のみを示しているが、汎用ＯＳスケジューラー３７が複数のユーザー空間３８を管理するものであってもよい。

また、汎用ＯＳ・３６は、リアルタイム通信要求共有メモリー１９１を有する。
リアルタイム通信要求共有メモリー１９１は、ユーザー空間３８内で稼働するすべてのタスクからアクセス可能なメモリーである。後述するリアルタイム通信要求処理共有ライブラリ１９２が、アプリケーション部７０１からの通信要求等を一時的に記憶するバッファーは、このリアルタイム通信要求共有メモリー１９１内に設けられる。汎用ＯＳ・３６の機能として、タスク間で共有するためのメモリー空間を設けることができる。本実施形態では、リアルタイム通信要求共有メモリー１９１は、ユーザー空間の外に設けられているが、アプリケーション部７０１のメモリー空間内の所定の場所にマッピングされる。これにより、アプリケーション部７０１はリアルタイム通信要求共有メモリー１９１にもアクセスすることができる。

ユーザー空間３８は、リアルタイム通信部１８１と、アプリケーション部７０１−１，７０１−２，・・・の各機能を稼働させる環境である。アプリケーション部７０１は、リアルタイム通信要求処理共有ライブラリ１９２と、リアルタイム通信ＡＰＩ共有ライブラリ１９３（ＡＰＩは、「アプリケーションプログラミングインタフェース」の略）の機能を実行させる。リアルタイム通信要求処理共有ライブラリ１９２と、リアルタイム通信ＡＰＩ共有ライブラリ１９３との機能は、アプリケーションロジックに適宜連係される。ユーザー空間３８に含まれるアプリケーション部７０１、リアルタイム通信要求処理ライブラリ１９２、リアルタイム通信ＡＰＩ共有ライブラリ１９３、リアルタイム通信部１８１等は、プログラムやメモリーを用いて実現可能である。それらのプログラムは、汎用ＯＳスケジューラー３７によって適宜割り当てられるＣＰＵによって実行される。また、メモリーは、例えば半導体や磁気記録媒体などを用いて実現される。なお、ユーザー空間３８で実行される機能は必ずしもメモリーを持たない場合もあり得る。逆に、情報を記憶するのみであって実行する処理を持たない機能は、プログラムを持つ必要がない。
なお、アプリケーション部７０１−１，７０１−２，・・・を、単に「アプリケーション部７０１」と呼ぶ場合がある。

リアルタイム通信要求処理共有ライブラリ１９２は、デバイスドライバとしてカーネル空間に組み込まれるものではなく、ユーザー空間３８において稼働する。なお、リアルタイム通信要求処理共有ライブラリ１９２の機能（プログラム）は、アプリケーションソフトウェアのプログラムに静的にリンクされていてもよいし、リアルタイム通信要求処理共有ライブラリ１９２の機能が独立したタスクとして稼働してもよい。
リアルタイム通信要求処理共有ライブラリ１９２は、内部に、いずれも不図示の、リアルタイム通信要求受付ロジックと、リアルタイム通信送信ロジックと、リアルタイム通信受信ロジックの機能を備える。

リアルタイム通信要求処理共有ライブラリ１９２内のリアルタイム通信要求受付ロジックは、アプリケーション部７０１−１や７０１−２等の各々のアプリケーションロジックから、リアルタイム通信ＡＰＩ共有ライブラリ１９３経由で届くリアルタイム通信要求を受け付ける。そして、このリアルタイム通信要求受付ロジックは、受け付けた要求を集約し、要求（例えば送信要求）に付随する送信フレーム等を、送信要求の優先度に従って、バッファーに書き込む。このバッファーは、リアルタイム通信要求共有メモリー１９１内に存在する。このリアルタイム通信要求受付ロジックは、送信フレームをリアルタイム通信要求共有メモリー１９１内のバッファーに格納した場合には、リアルタイム通信要求処理共有ライブラリ１９２内のリアルタイム通信送信要求処理ロジックにその旨を通知する。

リアルタイム通信要求処理共有ライブラリ１９２内のリアルタイム通信送信ロジックは、上記のリアルタイム通信要求受付ロジックからの通知を受けると、リアルタイム通信要求共有メモリー１９１内のバッファーから送信フレームを取り出し、リアルタイム通信部１８１に渡す。具体的には、このリアルタイム通信送信ロジックは、リアルタイム通信部１８１内のリアルタイム通信部インターフェース１８２（リアルタイム通信部インターフェース）が有する要求バッファー１８８に送信フレームを書き込むことによって、送信を行う。なお、リアルタイム通信要求受付ロジックが要求を集約し、リアルタイム通信要求共有メモリー１９１内のバッファーに格納するのは、各アプリケーションの要求を要求内容や送信要求の優先度で整理した上で、リアルタイム通信部１８１に要求するためである。

リアルタイム通信要求処理共有ライブラリ１９２内のリアルタイム通信受信ロジックは、リアルタイム通信部１８１内のリアルタイム通信通知部１８３から受信通知を受けると、外部から受信されたフレームを受け取り、リアルタイム通信要求共有メモリー１９１内のバッファーに書き込む。また、このリアルタイム通信受信ロジックは、フレームを受信した旨を、リアルタイム通信要求受付ロジックに通知する。
リアルタイム通信要求受付ロジックは、リアルタイム通信受信ロジックからの上記の通知に基づき、リアルタイム通信要求共有メモリー１９１内のバッファーから受信フレームを取り出し、受信要求を発行していたアプリケーション部７０１にその受信フレームを返す。

なお、リアルタイム通信要求処理共有ライブラリ１９２とリアルタイム通信送信ロジックおよびリアルタイム通信受信処理ロジックは、従来技術における、マイクロソフト社のWindowsにおけるNetwork Driver Interface Specification （ＮＤＩＳ）に準拠するデバイスドライバで実現していた機能に相当する。従来技術におけるＮＤＩＳはカーネル空間で稼働するものであった。本実施形態におけるリアルタイム通信要求処理共有ライブラリ１９２の機能はユーザー空間で稼働する。

リアルタイム通信ＡＰＩ共有ライブラリ１９３は、アプリケーション部７０１がリアルタイム通信を行うためのＡＰＩを含む共有ライブラリである。アプリケーション部７０１がリアルタイム通信ＡＰＩ共有ライブラリ１９３の機能を静的にリンクして使用してもよい。また、アプリケーション部７０１の実行時にリアルタイム通信ＡＰＩ共有ライブラリ１９３の機能に動的にリンクするようにしてもよい。

アプリケーション部７０１−１，７０１−２等は、例えばプラントや機器の制御のための処理を行うものである。アプリケーション部７０１は、例えば、プラントの測定データの表示やプラントに対する操作が行えるＨＭＩ（ヒューマンマシンインターフェエース）や、プラントを制御するコントローラーの制御プログラムが作成されるＥＮＧ（エンジニアリングサーバー）や、ゲートウェイや、プラントの制御を行うコントローラーなどといったアプリケーションに関するソフトウェアを稼働させる。複数のアプリケーション部７０１が同時並行的に稼働してもよい。本実施形態では、アプリケーション部７０１は、通信要求を、複数のアプリケーション部７０１間で共有される記憶部であるリアルタイム通信要求共有メモリー１９１に一旦格納してから、そのリアルタイム通信要求共有メモリー１９１から取り出した通信要求をリアルタイム通信部１８１に渡す。ユーザー空間１８内で稼働するアプリケーションソフトウェアの数は任意である。アプリケーション部７０１がリアルタイム通信部１８１に対して行う要求は、論理的な通信路の確立又は解放や、フレーム（パケット等とも呼ぶ。データ送受信の論理的な単位である。）の送信あるいは受信等である。

リアルタイム通信部１８１は、アプリケーション部７０１等からの通信要求に基づいて、リアルタイムに通信を行う機能を有するものである。具体的には、リアルタイム通信部１８１は、アプリケーション部７０１等から通信要求を受け、その通信要求に基づいてデータの送受信を行う。リアルタイム通信部１８１が行う処理の性質上、コントローラー８０１やＰＣ・８０２とフレームの送受信等のタイミングを合わせる必要があり、リアルタイム性が要求される。ここで、リアルタイム性とは、リアルタイム通信部１８１がコントローラー８０１やＰＣ・８０２対して行った要求が所定の時間内に完結することである。また、仮に所定の時間内に要求が完結しない場合にも当該所定の時間内にリアルタイム通信部１８１にレスポンスが戻る（例えばエラー等が報告される）ことである。ここで「所定の時間」は、適用分野によって異なるが、例えば、数ミリ秒から数百ミリ秒までといった範囲内の時間である。なお、リアルタイム通信部１８１は、アプリケーション部７０１から独立のタスクとして稼働する。

これにより、リアルタイム通信部１８１が行う他機器への通信は、滞らず実行される。つまり、リアルタイム通信部１８１は、送信相手からの肯定応答（Ａｃｋ）を確実に受信できる。また、自機器（通信処理装置）の存在を他機器へ通知するための診断通信が滞らず実行される。診断通信が確実に行われることにより、自機器の存在は、他機器から正しく認識される。これにより、システム内で自機器の通信不具合による他機器への悪影響は発生しない。

アプリケーション部７０１およびリアルタイム通信部１８１には、ＰＣ・３１内の物理ＣＰＵ・３１０が割り当てられる。
なお、汎用ＯＳ・３６において、リアルタイム通信部１８１のタスクには、アプリケーション部７０１のタスクの優先度よりも高いタスク優先度を割り当てるようにする。つまり、汎用ＯＳスケジューラー１７が計算資源をリアルタイム通信部１８１に対して優先的に与えるため、リアルタイム通信部１８１は、同時並行的に稼働する他の機能部（例えば、アプリケーション部７０１）よりもより優先して実行される。
タスク優先度はリアルタイム通信部１８１に対して、アプリケーション部７０１よりも優先的に計算資源を割り当てるよう、汎用ＯＳスケジューラー１７に指示するための指標である。タスク優先度は一般的に優先順位を示す数値（値の高低でどちらを優先するのかは汎用ＯＳの実装による）であるが、数値に限らず、例えば、汎用ＯＳスケジューラーがより優先的に処理可能なスケジューリングアルゴリズムを指定してもよい。
なお、本実施形態で開示される優先度の設定方法は、これに限らず、他の設定方法であってもよい。

リアルタイム通信部１８１の内部の機能構成は次の通りである。リアルタイム通信部１８１は、リアルタイム通信部インターフェース１８２と、リアルタイム通信通知部１８３と、送信バッファー１８４と、自己診断部１８５と、自己診断指標記憶部１８６とを含んで構成される。なお、リアルタイム通信部インターフェース１８２は、その内部に、要求バッファー１８８を含んでいる。ここに列挙した各機能部の機能は、次の通りである。

リアルタイム通信部インターフェース１８２は、リアルタイム通信部１８１内において、アプリケーション部７０１からの要求を受け付けたり、その要求に対する応答をアプリケーション部７０１に返したりする機能を有する。リアルタイム通信部インターフェース１８２は、受け取った通信要求がデータの送信要求である場合に、要求バッファー１８８からその送信要求を取り出して送信処理を行う。また、リアルタイム通信部インターフェース１８２は、自己診断部１８５から動作状況の通知（不安定動作の通知）を受けた場合には、要求バッファー１８８から送信要求を取り出す時間間隔を調整する。具体的には、リアルタイム通信部インターフェース１８２は、不安定動作の通知を受けた場合には、当該通知を受けない場合よりも、要求バッファー１８８から送信要求を取り出すタイミングを遅くする。一例として、リアルタイム通信部インターフェース１８２は、送信要求を要求バッファー１８８から取り出す際に所定時間の待ち（ＷＡＩＴ）を行う。さらに、リアルタイム通信部インターフェース１８２は、自己診断部１８５から動作状況の通知を所定時間継続して受けた場合には、通知を所定時間継続して受けない場合よりも要求バッファー１８８から送信要求を取り出す時間間隔をさらに調整する。一例として、リアルタイム通信部インターフェース１８２は、要求バッファー１８８から送信要求を取り出す時間間隔をさらに調整する。具体的には、その通知を所定時間継続して受けた場合には、通知を所定時間継続して受けない場合よりも、上記の待ちの時間をさらに長くする。リアルタイム通信部インターフェース１８２は、リアルタイム通信ＡＰＩ共有ライブラリ１９３およびリアルタイム通信要求処理共有ライブラリ１９２を介して、アプリケーション部７０１との間のやり取りを行う。このようにリアルタイム通信部インターフェース１８２は、アプリケーション部７０１からの送信要求を受ける受け口である。そして、自己診断部１８５からリアルタイム通信部１８１において不安定動作が生じている旨の通知を受けると、リアルタイム通信部インターフェース１８２は、アプリケーション部７０１から届く送信フレームの処理を一時的に待たせる。つまり、リアルタイム通信部インターフェース１８２は、アプリケーション部７０１から要求バッファー１８８に入る送信要求が、送信バッファー１８４側に過大に流入しないよう制御する。つまり、要求バッファー１８８が大量に送信要求を受信しても、リアルタイム通信部インターフェース１８２は、その都度それらの送信要求を処理しない。これにより、リアルタイム通信部１８１の不安定動作が生じた状況においては、リアルタイム通信部インターフェース１８２はその不安定さを緩和させる作用を有する。

リアルタイム通信通知部１８３は、リアルタイム通信要求処理共有ライブラリ１９２に対して通知を行う。
具体的には、リアルタイム通信通知部１８３は、定周期の時間通知をリアルタイム通信要求処理共有ライブラリ１９２に対して行う。リアルタイム通信要求処理共有ライブラリ１９２内のリアルタイム通信送信要求処理ロジックは、時間通知ごとに起床し、フレームを送信する処理がタイムアウトしていないか確認する。フレームの送信処理のタイムアウトは、例えばリアルタイム通信部１８１が送信先の外部機器からの肯定応答が返送されない等で、リアルタイム通信要求処理共有ライブラリ１９２に対して受信通知を用いた送信完了通知を行わないまま予め定められた時間が経過したときに発生する事象である。リアルタイム通信通知部１８３が送信タイムアウトに関する時間通知を行うことにより、リアルタイム通信部インターフェース１８２に対してフレームの再送（アプリケーション層による再送）を指示できる。
また、リアルタイム通信通知部１８３は、外部機器から通信処理装置１に向けて送信されたフレームを受信すると、リアルタイム通信要求処理共有ライブラリ１９２内のリアルタイム通信要求受付ロジックおよびリアルタイム通信受信処理ロジックに受信通知を行う。これにより、リアルタイム通信要求処理共有ライブラリ１９２内のリアルタイム通信受信処理ロジックは、受信したフレームを取り出すことができる。

送信バッファー１８４は、送信すべきフレームのデータを少なくとも一時的に蓄積するバッファーである。リアルタイム通信部インターフェース１８２が、送信するフレームのデータをこの送信バッファー１８４に書き込む。送信バッファー１８４に書き込まれたフレームは、順次読み出され、外部機器に向けて送信される。なお、送信バッファー１８４は基本的にＦＩＦＯ（先入れ先出し）であるが、フレームの優先度等に基づいて処理順序の追い越しが発生してもよい。

自己診断部１８５は、リアルタイム通信部１８１に関するリアルタイム通信処理や状態の不安定動作を検出する。自己診断部１８５が不安定動作を検出すると、その旨をリアルタイム通信部インターフェース１８２に通知する。具体的には、自己診断部１８５は、リアルタイム通信処理や状態の不安定動作（例えば、ＣＰＵ使用率等の処理負荷や、応答時間遅れ等）を検知し、不安定動作をしていると認められる場合にはその動作状況（不安定動作）をリアルタイム通信部インターフェース１８２に対して通知する。具体的には、自己診断部１８５は、リアルタイム通信部１８１の処理に関する診断指標（ＣＰＵ使用率や処理応答時間等の指標値）を検知し、前記診断指標が所定範囲にある場合にはその動作状況を前記リアルタイム通信部インターフェース部に対して通知する。例えば、ＣＰＵ使用率が所定の閾値を超えている場合や、処理応答時間が所定の閾値を超えている場合に、自己診断部１８５は、不安定動作が生じていると判断して、リアルタイム通信部インターフェース１８２に対する通知を行う。自己診断部１８５は、不安定動作を検出するために、後述する自己診断指標記憶部１８６を参照する。自己診断部１８５は、例えば、（１）ＣＰＵ負荷（ＣＰＵ使用率）、（２）応答性（応答時間）、をモニタリングすることにより、リアルタイム通信部１８１の不安定動作を検知する。これらについて次に説明する。

（１）ＣＰＵ負荷： 自己診断部１８５は、リアルタイム通信部１８１のＣＰＵ使用率の数値を、汎用ＯＳ・３６から取得する。汎用ＯＳ・３６は、プログラムがＯＳ内のパフォーマンスデータを取得するためのインターフェースを設けており、そのパフォーマンスデータに、タスクごとのＣＰＵ使用率の数値が含まれる。自己診断部１８５は、リアルタイム通信部１８１のＣＰＵ使用率が予め設定された所定の閾値以上になったときに、その状況を不安定動作として検出する。
なお、自己診断部１８５は、他の指標に基づいて不安定動作を検出するようにしてもよい。例えば、自己診断部１８５が、汎用ＯＳ・３６全体のＣＰＵ使用率や、当該汎用ＯＳ・３６が稼働する仮想ハードウェア１５に割てられるＣＰＵコア数等の数値情報を取得してもよい。自己診断部１８５は、これらの数値を複数組み合わせて判定した結果が所定の閾値（例えば、ＣＰＵコアが４個の時はＣＰＵ使用率３０％、８個のときはＣＰＵ使用率１５％等）を超えたときに不安定動作が生じたことを検出する。

（２）応答性： 自己診断部１８５は、リアルタイム通信部１８１の応答性が低下したときに、不安定動作が生じたものとして検出する。具体的には、自己診断部１８５は、リアルタイム通信部１８１がフレームの送信を行ったときのリトライ発生回数の情報を取得する。送信のリトライは、リアルタイム通信部１８１が処理を待たされる場合に発生する。リトライが多発する場合には通信のリアルタイム性が阻害されていると考えることができる。したがって、自己診断部１８５は、１個のフレームに対するリトライ回数が所定の閾値を超えた場合、あるいは所定時間内におけるトータルの送信リトライ回数が所定の閾値を超えた場合、その状況が不安定動作であると判定する。

自己診断部１８５は、上に例示した指標以外の状況に基づいて、不安定動作を検出するようにしてもよい。なお、自己診断部１８５が不安定動作を検出する際の各種閾値（前述）は、下記の自己診断指標記憶部１８６に記憶させておくことができる。また、これらの閾値を、外部から設定可能としてもよい。

自己診断指標記憶部１８６は、自己診断部１８５が不安定動作を検出するための指標と、その閾値とのペアを、複数組記憶する。例えば、自己診断指標記憶部１８６は、リアルタイム通信部１８１のＣＰＵ使用率に関する閾値や、送信フレームのリトライ回数に関する閾値や、その他の閾値を記憶する。

要求バッファー１８８は、アプリケーション部７０１等からの通信要求を、少なくとも一時的に蓄積するバッファーである。リアルタイム通信要求処理共有ライブラリ１９２から渡される通信要求が、この要求バッファー１８８に書き込まれる。書き込まれる通信要求は、例えば、フレームの送信要求や受信要求などである。要求バッファー１８８に書き込まれたフレームは、リアルタイム通信部インターフェース１８２によって順次読み出され、処理される。なお、要求バッファー１８８は基本的にＦＩＦＯ（先入れ先出し）であるが、通信要求の優先度等に基づいて処理順序の追い越しが発生してもよい。

図２は、図１に示した通信処理装置３の機能構成を別の側面から示すブロック図である。
図２における汎用ＯＳ・３６は、図１に示した汎用ＯＳ・３６と同じものである。汎用ＯＳ・３６は、ユーザー空間３８とカーネル空間３９とを有している。ユーザー空間３８は、アプリケーション部７０１−１，７０１−２，・・・と、リアルタイム通信部１８１とを含む。アプリケーション部７０１−１，７０１−２，・・・と、リアルタイム通信部１８１とは、独立のタスクとしてユーザー空間３８内で稼働する。図示するように、リアルタイム通信要求処理共有ライブラリ１９２の機能とリアルタイム通信ＡＰＩ共有ライブラリ１９３の機能とは、本実施形態では、例えばライブラリ関数として、アプリケーション部７０１−１，７０１−２，・・・に組み込まれている。また、カーネル空間３９には、前述のリアルタイム通信要求共有メモリー１９１と、汎用ＯＳスケジューラー３７とを含む。

ＰＣ・３１（ハードウェア）は、前述の通り、物理ＣＰＵ・３１０と、物理ＮＩＣ・３１２と、ＮＩＣインターフェース３１３とを含む。
ＰＣ・３１は、物理ＮＩＣ・３１２を介して、制御ネットワーク８００に接続される。制御ネットワーク８００は、プロセス制御システムを構成する機器間で通信を行うためのネットワークである。制御ネットワーク８００には、コントローラー８０１や、ＰＣ・８０２などといった機器が接続される。ＰＣ・３１は、例えば、ＨＭＩで、制御ネットワーク８００を介して、コントローラー８０１やＰＣ・８０２との間で通信を行う。また、コントローラー８０１には、ＰＣ・３１に対して測定データを送るとともに、ＰＣ・３１からの操作量が入力される。そして、コントローラー８０１には、複数のフィールド機器８０３が接続される。コントローラー８０１は、フィールド機器８０３をコントロールすることにより、プラントの制御を行う。フィールド機器８０３は、例えば、流量計、温度計、湿度計、圧力計などのセンサーや、バルブ、ポンプ、アクチュエーターなどといった機器である。

次に、上記構成を有する通信処理装置３がどのように動作し、どのようにその特有の効果が生じるかについて説明する。

近年では、ＣＰＵの性能の向上により、汎用ＯＳ・３６でも、最大レイテンシー２５ミリ秒程度のリアルタイム性は確保できる。一例として、リアルタイム・プラント・ネットワーク・システムであるＶｎｅｔ／ＩＰ（登録商標）を用いる場合、送信等タイミングを決定する時間スロットの周期は１００ミリ秒であるため、１００ミリ秒以内ならば、遅れを補償する処理を行って、リアルタイム通信を継続することができる。つまり、理論上は、汎用ＯＳ上でリアルタイム通信機能を実現することは可能である。しかしながら、現実に適用するシステムにおいて、汎用ＯＳ・３６上では、リアルタイム通信部１８１だけでなく、他の機能も並列的に動作する。ここで、他の機能とは、例えば、リアルタイム通信を行わないアプリケーションソフトウェアである。また他には例えば、リアルタイム通信を行うとともに、リアルタイム通信部１８１以外の通信機能を用いて非リアルタイム通信を行うアプリケーションソフトウェアなどである。

こういったアプリケーションソフトウェア等の動作により応答性能が悪くなるのを防ぐため、応答性能を良くしたいタスク（例えば、リアルタイム通信部１８１のタスク）にはアプリケーションソフトウェアよりも高いタスク優先度を割り当てる手法を取り得る。

しかしながら、既存の汎用ＯＳのスケジューラーは、リアルタイムＯＳのスケジューラーとは違い、優先度の低いタスクにも必要な計算資源をそれなりに与えて並列動作させることができることを特徴とする。そのような汎用ＯＳのスケジューラーは、優先度の低いタスクの動作を完全に止めることのないように、そのようなタスクにも所定量の計算資源を割り当てるためである。つまり、そういった汎用ＯＳを用いて制御システムを構築すると、高優先度のタスクのリアルタイム性が、他の（低優先度の）アプリケーション等の動作により阻害される可能性がある。場合によっては、１００ミリ秒のオーダーで高優先度のタスクの処理が停止してしまう可能性もある。

汎用ＯＳのスケジューラーは、タスクに対してＣＰＵ時間を割り当てる際、優先度の高いタスクに対してより多くのＣＰＵ時間を割り当てようとする。しかしながら、優先度の高いタスクがＣＰＵ時間を使いすぎた場合、ある種の汎用ＯＳのスケジューラーは、優先度の高いタスクの実行を止め、その分のＣＰＵ時間を優先度の低いタスクに与える。つまり、その汎用ＯＳのスケジューラーは、これによって管理下の全タスクの並列動作の確保を図る。スケジューラーが上記のような制御を行う場合、優先度の高いタスクが待たされ、リアルタイム性が阻害される。

そこで、本実施形態によるリアルタイム通信部１８１内の自己診断部１８５は、リアルタイム通信部１８１自身の処理負荷をモニタリングする。そして、リアルタイム通信部１８１の処理負荷がある閾値に達したことを検知すると、自己診断部１８５は、リアルタイム通信部インターフェース１８２に対して、フレーム送信の処理の負荷を下げるよう指示する。処理負荷をモニタリングするための診断指標の一例として、自己診断部１８５は、リアルタイム通信部１８１のＣＰＵ使用率が所定の閾値を超えているか否かを検知する。この閾値は、汎用ＯＳ・３６に割り当てられたＣＰＵのコア数や、高負荷テストの結果に基づいて、外部から設定できるようにする。リアルタイム通信部インターフェース１８２は、処理負荷が高くなったことを示す通知を自己診断部１８５から受けると、リアルタイム通信部１８１の処理負荷を低くするための制御を行う。具体例として、リアルタイム通信部インターフェース１８２は、アプリケーション部７０１側から届くフレームの送信要求を要求バッファー１８８から取り出す量を抑制する。この量とは、例えば、単位時間当たりの送信フレーム数や、単位時間当たりの送信バイト数などである。例えば、リアルタイム通信部インターフェース１８２は、要求バッファー１８８から送信要求を取り出す際に、所定時間（例えば、１ミリ秒以下の範囲）、待機する。これは、リアルタイム通信部１８１の計算資源使用率（ＣＰＵ使用率等）を下げる方向に作用する。

上述した制御により、優先度の高いタスク（リアルタイム通信部１８１）の計算資源使用率（ＣＰＵ使用率等）が所定値以下に抑えられる。これにより、優先度の低いタスク（アプリケーション部７０１等）がＣＰＵ時間を使いすぎると、汎用ＯＳスケジューラー３７は、優先度の低いタスクの実行を止め、優先度の高いタスクにＣＰＵ時間を優先的に割り当てる。つまり、自己診断部１８５とリアルタイム通信部インターフェース１８２とが連携してリアルタイム通信部１８１の処理負荷を所定量以下に抑制することにより、リアルタイム通信部１８１には常に必要なＣＰＵ時間が確保される。言い換えれば、自己診断部１８５とリアルタイム通信部インターフェース１８２とが連携してリアルタイム通信部１８１の不安定動作を緩和させることにより、リアルタイム通信部１８１には常に必要な計算時間が確保される。つまり、通信処理装置３のリアルタイム性が維持される。
上記の通り、本実施形態のリアルタイム通信部１８１を含んだ通信処理装置３では、リアルタイム性が阻害されない。つまり、通信処理装置３では、一度開始した他機器への通信や、自機器の存在を他機器へ通知する診断通信において、通信の停滞が生じない。

次に、リアルタイム通信要求処理共有ライブラリ１９２とリアルタイム通信部１８１とを、別の機能部として分離する理由を説明する。
リアルタイム通信部１８１は、複数のアプリケーション部７０１からの要求に応じた処理を行う。そのため、リアルタイム通信部１８１への処理負荷の集中を避けることが好ましい。リアルタイム通信要求処理共有ライブラリ１９２とリアルタイム通信部１８１とを分離することによって、リアルタイム通信部１８１の処理負荷を軽くすることが可能となる。リアルタイム通信要求処理共有ライブラリ１９２の機能をアプリケーション部７０１に静的にリンクして実行させる場合、リアルタイム通信要求処理共有ライブラリ１９２の機能の処理負荷を、アプリケーション部７０１のタスクが負担する。したがって、アプリケーション部７０１は、リアルタイム通信部１８１の処理負荷状況を考慮することなく通信要求を行うことができる。
仮に、リアルタイム通信要求処理共有ライブラリ１９２の機能が、リアルタイム通信部１８１側のタスクに置かれていると、リアルタイム通信部１８１の計算資源の消費量（ＣＰＵ使用率等）がアプリケーション部７０１の要求に左右される。これは、通信処理装置３のリアルタイム性を阻害の要因になり得る。

リアルタイム通信要求処理共有ライブラリ１９２の機能を、リアルタイム通信部１８１から独立させた構成とすることにより、次のような状況が生じる。即ち、アプリケーション部７０１等からの通信要求が多発した際でも、それらの通信要求はリアルタイム通信部インターフェース１８２の要求バッファー１８８に蓄積される。したがって、リアルタイム通信部１８１は、抑制されたペースでしか通信要求の処理を行わない。よって、通信処理装置３のリアルタイム性は維持される。

次に、通信処理装置３内の機能の処理手順について説明する。
図３は、リアルタイム通信部１８１内のリアルタイム通信部インターフェース１８２の動作手順を示すフローチャートである。以下、このフローチャートに沿って説明する。

まず、ステップＳ１１において、リアルタイム通信部インターフェース１８２は、自己診断部１８５から不安定動作の通知が直近においてあったか否かを判定する。不安定動作の通知があった場合（ステップＳ１１：ＹＥＳ）にはステップＳ１２に進み、不安定動作の通知がなかった場合（ステップＳ１１：ＮＯ）にはステップＳ１５に進む。

ステップＳ１２に進んだ場合、同ステップにおいて、リアルタイム通信部インターフェース１８２は、過去からの所定時間、不安定動作の通知を継続して受けていたか否かを判定する。不安定動作の通知を継続して受けていた場合（ステップＳ１２：ＹＥＳ）はステップＳ１３に進み、継続していなかった場合（ステップＳ１２：ＮＯ）にはステップＳ１４に進む。

ステップＳ１３に進んだ場合、同ステップにおいて、リアルタイム通信部インターフェース１８２は、指定時間に所定の時間を加算する。この指定時間とは、ステップＳ１４においてリアルタイム通信部インターフェースが待つ際に指定される時間である。なお、本ステップで加算される時間は正の値である。つまり、本ステップの処理において、リアルタイム通信部インターフェース１８２は、指定時間を増加させる。

ステップＳ１４に進んだ場合（ステップＳ１２またはＳ１３から）、同ステップにおいて、リアルタイム通信部インターフェース１８２は、指定時間分のＷＡＩＴを行う。このＷＡＩＴにより、リアルタイム通信部インターフェース１８２は、次のステップに移る前に指定時間分、待つ。リアルタイム通信部インターフェース１８２が本ステップにおいて待つ間、計算資源は、リアルタイム通信部１８１内の他の処理やアプリケーション部７０１の処理に割り当てられ、ＷＡＩＴがない状態と比較してリアルタイム通信部１８１の処理負荷が低減される。リアルタイム通信部インターフェース１８２が待ち始めてから上記指定時間が経過すると、再びリアルタイム通信部インターフェース１８２に計算資源が割り当てられ、次のステップの処理に進む。ステップＳ１４の処理の終了後には、ステップＳ１６に進む。
なお、こういった計算資源の割当制御は、本実施形態においては汎用ＯＳスケジューラー１７が行う。

ステップＳ１５に進んだ場合、同ステップにおいて、リアルタイム通信部インターフェース１８２は、指定時間を初期値にリセットする。つまり、それまでの処理においてステップＳ１３での指定時間の加算が行われていた場合にも、不安定動作の通知がなくなったことにより、指定時間を一旦、元の初期値に戻す。
なお、ステップＳ１１において「ＮＯ」（不安定動作通知なし）と判断されたときに直ちにステップＳ１５における指定時間リセットの処理を行う代わりに、「不安定動作通知なし」の状態が所定時間継続した場合にのみステップＳ１５において指定時間をリセットするようにしてもよい。
ステップＳ１５の処理の終了後には、ステップＳ１６に移る。

次に、ステップＳ１６において、リアルタイム通信部インターフェース１８２は、アプリケーション部７０１−１や７０１−２など（アプリ）から要求された送信フレームがあるか否かを判定する。具体的には、リアルタイム通信部インターフェース１８２は、要求バッファー１８８を参照することにより、送信フレームの有無を判定する。送信フレームがある場合（ステップＳ１６：ＹＥＳ）、次のステップＳ１７に進む。送信フレームがない場合（ステップＳ１６：ＮＯ）、ステップＳ１９に飛ぶ。

ステップＳ１７に進んだ場合、同ステップにおいて、リアルタイム通信部インターフェース１８２は、要求バッファー１８８から１つの送信フレームを取り出す。ただし、複数の送信フレームをまとめて取り出して送信できる場合には、リアルタイム通信部インターフェース１８２は、予め定められた所定数以下の送信フレームを要求バッファー１８８から取り出す。なお、要求バッファー１８８内の送信フレームは、送信バッファー１８４への転送が成功した後に適宜削除される。
続いて、ステップＳ１８において、リアルタイム通信部インターフェース１８２は、ステップＳ１７で取り出した送信フレームを、送信バッファー１８４に格納する。
なお、送信バッファー１８４に格納された送信フレームを、リアルタイム通信部１８１は順次送信する（図４参照）

次に、ステップＳ１９において、リアルタイム通信部インターフェース１８２は、リアルタイム通信部１８１の処理を終了すべきか否かを判定する。リアルタイム通信部１８１の処理を終了するのは、例えば、通信処理装置１内における上位の管理機能から終了を指示された場合や、オペレーター等から終了コマンドが入力された場合や、エラー事象等による割込みを解析した結果として終了すべきと判断される場合などである。リアルタイム通信部１８１を終了させる場合（ステップＳ１９：ＹＥＳ）には、本フローチャート全体の処理を終了する。リアルタイム通信部１８１を終了させない場合（ステップＳ１９：ＮＯ）には、ステップＳ１１に戻って、上述した処理を繰り返す。

なお、ステップＳ１４において待つ時間（指定時間）は、予め定めておいた初期値と、ステップＳ１３において加算される加算値によって定まる。この加算値も、予め定めておくことができる。不安定動作通知が所定時間継続する状況が連続的に続く場合には、ステップＳ１３における指定時間の加算を複数回繰り返してもよい（ステップＳ１９からステップＳ１１に処理が戻ることによる繰り返し）。
また、ステップＳ１３で指定時間の加算を行う場合も含めて、Ｓ１４において待つ時間（指定時間）の下限や上限を予め定めておいてもよい。上限が定められている場合、ステップＳ１３における加算の結果は、当該上限値より大きくはならない。
また、ステップＳ１４において待つ時間を、不安定動作通知の内容を加味して決定してもよい。ステップＳ１４において待つ時間は、計時による値に限定されず、例えば「不安定動作が解消した」等の、何らかの状態変化が発生するまで待ち続ける動作であってもよい。

また、ステップＳ１２において不安定動作の通知が所定時間継続しているか否かを判断するが、その具体的な判断方法の一例は、次の通りである。つまり、ステップＳ１１において不安定動作通知の有無を判定するが、直近の過去ｍ回のステップＳ１１での判断の内、ｎ回以上「ＹＥＳ」（不安定動作通知あり）と判定され、且つ直近の回においても「ＹＥＳ」（不安定動作通知あり）と判定された場合に、「所定時間継続」（ステップＳ１２：ＹＥＳ）と判定される。なお、ｍ，ｎはそれぞれ予め定められる整数であり、１≦ｎ≦ｍである。

図３に示したフローチャートでは、不安定動作の状況が継続する場合には、その間のステップＳ１１での判断結果は常に「ＹＥＳ」である。その場合、要求バッファー１８８からの送信要求の取り出しにはステップＳ１４における待ちを伴う。要求バッファー１８８からの送信要求の取り出しの頻度と要求バッファー１８８への送信要求の到着の頻度との関係次第では、送信要求が要求バッファー１８８において待たされる時間はリアルタイム通信要求処理共有ライブラリ１９２内のリアルタイム通信送信要求処理ロジックがフレーム送信処理をタイムアウトと認識する時間に達する場合もあり得る。こういった場合も含め、リアルタイム通信部インターフェース１８２は、不安定動作の状況が解消されるまで、送信要求の処理量を抑制する。

図４は、リアルタイム通信部１８１の動作手順を示すフローチャートである。以下、このフローチャートに沿って説明する。

ステップＳ２１において、リアルタイム通信部１８１は、送信バッファー１８４に送信フレームが書き込まれているか否かを判定する。送信バッファー１８４に送信フレームがある場合（ステップＳ２１：ＹＥＳ）には、次のステップＳ２２に進む。送信バッファー１８４に送信フレームがない場合（ステップＳ２１：ＮＯ）には、ステップＳ２６に飛ぶ。

ステップＳ２２に進んだ場合、リアルタイム通信部１８１は、送信バッファー１８４から１つの送信フレームを取り出し、そのフレームを送信する。ただし、複数の送信フレームをまとめて取り出して送信できる場合には、リアルタイム通信部１８１は、予め定められた所定数以下の送信フレームを送信バッファー１８４から取り出して、それらのフレームを送信する。
ステップＳ２３において、リアルタイム通信部１８１は、ステップＳ２２においてフレームを送信した相手（フレームの受信側）からの肯定応答（Ａｃｋ，acknowledgement）が到着するのを所定時間待つ。

ステップＳ２４において、リアルタイム通信部１８１は、待っている肯定応答が到着したか否かを判定する。肯定応答の到着があった場合（ステップＳ２４：ＹＥＳ）、つまり、そのフレームが相手側で受信されたことが確認された場合、ステップＳ２５に進む。肯定応答の到着がなかった場合（ステップＳ２４：ＮＯ）、つまり、送信したフレームに対応する否定応答が到着した場合や、待っている肯定応答がタイムアウトした場合には、ステップＳ２６に飛ぶ（つまり、ステップＳ２５における処理をスキップする）。
ステップＳ２５において、リアルタイム通信部１８１は、送信が成功したフレーム、つまり肯定応答が得られた送信フレームを、送信バッファー１８４から消去する。
なお、一定処理回数の間に肯定応答の到着がなかった場合には、リアルタイム通信部１８１は、送信先が通信できない状況と判断してもよい。この場合、リアルタイム通信部１８１は、送信バッファーから送信フレームを消去し、送信を失敗させてもよい。

ステップＳ２６において、リアルタイム通信部１８１は、リアルタイム通信部１８１自身の処理を終了すべきか否かを判定する。リアルタイム通信部１８１の処理を終了する状況とは、図３のステップＳ１９において説明した通りである。リアルタイム通信部１８１を終了させる場合（ステップＳ２６：ＹＥＳ）には、本フローチャート全体の処理を終了する。リアルタイム通信部１８１を終了させない場合（ステップＳ２６：ＮＯ）には、ステップＳ２１に戻って、上述した処理を繰り返す。

以上説明したように、本実施形態によれば、次の作用が得られる。
即ち、通信処理装置３では、リアルタイム通信部１８１の処理負荷に基づいて、リアルタイム通信部１８１の処理量を調整する。具体的には、例えば、処理すべき要求が流入するリアルタイム通信部１８１の処理のペースを、相対的に早くしたり遅くしたりするなどといった調整を行う。この調整は、自己診断部１８５が検出する処理負荷の重さに基づいて行う。具体的には、例えば、リアルタイム通信部１８１が要求バッファー１８８から取り出す通信要求の量（あるいは処理すべきデータの量）を調整し、処理にかかるＣＰＵ使用時間を増減する。これにより、非リアルタイム処理でもよいアプリケーション部７０１の処理と、リアルタイム処理であることが求められるリアルタイム通信部１８１との間で、ロードバランシングが可能になる。上記の作用により、通信処理装置３の処理のリアルタイム性が確保される。

また、本実施形態では、リアルタイム通信部１８１に対する、汎用ＯＳスケジューラー３７が行うタスクの調停による、リアルタイム性の阻害を防ぐことができる。つまり、リアルタイム通信部１８１の処理負荷が高まった（例えばＣＰＵ使用率が所定レベルより高くなった）ことに起因してリアルタイム通信部１８１へのＣＰＵ時間の割り当てが下げられる状況を回避することができる。
また、リアルタイム通信要求処理共有ライブラリ１９２のロジックをアプリケーション部７０１側のタスクで実行する場合、そのロジックの処理の負荷がリアルタイム通信部１８１にかからず、通信処理装置３のリアルタイム性の阻害を防げる状態を保つことができる。
また、処理負荷のバランシングを行うことで、リアルタイム通信部１８１が一度開始した他機器への通信や、自機器の存在を他機器へ通知する診断通信が滞ることを防ぐことができる。
また、リアルタイム通信要求処理共有ライブラリ１９２やリアルタイム通信部１８１は汎用ＯＳのカーネル空間のモジュール（デバイスドライバ）ではないので、デバイスドライバで発生するメンテナンス問題あるいは互換性問題を回避できる。

［第２実施形態］
次に、本発明の第２実施形態について説明する。なお、前実施形態において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。

図５は、第２実施形態による通信処理装置の機能構成の一部を示す機能ブロック図である。図示するように、通信処理装置１は、ＰＣ上で稼働する仮想ハードウェア１５と、仮想ハードウェア１５上で稼働するゲストＯＳ・１６とを含む。なお、ゲストＯＳ・１６は、第１実施形態と同様の汎用ＯＳであってよい。本実施形態の特徴は、仮想化部１２を設けることにより、ＰＣ・１１上で複数の仮想ハードウェア１５を稼働させ、各仮想ハードウェア１５上で前述のゲストＯＳ・１６を稼働させるようにした点である。

ゲストＯＳ・１６は、ユーザー空間１８とカーネル空間１９とを有する。
カーネル空間１９には、汎用ＯＳスケジューラー１７と、リアルタイム通信要求共有メモリー１９１とが存在する。
汎用ＯＳスケジューラー１７は、ユーザー空間１８内で稼働する複数のタスクをスケジューリングする。つまり、汎用ＯＳスケジューラー１７は、計算資源を、ユーザー空間１８内の各タスクに割り当てる。本実施形態においても、ゲストＯＳ・１６はリアルタイム制御用のＯＳではなく、汎用ＯＳスケジューラー１７はリアルタイムスケジューラーではない。なお、同図では１つのユーザー空間１８のみを示しているが、汎用ＯＳスケジューラー１７が複数のユーザー空間１８を管理するものであってもよい。

ユーザー空間１８内には、アプリケーション部７０１−１，７０１−２，・・・と、リアルタイム通信部１８１とが存在する。
アプリケーション部７０１−１，７０１−２，・・・には、リアルタイム通信要求処理共有ライブラリ１９２やリアルタイム通信ＡＰＩ共有ライブラリ１９３が有するライブラリ関数の機能が組み込まれている。
リアルタイム通信部１８１は、アプリケーション部７０１−１，７０１−２，・・・から独立のタスクとして稼働する。

図６は、本実施形態により、ＰＣを仮想化し、複数の仮想ハードウェア上でそれぞれゲストＯＳを稼働させるための機能を中心として示した通信処理装置１全体のブロック図である。図示するように、通信処理装置１は、ＰＣ（パーソナルコンピューター）上で稼働する仮想ハードウェア１５と、仮想ハードウェア１５上で稼働するゲストＯＳ・１６とを含む。

同図におけるゲストＯＳ・１６−１および１６−２は、それぞれ、図５に示したゲストＯＳ・１６と同様のものである。ここでは、２個のゲストＯＳが稼働している状況を示しているが、ゲストＯＳの個数は任意であり、１個でもよく、３個以上であってもよい。また、仮想ハードウェア１５−１および１５−２は、それぞれ、図５に示した仮想ハードウェア１５と同様のものである。仮想ハードウェア１５−１の上でゲストＯＳ・１６−１が稼働し、仮想ハードウェア１５−２の上でゲストＯＳ・１６−２が稼働する。仮想ハードウェア１５が３個以上含まれる場合、同様に、各々の仮想ハードウェア１５上でゲストＯＳ・１６が稼働可能である。

また、図６に示すように、通信処理装置１は、ＰＣ・１１を用いて実現される。ＰＣ・１１は、演算装置や、メモリーや、通信用のインターフェース機能など、通常のコンピューターが有する機能を持つ。ＰＣ・１１上では、ソフトウェアで実現される機能が、実行可能形式のプログラムとして適切な記憶領域に記憶される。また、それらのプログラムが、適宜、演算装置（下記の物理ＣＰＵ・１１０）によって実行される。

ＰＣ・１１は、ハードウェアとして、物理ＣＰＵ・１１０と、汎用ＮＩＣ・１１２と、ＮＩＣインターフェース１１３とを含んで構成される。

物理ＣＰＵ・１１０は、内部にコア１１１−１，１１１−２，１１１−３，・・・を含む。なお、物理ＣＰＵ・１１０に含まれるコアの個数は任意である。各々のコア１１１は、プログラムに含まれる命令を順次フェッチして、実行する。また、ＰＣ・１１が複数の物理ＣＰＵ・１１０を備える構成としてもよい。
汎用ＮＩＣ・１１２は、ＰＣ・１１上のプログラム等からの通信の要求を受け、実行するものである。汎用ＮＩＣ・１１２は、ＰＣ・１１に接続されているネットワークを介して、外部の機器との間で通信を行う。
ＮＩＣインターフェース１１３は、ＰＣ・１１上のプログラム等と汎用ＮＩＣ・１１２との間のインターフェースを提供するものである。

また、ＰＣ・１１は、仮想化部１２の機能を備える。仮想化部１２は、ハードウェアとソフトウェアとが協調する形で実現される。仮想化部１２は、内部に、仮想化部スケジューラー１４と、複数の仮想ハードウェア１５とを含んでいる。

仮想化部スケジューラー１４は、物理ＣＰＵ・１１０内の複数のコア１１１のＣＰＵ時間を、複数の仮想ハードウェア１５内の仮想ＣＰＵコア１５１に適宜割り当てる。

仮想ハードウェア１５は、仮想化部１２の機能によって実現される仮想的なコンピューターハードウェアである。仮想ハードウェア１５は、少なくとも、仮想ＣＰＵと仮想メモリーとを有する。また、仮想ハードウェア１５は、通信を行うためのネットワークインターフェース機能を有する。仮想ハードウェア１５におけるこれらの仮想資源は、仮想化部１２を通して、実際の物理的なコンピューターハードウェア資源に対応付けられる。
仮想ハードウェア１５の内部構成は次の通りである。即ち、例えば、仮想ハードウェア１５−１は、仮想ＣＰＵコア１５１−１と、仮想ＮＩＣ・１５２−１と、ＮＩＣインターフェース１５３−１とを含む。また、仮想ハードウェア１５−２は、仮想ＣＰＵコア１５１−２と、仮想ＮＩＣ・１５２−２と、ＮＩＣインターフェース１５３−２とを含む。仮想ハードウェア１５−３（またはそれ以後）が存在する場合、各々の仮想ハードウェアは仮想ハードウェア１５−１等と同様の構成を有する。なお、仮想ハードウェア１５の内部の機能は、仮想化技術によって実現される機能である。
なお、図面等では仮想ハードウェアおよびその内部の構成要素の符号にサフィックス（１，２等）を付けているが、以下において、単に、仮想ハードウェア１５、仮想ＣＰＵコア１５１、仮想ＮＩＣ・１５２、ＮＩＣインターフェース１５３等と呼ぶ場合がある。

仮想ＣＰＵコア１５１−１，１５１−２等は、それぞれ、仮想化部１２によって実現される仮想的なＣＰＵコアである。仮想ＣＰＵコア１５１は、仮想化部１２のタスクの一つであり、仮想化部スケジューラー１４がそのタスクに対して物理ＣＰＵのコアを割り当てることで、仮想ＣＰＵコア１５１に割り当てられたプログラムを動作させ、仮想ＣＰＵコアの機能を実現する。仮想ハードウェア１５をマルチコアにする場合には、仮想化部１２は、複数のコア１１１を複数の仮想ＣＰＵコア１５１に対応付けて、各々のタスクを仮想ＣＰＵコア１５１上で並列に動作させる。各々の仮想ＣＰＵコア１５１には、専用の物理ＣＰＵ１１０のコア１１１が割り当てられる。つまり、ある仮想ＣＰＵコア１５１に割り当てられるコア１１１は、他の仮想ＣＰＵコア１５１に割り当てられるコアや、仮想化部１２の処理に割り当てられるコア１１１とは異なる。これにより、複数の仮想ハードウェア１５の間で計算資源、特にＣＰＵ資源が競合しないため、ゲストＯＳ・１６のリアルタイム性を確保しやすくなる。
なお、ユーザー（通信処理装置１の管理者）が、仮想化部１２を管理するためのツールを用いて、物理ＣＰＵ・１１０内のコア１１１の仮想ＣＰＵコア１５１への割り当てを設定することができる。本実施形態では、仮想ＣＰＵコア１５１へのコア１１１の割り当て数を含む仮想ハードウェア１５それぞれの仮想資源の構成は、基本的に固定的なものである。ただし、仮想化部１２の実装により、仮想ハードウェア１５の動作中にも、ツールを用いた設定により、仮想ＣＰＵコア１５１の割り当て数を含む仮想資源の構成を仮想の計算資源を増やす方向に変更できる場合がある。なお、仮想ハードウェア１５の動作中に計算資源の減らす方向に仮想資源の構成を変更することは、突然の計算資源の減少がリアルタイム性に悪影響を与えるため、原則としてできない。

仮想ハードウェア１５が要求する仮想資源よりも物理的なコンピューターハードウェア資源の方が少なく、割り当てるべき計算資源が足りない場合、少なくとも一部の複数の仮想ハードウェアで計算資源を共有させることもできる。これをオーバーコミットと言う。しかし、オーバーコミットを行うと、ある仮想ハードウェア１５の処理が高負荷になったときに、その仮想ハードウェア１５と計算資源を共有する他の仮想ハードウェア１５に計算資源を充分に割り当てられない場合があり得る。このような状況はゲストＯＳ・１６のリアルタイム性を阻害する可能性がある。よって、実施に当たってオーバーコミットを行わない。
つまり、本実施形態において、ゲストＯＳ・１６（汎用ＯＳ）は、仮想ハードウェア１５上で稼働するものである。また、複数の仮想ハードウェア１５が、物理コアを共有しないよう構成した。言い換えれば、複数の仮想ハードウェアが、仮想ハードウェアに対して個々に割り当てられるＣＰＵ資源（中央処理装置資源）を共有しないよう構成した。これにより、各ゲストＯＳ・１６での処理にリアルタイム性を確保することができる。

仮想ＮＩＣ・１５２−１，１５２−２等は、それぞれ、仮想ハードウェア１５−１，１５−２等における仮想的なネットワークインターフェースカードである。仮想ＮＩＣ・１５２の機能は、仮想化部１２によって実現されるものである。つまり、ゲストＯＳ・１６側からの仮想ＮＩＣ・１５２への通信要求は、ＰＣ・１１が備える汎用ＮＩＣ・１１２に引き継がれる。
また、ＮＩＣインターフェース１５３−１，１５３−２等は、それぞれ、ゲストＯＳ・１６−１，１６−２側から上記の仮想ＮＩＣ・１５２−１，１５２−２等にアクセスするためのインターフェースである。

図６に示す例では、ゲストＯＳ・１６−１上で、アプリケーション部７０１−１１および７０１−１２が稼働する。また、ゲストＯＳ・１６−２上で、アプリケーション部７０１−１３が稼働する。
アプリケーション部７０１−１１は、例えば、ＨＭＩ（ヒューマンマシンインターフェエース）である。
アプリケーション部７０１−１２は、例えば、ＥＮＧ（エンジニアリングサーバー）である。
アプリケーション部７０１−１３は、例えば、コントローラーである。
ゲスト・ＯＳ１６−１および１６−２のそれぞれにおいてリアルタイム通信部１８１も稼働するが、ここではリアルタイム通信部１８１の図示を省略している。

第１実施形態における場合と同様に、本実施形態においても、ＰＣ・１１は、汎用ＮＩＣ・１１２を介して、制御ネットワーク８００に接続される。制御ネットワーク８００は、プロセス制御システムを構成する機器間で通信を行うためのネットワークである。制御ネットワーク８００には、コントローラー８０１や、ＰＣ・８０２などといった機器が接続される。ＰＣ・１１は、例えば、ＨＭＩで、制御ネットワーク８００を介して、コントローラー８０１やＰＣ・８０２との間で通信を行う。また、コントローラー８０１には、ＰＣ・１１に対して測定データを送るとともに、ＰＣ・１１からの操作量が入力される。そして、コントローラー８０１には、複数のフィールド機器８０３が接続される。コントローラー８０１は、フィールド機器８０３をコントロールすることにより、プラントの制御を行う。フィールド機器８０３は、例えば、流量計、温度計、湿度計、圧力計などのセンサーや、バルブ、ポンプ、アクチュエーターといった機器である。

本実施形態においては、仮想化部１２により、１台のＰＣ・１１上で複数のゲストＯＳ・１６を稼働させている。また、各ゲストＯＳ・１６で稼働するリアルタイム通信部１８１の機能により、第１実施形態と同様に、各ゲストＯＳ・１６上で稼働する機能のリアルタイム性を確保している。

また、本実施形態においては、リアルタイム通信部１８１がゲストＯＳ・１６上で稼働する構成としているため、仮想化部１２がプロプライエタリ・ソフトウェアであり、仮想化部に機能拡張を行えない場合にも、リアルタイム制御通信が可能である。

［第３実施形態］
次に、本発明の第３実施形態について説明する。なお、前実施形態までにおいて既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。

第１実施形態および第２実施形態においては、リアルタイム通信要求処理共有ライブラリ１９２からアクセスするためのリアルタイム通信要求共有メモリー１９１を設けていた。アプリケーション部７０１からの通信要求は、一時的にリアルタイム通信要求共有メモリー１９１内のバッファーに格納されていた。しかしながら、リアルタイム通信要求共有メモリー１９１は、どのアプリケーション部７０１からも読み書き可能である。つまり、あるアプリケーション部７０１が、他のアプリケーション部７０１の通信要求に干渉する可能性があるという、セキュリティ上の問題が懸念される。ここで言う「干渉」とは、通信要求を無断で読み取ったり、書き換えてしまったりといった事象である。

上記の懸念を解消するため、本実施形態では、ユーザー空間１８内に、アプリケーション代理部２９１を設ける。
図７は、本実施形態による通信処理装置２の一部の機能構成を示す機能ブロック図である。図７に示すゲストＯＳ・１６は、第２実施形態と同様に（図６を参照）、仮想ハードウェア１５の上で稼働する。本実施形態による通信処理装置２では、図７に示すように、ユーザー空間１８内において、アプリケーション部７０１−１，７０１−２，・・・と、リアルタイム通信ＡＰＩ共有ライブラリ１９３と、アプリケーション代理部２９１と、リアルタイム通信部１８１との各機能が稼働する。
これらのうち、アプリケーション部７０１−１，７０１−２，・・・と、リアルタイム通信ＡＰＩ共有ライブラリ１９３と、リアルタイム通信部１８１との各部の機能は、それぞれ、第１実施形態および第２実施形態におけるそれらと同様の機能を有するものである。

本実施形態に特有の機能であるアプリケーション代理部２９１は、アプリケーション部７０１から独立したタスクとして動作する。そして、アプリケーション代理部２９１は、アプリケーション部７０１からの通信要求を受け付け、受け付けた通信要求を当該タスク内の専用の（私的な）記憶部であるリアルタイム通信要求タスク内メモリー２９３に一旦格納してから、リアルタイム通信要求タスク内メモリー２９３から取り出した通信要求をリアルタイム通信部１８１に渡す。アプリケーション代理部２９１は、内部にリアルタイム通信要求タスク内メモリー２９３を有し、このリアルタイム通信要求タスク内メモリー２９３を、第１実施形態および第２実施形態におけるリアルタイム通信要求共有メモリー１９１の代替手段として使用する。つまり、アプリケーション代理部２９１は独立したタスクであり、リアルタイム通信要求タスク内メモリー２９３はその専用のメモリー領域内に設けられる。これにより、他のタスク（例えば、アプリケーション部７０１）は、リアルタイム通信要求タスク内メモリー２９３に干渉（読み書き）することができない。したがって、リアルタイム通信要求タスク内メモリー２９３内のバッファーに蓄えられる通信要求は、アプリケーション代理部２９１のみによって読み書き可能であり、安全性が確保される。

アプリケーション代理部２９１は、リアルタイム通信要求処理ライブラリ２９２と、リアルタイム通信要求タスク内メモリー２９３と、アプリケーション要求処理部２９４−１，２９４−２，・・・を含んで構成される。なお、アプリケーション要求処理部２９４−１，２９４−２，・・・を単に「アプリケーション要求処理部２９４」と呼ぶ場合もある。

リアルタイム通信要求処理ライブラリ２９２は、第１実施形態および第２実施形態におけるリアルタイム通信要求処理共有ライブラリ１９２と同様の機能を有するものである。つまり、リアルタイム通信要求処理ライブラリ２９２は、アプリケーション部７０１からのデータ送信やデータ受信の要求を受け取り、それらの通信処理をリアルタイム通信部１８１に要求する。ただし、本実施形態におけるリアルタイム通信要求処理ライブラリ２９２は、アプリケーション代理部２９１のタスクの中で動作する。つまり、リアルタイム通信要求処理ライブラリ２９２は、第１実施形態や第２実施形態におけるリアルタイム通信要求処理共有ライブラリ１９２と異なり、複数のアプリケーション部７０１によって共有されるものではない。また、リアルタイム通信要求処理ライブラリ２９２は、タスク間共有メモリーではなく、アプリケーション代理部２９１のタスクの専用領域（私的領域）に設けられたリアルタイム通信要求タスク内メモリー２９３にアクセスする。つまり、リアルタイム通信要求処理ライブラリ２９２は、リアルタイム通信要求タスク内メモリー２９３内のバッファーに要求を書き込んだり、同バッファーから要求を取り出したりする。

リアルタイム通信要求タスク内メモリー２９３は、アプリケーション代理部２９１のタスクの専用領域に属するメモリーである。前述の通り、リアルタイム通信要求タスク内メモリー２９３は、通信要求を一時的に格納するためのバッファーを持つ。

アプリケーション要求処理部２９４−１，２９４−２，・・・は、それぞれ、アプリケーション部７０１−１，７０１−２，・・・に対応して設けられる。アプリケーション要求処理部２９４−１は、アプリケーション部７０１−１からの送信や受信の要求をハンドリングし、リアルタイム通信要求処理ライブラリ２９２の機能への橋渡しの役割を果たす。アプリケーション要求処理部２９４−２以後についても同様である。なお、アプリケーション要求処理部２９４の個数は任意であり、その個数は、アプリケーション部７０１の数に対応して変化し得る。
ただし、１つのアプリケーション部７０１に対して複数のアプリケーション要求処理部２９４を対応付けるようにしてもよい。その場合、例えば、通信種別毎あるいは通信方向毎に、それぞれアプリケーション要求処理部２９４を設けることができる。複数のアプリケーション要求処理部２９４は、タスクに割り当てられた計算資源を用いて、互いに並列に動作する（この並列に動作する実行体を一般的にはスレッドと呼ぶ）。

アプリケーション部７０１とアプリケーション要求処理部２９４との間や、リアルタイム通信要求処理ライブラリ２９２とリアルタイム通信部１８１との間では、プロセス間通信（ＩＰＣ，Interprocess Communication）により、通信要求やその応答の受け渡しが行われる。

なお、図７に示す形態では、リアルタイム通信部１８１のリアルタイム通信通知部１８３からリアルタイム通信要求処理ライブラリ２９２へ、時間通知と受信通知の２種類の通知が行われる。その変形例として、時間通知に関しては、アプリケーション代理部２９１自身が、自タスク内でタイマーをセットし、そのタイマーの満了等により時間通知を受けるようにしてもよい。この場合、リアルタイム通信部１８１のリアルタイム通信通知部１８３からリアルタイム通信要求処理ライブラリ２９２へは、受信通知のみが行われ、時間通知は不要である。

図８は、本実施形態による通信処理装置の機能構成の一部を示す機能ブロック図である。図示するように、通信処理装置２は、ＰＣ上で稼働する仮想ハードウェア１５と、仮想ハードウェア１５上で稼働するゲストＯＳ・１６とを含む。なお、ゲストＯＳ・１６は、第１実施形態および第２実施形態と同様の汎用ＯＳであってよい。本実施形態における仮想ハードウェア１５の実現方法は、第２実施形態におけるそれと同様である（図６を参照）ため、ここでは詳細な説明を省略する。

ゲストＯＳ・１６は、ユーザー空間１８とカーネル空間１９とを有する。
カーネル空間１９には、汎用ＯＳスケジューラー１７と、共有メモリー１９９とが存在する。
汎用ＯＳスケジューラー１７は、ユーザー空間１８内で稼働する複数のタスクをスケジューリングする。つまり、汎用ＯＳスケジューラー１７は、計算資源を、ユーザー空間１８内の各タスクに割り当てる。本実施形態においても、ゲストＯＳ・１６はリアルタイム制御用のＯＳではなく、汎用ＯＳスケジューラー１７はリアルタイムスケジューラーではない。
共有メモリー１９９は、タスク間で共有する情報がある場合に適宜用いられる。本実施形態では、なお、アプリケーション代理部２９１内にリアルタイム通信要求タスク内メモリー２９３を持つ。よって、アプリケーション部７０１からの通信要求を一時的に格納するための記憶部をこの共有メモリー１９９内に持つ必要はない。

ユーザー空間１８内には、アプリケーション部７０１−１，７０１−２，・・・と、アプリケーション代理部２９１と、リアルタイム通信部１８１とが存在する。
アプリケーション部７０１−１，７０１−２，・・・には、リアルタイム通信ＡＰＩ共有ライブラリ１９３が有するライブラリ関数の機能が組み込まれている。本実施形態では、アプリケーション代理部２９１がアプリケーション部７０１−１，７０１−２，・・・から独立のタスクとして稼働している。つまり、アプリケーション部７０１−１，７０１−２，・・・自体は、第２実施形態とは異なり、リアルタイム通信要求処理共有ライブラリ１９２の機能を含んでいない。

なお、本実施形態においては、仮想ハードウェア１５上でゲストＯＳ・１６（汎用ＯＳ）を稼働させ、そのユーザー空間１８においてアプリケーション代理部２９１を設けた。しかしながら、仮想化技術を用いず、ＰＣ（ハードウェア）上で直接、汎用ＯＳを稼働させ、そのユーザー空間において、本実施形態と同様にアプリケーション代理部を設けるようにしてもよい。

以上説明したように、本実施形態によれば、通信処理装置２が外部の他の装置との間で通信するフレームが共有メモリー上のバッファーに置かれない。その代わりに、アプリケーション代理部２９１のタスク内のメモリー空間上のバッファー（リアルタイム通信要求タスク内メモリー２９３内のバッファー）が用いられる。これにより、例えばアプリケーションソフトウェア間における干渉等の悪影響が生じないようにすることができる。つまり、例えば、送受信フレームの改ざんや覗き見等の懸念から、アプリケーションを保護することができる。

以上説明したいずれかの実施形態によれば、プロセス制御等を行うための通信処理装置の通信機能を汎用ＯＳ上で実現することができる。つまり、専用ハードウェアなしで通信処理装置を実施できるようになる。これにより、専用ハードウェアを必要としないため、仮想ＰＣ（仮想ハードウェア１５）上でも通信処理装置を実施できるようになる。プロセス制御のための通信ではリアルタイム性が特に重要である。システム内に存在する例えば１つの機器でリアルタイム性が阻害されて、制御通信の送受信が遅延すると、通信相手の機器が反応し、通信の再送を実施する。この再送処理は、再送処理を行う機器にとって本来は行う必要のない余計な処理である。つまり、再送処理が発生すると、システム内の計算資源を浪費することにつながり得る。また、再送処理が多発すると、計算資源や通信路の帯域が浪費されることにより、本来行うべき通信を行えなくなる。これにより、最初にリアルタイム性が阻害された機器だけでなく、他の複数の機器にも連鎖的に影響が広がる可能性がある。

このような連鎖的影響がシステム内で出ないようにするために、次の２つの点を満たすように通信処理装置を構成する。
１）リアルタイム通信部１８１が一度開始した他機器への通信（フレームの送信）は、通信の所定シーケンスが完了するまで滞らないことが必要である。所定シーケンスの完了とは、例えば、送信した相手からの肯定応答（Ａｃｋ）の受信である。
２）自機器（通信処理装置）の存在を他機器へ通知するための診断通信が滞らないようにする。この診断通信が滞ってしまうと、自機器は、他機器から、少なくとも一時的に不存在であるかのように見える。

そして、これらの実施形態では、自己診断部１８５が不安定動作を検出し、処理負荷増の通知に応じてリアルタイム通信部インターフェース１８２が要求バッファー１８８から要求を取り出す時間間隔（ペース）を変える。これにより、リアルタイム通信部１８１の処理負荷が高くなり過ぎず、処理に必要な計算資源が充分に与えられる。そのため、スケジューラーとして、リアルタイムスケジューラーの機能を持たない汎用ＯＳ（例えば、マイクロソフト社のWindows）のスケジューラーを利用することができる。そしてその場合にもリアルタイム性は阻害されない。
なお、リアルタイム通信部１８１には高い優先度を割り当てる。
通常、汎用ＯＳにおいては、高優先度のタスクに計算資源が集中した場合、低優先度タスクの動作を維持するため、高優先度タスクの計算資源を低優先度タスクに分配する。そのように高優先度タスクの計算資源が供給されなくなると、通信処理装置として、リアルタイム性が維持できなくなる可能性もある。しかしながら、上で説明した各実施形態では、リアルタイム通信部１８１は、高優先度を割り当てつつ、かつ、計算資源の使用（ＣＰＵ使用率等）を抑えるロジックを組み込んでいる。したがって、アプリケーション部７０１等の、リアルタイム通信部１８１以外の各部が、計算資源を多用しようと試みても、スケジューラーは計算資源の割り当てを抑制する。この動作により、リアルタイム通信部１８１以外の各部の処理能力は低下するものの、高優先度タスク（リアルタイム通信部１８１）への計算資源の分配が損なわれることはなく、つまりリアルタイム通信部１８１の計算資源は維持され、リアルタイム性を維持することが可能となる。

また、通信処理装置が仮想化部１２を備える場合において、仮想化部１２をプロプライエタリ・ソフトウェアで実現する場合でも、リアルタイム性を維持した通信が行える。
また、汎用ＯＳのスケジューラーを利用してシステムを実現可能であり、その場合にもリアルタイム通信部１８１に充分な計算資源が与えられる。
また、デバイスドライバを用いずにリアルタイム通信部１８１やリアルタイム通信要求処理共有ライブラリ１９２等を、実現することが可能である。つまり、システム（ソフトウェア）の開発および保守が容易になる。
また、リアルタイム通信部１８１に対して、ＣＰＵコアの固定的な割り当てを行わずにリアルタイム通信が行うことが可能となる。
また、通信処理装置におけるリアルタイム通信性の阻害を回避できるため、その通信処理装置の影響でシステム内の他の機器における通信リアルタイム性の阻害も回避することが可能となる。
また、専用通信カードが必要であった制御通信（リアルタイム通信）を、汎用通信カードと汎用ＯＳ上とで実現することが可能となる。

以上、複数の実施形態を説明したが、本発明はさらに次のような変形例でも実施することが可能である。
例えば、図６に示した構成において、ＰＣ・１１は、汎用ＮＩＣ・１１２とＮＩＣインターフェース１１３との組を１組だけ備えていた。変形例として、ＰＣ・１１が、汎用ＮＩＣ・１１２とＮＩＣインターフェース１１３との組を複数組備えるようにしてもよい。つまり、ＰＣ・１１が、物理的な（物理層の）ネットワークに接続される通信の系統を複数持つようにしてもよい。このとき、これら複数の通信系統を、ＰＣ・１１が同時に使用して通信を行うようにしてもよい。また、これら複数の通信系統を、冗長構成と見なして、ＰＣ・１１が、いずれかの通信系統に障害等が生じた場合に他の通信系統を用いた通信を行うようにしてもよい。なお、ここでは、図６の構成における汎用ＮＩＣ・１１２とＮＩＣインターフェース１１３との組の数について述べたが、図１や図２（第１実施形態）におけるＰＣ・３１の、物理ＮＩＣ・３１２とＮＩＣインターフェース３１３との組の数についても同じことが言える。つまり、物理ＮＩＣ・３１２とＮＩＣインターフェース３１３との組の数を、単数としてもよいし複数としてもよい。

なお、上述した各実施形態およびその変形例における通信処理装置の機能（またはその一部）をコンピュータープログラムで実現する場合、その機能のプログラムをコンピューター読み取り可能な記録媒体に記録しておく。そして、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行させるようにする。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＵＳＢメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明は、例えば、リアルタイム通信を行う機器類に適用することができる。その一例として、本発明を、プラント等を管理・制御するための通信処理装置に利用することができる。ただし、本発明の適用範囲は、ここに例示したものに限定されるものではない。

１，２，３…通信処理装置、１１…ＰＣ、１２…仮想化部、１４…仮想化部スケジューラー、１５，１５−１，１５−２…仮想ハードウェア、１６，１６−１，１６−２…ゲストＯＳ、１７…汎用ＯＳスケジューラー、１８…ユーザー空間、１９…カーネル空間、３１…ＰＣ、３６…汎用ＯＳ、３７…汎用ＯＳスケジューラー、３８…ユーザー空間、３９…カーネル空間、１１０…物理ＣＰＵ、１１１−１，１１１−２，１１１−３…コア、１１２…汎用ＮＩＣ、１１３…ＮＩＣインターフェース、１５１，１５１−１，１５１−２…仮想ＣＰＵコア、１５２，１５２−１，１５２−２…仮想ＮＩＣ、１５３，１５３−１，１５３−２…ＮＩＣインターフェース、１８１…リアルタイム通信部、１８２…リアルタイム通信部インターフェース（リアルタイム通信部インターフェース部）、１８３…リアルタイム通信通知部、１８４…送信バッファー、１８５…自己診断部、１８６…自己診断指標記憶部、１８８…要求バッファー、１９１…リアルタイム通信要求共有メモリー、１９２…リアルタイム通信要求処理共有ライブラリ、１９３…リアルタイム通信ＡＰＩ共有ライブラリ、２９１…アプリケーション代理部、２９２…リアルタイム通信要求処理ライブラリ、２９３…リアルタイム通信要求タスク内メモリー、２９４，２９４−１，２９４−２…アプリケーション要求処理部、３１０…物理ＣＰＵ、３１２…物理ＮＩＣ、３１３…ＮＩＣインターフェース、７０１，７０１−１，７０１−２，７０１−１１，７０１−１２，７０１−１３…アプリケーション部、８００…制御ネットワーク、８０１…コントローラー、８０２…ＰＣ、８０３…フィールド機器

Claims (9)

1. アプリケーションソフトウェアを稼働させるアプリケーション部と、
   前記アプリケーションソフトウェアからの通信要求を受け、前記通信要求に基づいてデータの送受信を行うリアルタイム通信部と、
   を具備し、プロセス制御システムにおける通信処理を行う通信処理装置であって、
   前記リアルタイム通信部は、
   前記アプリケーションソフトウェアからの前記通信要求を少なくとも一時的に蓄積する要求バッファーと、
   前記通信要求がデータの送信要求である場合に、前記要求バッファーから前記送信要求を取り出して送信処理を行うリアルタイム通信部インターフェース部と、
   前記リアルタイム通信部の処理に関する診断指標を検知し、前記診断指標が所定範囲にある場合にはその動作状況を前記リアルタイム通信部インターフェース部に対して通知する自己診断部と、
   を具備し、
   前記リアルタイム通信部インターフェース部は、前記自己診断部から前記動作状況の通知を受けた場合には、前記要求バッファーから前記送信要求を取り出す時間間隔を調整する、
   ことを特徴とする通信処理装置。
2. 前記リアルタイム通信部インターフェース部は、前記自己診断部から前記動作状況の前記通知を所定時間継続して受けた場合には、前記通知を所定時間継続して受けない場合よりも前記要求バッファーから前記送信要求を取り出す前記時間間隔をさらに調整する、
   ことを特徴とする請求項１に記載の通信処理装置。
3. 前記アプリケーション部は、複数の前記アプリケーションソフトウェアを同時並行的に稼働させるものであり、各々の前記アプリケーションソフトウェアからの前記通信要求を、前記複数のアプリケーションソフトウェア間で共有される記憶部であるリアルタイム通信要求共有メモリーに一旦格納してから、前記リアルタイム通信要求共有メモリーから取り出した前記通信要求を前記リアルタイム通信部に渡す、
   ことを特徴とする請求項１または請求項２に記載の通信処理装置。
4. 前記アプリケーション部から独立のタスクとして稼働し、前記アプリケーションソフトウェアからの前記通信要求を受け付け、受け付けた前記通信要求を当該タスク内の専用の記憶部であるリアルタイム通信要求タスク内メモリーに一旦格納してから、前記リアルタイム通信要求タスク内メモリーから取り出した前記通信要求を前記リアルタイム通信部に渡すアプリケーション代理部、
   をさらに具備することを特徴とする請求項１または請求項２に記載の通信処理装置。
5. 前記リアルタイム通信部は、前記アプリケーション部から独立のタスクとして稼働する、
   ことを特徴とする請求項１から４までのいずれか一項に記載の通信処理装置。
6. 前記アプリケーション部と前記リアルタイム通信部とは、汎用オペレーティングシステム上で稼働するものであり、前記汎用オペレーティングシステム内のスケジューラーの制御によって中央処理装置資源を与えられる、
   ことを特徴とする請求項５に記載の通信処理装置。
7. 前記汎用オペレーティングシステムは、仮想化部を有するコンピューターの仮想ハードウェア上で稼働するものであり、
   複数の前記仮想ハードウェアが、前記仮想ハードウェアに対して個々に割り当てられる中央処理装置資源を共有しないよう構成した、
   ことを特徴とする請求項６に記載の通信処理装置。
8. コンピューターを、
   請求項１から７までのいずれか一項に記載の通信処理装置として機能させるためのプログラム。
9. プロセス制御システムにおける通信処理を行う通信処理装置において、
   アプリケーション部が、アプリケーションソフトウェアを稼働させ、
   リアルタイム通信部が、前記アプリケーションソフトウェアからの通信要求を受け、前記通信要求に基づいてデータの送受信を行い、
   前記リアルタイム通信部において、
   要求バッファーが、前記アプリケーションソフトウェアからの前記通信要求を少なくとも一時的に蓄積し、
   リアルタイム通信部インターフェース部が、前記通信要求がデータの送信要求である場合に、前記要求バッファーから前記送信要求を取り出して送信処理を行い、
   自己診断部が、前記リアルタイム通信部の処理に関する診断指標検知し、前記診断指標が所定範囲にある場合にはその動作状況を前記リアルタイム通信部インターフェース部に対して通知し、
   前記リアルタイム通信部インターフェース部は、前記自己診断部から前記動作状況の通知を受けた場合には、前記要求バッファーから前記送信要求を取り出す時間間隔を調整する、
   通信処理方法。

Images