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

Abstract

【課題】汎用ＯＳのスケジューラを用いつつ、生産制御システムに必要なリアルタイム性を確保することできる通信処理装置、通信処理方法、およびプログラムを提供することを目的とする。【解決手段】生産制御システムにおける通信処理装置であって、リアルタイム通信部が、通信処理に関する診断指標を検知し、診断指標の値が所定の閾値を超えた場合、不安定動作発生の可能性をリソース調整判断部に通知し、リソース調整判断部が、リアルタイム通信部からの通知を受けた場合、仮想プロセッサに空きがあるか否かを判断し、仮想プロセッサに空きがある場合、不安定動作発生の可能性がある仮想マシンに仮想プロセッサを追加することを仮想化部に指示し、仮想プロセッサに空きがない場合、不安定動作発生の可能性がある仮想マシンに、稼働優先度が低い仮想マシンに割り当てられた仮想プロセッサを追加することを仮想化部に指示する。【選択図】図４

Description

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

生産制御システムなどにおいては、特に通信のリアルタイム性が求められる。従来、イーサネット（登録商標）またはＩＰ（インターネットプロトコル）などの標準的な通信技術を用いて、リアルタイム通信を行う方法が構築されている。

非特許文献１に記載の技術では、リアルタイム性を実現するために、送信局ごとに時間スロットを割り当てるなどによってパケット損失を防いでいる。また、非特許文献１に記載の技術では、例えば図４に示されるように、オープンな標準プロトコルを採用して、マルチベンダー機器によるネットワーク構成を可能としている。

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

プラントを制御するために構成するネットワークシステムにおいて、汎用製品を用いて、当該ネットワークシステムに属する機器を実現したいという要求がある。特に、リアルタイム性を確保しつつ、当該ネットワークシステムに属する機器に汎用製品を組み込むことにより、機器の低コスト化および供給の安定化を期待することができる。例えば、リアルタイム通信を行う通信処理装置としてコンピュータを用い、当該コンピュータ上で稼働するプログラムを制御するために、Linux（登録商標）などよりも汎用性の高いWindows（登録商標）などの汎用ＯＳ（オペレーティングシステム）を用いることが考えられる。

しかしながら、上述した通信処理装置に対して、同時並行的に稼働する複数のタスクに対する計算資源の割当てを行う汎用ＯＳのスケジューラをそのまま適用すると、以下の問題が発生する。例えば、プラント制御のための処理を行うアプリケーション部と、当該アプリケーション部からの通信要求をリアルタイムに処理するリアルタイム通信部とを備える通信処理装置では、従来の汎用ＯＳのスケジューラは、計算資源を適切に割り当てることができない場合がある。具体的には、汎用ＯＳのスケジューラを用いた通信処理装置では、リアルタイム性を確保するために、リアルタイム通信部のタスクの優先度がアプリケーション部のタスクの優先度よりも高く設定される。しかしながら、一般に、汎用ＯＳのスケジューラは、優先度が高いタスクのＣＰＵ使用率が所定の閾値を超えると、当該タスクには計算資源を与えず、当該タスクの優先度よりも優先度が低いタスクに計算資源を割り当てるというロジックで稼働する。このため、リアルタイム通信部は、充分な計算資源を用いて、アプリケーション部からの通信要求を処理することができず、結果として、リアルタイム性が損なわれるという問題が発生する。

そこで、本開示は、汎用ＯＳのスケジューラを用いつつ、生産制御システムに必要なリアルタイム性を確保することができる通信処理装置、通信処理方法、およびプログラムを提供することを目的とする。

幾つかの実施形態に係る通信処理装置は、コンピュータに含まれる仮想化部により実現される複数の仮想マシン上でそれぞれ稼働するアプリケーション部およびリアルタイム通信部と、リソース調整判断部と、を備える生産制御システムにおける通信処理装置であって、前記リアルタイム通信部は、通信処理に関する診断指標を検知し、前記診断指標の値が所定の閾値を超えた場合、不安定動作発生の可能性を前記リソース調整判断部に通知し、前記リソース調整判断部は、前記リアルタイム通信部からの通知を受けた場合、仮想プロセッサに空きがあるか否かを判断し、前記仮想プロセッサに空きがある場合、前記不安定動作発生の可能性がある前記仮想マシンに前記仮想プロセッサを追加することを、前記仮想化部に指示し、前記仮想プロセッサに空きがない場合、前記不安定動作発生の可能性がある前記仮想マシンに、稼働優先度が低い仮想マシンに割り当てられた仮想プロセッサを追加することを、前記仮想化部に指示する、通信処理装置である。

このように、不安定動作発生の可能性がある仮想マシンに割り当てる仮想プロセッサに空きがない場合であっても、生産制御システムに与える影響が小さい仮想マシンを停止させることにより、リアルタイム通信部の処理量を低減することなく、リアルタイム通信部のリアルタイム性を確保することができる。

一実施形態において、前記リアルタイム通信部は、前記診断指標の値が第１の閾値を超えた場合、前記不安定動作発生の可能性を前記リソース調整判断部に通知し、前記診断指標の値が第２の閾値を超えた場合、前記アプリケーション部からの通信要求を処理する時間間隔を調整してもよい。

このように、リアルタイム通信部インタフェースによって通信要求を処理する時間間隔を調整することにより、稼働優先順位の低い仮想マシンがない場合であっても仮想マシンにおける不安定動作発生の可能性を緩和させることができる。

一実施形態において、前記通信処理装置は、前記アプリケーション部から独立したタスクとして稼働し、前記アプリケーション部からの前記通信要求を受け付け、受け付けた前記通信要求を前記タスク内の専用の記憶部に格納した後に、前記記憶部から取り出した前記通信要求を前記リアルタイム通信部に渡すアプリケーション代理部を備えてもよい。

このように、アプリケーション代理部を設けることにより、アプリケーション部からの通信要求は、アプリケーション代理部のみによって読み書き可能であるので、安全性を確保することができる。

一実施形態において、前記通信処理装置における前記リアルタイム通信部は、前記アプリケーション部から独立したタスクとして稼働してもよい。

このように、リアルタイム通信部をアプリケーション部から独立したタスクとして稼働させることにより、リアルタイム通信部が行う他機器への通信を滞らず実行することができる。

幾つかの実施形態に係るプログラムは、コンピュータを前記通信処理装置として機能させてもよい。

このように、不安定動作発生の可能性がある仮想マシンに割り当てる仮想プロセッサに空きがない場合であっても、生産制御システムに与える影響が小さい仮想マシンを停止させることにより、リアルタイム通信部の処理量を低減することなく、リアルタイム通信部のリアルタイム性を確保することができる。

幾つかの実施形態に係る通信処理方法は、コンピュータに含まれる仮想化部により実現される複数の仮想マシン上でそれぞれ稼働するアプリケーション部およびリアルタイム通信部をそれぞれ稼働させる生産制御システムにおける通信処理装置を用いた通信処理方法において、前記リアルタイム通信部が、通信処理に関する診断指標を検知し、前記診断指標の値が所定の閾値を超えた場合、不安定動作発生の可能性をリソース調整判断部に通知するステップと、前記リソース調整判断部が、前記リアルタイム通信部からの通知を受けた場合、仮想プロセッサに空きがあるか否かを判断するステップと、前記リソース調整判断部が、前記仮想プロセッサに空きがある場合、前記不安定動作発生の可能性がある前記仮想マシンに前記仮想プロセッサを追加することを、前記仮想化部に指示するステップと、前記リソース調整判断部が、前記仮想プロセッサに空きがない場合、前記不安定動作発生の可能性がある前記仮想マシンに、稼働優先度が低い仮想マシンに割り当てられた仮想プロセッサを追加することを、前記仮想化部に指示するステップと、を含む。

このように、不安定動作発生の可能性がある仮想マシンに割り当てる仮想プロセッサに空きがない場合であっても、生産制御システムに与える影響が小さい仮想マシンを停止させることにより、リアルタイム通信部の処理量を低減することなく、リアルタイム通信部のリアルタイム性を確保することができる。

本開示によれば、汎用ＯＳのスケジューラを用いつつ、生産制御システムに必要なリアルタイム性を確保することができる通信処理装置、通信処理方法、およびプログラムを提供することができる。

比較例に係る通信処理装置の構成を示す機能ブロック図である。 図１のリアルタイム通信部インタフェースの処理手順を示すフローチャートである。 図１のリアルタイム通信部の処理手順を示すフローチャートである。 第１の実施形態に係る通信処理装置の構成を示す機能ブロック図である。 図４の仮想プロセッサの割当てを説明する図である。 図４の仮想マシン稼働優先順位テーブルを説明する図である。 図４の通信処理装置の処理手順を示すフローチャートである。 図４の通信処理装置の処理手順を示すフローチャートである。 第２の実施形態に係る通信処理装置の構成を示す機能ブロック図である。 図９の通信処理装置の処理手順を示すフローチャートである。 図９の通信処理装置の処理手順を示すフローチャートである。 第３の実施形態に係る通信処理装置の構成を示す機能ブロック図である。

