(58)【調査した分野】(Int.Cl.,DB名)
前記ネットワークに接続されて、前記プロセス制御装置から前記ネットワークを介して通知される動作状態が健全であるか否かを示す判定結果を受信する監視装置を備えることを特徴とする請求項5記載のプロセス制御システム。
【発明を実施するための形態】
【0015】
以下、図面を参照して本発明の実施形態によるプロセス制御装置及びシステム並びにその健全性判定方法について詳細に説明する。
【0016】
〔第1実施形態〕
図1は、本発明の第1実施形態によるプロセス制御システムの要部構成を示すブロック図である。
図1に示す通り、本実施形態のプロセス制御システム1は、複数のフィールド機器10、コントローラ20a,20b(プロセス制御装置)、及び監視装置30を備えており、監視装置30の監視の下でコントローラ20a,20bがフィールド機器10を制御することによって、プラント(図示省略)で実現される工業プロセスの制御を行う。また、本実施形態のプロセス制御システム1では、コントローラ20a,20bの健全性(不正アクセスやウィルス等のサイバー攻撃によってコントローラ20a,20bの動作に異常が生じたか否か)を判定することが可能である。
【0017】
ここで、フィールド機器10及びコントローラ20a,20bはフィールドネットワークN1に接続され、コントローラ20a,20b及び監視装置30は制御ネットワークN2に接続される。尚、
図1では図示の簡略化のために、コントローラ20bと制御ネットワークN2との接続の図示を省略している。フィールドネットワークN1は、例えばプラントの現場に敷設された有線のネットワークである。他方、制御ネットワークN2は、例えばプラントの現場と監視室との間を接続する有線のネットワークである。尚、これらフィールドネットワークN1及び制御ネットワークN2は、無線のネットワークであっても良い。
【0018】
フィールド機器10は、例えば流量計や温度センサ等のセンサ機器、流量制御弁や開閉弁等のバルブ機器、ファンやモータ等のアクチュエータ機器、その他のプラントの現場に設置される機器である。尚、
図1においては、理解を容易にするために、プラントに設置されたフィールド機器10のうちの流体の流量を測定するセンサ機器11と流体の流量を制御(操作)するバルブ機器12とを図示している。
【0019】
フィールド機器10は、コントローラ20a,20bからフィールドネットワークN1を介して送信されてくる制御データに応じた動作を行う。例えば、コントローラ20aからセンサ機器11に測定データ(流体の流量の測定結果を示すデータ)の送信要求が送信されてきた場合には、センサ機器11は、フィールドネットワークN1を介してコントローラ20aに向けて測定データを送信する。また、コントローラ20aからバルブ機器12に対して制御データ(開度を制御するデータ)が送信されてきた場合には、バルブ機器12は、流体が通過する弁の開度を制御データで指示される開度にする。
【0020】
コントローラ20a,20bは、監視装置30の監視の下で定周期処理を行う。ここで、定周期処理とは、コントローラ20a,20bが一定の周期で行う処理をいう。例えば、フィールド機器10(例えば、センサ機器11)からの測定データを一定の周期で収集する処理、フィールド機器10(例えば、バルブ機器12)を制御する制御データを一定周期で演算する処理、或いはフィールド機器10(例えば、バルブ機器12)に制御データを一定周期で送信する処理等の処理が挙げられる。これらコントローラ20a,20bの機能は、ソフトウェアがコンピュータに読み込まれて、ソフトウェアとハードウェア資源とが協働することによって実現される。以下では、コントローラ20aで実現される機能を例に挙げて説明する。
【0021】
コントローラ20aの機能は、MPU(Micro-Processing Unit:マイクロプロセッサ)やメモリ等からなるハードウェア21によって、インストールされたプログラムが実行されることによって実現される。尚、
図1中の「RD1」〜「RD3」は、NIC(Network Interface Card)やI/O(Input/Output)モジュール等のデバイス(実デバイス)を示している。ここで、コントローラ20aには、ハイパーバイザ22(仮想化部)を実現するプログラム、オペレーティングシステム(OS)23a,23b(制御部)を実現するプログラム、及びアプリケーション24a,24b(制御部)を実現するプログラムがインストールされている。
【0022】
上記のハイパーバイザ22は、ハードウェア21上でハードウェアの代わりとして仮想的に動作し、オペレーティングシステム23a及びアプリケーション24aと、オペレーティングシステム23b及びアプリケーション24bとをそれぞれ独立して動作させることを可能にするものである。つまり、ハイパーバイザ22を設けることで、オペレーティングシステム23a,23b及びアプリケーション24a,24bを以下の通り動作させることができる。
・オペレーティングシステム23a及びアプリケーション24aのみの動作
・オペレーティングシステム23b及びアプリケーション24bのみの動作
・オペレーティングシステム23a及びアプリケーション24aと、オペレーティングシステム23b及びアプリケーション24bとの並列動作
【0023】
図1に示す通り、ハイパーバイザ22は、デバイスドライバ41、実デバイストレース情報収集部C10、及び仮想マシーン(VM)42a,42bを備える。デバイスドライバ41は、ハイパーバイザ22の制御の下で、ハードウェア21のデバイス「RD1」〜「RD3」を駆動する。実デバイストレース情報収集部C10は、ハードウェア21(デバイス「RD1」〜「RD3」)とハイパーバイザ22との間で授受される情報をトレースして収集する。
【0024】
仮想マシーン42a,42bは、ハイパーバイザ22の制御の下でオペレーティングシステム23a,23bをそれぞれ動作させる。ここで、仮想マシーン42aは、ハードウェア21のデバイス「RD1」〜「RD3」に対応する仮想デバイス「VD11」〜「VD13」と仮想デバイストレース情報収集部C11とを備えており、仮想マシーン42bは、ハードウェア21のデバイス「RD1」〜「RD3」に対応する仮想デバイス「VD21」〜「VD23」と仮想デバイストレース情報収集部C12とを備えている。上記の仮想デバイストレース情報収集部C11は、オペレーティングシステム23aと仮想マシーン42aとの間で授受される情報をトレースして収集し、上記の仮想デバイストレース情報収集部C12は、オペレーティングシステム23bと仮想マシーン42bとの間で授受される情報をトレースして収集する。
【0025】
また、ハイパーバイザ22は、動作モデル定義部51(格納部)、トレース情報収集部52(第1収集部)、及び健全性判定部53(判定部)を備える。動作モデル定義部51は、コントローラ20aが健全状態である場合(例えば、コントローラ20aに対するサイバー攻撃が行われておらず、コントローラ20aが正常に動作している場合)に、オペレーティングシステム23a,23bやアプリケーション24a,24bの仕様から導かれるコントローラ20aの動作仕様である動作モデル(健全動作情報)を定義する。つまり、この動作モデルで規定されている動作以外の動作は、ウィルス等に起因する不正な動作であるということができる。この動作モデルは、例えばプロセス制御装置20aの提供者(システムベンダ)により作成されて提供される。
【0026】
具体的に、動作モデル定義部51で定義される動作モデルは、以下に示す通り、定周期処理についての「処理の期間に関する仕様」と「処理の特徴に関する仕様」とに大別される。また、後者の「処理の特徴に関する仕様」は、「制御処理仕様」と「通信処理仕様」とに区分される。
【0027】
・「処理の期間に関する仕様」…定周期処理が行われる周期と、その周期内で行われる個々の処理時間(最大時間或いは最小時間)とが規定されたものである。例えば、定周期処理の周期として1[sec]が規定され、この周期内で行われる入力処理、演算処理、出力処理、及び通信処理の処理時間として100[msec]、500[msec]、50[msec]、及び100[msec]がそれぞれ規定される。尚、「処理の期間に関する仕様」には許容できる誤差の範囲(例:±10%、1.9秒〜2.1秒、等)を合わせて規定してもよい。
【0028】
・「処理の特徴に関する仕様」…定周期処理で行われる処理の特徴が規定されたものであって、制御処理内容を規定した「制御処理仕様」と通信処理内容を規定した「通信処理仕様」とからなる。上記「制御処理仕様」は、コントローラ20aで行われる制御処理の内容が規定されたものである。例えば、“センサ機器11からの測定データが入力された場合に、一定時間経過後に制御データがバルブ機器12に出力される”といった内容が規定される。より具体的には、データの入出力方向を示す情報、データの送信元や送信先を示す情報、及びデータの入出力時に経由するデバイス(
図1中のデバイス「RD1」〜「RD3」や、仮想デバイス「VD11」〜「VD13」,「VD21」〜「VD23」)を示す情報が規定される。上記の「通信処理仕様」は、コントローラ20aに入出力されるデータのデータ構造(フォーマット)、通信タイミング、データ量等が規定されたものである。
【0029】
図2は、本発明の第1実施形態における動作モデルの一例を示す図である。尚、
図2に示す動作モデルは、
図3に示す定周期処理が行われる場合のコントローラ20aの動作モデルである。
図3は、本発明の第1実施形態で行われる定周期処理の一例を示す図である。
図3に示す通り、本実施形態で行われる定周期処理は、2秒間隔でコントローラ20bから送信されてくるデータをコントローラ20aが受信し、バルブ機器12及び監視装置30に対してコントローラ20aが4秒間隔でデータをそれぞれ送信するというものである。尚、コントローラ20aから監視装置30へのデータの送信は、コントローラ20aからフィールド機器10へのデータの送信が行われてから0.5秒後に行われる。
【0030】
図2に例示する動作モデルは、「入出力方向」、「相手」、「経由デバイス」、及び「周期」からなる。上記「入出力方向」は、データの入出力方向を示す情報であり、上記「相手」は、データの送受信相手を示す情報であり、上記「経由デバイス」はデータ入出力時に経由するデバイスを示す情報である。また、上記「周期」は、定周期処理の周期を示す情報である。
【0031】
例えば、
図2の上段の動作モデルM1は、2秒間隔でコントローラ20bから送信されてくるデータをコントローラ20aのデバイスRD1で受信(入力)して保持する動作を規定するものである。ここで、保持とは、アプリケーションの定周期処理が処理中に参照できるように、デバイスRD1で受信されたデータをコントローラ20aの内部に格納することを言う。また、
図2の中段の動作モデルM2は、コントローラ20aの仮想デバイスVD11及びデバイスRD3を順に経由したデータを監視装置30に対して4秒間隔で送信(出力)する動作を規定するものであり、
図2の下段の動作モデルM3は、コントローラ20aの仮想デバイスVD13及びデバイスRD2を順に経由したデータをバルブ機器12に対して4秒間隔で送信(出力)する動作を規定するものである。
【0032】
トレース情報収集部52は、ハイパーバイザ22に直接設けられた実デバイストレース情報収集部C10と、ハイパーバイザ22上の仮想マシーン42a,42bに設けられた仮想デバイストレース情報収集部C11,C12とからなり、ハードウェア21とオペレーティングシステム23a,23bとの間で授受される情報をトレースして収集する。例えば、トレース情報収集部52は、アクセスするデバイスの種類、アクセスの種類、アクセス時の入出力データ、アクセス時のタイムスタンプ、及びアクセスの処理結果等を収集する。尚、本実施形態では、理解を容易にするため、二つの仮想マシーンを設ける例を示しているが、ハイパーバイザ22上にさらに多くの仮想マシーンを設けて複数のオペレーティングシステム及びアプリケーションを動作させることもできる。その場合、各仮想マシーンに対応する仮想デバイストレース情報収集部が各仮想マシーン上に設けられる。
【0033】
健全性判定部53は、動作モデル定義部51で定義された動作モデルと、トレース情報収集部52で収集された情報とを比較し、コントローラ20aの健全性を判定する。具体的に、トレース情報収集部52で収集された情報が、動作モデル定義部51で定義された動作モデルに適合する場合には、コントローラ20aが健全状態であると判定する。これに対し、トレース情報収集部52で収集された情報が、動作モデル定義部51で定義された動作モデルに適合しない場合には、コントローラ20aが不健全状態であると判定する。
【0034】
健全性判定部53は、コントローラ20aが不健全状態であると判定した場合には、その旨を監視装置30に通知する。ここで、コントローラ20aが不健全状態であると健全判定部53が判定した場合には、ハイパーバイザ22は、不健全状態であると判定される元となったデータに対する応答がなされないように対処する。例えば、コントローラ20aのデバイスRD1で受信されるべきコントローラ20bからのデータがデバイスRD2で受信された場合には、そのデータを破棄してオペレーティングシステム23a,23bに渡さないようにする。
【0035】
オペレーティングシステム23a,23bは、ハイパーバイザ22の仮想マシーン42a,42b上でそれぞれ動作し、例えばアプリケーション24a,24bを動作させるために必要となるプロセス管理やメモリ管理等の各種管理をそれぞれ行う。オペレーティングシステム23aには、仮想マシーン42aに設けられる仮想デバイス「VD11」〜「VD13」を駆動するデバイスドライバD1が設けられており、オペレーティングシステム23bには、仮想マシーン42bに設けられる仮想デバイス「VD21」〜「VD23」を駆動するデバイスドライバD2が設けられている。
【0036】
アプリケーション24a,24bは、オペレーティングシステム23a,23b上で動作し、プロセスの制御を行う上で必要なフィールド機器10の制御(例えば、センサ機器11からの測定データ等の収集やバルブ機器12に対する制御データの送信等)をそれぞれ行う。尚、本実施形態では、説明を簡単にするために、主としてアプリケーション24aがフィールド機器10の制御を行うものとして説明する。
【0037】
監視装置30は、例えばコンピュータによって実現され、運転員によって操作されてプロセスの監視のために用いられる。具体的に、監視装置30は、コントローラ20aで動作するオペレーティングシステム23a,23bやアプリケーション24a,24bの動作状態のモニタや管理を行い、そのモニタ等の結果に応じて(或いは、運転員の操作指示に応じて)コントローラ20aを制御する。また、監視装置30は、コントローラ20aから制御ネットワークN2を介して通知される判定結果(コントローラ20aの動作状態が健全であるか否かを示す判定結果)を受信する。
【0038】
次に、上記構成におけるプロセス制御システム1の動作について説明する。
図4は、本発明の第1実施形態によるプロセス制御システムの動作の概要を説明するためのフローチャートである。まず、
図4に示す通り、予め作成された動作モデル(オペレーティングシステム23a,23bやアプリケーション24a,24bの仕様から導かれるコントローラ20aの動作仕様)が、ハイパーバイザ22の動作モデル定義部51に格納される(ステップS11:第1ステップ)。動作モデルを動作モデル定義部51に格納する作業は、例えば、アプリケーションの構築者がアプリケーション24a、24bを実現するプログラムをオペレーティングシステム23a、23bにインストールする際、或いは、インストール後のアプリケーション24a、24bの設定(エンジニアリング)を完了させた直後に行われる。
【0039】
以上の作業が終了すると、アプリケーション24aが動作しているときのハードウェア21とオペレーティングシステム23aとの間で授受される情報をトレースして収集する処理がコントローラ20aのトレース情報収集部52で行われる(ステップS12:第2ステップ)。具体的には、ハードウェア21とハイパーバイザ22との間で授受される情報が実デバイストレース情報収集部C10でトレースされて収集され、オペレーティングシステム23aと仮想マシーン42aとの間で授受される情報が仮想デバイストレース情報収集部C11でトレースされて収集される。
【0040】
そして、動作モデル定義部51で定義された動作モデルと、トレース情報収集部52で収集された情報とが健全性判定部53において比較され、コントローラ20aの健全性が判定される(ステップS13:第3ステップ)。具体的に、トレース情報収集部52で収集された情報が、動作モデル定義部51で定義された動作モデルに適合する場合には、健全性判定部53によってコントローラ20aが健全状態であると判定される。これに対し、トレース情報収集部52で収集された情報が、動作モデル定義部51で定義された動作モデルに適合しない場合には、健全性判定部53によってコントローラ20aが不健全状態であると判定される。
【0041】
仮に、コントローラ20aが不健全状態であると判定された場合には、例えばコントローラ20aで受信されたデータ或いはコントローラ20aから送信されようとしているデータがハイパーバイザ22で破棄される。これにより、ハイパーバイザ22が、いわばファイアーウォール(防火壁)として機能するため、受信した不正なデータがオペレーティングシステム23aに渡されること、及び不正なデータが外部に送信されることを防止することができる。また、コントローラ20aが不健全状態であると判定された場合には、その旨がコントローラ20aから監視装置30に通知される。以後、コントローラ20aでは、ステップS12,S13の処理が繰り返し行われる。
【0042】
図5は、本発明の第1実施形態においてトレース情報収集部で収集される情報の一例を示す図であって、(a)はコントローラ20aへのデータ入力がなされた場合に収集される情報の一例を示す図であり、(b)はコントローラ20aからのデータ出力がなされる場合に収集される情報の一例を示す図である。
図5に示す通り、トレース情報収集部52で収集される情報は、
図2に示す動作モデルと同様の「入出力方向」、「相手」、及び「経由デバイス」を示す情報に加えて、情報が収集された時間を示す「収集時間」(タイムスタンプ)からなる。
【0043】
図3に示す通り、2秒間隔でコントローラ20bから送信されてくるデータをコントローラ20aが受信した場合には、例えば
図5(a)に示す情報がトレース情報収集部52で収集される。具体的には、「入出力方向」が入力であり、「相手」がコントローラ20bであり、「経由デバイス」がデバイスRD1(デバイスRD1を経由した後は保持)であることを示す情報に加えて、トレースによって情報収集が行われた時間(「収集時間」)が収集される。ここで、
図5(a)に示す例では、「収集時間」の時間間隔が2秒である点に注意されたい。
【0044】
健全性判定部53は、コントローラ20bからのデータがコントローラ20aで受信された場合には、
図5(a)に示す情報と
図2の動作モデルM1との比較を行って、コントローラ20aの健全性を判定する。
図5(a)に示す例では、「入出力方向」、「相手」、及び「経由デバイス」を示す情報が、
図2の動作モデルM1の「入出力方向」、「相手」、及び「経由デバイス」とそれぞれ一致する。また、
図5(a)における「収集時間」の時間間隔は、
図2の動作モデルM1の「周期」の規定の範囲内である。このため、動作モデルに適合すると言え、
図5(a)に例示する情報が収集された場合には、健全性判定部53は、コントローラ20aの動作状態が健全であると判定する。
【0045】
これに対し、
図3に示す通り、監視装置30に対してコントローラ20aが4秒間隔でデータを送信する場合には、例えば
図5(b)に示す情報がトレース情報収集部52で収集される。具体的には、「入出力方向」が出力であり、「相手」が監視装置30であり、「経由デバイス」が仮想デバイスVD11→デバイスRD3であることを示す情報に加えて、トレースによって情報収集が行われた時間(「収集時間」)が収集される。ここで、
図5(b)に示す例では、「収集時間」の時間間隔が3秒或いは5秒と一定ではない点に注意されたい。
【0046】
健全性判定部53は、コントローラ20aから監視装置30に対してデータが送信される場合には、
図5(b)に示す情報と
図2の動作モデルM2との比較を行って、コントローラ20aの健全性を判定する。
図5(b)に示す例では、「入出力方向」、「相手」、及び「経由デバイス」を示す情報が、
図2の動作モデルM2の「入出力方向」、「相手」、及び「経由デバイス」とそれぞれ一致する。しかしながら、
図5(a)における「収集時間」の時間間隔は一定ではなく、
図2の動作モデルM2の「周期」の規定の範囲外である。このため、動作モデルに適合しないと言え、
図5(b)に例示する情報が収集された場合には、健全性判定部53は、コントローラ20aの動作状態が健全ではないと判定する。
【0047】
尚、以上では、説明を簡単にするために、動作モデル定義部51で定義された動作モデルが「入出力方向」、「相手」、「経由デバイス」、及び「周期」からなるものとして説明した。しかしながら、これらに加えて、データ構造(フォーマット)、通信タイミング、データ量等の「通信処理仕様」が規定された動作モデルを用いることによって、より精度良くコントローラ20aの健全性を判定することができる。
【0048】
以上説明した通り、本実施形態では、オペレーティングシステム23a,23bやアプリケーション24a,24bの仕様から導かれるコントローラ20aの動作仕様である動作モデルを定義し、この定義モデルと、トレース情報収集部52で収集される情報(ハードウェア21とオペレーティングシステム23aとの間で授受される情報)とを比較してコントローラ20aの動作状態が健全であるか否かを判定している。そして、その判定結果に基づいてデータの破棄等の処理を行っている。
【0049】
また、本実施形態では、動作モデルがホワイトリストと同じような役割を果たし、トレース情報収集部52で収集された情報が、動作モデルに適合するか否かによってコントローラ20aの動作状態が健全であるか否かを判定しているため、外部からの不正アクセスやウィルスが既知であるのか、或いは未知であるのかに拘わらず、コントローラ20aの健全性を判定することができる。更に、本実施形態では、ハイパーバイザ22がいわばファイアーウォール(防火壁)として機能するため、オペレーティングシステム23a,23bの脆弱性を突くような不正行為があったとしても、その脆弱性に起因する不具合が生ずることはない。このため、オペレーティングシステムの脆弱性を修正する修正パッチを導入することなく、長期に亘って強固なセキュリティを維持することが可能である。
【0050】
〔第2実施形態〕
図6は、本発明の第2実施形態によるプロセス制御システムの要部構成を示すブロック図である。尚、
図6においては、
図1に示す構成に相当する構成には同一の符号を付してある。
図6に示す通り、本実施形態のプロセス制御システム2は、
図1中のコントローラ20a,20bに代えてコントローラ60a,60bを設けた構成である。
【0051】
これらコントローラ60a,60bは、
図1に示すコントローラ20a,20bが備える動作モデル定義部51に代えて健全状態時データ格納部61(格納部)を設けた構成であり、第1実施形態における動作モデルを作成することなくコントローラ60a,60bの動作状態が健全であるか否かを判定可能にしたものである。尚、以下では、説明を簡単にするために、コントローラ60aを例に挙げて説明する。
【0052】
コントローラ60aに設けられる健全状態時データ格納部61は、コントローラ60aが健全状態である場合に、ハードウェア21とオペレーティングシステム23a,23bとの間で授受されたデータ(健全状態時データ:第1データ)を格納する。尚、コントローラ60aが健全状態であるとは、第1実施形態におけるコントローラ20aが健全状態である場合と同様に、例えばコントローラ60aに対するサイバー攻撃が行われておらず、コントローラ60aが正常に動作している状態をいう。
【0053】
図7は、本発明の第2実施形態における健全状態時データの一例を示す図である。尚、
図7に示す健全状態時データは、
図3に示す定周期処理と同様の動作が行われる場合のものである。
図7に例示する健全状態時データは、「入出力方向」、「相手」、「経由デバイス」、「収集時間」、及び「収集場所」からなる。上記「入出力方向」、「相手」、「経由デバイス」、及び「収集時間」は、
図5に示したものと同様である。但し、
図5における「経由デバイス」には複数のデバイスが規定されていたが、
図7における「経由デバイス」は1つのデバイスのみが規定されている。上記「収集場所」は、健全状態時データの収集が行われた場所を示す情報である。
【0054】
例えば、
図7中の健全状態時データd1,d2,d7,d8は、アプリケーション24aからバルブ機器12に向けたデータの送信(出力)が行われる場合に収集されたデータであり、健全状態時データd3,d4は、アプリケーション24aから監視装置30に向けたデータの送信(出力)が行われる場合に収集されたデータである。また、健全状態時データd5,d6は、コントローラ60bからのデータを受信した場合に収集されたデータである。
【0055】
具体的に、健全状態時データd1は、「入出力方向」が出力であり、「相手」がバルブ機器12であり、「経由デバイス」が仮想デバイスVD13であることを示す情報が、時間00:00′00″00において、仮想デバイストレース情報収集部C11で収集された旨を示すデータである。また、健全状態時データd2は、「入出力方向」が出力であり、「相手」がバルブ機器12であり、「経由デバイス」がデバイスRD2あることを示す情報が、時間00:00′00″30において、実デバイストレース情報収集部C10で収集された旨を示すデータである。
【0056】
次に、上記構成におけるプロセス制御システム2の動作について説明する。
図8は、本発明の第2実施形態によるプロセス制御システムの動作の概要を説明するためのフローチャートである。まず、
図8に示す通り、コントローラ60aが健全状態であるときに、健全状態時データを取得して健全状態時データ格納部61に格納する処理が行われる(ステップS21:第1ステップ)。
【0057】
具体的には、フィールドネットワークN1及び制御ネットワークN2をサイバー攻撃が行われる可能性のあるネットワークから切り離した状態で、
図6に示すプロセス制御システム2を起動させる。そして、サイバー攻撃が行われてないときに、コントローラ60aのハードウェア21とオペレーティングシステム23a,23bとの間で授受されたデータを、健全状態時データとして取得して健全状態時データ格納部61に格納する。尚、健全状態時データの格納が終了すると、格納された健全状態時データが読み取り専用とされ、フィールドネットワークN1及び制御ネットワークN2が切り離される前の状態に戻される。
【0058】
以上の処理が終了すると、第1実施形態と同様に、アプリケーション24aが動作しているときのハードウェア21とオペレーティングシステム23aとの間で授受される情報をトレースして収集する処理がコントローラ60aのトレース情報収集部52で行われる(ステップS22:第2ステップ)。そして、健全状態時データ格納部61に格納された健全状態時データと、トレース情報収集部52で収集された情報とが健全性判定部53において比較され、コントローラ60aの健全性が判定される(ステップS23:第3ステップ)。
【0059】
具体的には、健全状態時データ格納部61に格納された健全状態時データと、トレース情報収集部52で収集された情報とを時系列順に比較する処理(パターンマッチング処理)が健全性判定部53で行われる。これらの内容及び時系列順が一致している場合には、健全性判定部53によってコントローラ60aが健全状態であると判定される。これに対し、これらの内容及び時系列順の少なくとも一方が一致しない場合には、健全性判定部53によってコントローラ60aが不健全状態であると判定される。尚、コントローラ60aが不健全状態であると判定された場合には、第1実施形態と同様にデータを破棄する処理や、監視装置30にその旨を通知する処理が行われる。以後、コントローラ60aでは、ステップS22,S23の処理が繰り返し行われる。
【0060】
図9は、本発明の第2実施形態においてトレース情報収集部で収集される情報の一例を示す図である。
図9に示す通り、トレース情報収集部52で収集される情報は、
図7に示す健全状態時データと同様に、「入出力方向」、「相手」、「経由デバイス」、「収集時間」、及び「収集場所」からなる。
図7に示す健全状態時データと
図9に示すものとを比較すると、
図7中の健全状態時データd6に相当するデータ(
図9中のデータd15とデータd16との間に配置されるべきデータ)が
図9では欠落していることが分かる。このため、
図9に例示する情報が収集された場合には、健全性判定部53は、コントローラ60aの動作状態が不健全であると判定する。
【0061】
以上説明した通り、本実施形態では、コントローラ60aが健全状態であるときにハードウェア21とオペレーティングシステム23aとの間で授受される情報を健全状態時データとして取得し、この健全状態時データとトレース情報収集部52で収集される情報(ハードウェア21とオペレーティングシステム23aとの間で授受される情報)とを比較してコントローラ60aの動作状態が健全であるか否かを判定している。そして、その判定結果に基づいてデータの破棄等の処理を行っている。このため、第1実施形態と同様に脆弱性を突くような不正行為による不具合は生じない。よって、オペレーティングシステムの脆弱性を修正する修正パッチを導入することなく、長期に亘って強固なセキュリティを維持することが可能である。
【0062】
また、本実施形態では、コントローラ60aが健全状態であるときにハードウェア21とオペレーティングシステム23aとの間で授受される情報を健全状態時データとして取得しているため、動作モデルを作成する作業を省略することができる。また、動作モデルを用いる場合よりも多種多様なパターンを用いることができるため、第1実施形態よりも精度の良い判定が可能である。
【0063】
〔第3実施形態〕
図10は、本発明の第3実施形態によるプロセス制御システムに設けられるコントローラの要部構成を示すブロック図である。尚、本実施形態のプロセス制御システムの全体構成は、
図6に示すプロセス制御システム2が備えるコントローラ60a,60bに代えてコントローラ70a,70b(コントローラ70bについては図示を省略している)を設けた構成である。また、
図10においては、
図6に示す構成に相当する構成には同一の符号を付してある。
【0064】
図10に示す通り、本実施形態のプロセス制御システムに設けられるコントローラ70aは、
図6に示すコントローラ60aのオペレーティングシステム23a,23bにトレース情報収集部C21,C22(第2収集部)をそれぞれ追加した構成である。かかる構成のコントローラ70aは、
図6に示すコントローラ60aよりも精度の良い判定を可能とするとともに、定周期処理ではない処理(非定周期処理)を行う場合にもコントローラ70aの動作状態が健全であるか否かを判定可能にしたものである。
【0065】
トレース情報収集部C21は、オペレーティングシステム23aとアプリケーション24aとの間で授受される情報をトレースして収集し、トレース情報収集部C22は、オペレーティングシステム23bとアプリケーション24bとの間で授受される情報をトレースして収集する。ここで、第2収集部が収集する前記授受される情報にはアプリケーションの処理としてオペレーティングシステムに対して行うシステムコールの情報、例えば、呼び出されたシステムコールの種類が含まれる。これらトレース情報収集部C21,C22で収集されたデータは、トレース情報収集部52で収集されたデータとともにハイパーバイザ22の健全状態時データ格納部61又は健全性判定部53に出力される。
【0066】
具体的に、コントローラ70aが健全状態である場合にトレース情報収集部C21,C22で収集されたデータは、トレース情報収集部52で収集されたデータとともに、健全状態時データとして健全状態時データ格納部61に格納される。また、健全状態時データが健全状態時データ格納部61に格納された後においては、トレース情報収集部C21,C22で収集されたデータは、トレース情報収集部52で収集されたデータとともに、健全性判定部53において健全状態時データと比較される。
【0067】
次に、上記構成のコントローラ70aで非定周期処理が行われる場合の動作について説明する。尚、コントローラ70aで定周期処理が行われる場合の動作と、コントローラ70aで非定周期処理が行われる場合の動作とは基本的に同じである。
図11は、本発明の第3実施形態で行われる非定周期処理の一例を示す図である。
図11に例示する非定周期処理は、監視装置30が、工場プロセスの制御を監視する際、監視表示を行うための情報(監視表示情報)を収集する動作として行われるものである。
【0068】
具体的に、監視装置30からコントローラ70aに対して監視表示情報の取得要求が非同期で送信されると(ステップS31)、コントローラ70aでは、その監視表示情報の取得要求を受信する受信処理(ステップS32)、監視表示情報を生成する生成処理(ステップS33)が行われ、前記生成処理中に、センサ機器11から測定データを取得する取得処理(ステップS34)、及び監視表示情報を送信する送信処理(ステップS35)が行われる。
【0069】
上記受信処理(ステップS32)では、ハードウェア21で受信されてデバイスRD3及び仮想デバイスVD11を介した監視表示情報の取得要求が、割込処理によってオペレーティングシステム23aからアプリケーション24aに出力される。アプリケーション24aが行う出力の受信には、例えば、割り込みハンドラやシグナルハンドラを用いる。
【0070】
出力を受け取ったアプリケーション24aは、(例えば、IPC(Inter Process Communication)の)システムコールを用い、上記取得要求に対応する上記生成処理(ステップS33)を起床(wakeup)する。生成処理では、上記取得処理(ステップS34)で取得された測定データを用いてアプリケーション24aで監視表示情報が生成される。生成された監視表示情報は、上記送信処理(ステップS35)により、コントローラ70aの外部へ出力される。
【0071】
上記取得処理(ステップS34)では、アプリケーション24aがシステムコールを呼び出し、データ読出要求(read)をオペレーティングシステム23aに出力する。このデータ読出要求に基づき、仮想デバイスVD12及びデバイスRD2を介してセンサ機器11から測定データが取得される。上記送信処理(ステップS35)では、アプリケーション24aがシステムコールを呼び出し、データ書込要求(write)をオペレーティングシステム23aに出力する。このデータ書込要求に基づき、仮想デバイスVD11及びデバイスRD3を介して監視表示情報が出力される。尚、コントローラ70aから出力された監視表示情報は、制御ネットワークN2を介して監視装置30に送信される(ステップS36)。
【0072】
図12は、本発明の第3実施形態においてトレース情報収集部で収集される情報の一例を示す図である。尚、
図12に示す情報は、
図11に示す非同期処理が行われたときにトレース情報収集部52及びトレース情報収集部C21で収集される情報である。この情報には経由デバイスとともに経由システムコールとして、呼び出されたシステムコールの種類が、相手としてシステムコールを作用させた対象が記録される。このような情報が収集されると、第2実施形態と同様に、健全性判定部53において、健全状態時データ格納部61に格納されている健全状態時データと比較され、コントローラ70aが健全であるか否かが判定される。尚、コントローラ70aが不健全状態であると判定された場合には、第2実施形態と同様にデータを破棄する処理や、監視装置30にその旨を通知する処理が行われる。
【0073】
以上説明した通り、本実施形態では、コントローラ70aが健全状態であるときに、ハードウェア21とオペレーティングシステム23aとの間で授受される情報と、オペレーティングシステム23aとアプリケーション24aとの間で授受される情報とを健全状態時データとして取得している。そして、この健全状態時データとトレース情報収集部52で収集される情報及びトレース情報収集部C21で収集される情報とを比較してコントローラ70aの動作状態が健全であるか否かを判定している。そして、その判定結果に基づいてデータの破棄等の処理を行っている。このため、第2実施形態と同様に、オペレーティングシステムの脆弱性を修正する修正パッチを導入することなく、長期に亘って強固なセキュリティを維持することが可能である。
【0074】
また、本実施形態では、ハードウェア21とオペレーティングシステム23aとの間で授受される情報に加えて、オペレーティングシステム23aとアプリケーション24aとの間で授受される情報を健全状態時データとしている。このため非定周期で処理されたアプリケーション24aの動作とその種類に、オペレーティングシステム23aやハードウェア21の動作を対応付けて確認することができる。これにより、非定周期処理においても、コントローラ70aの動作状態の健全性を判定することができる。
【0075】
尚、本実施形態では、理解を容易にするため、第2収集部がシステムコールの情報として、呼び出されたシステムコールの種類をトレースするとして説明を行ったが、システムコールの情報として、システムコールの呼び出しに用いた引数の種類や値、システムコールの戻り値等の情報も合わせてトレースし、健全性の判定に用いてもよい。
【0076】
また、本実施形態では、アプリケーションとオペレーティングシステムとの間で情報が授受されるタイミングをシステムコールとしている。アプリケーションは自らの処理を遂行するために、システムコールを必ず行うため、タイミングをシステムコールとすることにより、アプリケーションをトレースに対応させるための特別な改造や機能追加が不要となるという効果がある。
【0077】
逆に、アプリケーションの改造や機能追加が許容される場合は、意図的にオペレーティングシステムとの間で情報を授受するタイミング(トレースポイント)を設けることにより、アプリケーション動作のトレースを詳細化し、健全性の判定をより精密に行えるようにしてもよい。例えば、システムコール以外にトレースポイントを
・サブルーチン・関数のコール/リターン地点
・条件分岐等の分岐と分岐処理の合流点
・繰り返し処理の先頭と末尾
・アプリケーションとして重要なデータ(変数)の内容変更処理の前後
等に設けることで、トレースを詳細化できる。
【0078】
尚、上述した第2,第3実施形態において、健全状態時データ格納部61に健全状態時データを格納する際に、健全状態時データの「収集時間」に対し、一致とみなしてよい時間の誤差の範囲(例:±10%、1.9〜2.1秒、等)を別途定義してから格納してもよい。
【0079】
〔第4実施形態〕
図13は、本発明の第4実施形態によるプロセス制御システムに設けられるコントローラの概略構成を示すブロック図である。尚、本実施形態のプロセス制御システムの全体構成は、
図1に示すプロセス制御システム1が備えるコントローラ20a,20bに代えてコントローラ80a,80b(コントローラ80bについては図示を省略している)を設けた構成である。また、
図13においては、
図1に示す構成に相当する構成には同一の符号を付してある。
【0080】
図13に示す通り、本実施形態のプロセス制御システムに設けられるコントローラ80aは、
図1に示すコントローラ20aのハードウェア21を、複数のMPU81〜83(処理装置)を備えるハードウェア21としたものである。ここで、MPU81〜83は、プロセッサ・コアを意味しており、それぞれ異なるパッケージとして実装される形態(シングルコア)であっても良く、全てが1つのパッケージとして実装される形態(マルチコア)であっても良い。
【0081】
本実施形態におけるコントローラ80aの機能は、各機能を実現するプログラムが、MPU81〜83の何れかで実行されることによって実現される。例えば、ハイパーバイザ22(動作モデル定義部51、トレース情報収集部52、及び健全性判定部53を含む)は、これらを実現するプログラムがMPU81で実行されることによって実現される。また、オペレーティングシステム23a及びアプリケーション24aは、これらを実現するプログラムがMPU82で実行されることによって実現され、オペレーティングシステム23b及びアプリケーション24bは、これらを実現するプログラムがMPU83で実行されることによって実現される。尚、プログラムを実行させるMPU81〜83の割り当ては、例えばハイパーバイザ22が行う。
【0082】
このように、コントローラ80aの各機能を実現するプログラムを複数のMPU81〜83で実行させることにより、コントローラ80aに対するDoS(Denial of Services)攻撃がなされたとしても、コントローラ80aの性能劣化やサービス停止が生ずるといった事態を防止することができる。つまり、DoS攻撃はMPU81で処理され、アプリケーション24a等の処理を行うMPU82,83の負荷が増加することはないため、コントローラ80aの性能劣化等が生じない。
【0083】
尚、上述したコントローラ80aは、
図1に示す第1実施形態におけるコントローラ20aのハードウェア21を、複数のMPU81〜83を備えるハードウェア21としたものであった。しかしながら、
図6に示す第2実施形態におけるコントローラ60aや
図10に示す第3実施形態におけるコントローラ70aのハードウェア21を、複数のMPU81〜83を備えるハードウェア21とすることも可能である。
【0084】
以上、本発明の実施形態によるプロセス制御装置及びシステム並びにその健全性判定方法について説明したが、本発明は上述した実施形態に制限されることなく、本発明の範囲内で自由に変更が可能である。例えば、上記実施形態では、複数のオペレーティングシステムやアプリケーションを動作させ得る仮想環境をハイパーバイザ22によってコントローラ20a,60a,70a,80aに実現する例について説明したが、このような仮想環境を実現する手段はハイパーバイザ22に限られるものではない。例えば、上記の仮想環境をハードウェアによって実現しても良い。
【0085】
また、上述した実施形態では、フィールド機器10がフィールドネットワークN1を介したディジタル通信が可能なものを例に挙げて説明したが、アナログ信号の入出力を行うフィールド機器を用いることもできる。このようなフィールド機器を用いる場合には、フィールド機器で入出力される信号(アナログ信号)とフィールドネットワークN1を介して通信される信号(ディジタル信号)との変換を行うIOノードをフィールドネットワークN1に接続し、このIOノードとフィールド機器とをアナログ伝送路(例えば、「4〜20mA」信号の伝送に使用される伝送線)で接続すれば良い。
【0086】
また、上述した実施形態では、動作モデル定義部51(健全状態時データ格納部61)、トレース情報収集部52、及び健全性判定部53がハイパーバイザ22に設けられた構成について説明した。しかしながら、これらは仮想マシーン42a,42b毎に設けられていても良い。また、動作モデル定義部51(健全状態時データ格納部61)は、例えばハードディスクの記録装置や半導体メモリ等の記憶装置に設けられていても良い。
【0087】
また、上述した第2,第3実施形態では、コントローラ60a,70aが健全状態である場合に健全状態時データを予め取得する例について説明した。しかしながら、健全状態時データを取得した後においても、改めて健全状態時データを取得(追加取得)するようにしても良い。このようにすることで、仕様の変化等によってコントローラ60a,70aで実行されるアプリケーション23a,23bの挙動が変化した場合であっても、支障なく健全性の判定を行うことが可能になる。
【0088】
また、上述した第1,第2,第3実施形態では、理解を容易にするため、仮想デバイスVD11〜VD13と実デバイスRD1〜RD3、仮想デバイスVD21〜VD23と実デバイスRD1〜RD3がそれぞれ一対一に対応するとして説明したが、仮想デバイスの設計によっては、一つの仮想デバイスに複数の実デバイスを対応させる構成、若しくは、複数の仮想デバイスに一つの実デバイスを対応させる構成も考えられる。このような構成であっても、仮想デバイス、実デバイスに対応したトレース情報を収集できることに代わりはなく、上述した第1,第2,第3実施形態と同様に、コントローラの動作状態の健全性を確認できる。