以下、本開示を実施するための形態について、図面を参照しながら説明する。各図において、同一符号は、同一または同等の構成要素を示す。

（第１の実施形態）
まず比較のために、図１を参照して、比較例に係る通信処理装置４の構成例を説明する。

図１に示すとおり、通信処理装置４は、ハードウェアであるＰＣ１１（物理ＰＣ）上で構成される。ＰＣ１１は、物理プロセッサ１１１と、物理ＮＩＣ１１２と、物理ＮＩＣ ＩＦ１１３とを含む。また、ＰＣ１１は、メモリなどの他の構成要素を含んでもよい。ＰＣ１１は、物理ＮＩＣ１１２を介して、制御ネットワーク２０に接続される。なお、制御ネットワーク２０は、生産制御システムを構成する機器間で通信を行うためのネットワークであり、制御ネットワーク２０には、コントローラ２１およびＰＣ２２などの機器が接続される。ＰＣ２２は、例えば、制御ネットワーク２０を介して、コントローラ２１などと通信を行うことができる。コントローラ２１は、複数のフィールド機器２３が接続され、フィールド機器２３をコントロールすることにより、プラントの制御を行う。フィールド機器２３は、例えば、流量計、温度計、湿度計、もしくは圧力計などのセンサ、またはバルブ、ポンプ、もしくはアクチュエータなどの機器である。なお、ＰＣは、「パーソナルコンピュータ」の略である。ＮＩＣは、「ネットワークインタフェースカード」の略である。ＮＩＣは、単に「ネットワークカード」と呼ばれる場合もある。また、「ＩＦ」は、「インタフェース」の略である。

物理プロセッサ１１１は、メモリにロードされたプログラムに含まれる命令を逐次フェッチして実行する。物理プロセッサとして、例えば物理ＣＰＵが挙げられ、当該物理ＣＰＵに含まれるコアの個数は任意である。なお、ＣＰＵは、「中央処理装置（Central Processing Unit）」の略である。また、ＰＣ１１が複数の物理プロセッサ１１１を備えてもよい。なお、物理プロセッサ１１１のＣＰＵ時間は、後述するユーザ空間内の各機能に割り当てられる。

物理ＮＩＣ１１２は、ＰＣ１１に接続される制御ネットワーク２０を介して、外部の機器と通信するためのインタフェース機能を有する。物理ＮＩＣ１１２は、汎用ＮＩＣであってよい。

物理ＮＩＣ ＩＦ１１３は、ＰＣ１１上のプログラムなどと物理ＮＩＣ１１２との間のインタフェースを提供する。

ＰＣ１１上では、汎用ＯＳ１９が稼働する。汎用ＯＳ１９は、ユーザ空間１４と、カーネル空間１６とを有する。ＯＳは、「オペレーティングシステム」の略である。汎用ＯＳ１９を用いて通信処理装置４を構成することにより、通信処理装置４を低コスト化し、かつ安定的に供給することが可能となる。汎用ＯＳ１９としては、例えばマイクロソフト社（Microsoft Corporation，米国）のＰＣ用ＯＳであるWindows（登録商標）系のＯＳが挙げられる。

カーネル空間１６には、汎用ＯＳスケジューラ１６１と、リアルタイム通信要求共有メモリ１６２とが存在する。また、カーネル空間１６には、ユーザ空間１４内で稼働するタスク間で共有する情報がある場合に適宜用いられる共有メモリが存在してもよい。

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

リアルタイム通信要求共有メモリ１６２は、ユーザ空間１４内で稼働するすべてのタスクからアクセス可能なメモリである。後述するリアルタイム通信要求処理共有ライブラリ１４２が、アプリケーション部１４１−１、１４１−２、・・・からの通信要求などを一時的に記憶するバッファは、このリアルタイム通信要求共有メモリ１６２内に設けられる。なお、リアルタイム通信要求共有メモリ１６２は、ユーザ空間１４の外に設けられており、アプリケーション部１４１−１、１４１−２、・・・のメモリ空間内の所定の場所にマッピングされる。これにより、アプリケーション部１４１−１、１４１−２、・・・はリアルタイム通信要求共有メモリ１６２にアクセスすることができる。

ユーザ空間１４には、アプリケーション部１４１−１、１４１−２、・・・（以下、「アプリケーション部１４１」と略記する場合がある。）と、リアルタイム通信要求処理共有ライブラリ１４２と、リアルタイム通信ＡＰＩ共有ライブラリ１４３と、リアルタイム通信部１９１とが存在する。ＡＰＩは、「アプリケーションプログラミングインタフェース」の略である。アプリケーション部１４１、リアルタイム通信要求処理ライブラリ１４２、リアルタイム通信ＡＰＩ共有ライブラリ１４３、およびリアルタイム通信部１９１は、プログラムおよびメモリを用いて実現可能である。プログラムは、汎用ＯＳスケジューラ１６１によって適宜割り当てられる物理プロセッサ１１１によって実行される。また、メモリは、例えば半導体または磁気記録媒体などを用いて実現される。なお、ユーザ空間１４で実行される機能は、必ずしもメモリを利用しない場合もある。また、情報を記憶するのみであって、処理を実行しない機能は、プログラムを利用する必要がない。

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

アプリケーション部１４１には、リアルタイム通信要求処理共有ライブラリ１４２およびリアルタイム通信ＡＰＩ共有ライブラリ１４３が有するライブラリ関数の機能が組み込まれている。リアルタイム通信要求処理共有ライブラリ１４２と、リアルタイム通信ＡＰＩ共有ライブラリ１４３との機能は、アプリケーションロジックに適宜連係される。

リアルタイム通信要求処理共有ライブラリ１４２は、アプリケーション部１４１に静的にリンクされていてもよく、独立したタスクとして稼働してもよい。リアルタイム通信要求処理共有ライブラリ１４２は、リアルタイム通信要求受付ロジックと、リアルタイム通信送信ロジックと、リアルタイム通信受信ロジックとの機能を備える。

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

リアルタイム通信送信ロジックは、リアルタイム通信要求受付ロジックからの通知を受けると、リアルタイム通信要求共有メモリ内のバッファから送信フレームを取り出し、リアルタイム通信部１９１に渡す。具体的には、当該リアルタイム通信送信ロジックは、リアルタイム通信部１９１内のリアルタイム通信部インタフェース１９２に含まれる要求バッファ１９３に送信フレームを書き込むことによって、送信を行う。

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

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

リアルタイム通信部１９１は、アプリケーション部１４１からの通信要求に基づいて、リアルタイムにデータの送受信を行う。リアルタイム通信部１９１が行う処理の性質上、コントローラ２１またはＰＣ２２と、フレームの送受信などのタイミングを合わせる必要があり、リアルタイム性が要求される。ここで、「リアルタイム性」とは、リアルタイム通信部１９１がコントローラ２１またはＰＣ２２に対して行った通信要求が所定時間内に完結すること、あるいは所定時間内に通信要求が完了しない場合であっても、当該所定時間内にリアルタイム通信部１９１にレスポンスが戻る（例えば、エラーなどが報告される）ことを意味する。なお、「所定時間」は、適用分野によって異なるが、例えば、数ミリ秒から数百ミリ秒までといった範囲内の時間である。なお、リアルタイム通信部１９１のタスクの優先度は、アプリケーション部１４１のタスクの優先度よりも高く設定される。以下、リアルタイム通信部１９１を詳細に説明する。

リアルタイム通信部１９１は、リアルタイム通信部インタフェース１９２と、リアルタイム通信通知部１９３と、送信バッファ１９４と、自己診断部１９５と、自己診断指標記憶部１９６とを含む。また、リアルタイム通信部インタフェース１９２は、要求バッファ１９７を含む。

要求バッファ１９７は、アプリケーション部１４１からの通信要求を少なくとも一時的に蓄積する。アプリケーション部１４１からの通信要求は、リアルタイム通信要求処理共有ライブラリ１４２およびリアルタイム通信ＡＰＩ共有ライブラリ１４３を介して要求バッファ１９７に蓄積される。要求バッファ１９７に蓄積された通信要求は、リアルタイム通信部インタフェース１９２によって取り出され、送信バッファ１９４に格納される。なお、要求バッファ１９７は、基本的にＦＩＦＯ（先入れ先出し）であるが、通信要求の優先度などに基づいて処理順序の追い越しが発生してもよい。

送信バッファ１９４は、リアルタイム通信部インタフェース１９２からの通信要求を少なくとも一時的に蓄積する。送信バッファ１９４に蓄積された通信要求は、順次送信される。なお、送信バッファ１９４は、基本的にＦＩＦＯ（先入れ先出し）であるが、通信要求の優先度などに基づいて処理順序の追い越しが発生してもよい。

リアルタイム通信部インタフェース１９２は、リアルタイム通信要求処理共有ライブラリ１４２およびリアルタイム通信ＡＰＩ共有ライブラリ１４３を介して、アプリケーション部１４１からの通信要求を受け付けたり、当該通信要求に対する応答をアプリケーション部１４１に返したりする。具体的には、通信要求が送信要求である場合、リアルタイム通信部インタフェース１９２は、アプリケーション部１４１からの通信要求を要求バッファ１９７に一時的に蓄積し、当該通信要求を要求バッファ１９７から取り出し、送信バッファ１９４に格納することによって、送信処理を行う。また、リアルタイム通信部インタフェース１９２は、後述する自己診断部１９５から不安定動作発生の可能性がある旨の通知を受けた場合には、要求バッファ１９７から送信要求を取り出す際に指定時間の待ち（ＷＡＩＴ）を行う。つまり、リアルタイム通信部インタフェース１９２は、要求バッファ１９７に蓄積された送信要求が、送信バッファ１９４に過大に流入しないように制御する。したがって、要求バッファ１９７が大量に送信要求を受信しても、リアルタイム通信部インタフェース１９２は、その都度これらの送信要求を処理しない。これにより、リアルタイム通信部１９１に不安定動作発生の可能性があっても、リアルタイム通信部インタフェース１９２は、当該不安定動作発生の可能性を緩和させることが可能となる。なお、当該指定時間は予め定めておくことができる。「指定時間」は、適用分野によって異なるが、例えば、数ミリ秒から数百ミリ秒までといった範囲内の時間である。

自己診断部１９５は、リアルタイム通信部１９１の処理に関する診断指標（例えば、ＣＰＵ使用率または処理応答時間）を検知し、当該診断指標の値が所定の閾値を超えた場合、リアルタイム通信部１９１に不安定動作発生の可能性があると判断して、その旨をリアルタイム通信部インタフェース１９２に通知する。なお、自己診断部１９５は、当該診断指標を検知するにあたり、自己診断指標記憶部１９６を参照する。

自己診断指標記憶部１９６は、上述した診断指標と、当該診断指標の閾値とのペアを、複数組記憶する。例えば、自己診断指標記憶部１９６は、リアルタイム通信部１９１のＣＰＵ使用率の閾値、処理応答時間（例えば送信フレームのリトライ回数）の閾値、またはその他の閾値を記憶する。なお、これらの閾値は、外部から設定することもできる。

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

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

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

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

ステップＳ１３に進んだ場合、ステップＳ１３において、リアルタイム通信部インタフェース１９２は、指定時間を初期値にリセットする。ステップＳ１３の処理が終了すると、ステップＳ１４に進む。

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

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

次に、ステップＳ１６において、リアルタイム通信部インタフェース１９２は、ステップＳ１５で取り出した送信フレームを、送信バッファ１９４に格納する。なお、送信バッファ１９４に格納された送信フレームは、リアルタイム通信部１９１によって順次送信される。これについては、図３を参照して後述する。

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

図３は、リアルタイム通信部１９１の動作手順を示すフローチャートである。

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

ステップＳ２２に進んだ場合、リアルタイム通信部１９１は、送信バッファ１９４から１つの送信フレームを取り出し、当該フレームを送信する。ただし、複数の送信フレームをまとめて取り出して送信できる場合、リアルタイム通信部１９１は、予め定められた所定数以下の送信フレームを送信バッファ１９４から取り出して、これらのフレームを送信する。

続いて、ステップＳ２３において、リアルタイム通信部１９１は、ステップＳ２２においてフレームを送信した相手（フレームの受信側）からの肯定応答（Ａｃｋ，acknowledgement）が到着するのを所定時間待つ。

続いて、ステップＳ２４において、リアルタイム通信部１９１は、肯定応答が到着したか否かを判断する。肯定応答が到着した場合（ステップＳ２４：ＹＥＳ）、つまり、そのフレームが相手側で受信されたことが確認された場合、ステップＳ２５に進む。肯定応答が到着しなかった場合（ステップＳ２４：ＮＯ）、つまり、送信したフレームに対応する否定応答が到着した場合、または所定時間が経過してタイムアウトした場合、ステップＳ２６に飛ぶ。

ステップＳ２５に進んだ場合、ステップＳ２５において、リアルタイム通信部１９１は、送信が成功したフレーム、つまり肯定応答が得られた送信フレームを、送信バッファ１９４から消去する。なお、一定の処理回数の間に肯定応答が到着しなかった場合、リアルタイム通信部１９１は、送信先が通信できない状況にあると判断してもよい。この場合、リアルタイム通信部１９１は、送信バッファ１９４から送信フレームを消去し、送信を失敗させてもよい。

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

このように、比較例に係る通信処理装置４では、不安定動作発生の可能性がある場合、リアルタイム通信部インタフェース１９２は、要求バッファ１９７から送信要求を取り出す際にＷＡＩＴを行うことにより、要求バッファ１９７に蓄積された送信要求が送信バッファ１９４に過大に流入しないように制御する。しかしながら、このような制御を行う通信処理装置４では、以下に説明するように、本来処理したいデータ量を処理することができず、例えば単位時間あたりのデータ送信量など、アプリケーションの処理性能が低下するという問題がある。

一般に、通信処理装置における全体の処理負荷は、下記（１）式にて算出される。
全体の処理負荷＝（プロセスが使用する各プロセッサの処理負荷の合計値）/（全プロセッサの最大負荷の合計値）・・・（１）
ここで、プロセッサの全数が２つであり、１つのプロセッサにおいて処理可能な最大負荷が１００％であり、各プロセッサの処理負荷が７０％と５０％であり、汎用ＯＳスケジューラがプロセスの処理を止める処理負荷の閾値が５０％である場合を具体例として説明する。この場合、上記（１）式にて算出される全体の処理負荷は６０％（＝（７０＋５０）/（１００＋１００））となる。このため、全体の処理負荷（６０％）は、処理負荷の閾値（５０％）を超えるので、リアルタイム性を確保することができない。この対策として、比較例に係る通信処理装置４では、全体の処理負荷が処理負荷の閾値を超えないように、例えばＷＡＩＴを行うことにより、各プロセッサの処理負荷を低減している。より具体的には、比較例に係る通信処理装置４において、ＷＡＩＴを行うことにより低減した後の各プロセッサの処理負荷をそれぞれ４０％とする。すると、上記（１）式にて算出される全体の処理負荷は、４０％（＝（４０＋４０）/（１００＋１００））となり、処理負荷の閾値で（５０％）より小さくなる。しかしながら、プロセスが実際に使用するプロセッサの処理負荷の合計値は、１２０％（＝７０％＋５０％）から８０％（＝４０％＋４０％）に低下している。このため、比較例に係る通信処理装置４では、本来処理したいデータ量を処理することができず、例えば単位時間あたりのデータ送信量など、アプリケーションの処理性能が低下するという問題が生じる。

この問題に対して、ＰＣを仮想化し、処理負荷が所定の閾値を超えた場合、仮想プロセッサを追加することにより、アプリケーションソフトウェアの処理性能を維持しつつ、リアルタイム性を確保するという対応が考えられる。上述した具体例において、仮想プロセッサを１つ追加すると、仮想マシン全体の処理負荷は、以下となる。
仮想マシン全体の処理負荷＝（７０＋５０）/（１００＋１００＋１００）
＝１２０/３００
＝４０％
つまり、仮想プロセッサを追加することにより、プロセスが使用するプロセッサの処理負荷の合計値は１２０％（＝７０％＋５０％）を維持した状態で、仮想マシン全体の処理負荷を相対的に４０％に下げることができる。このため、アプリケーションの処理性能を維持した状態で、リアルタイム性を確保することが可能となる。しかしながら、生産制御システムにおけるアプリケーションの重要度を考慮せずに、単に仮想プロセッサを追加するだけでは、全ての仮想プロセッサが割当て済みの場合などには、仮想プロセッサを追加することができず、依然としてアプリケーションの処理性能が低下するという問題が残る。

そこで、本開示では、汎用ＯＳのスケジューラを用いつつ、生産制御システムに必要なリアルタイム性を確保することができる通信処理装置について説明する。加えて、本開示では、仮想プロセッサに空きがない場合であっても、生産制御システム全体に与える影響を考慮することにより、リアルタイム通信部の処理量を低減することなく、リアルタイム性を確保することができる通信処理装置について説明する。

以下、本開示の第１の実施形態に係る生産制御システムにおける通信処理装置について説明する。図４は、本実施形態に係る通信処理装置１の機能構成を示す機能ブロック図である。

通信処理装置１は、ハードウェアであるＰＣ１１（物理ＰＣ）上で構成される。ＰＣ１１は仮想化されている。すなわち、ＰＣ１１は仮想化部１２を有し、ＰＣ１１上ではホストＯＳが稼働し、当該ホストＯＳ上では仮想マシンが稼働する。なお、ホストＯＳとしては、汎用ＯＳを適用することができる。汎用ＯＳとしては、例えばマイクロソフト社（Microsoft Corporation，米国）のＰＣ用ＯＳであるWindows（登録商標）系のＯＳが挙げられる。

ＰＣ１１は、物理プロセッサ１１１と、物理ＮＩＣ１１２と、物理ＮＩＣ ＩＦ１１３とを含む。ＰＣ１１は、メモリなどの他の構成要素を含んでもよい。ＰＣ１１は、物理ＮＩＣ１１２を介して、制御ネットワーク２０に接続される。制御ネットワーク２０には、コントローラ２１およびＰＣ２２などの機器が接続されており、コントローラ２１には、複数のフィールド機器２３が接続されている。なお、物理プロセッサ１１１、物理ＮＩＣ１１２、物理ＮＩＣ ＩＦ１１３、制御ネットワーク２０、コントローラ２１、ＰＣ２２、およびフィールド機器２３は、それぞれ比較例で説明した物理プロセッサ１１１、物理ＮＩＣ１１２、物理ＮＩＣ ＩＦ１１３、制御ネットワーク２０、コントローラ２１、ＰＣ２２、およびフィールド機器２３と同様である。

仮想化部１２は、仮想化部スケジューラ１２１と仮想ハードウェア１２２とを含み、仮想化技術によって実現される１つ以上の仮想マシンの動作を制御する。詳細は後述するが、仮想化部１２は、リソース指示部１８から受けたコマンドを実行することによって、仮想資源の変更を行う。「仮想資源の変更」とは、例えば、仮想マシンへの仮想プロセッサ１２３の追加もしくは仮想マシンからの仮想プロセッサ１２３の削除、または仮想マシンの停止もしくは再開などを含む。ここで、仮想資源の変更は、仮想マシンの稼働中に行ってもよく、この場合、仮想マシン上で稼働するゲストＯＳ１３には、仮想マシンの稼働中に仮想資源の変更が反映される。

仮想化部スケジューラ１２１は、物理プロセッサ１１１と仮想プロセッサ１２３とを１対１に適宜割り当てる。したがって、仮想プロセッサ１２３に空きがあるとは、ＰＣ１１に含まれる物理プロセッサ１１１に空きがあること、または仮想ハードウェア１２２に含まれる仮想プロセッサ１２３に空きがあることを意味する。一例として、仮想化部スケジューラ１２１は、物理ＣＰＵに含まれるコアと仮想ＣＰＵコアとを１対１に対応付ける。なお、物理ＣＰＵに含まれるコアの個数は任意であり、物理ＣＰＵは、複数のコアを含んでもよい。

仮想ハードウェア１２２は、仮想化部１２によって実現される仮想的なコンピュータハードウェアである。仮想ハードウェア１２２は、仮想プロセッサ１２３と、仮想ＮＩＣ１２４と、仮想ＮＩＣ ＩＦ１２５とを有する。また、仮想ハードウェア１２２は、仮想メモリを有してもよい。

仮想プロセッサ１２３は、仮想化部１２によって実現される仮想的なプロセッサである。仮想化部１２のタスクに対して、仮想化部スケジューラ１２１が物理プロセッサ１１１を適宜割り当てることで、仮想プロセッサ１２３に割り当てられたプログラムが稼働する。

仮想ＮＩＣ１２４は、仮想的なネットワークインタフェースカードである。つまり、ゲストＯＳ１３側からの仮想ＮＩＣ１２４への通信要求は、物理ＮＩＣ１１２に引き継がれる。

仮想ＮＩＣ ＩＦ１２５は、ゲストＯＳ１３側から仮想ＮＩＣ１２４にアクセスするための仮想的なインタフェースである。

ゲストＯＳ１３は、各仮想マシン上で稼働する。なお、同図では１つのゲストＯＳ１３のみを示しているが、ＰＣ１１上では複数のゲストＯＳ１３が稼働することができる。各ゲストＯＳ１３は、ユーザ空間１４と、カーネル空間１６とを有する。なお、ゲストＯＳ１３として、汎用ＯＳを適用することができる。汎用ＯＳとしては、例えばマイクロソフト社（Microsoft Corporation，米国）のＰＣ用ＯＳであるWindows（登録商標）系のＯＳが挙げられる。

カーネル空間１６には、汎用ＯＳスケジューラ１６１と、リアルタイム通信要求共有メモリ１６２とが存在する。また、カーネル空間１６には、ユーザ空間１４内で稼働するタスクの共有メモリが存在してもよい。なお、汎用ＯＳスケジューラ１６１、リアルタイム通信要求共有メモリ１６２、および共有メモリは、比較例で説明した汎用ＯＳスケジューラ１６１、リアルタイム通信要求共有メモリ１６２、および共有メモリと同様である。

ユーザ空間１４には、アプリケーション部１４１−１、１４１−２、・・・（以下、「アプリケーション部１４１」と略記する場合がある。）と、リアルタイム通信要求処理共有ライブラリ１４２と、リアルタイム通信ＡＰＩ共有ライブラリ１４３と、リアルタイム通信部１５１とが存在する。なお、アプリケーション部１４１、リアルタイム通信要求処理共有ライブラリ１４２、およびリアルタイム通信ＡＰＩ共有ライブラリ１４３は、ゲストＯＳ１３内で稼働すること以外は、比較例で説明したアプリケーション部１４１、リアルタイム通信要求処理共有ライブラリ１４２、およびリアルタイム通信ＡＰＩ共有ライブラリ１４３と同様である。

リアルタイム通信部１５１は、アプリケーション部１４１からの通信要求に基づいて、リアルタイム通信を行う。具体的には、リアルタイム通信部１５１は、アプリケーション部１４１から通信要求を受け、当該通信要求に基づいてデータの送受信を行う。リアルタイム通信部１５１が行う処理の性質上、コントローラ２１またはＰＣ２２とフレームの送受信などのタイミングを合わせる必要があり、リアルタイム性が要求される。また、リアルタイム通信部１５１は、アプリケーション部１４１から独立したタスクとして稼働することが好ましい。これにより、リアルタイム通信部１５１が行う他機器への通信は、滞らず実行されるからである。ここで、リアルタイム通信部１５１は、通信処理に関する診断指標を検知し、当該診断指標の値が所定の閾値を超えた場合、不安定動作発生の可能性がある旨をリソース調整判断部１７に通知する。以下、本実施形態に係るリアルタイム通信部１５１について、詳細に説明する。

リアルタイム通信部１５１は、リアルタイム通信部インタフェース１５２と、リアルタイム通信通知部１５３と、送信バッファ１５４と、自己診断部１５５と、自己診断指標記憶部１５６と、診断結果通知部１５７とを含む。また、リアルタイム通信部インタフェース１５２は、要求バッファ１５８を含む。

リアルタイム通信部インタフェース１５２は、リアルタイム通信要求処理共有ライブラリ１４２およびリアルタイム通信ＡＰＩ共有ライブラリ１４３を介して、アプリケーション部１４１からの要求を受け付けたり、その要求に対する応答をアプリケーション部１４１に返したりする機能を有する。リアルタイム通信部インタフェース１５２は、受け取った通信要求がデータの送信要求である場合に、要求バッファ１５８から当該送信要求を取り出して送信処理を行う。

自己診断部１５５は、リアルタイム通信部１５１の処理に関する診断指標を検知し、検知した診断指標の値が所定の閾値を超えたか否かを判断する。また、自己診断部１５５は、検知した診断指標の値が所定の閾値を超えた場合、当該診断指標を示したリアルタイム通信部１５１が稼働している仮想マシンにおいて不安定動作発生の可能性があると判断し、当該不安定動作発生の可能性がある旨を診断結果通知部１５７に通知する。なお、自己診断部１５５は、当該診断指標を検知するにあたり、自己診断指標記憶部１５６を参照することができる。また、自己診断指標記憶部１５６は比較例で説明した自己診断指標記憶部１９６と同様である。

自己診断部１５５が検知する診断指標としては、次に説明する（１）ＣＰＵ負荷（ＣＰＵ使用率）または（２）応答性（応答時間）が挙げられるが、これらに限定されない。

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

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

診断結果通知部１５７は、自己診断部１５５から受けた通知を次に説明するリソース調整判断部１７に通知する。ただし、自己診断部１５５は、診断結果通知部１５７を介さずに、上述した不安定動作発生の可能性をリソース調整判断部１７に通知してもよい。

リソース調整判断部１７は、診断結果通知部１５５からの通知を受けた場合、仮想プロセッサ１２３に空きがあるか否かを判断する。仮想プロセッサ１２３に空きがある場合、リソース調整判断部１７は、リソース指示部１８に対して、不安定動作発生の可能性がある仮想マシンに仮想プロセッサ１２３を追加することを指示する。例えば、図５は、２つの仮想マシンＶＭ１、ＶＭ２上で、それぞれゲストＯＳ１３−１、１３−２が稼働しており、仮想マシンＶＭ１において不安定動作発生の可能性がある場合を示す。この場合、仮想ハードウェア１２２に含まれる仮想プロセッサ１２３−３に空きがあるので、リソース調整判断部１７は、リソース指示部１８に対して、仮想マシンＶＭ１に仮想プロセッサ１２３−３を割り当てる（追加）することを指示する。一方、仮想プロセッサ１２３に空きがない場合、リソース調整判断部１７は、稼働優先度が低い仮想マシンがあるか否かを判断する。稼働優先度が低い仮想マシンがある場合、リソース調整判断部１７は、リソース指示部１８に対して、稼働優先度が低い仮想マシンを停止すること、停止した仮想マシンの仮想プロセッサ１２３を削除すること、および不安定動作発生の可能性がある仮想マシンに削除した仮想プロセッサ１２３を追加することを指示する。換言すると、リソース調整判断部１７は、仮想プロセッサ１２３に空きがない場合、不安定動作発生の可能性がある仮想マシンに、稼働優先度が低い仮想マシンに割り当てられた仮想プロセッサ１２３を追加することを、後述する仮想化部１２に指示する。なお、リソース調整判断部１７は、これらの判断を行うにあたり、不安定動作発生の可能性がある仮想マシンの情報、当該仮想マシンとは異なる仮想マシンの情報、各仮想マシンで稼働するアプリケーションの情報、仮想ハードウェアの情報、およびＰＣの情報などを収集することができる。また、リソース調整判断部１７は、稼働優先度が低い仮想マシンがあるか否かを判断するにあたり、次に説明する仮想マシン稼働優先順位テーブル１７１を参照することができる。「稼働優先度が低い仮想マシン」とは、稼働優先度が所定値以下の仮想マシンである。換言すると稼働優先度が低い仮想マシンとは、ＰＣ１１上で稼働する仮想マシンのうち、仮想マシンを停止しても生産制御システムに与える影響が小さい仮想マシンを意味する。

図６を参照して、図４中に示す仮想マシン稼働優先順位テーブル１７１の一例を説明する。仮想マシン稼働優先順位テーブル１７１は、仮想マシンＩＤと、稼働優先順位とを含む。なお、図６中、「稼働アプリケーション」および「備考」については、説明のために併記しているだけであり、実際の仮想マシン優先順位テーブル１７１は、これらの情報を含まなくてもよい。仮想マシンＩＤ（ＶＭ１、ＶＭ２、ＶＭ３、ＶＭ４）は、各仮想マシンを特定するためのＩＤであり、各仮想マシンに付されている。仮想マシンＩＤの欄に「＊」を付している場合、リソース調整判断部１７は、「＊」を付した仮想マシンＩＤに対応する仮想マシン上で稼働するアプリケーションの情報を取得し、対応するアプリケーションが稼働する全ての仮想マシンを停止対象とする。次に、稼働優先順位は、その値が高い仮想マシンほど優先的に稼働させる必要があることを意味しており、例えば以下のように予め設定することができる。データサーバのようにサーバ機能を有し、機能が停止すると生産制御システムに与える影響が大きいアプリケーションが稼働している仮想マシン（ＶＭ１）の稼働優先順位は高く設定される（稼働優先順位：１）。また、あるアプリケーションが１つの仮想マシン（ＶＭ２）上でのみ稼働している場合、仮想マシン（ＶＭ２）の稼働優先順位は高く設定される（稼働優先順位：２）。一方、２つの仮想マシン（ＶＭ３、ＶＭ４）上で同じアプリケーションが稼働している場合、一方の仮想マシン（ＶＭ４）の稼働優先順位（稼働優先順位：３）は、他方の仮想マシン（ＶＭ３）の稼働優先順位（稼働優先順位：１）よりも低く設定される。いずれか一方の仮想マシン（ＶＭ４）が停止しても、他方の仮想マシン（ＶＭ３）上で当該アプリケーションを処理することができるからである。また、ＨＭＩなどのクライアント機能が稼働している仮想マシンの稼働優先順位は、１つの仮想マシンが停止しても生産制御システムに与える影響は小さいので、低く設定される。また、アプリケーションの動作周期が長い場合（例えば１週間に１回の動作周期）、当該アプリケーションが稼働する仮想マシンの稼働優先順位は低く設定される。なお、仮想マシン優先順位テーブル１７１は、リソース調整判断部１７内のメモリに予め格納されてもよいが、これに限定されない。

リソース調整判断部１７は、リアルタイム通信を行うＰＣ１１とは異なるＰＣ上、特に制御システム全体の仮想マシン、仮想マシンが稼働するＰＣ１１、ネットワーク２０、コントローラ２１などの動作状況を監視するＮＭＳ（Network Management Service）上で稼働するが、これに限定されない。即応性を重視して、リソース調整判断部１７は、仮想化部１２上で稼働してもよく、リアルタイム通信を行うゲストＯＳ１３上で稼働してもよく、リアルタイム通信を行わないゲストＯＳ上で稼働してもよい。

リソース指示部１８は、リソース調整判断部１７から受けた指示に基づくコマンドを仮想化部１２に送信する。これにより、仮想化部１２は、当該コマンドを実行することができる。本実施形態では、リソース指示部１８は、リアルタイム通信を行うＰＣ１１上で稼働するが、これに限定されない。例えば、ネットワークを介したリモートにて、上述したコマンドの送信を行ってもよく、この場合、リソース指示部１８は、リアルタイム通信を行うＰＣ１１とは異なるＰＣ上で稼働することができる。

なお、リアルタイム通信通知部１５３、送信バッファ１５４、および要求バッファ１５８は、それぞれ比較例で説明したリアルタイム通信通知部１９３、送信バッファ１９４、および要求バッファ１９７と同様である。

次に、本実施形態に係る通信処理装置１の各機能の処理手順について説明する。図７および図８は、本実施形態におけるリアルタイム通信部１５１、リソース調整判断部１７、リソース指示部１８、および仮想化部１２の処理手順を示すフローチャートである。

まず、ステップＳ１０１において、自己診断部１５５は、リアルタイム通信部１５１の処理に関する診断指標を検知し、当該診断指標の値が所定の閾値を超えたか否かを判断する。当該診断指標の値が所定の閾値を超えた場合（ステップＳ１０１：ＹＥＳ）、ステップＳ１０２に進む。当該診断指標の値が所定の閾値を超えていない場合（ステップＳ１０１：ＮＯ）、図８のステップＳ１１２に飛ぶ。

ステップＳ１０２に進んだ場合、ステップＳ１０２において、自己診断部１５５は、ステップＳ１０１の診断指標を示したリアルタイム通信部１５１が稼働している仮想マシンにおいて不安定動作発生の可能性があると判断し、その旨を診断結果通知部１５７に通知する。

続いて、ステップＳ１０３において、診断結果通知部１５７は、自己診断部１５５から受けた通知をリソース調整判断部１７に通知する。ただし、自己診断部１５５は、診断結果通知部１５７を介さずに、上述した不安定動作発生の可能性をリソース調整判断部１７に通知してもよい。

続いて、ステップＳ１０４において、リソース調整判断部１７は、仮想プロセッサ１２３に空きがあるか否かを判断する。例えば、リソース調整判断部１７は、仮想ハードウェア１２２またはＰＣ１１から情報を収集し、収集した情報に基づいて当該判断を行うことができる。仮想プロセッサ１２３に空きがある場合（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５に進む。仮想プロセッサ１２３に空きがない場合（ステップＳ１０４：ＮＯ）、ステップＳ１０６に進む。

ステップＳ１０５に進んだ場合、すなわち、仮想プロセッサ１２３に空きがある場合、ステップＳ１０５において、リソース調整判断部１７は、リソース指示部１８に対して、不安定動作発生の可能性がある仮想マシンに仮想プロセッサ１２３を追加することを指示する。その後、ステップＳ１０８に進む。

ステップＳ１０６に進んだ場合、すなわち、仮想プロセッサ１２３に空きがない場合、リソース調整判断部１７は、稼働優先順位が低い仮想マシンがあるか否かを判断する。例えば、リソース調整判断部１７は、不安定動作発生の可能性がある仮想マシンの情報、当該仮想マシンとは異なる仮想マシンの情報、および各仮想マシンで稼働するアプリケーションの情報を収集し、収集した情報に基づいて、当該判断を行うことができる。具体的には、リソース調整判断部１７は、図６に示す仮想マシン稼働優先順位テーブルを適宜参照して、当該判断を行うことができる。稼働優先順位が低い仮想マシンがある場合（ステップＳ１０６：ＹＥＳ）、ステップＳ１０７に進む。稼働優先順位が低い仮想マシンがない場合（ステップＳ１０６：ＮＯ）、ステップＳ１１６に進む。

ステップＳ１０７に進んだ場合、すなわち、稼働優先順位が低い仮想マシンがある場合、ステップＳ１０７において、リソース調整判断部１７は、リソース指示部１８に対して、稼働優先順位が低い仮想マシンを停止すること、停止した仮想マシンに割り当てられた仮想プロセッサ１２３を削除すること、および不安定動作発生の可能性がある仮想マシンに対して削除した仮想プロセッサ１２３を追加することを指示する。なお、リソース調整判断部１７は、リソース指示部１８に対して、これらの指示を同時に行わず、順次行ってもよい。

続いて、ステップＳ１０８において、リソース指示部１８は、リソース調整判断部１７から受けた指示に基づくコマンドを仮想化部１２に送信する。すなわち、ステップＳ１０５からステップＳ１０８に進んだ場合には、当該コマンドは、不安定動作発生の可能性がある仮想マシンに対して仮想プロセッサ１２３を追加する旨のコマンドを含む。一方、ステップＳ１０７からステップＳ１０８に進んだ場合には、当該コマンドは、稼働優先度が低い仮想マシンを停止する旨のコマンド、停止した前記仮想マシンの仮想プロセッサ１２３を削除する旨のコマンド、および不安定動作発生の可能性がある仮想マシンに削除した仮想プロセッサ１２３を追加する旨のコマンドを含む。

続いて、ステップＳ１０９において、仮想化部１２は、リソース指示部１８から受信したコマンドを実行する。

続いて、ステップＳ１１０において、自己診断部１５５は、仮想プロセッサ１２３を追加した仮想マシンにおいて不安定動作発生の可能性が解消されたか否かを判断する。当該判断は、ステップＳ１０１と同様の方法により行うことができる。不安定動作発生の可能性が解消された場合（ステップＳ１１０：ＹＥＳ）、ステップＳ１１１に進む。不安定動作発生の可能性が解消されていない場合（ステップＳ１１０：ＮＯ）、自己診断部１５５は、予め定めておいた指定時間だけ待った後に、再びステップＳ１１０の処理を行う。

続いて、ステップＳ１１１において、仮想化部１２は、追加した仮想プロセッサ１２３を解放する。解放された仮想プロセッサ１２３は、例えば、上述した処理と同様にして、不安定動作発生の可能性がある仮想マシンに割り当てられてもよい。

続いて、図８を参照して、ステップＳ１１２において、リアルタイム通信部インタフェース１５２は、アプリケーション部１４１から要求された送信フレームがあるか否かを判定する。例えば、リアルタイム通信部インタフェース１５２は、要求バッファ１５８を参照することにより、送信フレームがあるか否かを判断することができる。送信フレームがある場合（ステップＳ１１２：ＹＥＳ）、ステップＳ１１３に進む。送信フレームがない場合（ステップＳ１１２：ＮＯ）、ステップＳ１１５に飛ぶ。

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

続いて、ステップＳ１１４において、リアルタイム通信部インタフェース１５２は、ステップＳ１１３で取り出した送信フレームを、送信バッファ１５４に格納する。なお、送信バッファ１５４に格納された送信フレームは、例えば図３に示す比較例と同様にして、リアルタイム通信部１５１によって順次送信される。

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

なお、図７のステップＳ１０６からステップＳ１１６に進んだ場合、すなわち、稼働優先順位が低い仮想マシンがない場合、不安定動作発生の可能性がある仮想マシンを生産制御システムのネットワークから切り離して、本フローチャートを終了する。具体的には、リソース指示部１８を介して、不安定動作発生の可能性がある仮想マシンに対応する仮想ＮＩＣ１２４を無効化にすることにより、当該仮想マシンをネットワークから切り離し、本フローチャートの処理を終了する。

以上、本実施形態によれば、次の作用効果が得られる。すなわち、本実施形態によれば、リアルタイム通信部の処理負荷が高くなり、仮想マシンにおいて不安定動作発生の可能性がある場合、当該仮想マシンに仮想プロセッサを追加するため、リアルタイム通信部の処理量を低減することなく、リアルタイム性を確保することができる。また、仮想マシンに追加する仮想プロセッサに空きがない場合であっても、生産制御システム全体に与える影響を考慮することにより、リアルタイム通信部の処理量を低減することなく、リアルタイム性を確保することができる。

（第２の実施形態）
次に、本開示の第２の実施形態について説明する。ここでは、本実施形態に特有の事項を説明し、第１の実施形態において既に説明した事項については説明を省略する。

図９は、第２の実施形態による生産制御システムにおける通信処理装置２の機能構成を示す機能ブロック図である。本実施形態では、自己診断部１５５が検知した診断指標の値に応じて、自己診断部１５５の通知先が異なる点が、第１の実施形態における自己診断部１５５と異なる。すなわち、通信処理装置２における自己診断部１５５は、自己診断部１５５が検知した診断指標の値が第１の閾値を超えた場合、仮想マシンにおいて不安定動作発生の可能性があると判断し、その旨を診断結果通知部１５７に通知する。一方、自己診断部１５５は、自己診断部１５５が検知した診断指標の値が第２の閾値を超えた場合、仮想マシンにおいて不安定動作発生の可能性があると判断し、その旨をリアルタイム通信部インタフェース１５２に通知する。換言すると、本実施形態において、リアルタイム通信部１５１は、当該診断指標の値が第１の閾値を超えた場合、不安定動作発生の可能性がある旨をリソース調整判断部１７に通知する。さらに、リアルタイム通信部１５１は、該診断指標の値が第２の閾値を超えた場合、アプリケーション部１４１からの通信要求を処理する時間間隔を調整する。なお、第１の閾値は、第２の閾値よりも小さく設定される。したがって、リアルタイム通信部１５１は、当該診断指標の値が第１の閾値を超えているが、第２の閾値を超えていない場合には、リアルタイム通信部１５１は、時間間隔を調整しないで、いわゆる通常のリアルタイム通信処理を行う。また、第２の閾値は、汎用ＯＳスケジューラ１６１の処理負荷の閾値よりも小さく設定される。「汎用ＯＳスケジューラの処理負荷の閾値」とは、優先度が高いタスクから優先度が低いタスクに、汎用ＯＳスケジューラが強制的に計算資源を割り当てる際の基準値を意味する。

次に、本実施形態に係る通信処理装置２の各機能の処理手順について説明する。図１０および図１１は、本実施形態におけるリアルタイム通信部１５１、リソース調整判断部１７、リソース指示部１８、および仮想化部１２の処理手順を示すフローチャートである。

まず、ステップＳ２０１において、自己診断部１５５は、リアルタイム通信部１５１の処理に関する診断指標を検知し、検知した診断指標の値が第１の閾値を超えたか否かを判断する。当該診断指標の値が第１の閾値を超えた場合（ステップＳ２０１：ＹＥＳ）、ステップＳ２０２に進む。当該診断指標の値が第１の閾値を超えていない場合（ステップＳ２０１：ＮＯ）、図１１のステップＳ２１５に飛ぶ。

ステップＳ２０２に進んだ場合、ステップＳ２０２において、自己診断部１５５は、仮想マシンにおいて不安定動作発生の可能性があると判断し、その旨を診断結果通知部１５７に通知する。

続いて、ステップＳ２０３において、診断結果通知部１５７は、自己診断部１５５から受けた通知をリソース調整判断部１７に通知する。

続いて、ステップＳ２０４において、リソース調整判断部１７は、仮想プロセッサ１２３に空きがあるか否かを判断する。仮想プロセッサ１２３に空きがある場合（ステップＳ２０４：ＹＥＳ）、ステップＳ２０５に進む。仮想プロセッサ１２３に空きがない場合（ステップＳ２０４：ＮＯ）、ステップＳ２０６に進む。なお、ステップＳ２０４の処理は、第１の実施形態におけるステップＳ１０４の処理と同様である。

ステップＳ２０５に進んだ場合、ステップＳ２０５において、リソース調整判断部１７は、リソース指示部１８に対して、不安定動作発生の可能性がある仮想マシンに仮想プロセッサ１２３を追加することを指示する。その後、ステップＳ２０８に進む。

ステップＳ２０６に進んだ場合、リソース調整判断部１７は、稼働優先順位が低い仮想マシンがあるか否かを判断する。稼働優先順位が低い仮想マシンがある場合（ステップＳ２０６：ＹＥＳ）、ステップＳ２０７に進む。稼働優先順位が低い仮想マシンがない場合（ステップＳ２０６：ＮＯ）、ステップＳ２１２に進む。なお、ステップＳ２０６の処理は、第１の実施形態におけるステップＳ１０６の処理と同様である。

ステップＳ２０７に進んだ場合、ステップＳ２０７において、リソース調整判断部１７は、リソース指示部１８に対して、稼働優先順位が低い仮想マシンを停止すること、停止した仮想マシンの仮想プロセッサ１２３を削除すること、および不安定動作発生の可能性がある仮想マシンに削除した仮想プロセッサ１２３を追加することを指示する。ただし、リソース調整判断部１７は、リソース指示部１８に対して、これらの指示を同時に行わず、順次行ってもよい。

続いて、ステップＳ２０８において、リソース指示部１８は、リソース調整判断部１７から受けた指示に基づくコマンドを仮想化部１２に送信する。すなわち、ステップＳ２０５からステップＳ２０８に進んだ場合には、当該コマンドは、不安定動作発生の可能性がある仮想マシンに仮想プロセッサを追加する旨のコマンドを含む。一方、ステップＳ２０７からステップＳ２０８に進んだ場合には、当該コマンドは、稼働優先度が低い仮想マシンを停止する旨のコマンド、停止した前記仮想マシンの仮想プロセッサ１２３を削除する旨のコマンド、および不安定動作発生の可能性がある仮想マシンに削除した仮想プロセッサ１２３を追加する旨のコマンドを含む。

続いて、ステップＳ２０９において、仮想化部１２は、リソース指示部１８から受信したコマンドを実行する。

続いて、ステップＳ２１０において、自己診断部１５５は、仮想プロセッサ１２３を追加した仮想マシンにおいて不安定動作発生の可能性が解消されたか否かを診断する。不安定動作発生の可能性が解消された場合（ステップＳ２１０：ＹＥＳ）、ステップＳ２１１に進む。不安定動作発生の可能性が解消されていない場合（ステップＳ２１０：ＮＯ）、自己診断部１５５は、予め定めておいた指定時間だけ待った後に、再びステップＳ２１０の処理を行う。

続いて、ステップＳ２１１において、仮想化部１２は、追加した仮想プロセッサ１２３を解放する。その後、ステップＳ２１５に進む。

ステップＳ２１２に進んだ場合、ステップＳ２１２において、自己診断部１５５は、不安定動作発生の可能性がある仮想マシンにおけるリアルタイム通信部１５１の処理に関する診断指標を検知し、当該診断指標の値が第２の閾値を超えたか否かを判断する。当該診断指標の値が第２の閾値を超えた場合（ステップＳ２１２：ＹＥＳ）、ステップＳ２１３に進む。当該診断指標の値が第２の閾値を超えていない場合（ステップＳ２１２：ＮＯ）、図１１のステップＳ２１５に飛ぶ。

続いて、ステップＳ２１３において、リアルタイム通信部インタフェース１５２は、自己診断部１５５から当該診断指標の値が第２の閾値を超えた旨の通知を受けると、アプリケーション部１４１からの通信要求を処理する時間間隔を調整する。一例として、リアルタイム通信部インタフェース１５２は、指定時間分のＷＡＩＴを行う。なお、当該指定時間は予め定めておくことができる。これにより、計算資源は、リアルタイム通信部１５１内の他の処理およびアプリケーション部１４１の処理に割り当てられるので、ＷＡＩＴがない状態と比較してリアルタイム通信部１５１の処理負荷が低減される。リアルタイム通信部インタフェース１５２が待ち始めてから当該指定時間が経過すると、再びリアルタイム通信部インタフェース１５２に計算資源が割り当てられる。

続いて、ステップＳ２１４において、ステップＳ２１３において時間間隔の調整を行った仮想マシンにおいて不安定動作発生の可能性が解消されたか否かを診断する。不安定動作発生の可能性が解消された場合（ステップＳ２１４：ＹＥＳ）、ステップＳ２１５に進む。不安定動作発生の可能性が解消されていない場合（ステップＳ２１４：ＮＯ）、自己診断部１５５は、予め定めておいた指定時間だけ待った後に、再びステップＳ２１４の処理を行う。

図１１を参照して、ステップＳ２１５では、リアルタイム通信部インタフェース１５２は、アプリケーション部１４１から要求された送信フレームがあるか否かを判定する。送信フレームがある場合（ステップＳ２１５：ＹＥＳ）、ステップＳ２１６に進む。送信フレームがない場合（ステップＳ２１５：ＮＯ）、ステップＳ２１８に飛ぶ。なお、ステップＳ２１５の処理は、第１の実施形態におけるステップＳ１１２の処理と同様である。

ステップＳ２１６に進んだ場合、ステップＳ２１６において、リアルタイム通信部インタフェース１５２は、要求バッファ１５８から１つの送信フレームを取り出す。なお、ステップＳ２１６の処理は、第１の実施形態におけるステップＳ１１３の処理と同様である。

続いて、ステップＳ２１７において、リアルタイム通信部インタフェース１５２は、ステップＳ２１６で取り出した送信フレームを送信バッファ１５４に格納する。なお、送信バッファ１５４に格納された送信フレームは、第１の実施形態と同様にして、リアルタイム通信部１５１によって順次送信される。

次に、ステップＳ２１８において、リアルタイム通信部インタフェース１５２は、リアルタイム通信を終了するか否かを判定する。リアルタイム通信を終了させる場合（ステップＳ２１８：ＹＥＳ）、本フローチャートの処理を終了する。リアルタイム通信を終了させない場合（ステップＳ２１８：ＮＯ）、ステップＳ２０１に戻って、上述した処理を繰り返す。なお、ステップＳ２１８の処理は、第１の実施形態におけるステップＳ１１５の処理と同様である。

以上、本実施形態によれば、第１の実施形態に加えて、次の作用効果が得られる。すなわち、本実施形態によれば、稼働優先順位の低い仮想マシンがない場合であっても、不安定動作発生の可能性がある仮想マシンをネットワークから切り離す必要がなく、リアルタイム通信インタフェースがアプリケーション部からの通信要求を処理する時間間隔を調整することによって、仮想マシンにおいて発生した不安定動作発生の可能性を緩和させることができる。

（第３の実施形態）
次に、本開示の第３の実施形態について説明する。なお、第１の実施形態および第２の実施形態において既に説明した事項については説明を省略する場合がある。

図１２は、本実施形態による生産制御システムにおける通信処理装置３の機能構成を示す機能ブロック図である。通信処理装置３は、第１の実施形態および第２の実施形態と同様に、仮想化されたＰＣ１１上で構成される。

ゲストＯＳ１３のカーネル空間１６には、汎用ＯＳスケジューラ１６１と、共有メモリ１６３とが存在する。汎用ＯＳスケジューラ１６１は、第１の実施形態および第２の実施形態と同様である。共有メモリ１６３は、タスク間で共有する情報がある場合に適宜用いられる。なお、本実施形態では、後述するアプリケーション代理部１４４内にリアルタイム通信要求タスク内メモリ１４６が存在するので、共有メモリ１６３内に、アプリケーション部１４１からの通信要求を一時的に格納するためのバッファを設ける必要はない。

ゲストＯＳ１３のユーザ空間１４には、アプリケーション部１４１−１、１４１−２、・・・（以下、「アプリケーション部１４１」と略記する場合がある。）と、リアルタイム通信ＡＰＩ共有ライブラリ１４３と、アプリケーション代理部１４４と、リアルタイム通信部１５１とが存在する。アプリケーション部１４１、リアルタイム通信ＡＰＩ共有ライブラリ１４３、およびリアルタイム通信部１５１は、それぞれ第１の実施形態および第２の実施形態におけるアプリケーション部１４１、リアルタイム通信ＡＰＩ共有ライブラリ１４３、およびリアルタイム通信部１５１と同様である。以下では、アプリケーション代理部１４４を詳細に説明する。

アプリケーション代理部１４４は、アプリケーション要求処理部１４５−１、１４５−２、・・・（以下、「アプリケーション代理部１４５」と略記する場合がある。）と、リアルタイム通信要求処理ライブラリ１４２と、リアルタイム通信要求タスク内メモリ１４６とを含む。アプリケーション代理部１４４は、アプリケーション部１４１から独立したタスクとして稼働する。

アプリケーション要求処理部１４５は、それぞれ、アプリケーション部１４１に対応して設けられる。アプリケーション要求処理部１４５は、対応するアプリケーション部１４１からの送信および受信の通信要求をハンドリングし、リアルタイム通信要求処理ライブラリ１４２に橋渡しする。なお、１つのアプリケーション部１４１に対して、複数のアプリケーション要求処理部１４５を対応付けてもよい。この場合、例えば、通信種別毎あるいは通信方向毎に、それぞれアプリケーション要求処理部１４５を設けることができる。複数のアプリケーション要求処理部１４５は、タスクに割り当てられた計算資源を用いて、互いに並列に動作する。

リアルタイム通信要求処理ライブラリ１４２は、アプリケーション要求処理部１４５を介して、アプリケーション部１４１からの通信要求を受け取り、受け取った通信要求をリアルタイム通信要求タスク内メモリ１４６に一時的に格納する。その後、リアルタイム通信要求タスク内メモリ１４６から取り出した通信要求をリアルタイム通信部１５１に要求する。

リアルタイム通信要求タスク内メモリ１４６は、アプリケーション代理部１４４のタスクの専用領域に属する記憶部である。リアルタイム通信要求タスク内メモリ１４６は、通信要求を一時的に格納するためのバッファを有する。

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

また、本実施形態では、リアルタイム通信部１５１のリアルタイム通信通知部１５３からリアルタイム通信要求処理ライブラリ１４２へ、時間通知と受信通知の通知が行われる。その変形例として、時間通知に関しては、アプリケーション代理部１４４自身が、自身のタスク内でタイマーをセットし、当該タイマーの満了などにより時間通知を受けてもよい。この場合、リアルタイム通信通知部１５３からリアルタイム通信要求処理ライブラリ１４２へは、受信通知のみが行われ、時間通知は不要である。

本実施形態によれば、第１の実施形態および第２の実施形態に加えて、以下の作用効果が得られる。本実施形態では、第１の実施形態および第２の実施形態とは異なり、あるアプリケーション部からの通信要求は、どのアプリケーション部からも読み書き可能であるリアルタイム通信要求共有メモリ内のバッファに格納されず、リアルタイム通信要求タスク内メモリ内のバッファに格納され、当該通信要求は、アプリケーション代理部のみによって読み書き可能である。これにより、あるアプリケーション部は、他のアプリケーション部の通信要求に干渉することなく、安全性が確保される。なお、本実施形態における「干渉」とは、通信要求を無断で読み取ったり、書き換えたりすることを意味する。つまり、本実施形態によれば、例えば、送受信フレームの改ざんおよび覗き見などの懸念から、アプリケーション部を保護することができる。

以上、本開示を諸図面および実施形態に基づき説明したが、当業者であれば本開示に基づき種々の変形又は修正を行うことが容易であることに注意されたい。したがって、これらの変形又は修正は本開示の範囲に含まれることに留意されたい。例えば、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数のステップ等を１つに組み合わせたり、あるいは分割したりすることが可能である。

例えば、上述した実施形態では、ＰＣ１１は、物理ＮＩＣ１１２と物理ＮＩＣ ＩＦ１１３との組を１組だけ含んでいた。変形例として、ＰＣ１１は、物理ＮＩＣ１１２と物理ＮＩＣ ＩＦ１１３との組を複数組含んでもよい。つまり、ＰＣ１１は、物理的なネットワークに接続される通信の系統を複数有してもよい。この場合、ＰＣ１１は、これら複数の通信系統を同時に使用して通信を行ってもよい。また、ＰＣ１１は、これら複数の通信系統を冗長構成と見做して、いずれかの通信系統に障害などが生じた場合に他の通信系統を用いた通信を行ってもよい。

また、汎用の通信処理装置を、上述した実施形態に係る通信処理装置として機能させることも可能である。具体的には、上述した実施形態に係る通信処理装置の各機能を実現する処理内容を記述したプログラムを通信処理装置のメモリに格納し、通信処理装置のプロセッサによって当該プログラムを読み出して実行させることも可能である。

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

１、２、３ 通信処理装置
１１ ＰＣ
１１１ 物理プロセッサ
１１２ 物理ＮＩＣ
１１３ 物理ＮＩＣ ＩＦ
１２ 仮想化部
１２１ 仮想化部スケジューラ
１２２ 仮想ハードウェア
１２３ 仮想プロセッサ
１２４ 仮想ＮＩＣ
１２５ 仮想ＮＩＣ ＩＦ
１３ ゲストＯＳ
１４ ユーザ空間
１４１−１、１４１−２ アプリケーション部
１４２ リアルタイム通信要求処理共有ライブラリ
１４３ リアルタイム通信ＡＰＩ共有ライブラリ
１４４ アプリケーション代理部
１４５−１、１４５−２ アプリケーション要求処理部
１４６ リアルタイム通信要求タスク内メモリ
１５１ リアルタイム通信部
１５２ リアルタイム通信部インタフェース
１５３ リアルタイム通信通知部
１５４ 送信バッファ
１５５ 自己診断部
１５６ 自己診断指標記憶部
１５７ 診断結果通知部
１５８ 要求バッファ
１６ カーネル空間
１６１ 汎用ＯＳスケジューラ
１６２ リアルタイム通信要求共有メモリ
１６３ 共有メモリ
１７ リソース調整判断部
１７１ 仮想マシン稼働優先順位テーブル
１８ リソース指示部
２０ 制御ネットワーク
２１ コントローラ
２２ ＰＣ
２３ フィールド機器

Claims (6)

1. コンピュータに含まれる仮想化部により実現される複数の仮想マシン上でそれぞれ稼働するアプリケーション部およびリアルタイム通信部と、リソース調整判断部と、を備える生産制御システムにおける通信処理装置であって、
   前記リアルタイム通信部は、通信処理に関する診断指標を検知し、前記診断指標の値が所定の閾値を超えた場合、不安定動作発生の可能性を前記リソース調整判断部に通知し、
   前記リソース調整判断部は、
   前記リアルタイム通信部からの通知を受けた場合、仮想プロセッサに空きがあるか否かを判断し、
   前記仮想プロセッサに空きがある場合、前記不安定動作発生の可能性がある前記仮想マシンに前記仮想プロセッサを追加することを、前記仮想化部に指示し、
   前記仮想プロセッサに空きがない場合、前記不安定動作発生の可能性がある前記仮想マシンに、稼働優先度が低い仮想マシンに割り当てられた仮想プロセッサを追加することを、前記仮想化部に指示する、通信処理装置。
2. 前記リアルタイム通信部は、
   前記診断指標の値が第１の閾値を超えた場合、前記不安定動作発生の可能性を前記リソース調整判断部に通知し、
   前記診断指標の値が第２の閾値を超えた場合、前記アプリケーション部からの通信要求を処理する時間間隔を調整する、請求項１に記載の通信処理装置。
3. 前記アプリケーション部から独立したタスクとして稼働し、前記アプリケーション部からの前記通信要求を受け付け、受け付けた前記通信要求を前記タスク内の専用の記憶部に格納した後に、前記記憶部から取り出した前記通信要求を前記リアルタイム通信部に渡すアプリケーション代理部を備える、請求項１または２に記載の通信処理装置。
4. 前記リアルタイム通信部は、前記アプリケーション部から独立したタスクとして稼働する、請求項１から３のいずれか一項に記載の通信処理装置。
5. コンピュータを、
   請求項１から４のいずれか一項に記載の通信処理装置として機能させるためのプログラム。
6. コンピュータに含まれる仮想化部により実現される複数の仮想マシン上でそれぞれ稼働するアプリケーション部およびリアルタイム通信部をそれぞれ稼働させる生産制御システムにおける通信処理装置を用いた通信処理方法において、
   前記リアルタイム通信部が、通信処理に関する診断指標を検知し、前記診断指標の値が所定の閾値を超えた場合、不安定動作発生の可能性をリソース調整判断部に通知するステップと、
   前記リソース調整判断部が、前記リアルタイム通信部からの通知を受けた場合、仮想プロセッサに空きがあるか否かを判断するステップと、
   前記リソース調整判断部が、前記仮想プロセッサに空きがある場合、前記不安定動作発生の可能性がある前記仮想マシンに前記仮想プロセッサを追加することを、前記仮想化部に指示するステップと、
   前記リソース調整判断部が、前記仮想プロセッサに空きがない場合、前記不安定動作発生の可能性がある前記仮想マシンに、稼働優先度が低い仮想マシンに割り当てられた仮想プロセッサを追加することを、前記仮想化部に指示するステップと、
   を含む通信処理方法。

Images