WO2013105554A1

WO2013105554A1 - 制御装置監視システムおよび制御装置の監視方法

Info

Publication number: WO2013105554A1
Application number: PCT/JP2013/050130
Authority: WO
Inventors: 尚寺江; 清水　勝人; 直也益子
Original assignee: 株式会社日立製作所
Priority date: 2012-01-12
Filing date: 2013-01-08
Publication date: 2013-07-18
Also published as: JP2013143077A; CN104054087A; IN2014DN05825A; JP5756412B2

Abstract

　ＰＬＣ（１）の動作状態を監視するため、制御対象（５）を制御する複数のＰＬＣ（１）の動作状態を監視するＰＬＣ監視システム（１０）であって、ＰＬＣ（１ｂ）は、自身とは別のＰＬＣ（１ａ）から、このＰＬＣ（１ａ）で実行されているユーザプログラムが出力した制御命令を取得し、取得した制御命令を基に、検証用データを生成することを特徴とする。そして、ＰＬＣ（１ｂ）は、検証用データを用いて、制御命令の送信元のＰＬＣ（１ａ）がウィルスに感染していないか否かを検証したり、検証用データをＰＣ（２）へ送信し、ＰＣ（２）がこの検証用データを表示装置に表示することで、ユーザがＰＬＣ（１ａ）のウィルスの感染を検証したりする。

Description

制御装置監視システムおよび制御装置の監視方法

　本発明は、制御装置の動作を監視する制御装置監視システムおよび制御装置の監視方法に関する。

　コンピュータウィルスなどの悪意のあるソフトウェア（以下、ウィルスと称する）はこれまで、一般的なパーソナルコンピュータ（以下、ＰＣ（Personal Computer）と称する）において脅威となる存在であった。このようなウィルスの代表的なものとしてトロイの木馬などが知られている。これらのウィルスはＦＤ（Flexible Disk）などの外部媒体、メール、インターネット上のＷｅｂサイトなどのさまざまな経路からコンピュータに侵入し、不正に情報を盗み出したり、情報を書き換えたりするなどの動作を行う。前記したように、このようなウィルスの脅威は、従来ＰＣにおいてのみ認知されていたが、近年、プログラマブルロジックコントローラ（以下、ＰＬＣ（programmable logic controller)と称する）においても、その感染例が報告されている。例えばｓｔｕｘｎｅｔなどは、ＵＳＢ（Universal Serial Bus）メモリなどを介して開発用ＰＣに侵入し、開発用ＰＣからＰＬＣへユーザプログラムをダウンロードするときにウィルスがＰＬＣに仕込まれる。そのため、ＰＬＣにおいても、ウィルス対策が求められてきている。

　ＰＬＣはプラント制御など、特定の目的に限定して利用される計算機である。このようなＰＬＣでは、ユーザが開発用ＰＣ上でユーザプログラムを生成し、そのユーザプログラムが開発用ＰＣからＰＬＣへダウンロードされる。ここで、開発用ＰＣがウィルスに感染していると、ユーザプログラムのダウンロード時に、開発用ＰＣ上のウィルスがＰＬＣにダウンロードされてしまうおそれがある。

　また、障害に備えて、同一のユーザプログラムを搭載した複数のＰＬＣによる多重化構成が運用されることも多く、その多重化構成を利用したソフトウェアの信頼性向上技術が多く考案されている。

　例えば、特許文献１には複数のプロセッサを備え、主として通信処理を行うプロセッサと、制御対象機器の制御を行うプロセッサとを独立させているコントローラおよびその制御方法が開示されている。
　また、特許文献２にはデータを所定のデータ量に分割し、分割されたそれぞれのデータから認証データを生成し、この認証データに対して２項演算を行い、演算結果と期待値が一致するか否かで認証を行う電子機器、遊技機、主制御基板、周辺基板、認証方法および認証プログラムが開示されている。

　さらに、特許文献３にはシステムバス制御装置と、メモリ装置を２重化している２重化メモリシステムが開示されている。
　そして、特許文献４には、ユーザプログラムの命令のＮ周期前から現在までのすべての入力値データおよび出力値データを用いて、制御プログラムの命令実行結果データの表示を行うプロセス制御コントローラの故障解析支援システムが開示されている。

特開２００４－０９４４７３号公報特開２０１１－０３０６０７号公報特開平０８－０１６４８４号公報特開２００１－０１４０２７号公報

　ウィルスは、ユーザに気づかれないようにプラントなどの制御対象を操作し、制御対象の誤動作や事故を発生させる。そのため、ウィルスは制御対象を管理・保有するユーザや、その制御対象を利用するエンドユーザに対して好ましくない影響をもたらすおそれがある。しかしながら、インターネットなどの外部の回線に接続されていないＰＬＣに対するウィルスの侵入方法は、ＰＣに比べると限定的である。例えば、ソフトウェア開発用のＰＣ（開発用ＰＣ）や、運用管理用のＰＣからソフトウェア更新のためのダウンロードの際にウィルスの侵入を許してしまうことが多いと考えられる。

　このような背景に鑑みて本発明がなされたのであり、本発明は、ＰＬＣの動作状態を監視することを課題とする。

　前記した課題を解決するため、本発明は、制御対象を制御する制御装置を複数備える制御装置監視システムにおいて、前記制御装置は、自身とは別の制御装置から、前記別の制御装置で実行されているプログラムが出力した、前記制御対象を制御する制御情報を取得し、前記取得した制御情報を基に、動作検証用のデータを生成する制御部を有することを特徴とする。
　その他の解決手段は、実施形態中で適宜説明する。

　本発明によれば、ＰＬＣの動作状態を監視することができる。

第１実施形態に係るＰＬＣ監視システムの構成図である。第１実施形態に係るＰＬＣのハードウェア構成例を示す図である。第１実施形態に係るＰＣのハードウェア構成例を示す図である。第１実施形態に係るＰＬＣ監視システムにおける情報の流れを示す図である。第１実施形態に係るＰＬＣ監視処理の動作例を示すタイミングチャートである。第１実施形態に係るＰＬＣ監視処理の別の動作例を示すタイミングチャートである。第１実施形態に係るＰＬＣ監視システムに用いられるフレームのフォーマット例を示す図である。第１実施形態に係るＰＬＣにおけるフレーム送信処理の詳細な手順を示すフローチャートである。第１実施形態に係るＰＬＣにおけるフレーム受信後処理の手順を示すフローチャートである。第１実施形態に係るＰＬＣ監視システムによる検証用データをグラフ化した例を示す図である。第１実施形態に係る監視プログラムテーブル更新処理の手順を示すフローチャートである。第１実施形態に係る監視プログラムテーブルの構成例を示す図である。第２実施形態に係るＰＬＣ監視処理の動作を示すタイミングチャートである。第３実施形態に係るＰＬＣ監視システムにおける情報の流れを示す図である。

　次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。

［第１実施形態］
（構成）
　図１は、第１実施形態に係るＰＬＣ監視システムの構成図である。
　制御装置監視システムであるＰＬＣ監視システム１０は、制御装置であるＰＬＣ１（１ａ，１ｂ）、管理装置である開発用ＰＣ（以下、単にＰＣ２と称する）、ＨＵＢ（機器）３、ＰＩ／Ｏ（Process Input/Output：機器）４、制御対象５を有している。
　ＰＬＣ１およびＰＣ２については、詳細を後記する。
　ＰＬＣ監視システム１０では、２重化構成となっているＰＬＣ１ａ，１ｂが、フィールドネットワーク７を介して、ＨＵＢ３に接続している。ここで、後記するように、ＨＵＢ３は、フィルタリングやネットワークの中継などを行う。ここでのフィルタリングは、後記するスレーブのＰＬＣ１から送信されたフレームのＰＩ／Ｏ４通過を許可しないが、後記するマスタのＰＬＣ１から送信されたフレームのＰＩ／Ｏ４通過を許可するといった機能を指す。また、ネットワークの中継とはＨＵＢ３が一方のＰＬＣ１から受信した制御命令（制御情報）を、ＰＩ／Ｏ４へ送信するとともに、他方のＰＬＣ１にも送信する機能を指す。

　ＨＵＢ３は、フィールドネットワーク８を介して、制御対象５を制御する装置であるＰＩ／Ｏ４に接続している。
　ＰＩ／Ｏ４には機能の異なる複数デバイス（機器）が搭載されており、それぞれのデバイスは固有の機器番号によって管理されているものとする。ＰＬＣ１は機器番号が指定されることでどのデバイスにもアクセスが可能である。
　また、各ＰＬＣ１には、ソフトウェアの更新やリモート制御を行うためのＰＣ２がフィールドネットワーク６を介して接続されている。
　前記の構成は制御システムとしては一般的な構成である。

　ここで、ＰＬＣ１ａ，１ｂの一方が制御対象５を制御する権利（マスタ権）を持った主系（以下、主系となっているＰＬＣ１を適宜マスタと称する）となり、他方がマスタ権を持たない従系（以下、従系となっているＰＬＣ１を適宜スレーブと称する）となる。そして、マスタが障害などで動作継続不可能になったときは、マスタ・スレーブ関係を切り替えることができる。

　まず、最初にＰＬＣ１ａがマスタ、ＰＬＣ１ｂがスレーブとなっているものとする。スレーブのＰＬＣ１ｂがマスタのＰＬＣ１ａの突発的な切替要求に対応できるようにするため、ＰＬＣ１ｂはＰＬＣ１ａがメモリに持っているデータや生存状態をフィールドネットワーク７を使って取得する。

　ここで、本実施形態におけるフィールドネットワーク７，８の通信方式は、フレーム単位でデータを送信するものとする。すなわち、一方のＰＬＣ１ｂがＰＩ／Ｏ４や、他方のＰＬＣ１ａなどの送信先の装置に対して、フレーム単位でフィールドネットワーク７の回線を介してデータを送信し、その宛先となっている送信先の装置が、送信されたフレームを受信するような方式である。

　前記したように、ＨＵＢ３はフィールドネットワーク７，８を中継し、フレームを監視する。ＰＬＣ１およびＰＩ／Ｏ４には、固有のアドレスが付与されており、そのアドレスをフレームのヘッダ情報に付与して送信している。フレームには、後記するように、フレームのヘッダ、あるいはデータ部分に、送信元のＰＬＣ１がマスタであるかスレーブであるかを示すマスタ識別子を付加することができる。このマスタ識別子により、ＨＵＢ３は制御対象５の制御権を持つマスタから送信されたフレームのみをＰＩ／Ｏ４へ送信し、スレーブから送信されたフレームをＰＩ／Ｏ４に送信できないようにするフィルタリング機能を実現する。

　図１に示すように、ＰＬＣ１が多重化構成になっていれば、その多重系におけるＰＬＣ１のうちの１つをソフトウェアの更新のために停止しても、他のＰＬＣ１は動作継続している。ＰＬＣ１へのソフトウェアの更新が、フィールドネットワーク６を経由したダウンロードによるものであれば、ダウンロードを実行するＰＬＣ１のアドレスのみを指定することで、動作継続中の他のＰＬＣ１に影響を与えずソフトウェアの更新が可能である。そのため、ウィルスは、ユーザプログラム１１２（図３）をダウンロードするために停止しているＰＬＣ１に侵入する可能性があるが、動作継続中のＰＬＣ１には侵入しないことになる。この時点では、動作継続中で健全なＰＬＣ１と、ウィルスの感染の可能性があるＰＬＣ１とが両立した状態となり、それら２種類のＰＬＣ１の状態を比較すれば、ウィルスの感染を特定することができる。本実施形態では、健全である動作継続中のＰＬＣ１によって、ダウンロード実施直後のＰＬＣ１の動作を検証することでウィルスの感染を特定する。

（ＰＬＣの構成）
　図２は、第１実施形態に係るＰＬＣのハードウェア構成例を示す図である。
　ＰＬＣ１は、メインメモリ１１０、ＣＰＵ（Central Processing Unit）１２０、入力装置１３０、出力装置１４０、記憶装置１５０を有している。
　メインメモリ１１０には、制御プログラム（制御部、送信側の制御部、受信側の制御部）１１１、ユーザプログラム１１２、ＰＩ／Ｏドライバ１１３、マスタ権制御プログラム１１４、データ生成プログラム１１５、検証プログラム１１６などが展開され、ＣＰＵ１２０によって実行されている。
　制御プログラム１１１は、各プログラム１１２～１１６を統括制御したり、監視プログラムテーブル１５１の更新を行ったりする。つまり、各プログラム１１２～１１６は制御プログラム１１１上で実行されるプログラムである。制御プログラム１１１は、例えばＯＳ（Operating System）などである。

　ユーザプログラム１１２は、制御対象５を制御するためのプログラム（制御装置で実行されているプログラム）であり、ユーザによってＰＣ２（図１）で開発され、ＰＬＣ１へダウンロードされる。
　ＰＩ／Ｏドライバ１１３は、ＰＩ／Ｏ４を制御するためのドライバである。ＰＩ／Ｏドライバ１１３はＰＩ／Ｏ４宛の送信フレームを生成して送信する処理と、ＰＩ／Ｏ４からのフレームを受信する処理を行う。二重化構成のＰＬＣ１では、ＰＩ／Ｏ４からＰＬＣ１宛の送信フレームだけでなく、相手系ＰＬＣ１が送信したＰＩ／Ｏ４宛の送信フレーム、相手系ＰＬＣ１から自系ＰＬＣ１宛の送信フレームを処理できるようになっている。
　マスタ権制御プログラム１１４は、マスタ権の切り替えを行う。なお、ＰＣ２がマスタ権の制御を行ったり、ユーザによる手動でのマスタ権の切り替えが行われる場合、ＰＬＣ１におけるマスタ権制御プログラム１１４は省略可能である。

　データ生成プログラム１１５は、ウィルスの感染検証（以下、単に「検証」と称する）を行うためのデータである動作検証用のデータ（検証用データ２５１（図３））などを生成する。
　検証プログラム１１６は、データ生成プログラム１１５で生成された検証用データ２５１などを基に、ＰＬＣ１がウィルスに感染しているか否かを検証するプログラムである。なお、検証がＰＣ２で行われる場合、検証プログラム１１６は省略可能である。
　また、記憶装置１５０には、後記する監視プログラムテーブル１５１が格納されている。
　検証がＰＬＣ１で行われる場合、図３の検証用データ２５１が生成され、記憶装置１５０に保存されることがある。
　なお、本ハードウェア構成はメインメモリ１１０と記憶装置１５０とを明示的に分離しているが、記憶装置１５０に格納される情報がメインメモリ上に存在しているような構成でも本実施形態は実現可能である。

（ＰＣの構成）
　図３は、第１実施形態に係るＰＣのハードウェア構成例を示す図である。
　ＰＣ２は、メインメモリ２１０、ＣＰＵ２２０、入力装置２３０、表示装置２４０、記憶装置２５０を有している。
　メインメモリ２１０には、制御プログラム（制御部）２１１、ダウンロードプログラム２１２、検証プログラム２１３などが展開され、ＣＰＵ２２０によって実行されている。
　制御プログラム２１１は、各プログラム２１２，２１３を統括制御する。つまり、各プログラム２１２，２１３は制御プログラム２１１上で実行されるプログラムである。制御プログラム２１１は、例えばＯＳなどである。
　ダウンロードプログラム２１２は、記憶装置２５０に格納されているユーザプログラム１１２をＰＬＣ１（図１）へダウンロードする。
　検証プログラム２１３は、ＰＬＣ１から送られてきた検証用データ２５１などを基に、ＰＬＣ１がウィルスに感染しているか否かを検証するプログラムである。なお、検証がＰＬＣ１で行われる場合、検証プログラム２１３は省略可能である。
　また、記憶装置２５０には、ユーザによって開発されたユーザプログラム１１２と、ＰＬＣ１から送信された検証用データ２５１などが格納されている。
　検証用データ２５１はウィルス感染の疑いのあるユーザプログラム１１２に関する挙動を記録したデータである。詳細は後記するが、検証用データ２５１はＰＬＣ１にてユーザプログラム１１２の挙動を監視した結果である監視プログラムテーブル１５１から、ＰＩ／Ｏ４への出力値などの特定の情報を抽出したものである。検証用データ２５１の具体例は図１０で後記する。

（情報の流れ）
　図４は、第１実施形態に係るＰＬＣ監視システムにおける情報の流れを示す図である。なお、図４における符号は、図１と同様であり、それぞれの構成要素についての説明を省略する。
　ここで、ＰＣ２で格納されているユーザプログラム１１２がウィルスに感染しているものとする。なお、図４において、ウィルスに感染している機器をドットで示すこととする。
　まず、ユーザプログラム１１２のダウンロード開始前に、ＰＬＣ１ａが一時停止し、各ＰＬＣ１ａ，１ｂの制御プログラム１１１で実行されているマスタ権制御プログラム１１４が、マスタ権をＰＬＣ１ａからＰＬＣ１ｂへ移す。
　マスタ権の移動後、自身のソフトウェアの更新のため、ＰＬＣ１の制御プログラム１１１は、ＰＣ２のダウンロードプログラム２１２と連携してＰＣ２からＰＬＣ１ａへユーザプログラム１１２のダウンロードを行う（Ｓ１０１）。このとき、ウィルスに感染しているユーザプログラム１１２がＰＬＣ１ａにダウンロードされ、ＰＬＣ１ａがウィルスに感染する。

　ここで、前記したように、ＨＵＢ３は、マスタ（ＰＬＣ１ｂ）から送信されるフレームをＰＩ／Ｏ４へ送るが（Ｓ１０２，Ｓ１０３）、スレーブから送信されるフレーム（Ｓ１０４）をＰＩ／Ｏ４へ送らない。つまり、ＨＵＢ３はマスタ・スレーブ両方からフレームを受信しても、受信フレーム内のマスタ識別子を参照してマスタになっているＰＬＣ１からのフレームをＰＩ／Ｏ４へ送信する。
　また、ＨＵＢ３は各ＰＬＣ１から送信されたフレームを別のＰＬＣ１へ転送する（Ｓ１０５、Ｓ１０６）。この動作は受信したフレームのマスタ識別子に関係なく、ＰＬＣ１ａからの受信フレームをＰＬＣ１ｂへ、ＰＬＣ１ｂからの受信フレームをＰＬＣ１ａへ送信する。

　ＨＵＢ３からフレームを転送された各ＰＬＣ１は、転送されたフレーム（別のＰＬＣ１から送信されたフレーム）を用いて、検証用データ２５１を生成したり、この検証用データ２５１を使用してウィルスの検証を行う。そして、各ＰＬＣ１は、検証用データ２５１や、感染検証の結果をＰＣ２へ送信する（Ｓ１０７，Ｓ１０８）。
　なお、ＨＵＢ３は前記したようなフィルタリング機能やネットワーク中継機能を有する装置であれば代用可能である。例えば、ＰＬＣ１自身がフレームの送信元がマスタかスレーブかを判定して、マスタならばＰＩ／Ｏ４と相手系ＰＬＣ１に送信し、スレーブならば相手系ＰＬＣ１にのみ転送するようにしてもよい。あるいは、ＰＬＣ１をＨＵＢ３に置き換えて、ＰＬＣ１がフィルタリングやネットワーク中継のためのプログラムを動作させてもよい。

　図５は、第１実施形態に係るＰＬＣ監視処理の動作例を示すタイミングチャートであり、ＰＣ２がウィルスに感染している状態から開始している。なお、図５におけるＰＬＣ１の処理は、ＰＬＣ１における制御部としての制御プログラム１１１が行う処理である。

　ＰＬＣ１ａが一時停止して、マスタ権をＰＬＣ１ｂへ移し、ＰＬＣ１ｂがマスタ、ＰＬＣ１ａがスレーブとなる。
　そして、ＰＣ２は、ＰＬＣ１ａへユーザプログラム１１２を送信し（Ｓ２０１）、ＰＬＣ１ａは送信されたユーザプログラム１１２を受信する（Ｓ２０２）。このとき、ＰＣ２からＰＬＣ１ａへウィルスが感染したとする。一方、ＰＬＣ１ｂはダウンロードを行っていないため、ウィルスには感染していない。以降、ＰＬＣ１ａを「感染ＰＬＣ」、ＰＬＣ１ｂを「正常ＰＬＣ」と適宜称することがある。

　前記したように、ＰＬＣ１ａはソフトウェア更新のために一時停止し、マスタ権をＰＬＣ１ｂへ移すことによって、ＰＬＣ１ｂがマスタ、ＰＬＣ１ａがスレーブとなっている。
　ＰＣ２からのダウンロード終了後、ＰＬＣ１ａが再起動されるが、ウィルスの検証処理が終了するまで、ＰＬＣ１ｂがマスタ、ＰＬＣ１ａがスレーブのままとなるよう設定されている。
　ウィルスがＰＬＣ１に感染した場合、ＰＬＣ１内部のメモリ（図２のメインメモリ１１０）やストレージ（図２の記憶装置１５０）の破壊、他の制御装置への感染なども脅威となるが、最も脅威となる挙動は、制御対象５（図１）への不正な操作である。ＰＬＣ１が制御する制御対象５は、発電プラントなどの、誤動作による影響が大きいものが含まれるため、制御対象５の不正な操作は最優先で防止すべきである。
　ＰＬＣ１が制御対象５の操作を行うには、ＰＩ／Ｏ４を操作する必要がある。そのため、本実施形態の構成においては、ウィルスに感染したＰＬＣ１ａが不正な制御命令をＰＩ／Ｏ４に発行して、そのＰＩ／Ｏ４がその制御命令を実行して不正な出力を制御対象５に発することを防止する必要がある。

　前記したように、ＰＬＣ１ａは、スレーブなので、ＰＬＣ１ａのユーザプログラム１１２が制御命令を発行してもＰＩ／Ｏ４を制御することはできない。
　一方、ＰＬＣ１ｂはマスタとなっているので、ＰＬＣ１ｂのユーザプログラム１１２がＨＵＢ３を経由してＰＩ／Ｏ４へ制御対象５を制御するための制御命令Ａをフレームとして送信する（Ｓ２０３）。
　ＨＵＢ３は、送信された制御命令ＡをＰＩ／Ｏ４とＰＬＣ１ａへ転送する（Ｓ２０４）。
　ＰＩ／Ｏ４は、ＨＵＢ３から送信された制御命令Ａを実行して（Ｓ２０５）、制御対象５（図１）を制御する。

　一方、ＰＬＣ１ａは、ＨＵＢ３から制御命令Ａを受信すると（Ｓ２０６）、ＰＬＣ１ａのデータ生成プログラム１１５が制御命令Ａを基に、検証用データ２５１を生成し、検証プログラム１１６は、その検証用データ２５１を用いて、制御命令Ａの送信元であるＰＬＣ１ｂがウィルスに感染しているか否かを検証する検証処理を行う（Ｓ２０７）。そして、ＰＬＣ１ａは、検証結果をＰＣ２へ送信し（Ｓ２０８）、検証結果を受信したＰＣ２は検証結果を表示装置２４０に表示する（Ｓ２０９）。
　なお、検証処理の結果、ＰＬＣ１ａによって、ＰＬＣ１ｂがウィルスに感染している疑いがあると判定された場合のみ、ＰＬＣ１ａは、ＰＬＣ１ｂがウィルスに感染している疑いがある旨の警告をＰＣ２へ送信するようにしてもよい。

　また、感染ＰＬＣであるＰＬＣ１ａは、制御命令Ａとは別の制御命令ＢをフレームとしてＰＩ／Ｏ４に向けて送信し続けているとする（Ｓ２１０）。
　このとき、ＨＵＢ３は、そのフレームがスレーブからのフレーム送信であることを判別し、ＰＩ／Ｏ４には送信しない。
　一方、ＨＵＢ３は、ＰＬＣ１ａから受信したフレームをＰＬＣ１ｂへ転送する（Ｓ２１１）。

　スレーブが制御命令を発行してもＰＩ／Ｏ４を制御できないようにする方法としては、以下の３つの手法が考えられる。
　（１）スレーブが自分自身をスレーブとして認識して、スレーブのソフトウェアが制御命令をＰＩ／Ｏ４に発行しないようにする。
　（２）ＰＩ／Ｏ４がマスタ・スレーブの両方から制御命令を受信しても、マスタからの制御命令のみを実行するようにする。
　（３）制御命令などが含まれているフレームが、送信元がマスタであることを示すマスタ識別子を有しており、ＨＵＢ３は、このマスタ識別子を有するフレームのみをＰＩ／Ｏ４へ送信する、などである。

　本実施形態で用いられるのは、（３）の手法であるが、（１）、（２）の手法が用いられてもよい。
　また、マスタ識別の方法についても、マスタ識別子による方法に限定されない。ＨＵＢ３やＰＩ／Ｏ４がアドレスやノード番号を記憶する機能と、フレーム受信時に送信元の装置をチェックする機能を持つようにしてもよい。この場合、ＨＵＢ３やＰＩ／Ｏ４がフレームの送信元の装置を判定して、マスタからの受信フレームのみを送信・実行する。マスタとスレーブの切り替え時には、ＰＬＣ１がマスタ・スレーブ切替を通知する専用のフレームを送信して、ＨＵＢ３やＰＩ／Ｏ４に記憶されているマスタのアドレスやノード番号を変更するようにすればよい。

　ＰＬＣ１ｂは、ＨＵＢ３から制御命令Ｂを受信すると（Ｓ２１２）、ＰＬＣ１ｂのデータ生成プログラム１１５が制御命令Ｂを基に、検証用データ２５１を生成する。そして、検証プログラム１１６は、その検証用データ２５１を用いて、制御命令Ｂの送信元であるＰＬＣ１ａがウィルスに感染しているか否かを検証する検証処理を行う（Ｓ２１３）。そして、ＰＬＣ１ｂは、検証結果をＰＣ２へ送信し（Ｓ２１４）、検証結果を受信したＰＣ２は検証結果を表示装置２４０に表示する（Ｓ２１５）。
　なお、検証処理の結果、ＰＬＣ１ｂによって、ＰＬＣ１ａがウィルスに感染している疑いがあると判定された場合のみ、ＰＬＣ１ｂは、ＰＬＣ１ａがウィルスに感染している疑いがある旨の警告をＰＣ２へ送信するようにしてもよい。

　マスタとなるＰＬＣ１は１つのＰＬＣ監視システム１０において複数存在せず、マスタとなるＰＬＣ１は必ず１つである。そのため、ソフトウェア更新後に再起動したＰＬＣ１ａが再度マスタ権を取得してマスタとなるためには、現在マスタであるＰＬＣ１ｂがマスタ権を放棄するのを待たなければならない。これにより、ＰＬＣ１ｂがマスタであるにもかかわらず、ＰＬＣ１ａに感染しているウィルスが、ＰＬＣ１ａを強制的にマスタにしようとしても、ＰＬＣ１ｂがマスタ権を放棄することにより、マスタ権を得ることができなければＰＩ／Ｏ４に対して有効な制御命令を発行することはできない。マスタ権の管理方法についてもいくつか手段が考えられるが、本実施形態ではマスタ権の管理はＰＬＣ１の制御プログラム１１１上で実行されているマスタ権制御プログラム１１４が行っている。そして本実施形態において、前記したように、制御命令のフレームが送信されるときに、そのフレームにマスタ識別子が付与されることによって、ＨＵＢ３がマスタ・スレーブの認識をしている。

　もしなんらかの方法でウィルスに感染したＰＬＣ１ａが強制的にマスタ権を取得し、ＰＬＣ１ａ，１ｂともマスタになった場合（両ＰＬＣ１マスタ状態）、つまり、ＰＬＣ１ａ，１ｂのそれぞれが有効かつ異なる制御を試みようとしている場合、機器であるＨＵＢ３あるいはＰＩ／Ｏ４が両ＰＬＣ１のマスタ状態を検出する。そして、ＨＵＢ３あるいはＰＩ／Ｏ４は、両ＰＬＣ１のマスタ状態を通知するフレームをＰＬＣ１ａ，１ｂへ送信し、その通知を受けたＰＬＣ１ａ，１ｂを強制的に停止する。つまり、機器であるＨＵＢ３あるいはＰＩ／Ｏ４は、それぞれのＰＬＣ１ａ，１ｂ（制御装置）が、制御対象５へ、それぞれ有効かつ異なる制御を同時に試みようとしていることを検知すると、それぞれのＰＬＣ１ａ，１ｂ（制御装置）が、１つの制御対象５へ、それぞれ有効かつ異なる制御を試みようとしていることを、それぞれのＰＬＣ１ａ，１ｂへ通知する。
　こうすることで、制御対象５への、ウィルスの不正操作による影響を小さくすることができる。

　マスタの切替の方法はＰＬＣ１に障害などが発生した場合の障害時切替のほかに、ＰＣ２がＰＬＣ１へマスタの切替を指示する計画的切替もある。また、ユーザが意図してＰＬＣ１のマスタを切り替える手法を用いている場合もあるが、この場合ＰＣ２に潜伏しているウィルスがユーザになりすましてマスタ切替命令をＰＬＣ１に発行するおそれがある。このときの不正操作防止手段としては、ＰＬＣ１に固有のパスワードなどを設定しておき、パスワードを認証できたらマスタ切替命令を受け付けるようにすることが考えられる。

　ここまで、ＨＵＢ３がスレーブ（ＰＬＣ１ｂ）の制御命令をＰＩ／Ｏ４に送信しないものとして説明してきたが、この役割を担う装置はＨＵＢ３ではなく、ＰＩ／Ｏ４としてもよい。ＰＩ／Ｏ４で制御命令の出力制御を行う場合には、ＰＩ／Ｏ４が制御命令をマスタとスレーブのＰＬＣ１の両方から受けとったとしても、ＨＵＢ３と同様の判別方法を用いることによって、制御対象５への出力を制御することができる（第３実施形態にて記載）。

　図６は、第１実施形態に係るＰＬＣ監視処理の別の動作例を示すタイミングチャートである。なお、図６におけるＰＬＣ１の処理は、ＰＬＣ１における送信側の制御部あるいは受信側の制御部としての制御プログラム１１１が行う処理である。
　図６におけるステップＳ３０１～Ｓ３０６の処理は、図５のステップＳ２０１～Ｓ２０６と同様であるため、説明を省略する。
　ＨＵＢ３経由で制御命令Ａ（送信元：ＰＬＣ１ｂ）を受信したＰＬＣ１ａは、受信した制御命令Ａを基に、検証用データ２５１を生成する（Ｓ３０７）。この検証用データ２５１は、ユーザが視認して、異常の判別を行うためのデータである。
　そして、ＰＬＣ１ａは検証用データ２５１をＰＣ２へ送信し（Ｓ３０８）、ＰＣ２は、検証用データ２５１を受信すると、表示装置２４０に検証用データ２５１を表示する（Ｓ３０９）。検証用データ２５１がグラフ化されて表示装置２０４に表示されたものを目視して、ＰＬＣ１ｂがウィルスに感染しているか否かをユーザは判別する。

　この後のステップＳ３１０～Ｓ３１２の処理は、図５のステップＳ２１０～Ｓ２１２の処理と同様であるため、説明を省略する。
　ＨＵＢ３から制御命令Ｂ（送信元：ＰＬＣ１ａ）を受信したＰＬＣ１ｂは、受信した制御命令Ｂを基に、検証用データ２５１を生成する（Ｓ３１３）。
　そして、ＰＬＣ１ｂは検証用データ２５１をＰＣ２へ送信し（Ｓ３１４）、ＰＣ２は、検証用データ２５１を受信すると、表示装置２４０に検証用データ２５１を表示する（Ｓ３１５）。ユーザは、検証用データ２５１がグラフ化されて表示装置２０４に表示されたものを目視して、ＰＬＣ１ａがウィルスに感染しているか否かを判別する。

　なお、ＰＣ２は、ステップＳ３０９で取得した検証用データ２５１（送信元：ＰＬＣ１ａ）と、ステップＳ３１５で取得した検証用データ２５１（送信元：ＰＬＣ１ｂ）とを比較することによって、検証処理を行ってもよい。

（フレームフォーマット）
　図７は、第１実施形態に係るＰＬＣ監視システムに用いられるフレームのフォーマット例を示す図である。
　フレームは、以下の構成を有している。
　フレーム開始フラグはフレーム内の他の部分に現れないユニークなパターンを使用し、フレームの開始であることを示している。宛先アドレスはフレームの宛先となる物理アドレスを示す。送信元アドレスはフレームの送信元の物理アドレスを示す。マスタ識別子は、該当するフレームの送信元であるＰＬＣ１（図１）がマスタであるか否かを示し、マスタからのフレームであればＨＵＢ３がＰＩ／Ｏ４にフレームを送信するためのものである。フレーム長はフレーム全体の長さを示す。送信データ本体は制御命令などの情報を格納している。フレームチェックシーケンスはフレーム開始フラグから送信データの終了までの間でビットの反転などの予期しない変異が発生したか否かをチェックする誤り検出コードである。

　送信データ本体は、以下の構成を有している。
　フレーム発行時刻はフレームが生成・発行された時刻を示しており、フレームの到達時間の計算に使用される。機器番号はフレームの送信先であるＰＩ／Ｏ４の番号を示す。図１などでは簡略化のためにＰＩ／Ｏ４は１つしか図示していないが、ＰＩ／Ｏ４が複数存在する場合や、ＰＩ／Ｏ４以外の機器が接続されている場合は、各ＰＩ／Ｏ４や、その他の機器に固有の機器番号をつけて管理する。コマンドはＰＩ／Ｏ４を操作するためのコマンドである。たとえば入力データの読み込み、出力データの書み込みなどである。データサイズは、その後に続く制御データの全体のサイズである。制御データはコマンドで使用されるデータである。制御データは、出力命令をＰＩ／Ｏ４に発行したときにＰＩ／Ｏ４から制御対象５へ出力させる値などを格納する。一方、入力命令において、ＰＬＣ１からＰＩ／Ｏ４へ送信するとき、制御データは空になるが、ＰＩ／Ｏ４が制御対象５から得た入力値をＰＬＣ１へ返送するときに入力値が格納される。プログラムフラグは、後に続くプログラム情報が存在するか否かを示している。プログラム情報が、その後につづく場合はプログラムフラグを「有効」にする。プログラム情報は、このフレームの発行元であるユーザプログラム１１２に関する情報を格納する。

　プログラム情報は、以下の構成を有する。
　プログラム番号は、ユーザプログラム１１２それぞれに対し一意に決められた番号が格納される。ユーザプログラム１１２にはその実行単位毎に管理できるように固有のプログラム番号が付与される。プログラム更新時刻はユーザプログラム１１２を更新した時刻が格納される。プログラムサイズはユーザプログラム１１２の全体サイズが格納される。プログラム情報としては他にも、プログラムのオブジェクトを原文としたメッセージダイジェスト値（ハッシュ値）なども考えられる。プログラムが更新されると、プログラム更新時刻、プログラムサイズ、メッセージダイジェスト値なども異なる値に更新される。

（フレーム送信処理）
　図８は、第１実施形態に係るＰＬＣにおけるフレーム送信処理の詳細な手順を示すフローチャートである。なお、適宜図１を参照する。この処理は、図５におけるステップＳ２０３、Ｓ２１０、図６におけるステップＳ３０３，Ｓ３１０のタイミングで行われる。
　フィールドネットワーク７に送信されるフレームは、ユーザプログラム１１２がＰＩ／Ｏ４を操作する制御命令を発行するときに生成・送信される。ＰＩ／Ｏ４を操作する制御命令を、ＰＬＣ１に搭載されたソフトウェア（制御プログラム１１１）のシステムコールとして用意しておくことで、後記するように、ユーザプログラム１１２が制御命令をコールすると、ユーザプログラム１１２自身がコンテキストとして記憶装置１５０に退避された状態となる。この状態から、ＰＬＣ１に搭載されたソフトウェア（制御プログラム１１１）は退避されたコンテキストの情報を取得することができる。ＰＬＣ１上にて、制御命令を実行するＰＩ／Ｏドライバ１１３を起動すると同時に、退避されたコンテキストから取得した情報から、呼び出し元のユーザプログラム１１２に関する情報（プログラム情報）をＰＩ／Ｏドライバ１１３に渡してやれば、ＰＩ／Ｏドライバ１１３はそのプログラム情報をフレームに格納して送信することが可能である。そのフレームを受信した相手系のＰＬＣ１は受信したフレームのプログラム情報から、どのユーザプログラム１１２が発行した制御命令であるかが判別可能である。これにより、フレーム情報からユーザプログラム１１２を特定し、相手系のＰＬＣ１をユーザプログラム１１２単位で監視することができる。

　ＰＬＣ１上のユーザプログラム１１２が制御命令を実行する（Ｓ３５１）と、システムコールとしてＰＬＣ１の制御プログラム１１１に処理が移る。
　次に、ＰＬＣ１上の制御プログラム１１１が、それまで実行していたユーザプログラム１１２の情報をコンテキストとして記憶装置１５０に退避させる（Ｓ３５２）。
　そして、ＰＬＣ１上の制御プログラム１１１が、退避されたコンテキストから情報を取得し（Ｓ３５３）、プログラム情報を生成する（Ｓ３５４）。
　コンテキストとして退避される情報としては、ユーザプログラム１１２が実行していたメモリアドレスなどが含まれるので、制御プログラム１１１はコンテキストとして退避される情報から、例えば、ユーザプログラム１１２が実行していたメモリアドレスなどをユーザプログラム１１２の固有の番号（プログラム番号）とすることで、プログラム番号を決定することができる。同時に、ユーザプログラム１１２がＰＣ２からＰＬＣ１にダウンロードされたときの時刻やサイズなどの情報が別のメインメモリ１１０領域に保存してあれば、制御プログラム１１１はプログラム番号を検索することで、これらの情報を取得することができる。

　続いて、制御プログラム１１１は、生成したプログラム情報を記憶装置１５０などに格納し（Ｓ３５５）、ＰＩ／Ｏドライバ１１３を起動し（Ｓ３５６）、プログラム情報をＰＩ／Ｏドライバ１１３へ渡す。
　そして、ＰＬＣ１上のＰＩ／Ｏドライバ１１３は、渡されたプログラム情報、および、実行された制御命令を取得して、取得したプログラム情報および制御命令を基にフレームを生成し（Ｓ３５７）、生成したフレームをフィールドネットワーク７へ送信する（Ｓ３５８）。このようにしてユーザプログラム１１２の情報を相手系のＰＬＣ１へ送信することができる。

　一方、プログラム情報をＰＩ／Ｏドライバ１１３へ渡した制御プログラム１１１は、退避していたコンテキストを復帰させる（Ｓ３５９）ことでユーザプログラム１１２を復帰し、復帰したユーザプログラム１１２に処理をリターンする（Ｓ３６０）。
　そして、ユーザプログラム１１２は、制御処理を継続する（Ｓ３６１）。

（フレーム受信後処理）
　図９は、第１実施形態に係るＰＬＣにおけるフレーム受信後処理の手順を示すフローチャートである。なお、適宜図１を参照する。また、この処理は、図５のステップＳ２０６，Ｓ２０７，Ｓ２１２，Ｓ２１３、図６のステップＳ３０６，Ｓ３０７，Ｓ３１２，Ｓ３１３のタイミングで行われる。
　まず、ＰＩ／Ｏドライバ１１３が相手系のＰＬＣ１からのフレームを受信する（Ｓ４０１）。
　すると、ＰＬＣ１の制御プログラム１１１が監視プログラムテーブル１５１の更新処理を開始し（Ｓ４０２）、ユーザプログラム１１２に対して割込みを行い、実行中の処理を中断させる（Ｓ４０３）。
　次に、ＰＬＣ１の制御プログラム１１１はフレームのプログラム情報を取得し（Ｓ４０４）、取得したプログラム情報などを使用して監視プログラムテーブル１５１を更新する（Ｓ４０５）。ステップＳ４０５の詳細は図１１で後記する。
　監視プログラムテーブル１５１の更新が完了すると、制御プログラム１１１は更新処理を終了し（Ｓ４０６）、ユーザプログラム１１２の実行を再開させる（Ｓ４０７）。

　その後、制御プログラム１１１は、監視プログラムテーブル１５１に登録されたユーザプログラムの挙動をチェックする検証処理を開始し（Ｓ４０８）、ユーザプログラム１１２に対して割込みを行い、実行中の処理を中断させる（Ｓ４０９）。
　そして、制御プログラム１１１は監視プログラムテーブル１５１のレコードを参照する（Ｓ４１０）。そして、データ生成プログラム１１５が参照したレコードに格納されているデータを基に、監視対象となっているユーザプログラムの検証用データ２５１を生成する（Ｓ４１１）。さらに、検証プログラム１１６が、その検証用データ２５１を基に検証を行う（Ｓ４１２）。このとき、図６に示すようにＰＣ２で検証を行う場合、検証プログラム１１６は検証処理を行わずに、ステップＳ４１１の検証用データ２５１の生成にとどめておき、その検証用データ２５１をＰＣ２へ送信するようにしてもよい。
　そして、ステップＳ４１２の検証処理が完了すると、制御プログラム１１１は検証結果をＰＣ２へ送信し、制御プログラム１１１は検証処理を終了し（Ｓ４１３）、ユーザプログラム１１２の実行を再開させる（Ｓ４１４）。
　なお、ステップＳ４０８～Ｓ４１４の処理は、一定時間間隔毎に周期的に行われる。
　ＰＬＣ１は、このようにして監視プログラムテーブル１５１を更新・参照して検証の処理を実施する。

（検証用データ例）
　検証用データ２５１の詳細を以下説明する。
　検証の方法として、ＰＬＣ１にあらかじめ検証パターンを設定してＰＬＣ１内部で検証する方法と、ＰＣ２にユーザプログラムの挙動をグラフ化するアプリケーションを用意してユーザプログラムの妥当性をユーザ自身が判断する方法とが考えられる。

　ウィルスがＰＬＣ１に潜伏する方法としてはいくつか考えられるが、既存のユーザプログラム１１２の書き換えや、あるいはまったく別のユーザプログラム１１２を新規に生成する、などがある。そのため、ウィルスが潜伏している可能性のあるユーザプログラム１１２は、更新されている形跡のあるものに限られてくる。しかし、本実施形態の状態において、ＰＬＣ１ａはソフトウェア（ユーザプログラム１１２）の更新を行った状態であるので、計画的にユーザがユーザプログラム１１２を更新しているのか、ＰＬＣ１ａに潜伏しているウィルスが更新しているのかの判断をユーザはできない。

　そこで、本実施形態では片系のＰＬＣ１のユーザプログラム１１２が変更された形跡が見られる場合は、そのユーザプログラム１１２を別系のＰＬＣ１で監視し、そのユーザプログラム１１２の挙動に異常があると判断したら、そのユーザプログラム１１２はウィルスにより改ざんされたと判断するようにする。検証用データ２５１は、監視の対象となるＰＬＣ１において変更された形跡のあるプログラムの挙動を、監視を行うＰＬＣ１またはＰＣ２の記憶装置１５０、２５０上に記録したものであり、そのプログラムがウィルスにより改ざんされたかソフトウェアの更新で変更されたかを判断する手段となる。

　図１０は第１実施形態に係るＰＬＣ監視システムによる検証用データをグラフ化した例を示す図である。
　検証用データ２５１は後記する監視プログラムテーブル１５１から、特定のユーザプログラム１１２が特定のアクションを行ったときのパラメータを格納したものである。図１０の例は、監視プログラムテーブル１５１に記録されたユーザプログラム１１２によって特定のＰＩ／Ｏ４へ発行された出力値を、データ生成プログラム１１５が検証用データ２５１を数字の羅列（ＣＳＶファイルなど）として抽出して、ＰＣ２の表示装置２４０にグラフ化して表示した例を示している。
　なお、図１０において、縦軸がユーザプログラム１１２の出力値、横軸はユーザプログラム１１２におけるコマンドの実行回数を示している。
　図５に示すステップＳ２０７、Ｓ２１３において、ＰＬＣ１の検証プログラム１１６は、相手系ＰＬＣ１におけるユーザプログラム１１２の出力の挙動などを基に、相手系ＰＬＣ１がウィルスに感染しているか否かを判定してもよい。また、図６に示す処理では、ステップＳ３１５において、ＰＣ２が表示装置２４０に図１０に示すようなグラフを表示することで、ＰＬＣ１がウィルスに感染しているか否か確認をユーザに促してもよい。

　破線１０１１と破線１０１２はあらかじめユーザが設定した出力値が許容される上限と下限を示している。またプロット１００１～１００９は１回目から９回目までのユーザプログラム１１２の出力値を示している。この例において、プロット１００１～１００４は上限１０１１と下限１０１２の間に収まっており、許容範囲内であることがわかる。しかし、プロット１００５，１００６，１００８，１００９は上限１０１１より高い出力値となっており、許容範囲外の値をとっていることがわかる。このグラフから、ユーザや、検証プログラム１１６はユーザプログラム１１２がウィルスによって改変されたことで、許容範囲外の値をとるようなユーザプログラム１１２となってしまった可能性があると検証できる。

　一方、プロット１００７はその前後のプロットと比較すると明らかに小さな値である。これも、ユーザプログラム１１２がウィルスによって改変され、急激に出力値を上下させて制御対象５に過剰な負荷を与えようとしている可能性があると、ユーザや、検証プログラム１１６が判断することができる。

　このように、監視プログラムテーブル１５１に登録されたユーザプログラム１１２の挙動をグラフ化することによって、ユーザや、検証プログラム１１６がウィルスの潜伏をチェックすることができるようになる。また、検証プログラム１１６が検証を行う際には、ＰＬＣ１に前記したような検証の基準を設定しておき、検証プログラム１１６が、設定されている基準に基づいて、検証を行うようにするとよい。そうすれば、前記した出力値の許容範囲チェック、出力値の連続性のチェックなどをＰＬＣ１の検証プログラム１１６や、ＰＣ２の検証プログラム２１３がチェックし、異常であればＰＣ２に警告を表示するようにすることができる。チェックするパラメータとして本実施形態ではＰＩ／Ｏ４の出力値を例として示したが、チェックするパラメータはそのほかにも様々考えられる。例えば、特定の命令の発行の頻度をチェックし、異常な頻度で発行されていればウィルスによる不正操作として警告する、などが考えられる。

　また、監視プログラムテーブル１５１をログ情報としてＰＣ２に提供することで、このログ情報からウィルスの挙動を解析するようにしてもよい。なお、検証を行ったＰＬＣ１が、ウィルスが潜伏していないにもかかわらず、ウィルスが潜伏していると判断してしまう可能性も考えられるので、警告を発するにとどめ、可用性を向上するためシステムの停止などの状態にはしないようにすることが望ましい。それ以外にも、ウィルスが潜伏していると判断されたプログラムのみ、あるいは、そのウィルスによって操作されているＰＩ／Ｏ４のみが停止させられ、縮退運転状態にさせられることもできる。この場合、制御プログラム１１１は、ウィルスが潜伏しているユーザプログラム１１２の番号を検証プログラム１１６から通知を受け、そのユーザプログラム１１２のプロセスを停止させる処理を行う。

（監視プログラムテーブル更新処理）
　図１１は、第１実施形態に係る監視プログラムテーブル更新処理の手順を示すフローチャートである。この処理は、図９のステップＳ４０５のタイミングで行われる。
　監視プログラムテーブル１５１の生成・更新は以下のように行われる。制御プログラム１１１は、相手系ＰＬＣ１からの受信フレームから得た相手系のユーザプログラム１１２の情報と、自系のユーザプログラム１１２の情報とを比較する。相手系には存在するが自系には存在しない、あるいは相手系と自系とで同一プログラム番号でもユーザプログラム１１２の情報に相違がある場合は、そのプログラムの情報を監視プログラムテーブル１５１に登録する。一度監視プログラムテーブル１５１に登録されたユーザプログラム１１２は、以後相手系ＰＬＣ１から情報を受信するたびに監視プログラムテーブルに自身の情報を追加・更新される。このようにして、ユーザプログラム１１２は変更が行われたユーザプログラム１１２の挙動を監視プログラムテーブル１５１へ記録し続ける。
　ＰＬＣ１上の制御プログラム１１１は、相手系のＰＬＣ１からフレームを受信すると（Ｓ５０１）、受信したフレームの内容を取得し、フレームに格納されているプログラム番号と同じプログラム番号を監視プログラムテーブル１５１から検索する（Ｓ５０２）。

　そして、制御プログラム１１１は、ステップＳ５０２の結果、監視プログラムテーブル１５１に該当するプログラム番号が登録されているか否かを判定する（Ｓ５０３）。
　ステップＳ５０３の結果、フレームに格納されているプログラム番号が監視プログラムテーブル１５１に、すでに登録されている場合（Ｓ５０３→Ｙｅｓ）、制御プログラム１１１はステップＳ５１０へ処理を進める。
　ステップＳ５０３の結果、フレームに格納されているプログラム番号が監視プログラムテーブル１５１に登録されていない場合（Ｓ５０３→Ｎｏ）、制御プログラム１１１は、処理対象となっているプログラム番号と同一のプログラム番号が自ＰＬＣ１において存在するか（ダウンロード済みか）否かを検索する（Ｓ５０４）。

　ステップＳ５０４の処理は、自ＰＬＣ１の中のユーザプログラム１１２の検索のために、自ＰＬＣ１の記憶装置１５０などに格納されている、ダウンロードされたユーザプログラム１１２の情報がプログラム番号でソートされたプログラム一覧表などを用いるとよい。
　制御プログラム１１１は、ステップＳ５０４における検索の結果、処理対象となっているプログラム番号に該当するユーザプログラム１１２が自ＰＬＣ１にあるか否かを判定する（Ｓ５０５）。

　ステップＳ５０５の結果、処理対象となっているプログラム番号に該当するユーザプログラム１１２が自ＰＬＣ１にない場合（Ｓ５０５→Ｎｏ）、制御プログラム１１１はステップＳ５０９へ処理を進める。
　ステップＳ５０５の結果、処理対象となっているプログラム番号に該当するユーザプログラム１１２が自ＰＬＣ１にある場合（Ｓ５０５→Ｙｅｓ）、制御プログラム１１１は、ユーザプログラム１１２が変更されているかを検査するため、フレームの中からプログラム更新時刻（相手系のＰＬＣ１における更新時刻）とプログラムサイズを取得する（Ｓ５０６）。
　続いて、制御プログラム１１１は取得した更新時刻およびプログラムサイズと、ステップＳ５０４で検索した自ＰＬＣ１のユーザプログラム１１２における更新時刻およびプログラムサイズとを比較する（Ｓ５０７）。

　そして、制御プログラム１１１は、ステップＳ５０７の結果、相手系のＰＬＣ１における更新時刻およびプログラムサイズの双方について、自ＰＬＣ１における更新時刻およびプログラムサイズと同じであるか否かを判定する（Ｓ５０８）。
　ステップＳ５０８の結果、更新時刻およびプログラムサイズの少なくとも一方が異なる場合（Ｓ５０８→Ｎｏ）、ユーザプログラム１１２は変更されているとみなし、制御プログラム１１１はフレームに格納されているプログラム番号を監視プログラムテーブル１５１の新しいレコードとして追加する（Ｓ５０９）。
　一方、ステップＳ５０８の結果、更新時刻およびプログラムサイズの双方が同じである場合（Ｓ５０８→Ｙｅｓ）、ユーザプログラム１１２は変更されていないとみなし、制御プログラム１１１は監視プログラムテーブル更新処理を終了する。
　次に、制御プログラム１１１は、フレームに格納されているコマンドを取得して（Ｓ５１０）、そのコマンドが制御対象５に対して出力を実行するコマンド（出力コマンド）であるか否かを判定する（Ｓ５１１）。

　ステップＳ５１１の結果、出力コマンドではない場合（Ｓ５１１→Ｎｏ）、制御プログラム１１１は監視プログラムテーブル更新処理を終了する。
　ステップＳ５１１の結果、出力コマンドである場合（Ｓ５１１→Ｙｅｓ）、制御プログラム１１１は処理対象となっているコマンド、コマンドを発行したＰＩ／Ｏ４の番号、そのコマンドを発行したときの制御データを監視プログラムテーブル１５１の該当するプログラム番号のレコードに追加登録する処理を行う（Ｓ５１２）。

　本実施形態では、制御プログラム１１１はプログラムの更新が行われているか否かの判定（Ｓ５０８）をプログラムサイズと更新時刻を用いて行っている。プログラムサイズと更新時間以外にも、メッセージダイジェスト値などのほかのプログラム情報を入手できるならば、判定に用いることができる。しかし、プログラムサイズだけ、あるいは、メッセージダイジェスト値だけで判定されてしまうと、変更されていてもサイズが同一である、異なるプログラムでもメッセージダイジェスト値が一致している、などが考えられ、プログラムの改変を見逃す可能性がある。従って、判定には複数のプログラム情報を用いることが望ましい。
　本実施形態では、出力コマンドのみが監視プログラムテーブル１５１に登録されている。なぜなら、ウィルスが制御対象５に対して望ましくない動作を行うことができるのは、出力コマンドに限られるためである。それ以外のコマンドでは制御対象５を操作するようなことはできないので、本実施形態では、監視プログラムテーブル１５１に登録していないが、出力コマンド以外のコマンドが監視プログラムテーブル１５１に登録されるようにしてもよい。例えば、ＰＬＣ１のマスタ・スレーブの切替命令や、稼動中のＰＩ／Ｏ４のデバイス停止・リセット命令、停止中のＰＩ／Ｏ４デバイスの起動命令、ＰＩ／Ｏ４の設定変更命令などもＰＩ／Ｏ４への操作になるので、これらの情報が監視プログラムテーブル１５１に登録されるようにしてもよい。

（監視プログラムテーブル）
　図１２は、第１実施形態に係る監視プログラムテーブルの構成例を示す図である。
　ＰＬＣ１あるいはＰＣ２は、検証のため、ユーザプログラム１１２の挙動を監視するので、監視対象となるユーザプログラム１１２を監視プログラムテーブル１５１で管理する。図１２に示すように、監視プログラムテーブル１５１には、監視するユーザプログラム１１２のプログラム番号、プログラム更新時刻、プログラムサイズ、コマンド、機器番号、制御データが格納されている。

　制御プログラム１１１は、フレームが送信されるたびにコマンド、機器番号などの情報を監視プログラムテーブル１５１に登録していく。監視されるユーザプログラム１１２の対象となるのは、自ＰＬＣ１には存在しないが相手系のＰＬＣ１には存在するユーザプログラム１１２や、自ＰＬＣ１と相手系のＰＬＣ１とでユーザプログラム１１２の更新時刻やサイズが異なるものである。このようなユーザプログラム１１２は、ソフトウェアの計画的な更新のときに追加・変更していることもあるが、潜伏しているウィルスがユーザプログラム１１２を追加・変更している可能性もある。よって、ＰＬＣ１あるいはＰＣ２はそのようなユーザプログラム１１２の挙動を監視する。

　図１１に示す処理が行われることによって、監視プログラムテーブル１５１に、ウィルスが潜伏している可能性のあるユーザプログラム１１２による出力コマンドの履歴が記録されていくことになる。図１２の１行目の例では、プログラム番号が０ｘ０００５のユーザプログラム１１２の更新時刻が２０１１年８月１日１４時４０分１０秒であり、ユーザプログラム１１２のサイズが４２８バイト、命令の内容としては、１回目に、機器番号が０ｘＢ００００Ｂ８０のアナログ出力デバイス（ＡＯ）にロングワードサイズ（ＬＯＮＧ）で０ｘＦＦＦＦ１１１１を書き込み（ＷＲＩＴＥ）、２回目に機器番号が０ｘＢ００００１４０のデジタル出力デバイス（ＤＯ）にワードサイズ（ＷＯＲＤ）で０ｘ００００１８６Ｄを書き込み（ＷＲＩＴＥ）したことがわかる。プログラム番号が同じであるのに、出力コマンドが異なっているのは、同じユーザプログラム１１２でも、実行する毎に異なるコマンドが実行されることがあるためである。

　図１２には一部の情報しか記録されていないが、監視対象のユーザプログラム１１２の挙動をより細かく監視するために、フレーム発行時刻、使用しているデータのアドレスなどが監視プログラムテーブル１５１に登録されてもよい。
　監視プログラムテーブル１５１が生成されたら、ユーザの要求あるいは一定周期のタイマなどをトリガにして、データ生成プログラム１１５が検証用データ２５１を生成する。データ生成プログラム１１５が抽出するデータはユーザによって自由にカスタマイズすることが可能である。例えば、図１０の例では、特定のユーザプログラム１１２が特定のＰＩ／Ｏ４に出力命令を発行したときの出力値（制御データ）を抽出している。

（第１実施形態のまとめ）
　第１実施形態によれば、二重化構成の一方のＰＬＣ１が検証を行ったり、検証用データ２５１を生成したりすることで、ウィルスに感染している疑いのある他方のＰＬＣ１をチェックすることができる。
　このように、本実施形態によれば、多重化構成のＰＬＣ１のうちの１つにウィルスが潜伏していても、それを多重化構成の他のＰＬＣ１が検出することができるので、ＰＬＣ１のセキュリティを向上させることができる。また、ダウンロードされたユーザプログラム１１２にウィルスが感染している可能性があるという、ＰＬＣ１におけるウィルスの特性に着目し、ダウンロードしたユーザプログラム１１２と、ダウンロードを行っていないユーザプログラム１１２の挙動を検証する手法をとっているため、ウィルス対策パッチなどの場当たり的な対策よりも根本的な対策が可能となる。

　本実施形態では、ユーザプログラム１１２の更新時刻やサイズの情報が、ウィルスに感染しているＰＬＣ１で正しく取得でき、その情報が検証を行うＰＬＣ１へ問題なく送信できる場合を想定して説明してきた。ウィルスの感染場所が、ユーザが利用するプログラム領域（ユーザプログラム１１２）などであれば問題ないが、ＰＬＣ１のシステムプログラムの領域（制御プログラム１１１、ＰＩ／Ｏドライバ１１３、マスタ権制御プログラム１１４、データ生成プログラム１１５、検証プログラム１１６）に感染してしまうと、プログラムの更新時刻やサイズの情報をウィルスに都合のいいように書き換えられてしまう可能性があり、フレームの内容も書き換えられてしまうことも考えられる。そのため、ソフトウェアの更新を行うときには、これらのシステムプログラムの領域は書き込み禁止の状態にして更新を行い、ウィルスが侵入できないようにしておくことが本実施形態の前提となる。

　また、本実施形態に示す方法で検証処理を実施したのち、ウィルスの感染が見られなかった場合には、ＰＬＣ監視システム１０は、ソフトウェア更新のために停止していたＰＬＣ１ａと一時的にマスタとなっていたＰＬＣ１ｂのマスタ・スレーブを切り替え、ソフトウェア更新前の状態である、ＰＬＣ１ａをマスタ、ＰＬＣ１ｂをスレーブに戻すことができる。
　ただし、ウィルスに感染しているユーザプログラム１１２が動作しない限り、相手系ＰＬＣ１はそのユーザプログラム１１２の情報を取得できない。これにより、前記のマスタ・スレーブ切り替えの時点までウィルスに感染したユーザプログラム１１２が動作しないと、ウィルスが潜伏したＰＬＣ１がマスタとなり、ウィルスに感染したマスタが制御対象５を制御できてしまうおそれがある。そのような事態を避けるため、ダウンロード実行後には登録されたユーザプログラム１１２をすべて強制的に実行させるようにしておくことで、すべてのユーザプログラム１１２に対して検証処理を行うことが可能である。

　監視プログラムテーブル１５１に登録されている内容から、ウィルスが潜伏している可能性がある場合には、前記したように、検証を行ったＰＬＣ１がＰＣ２へ警告を発行し、ログ情報をＰＣ２に提供する。
　ウィルスが潜伏しているときの挙動としては、ユーザプログラム１１２の更新時刻が他のユーザプログラム１１２の更新時刻と明らかに異なっている場合や、制御データ値が異常に大きいあるいは小さい場合、異常な周期で特定のデータを書き込んでいる場合、無効なコマンドを発行している場合などが考えられる。制御対象５によって正常な場合の挙動が異なるため、正常な場合とウィルスが潜伏している場合の区別は難しいので、使用環境やそのときの状況に応じてユーザが、検証機能をカスタマイズできることが望ましい。

［第２実施形態］
　これまで第１実施形態では、ソフトウェア更新中にスレーブがウィルスに感染している場合を前提にしてきたが、次に稼動中にマスタがウィルスに感染した場合について説明する。
　第１実施形態ではスレーブがウィルスに感染している場合に限定していたが、ＰＬＣ１が稼動中にＰＣ２とＰＬＣ１が通信を行う手段が存在していれば、ソフトウェア更新中以外でもＰＣ２を経由して、マスタ・スレーブ両系のＰＬＣ１がウィルスに感染する可能性がある。
　第１実施形態で説明したように、マスタ・スレーブともに相手系のプログラムの動作を検証する手段を備えているので、相手系が持っているユーザプログラム１１２の中で自系と異なっているものが存在していれば、ＰＬＣ監視システム１は、異常を検出することが可能である。

　マスタがウィルスに感染している場合、マスタがウィルスに感染していることを検証・検出するのはスレーブである。ただし、ウィルスに感染したマスタが制御対象５を制御することができる状態になっているので、好ましくない状態となっている。そのため、スレーブは、制御命令をＨＵＢ３を経由してマスタから取得し、それを解析して即座に検証を行わなければならない。また、ユーザは、スレーブから、マスタにウィルスが潜伏している、あるいは潜伏している可能性があるという警告を受けたら、即座にＰＬＣ１の停止などの手段を講じてウィルスの影響を回避しなければならない。

　マスタがウィルスに感染すると、スレーブが感染した場合とは別の問題も発生する。通常、２重系でホットスタンバイ状態を維持するため、マスタからスレーブに対してデータのコピーを行うことによって、データの同期化を行っている。もし、ウィルスに感染しているマスタから正常なスレーブに対してデータのコピーが行われた場合、第１実施形態で説明した方法だけではウィルスを検出することが困難である。なぜなら、ウィルスに感染したＰＬＣ１が、検証を行うＰＬＣ１のデータを上書きしてしまうため、正常なデータが失われてしまう可能性があるためである。
　そこで、第２実施形態では、スレーブがマスタから受信する同期化データの妥当性を検証し、妥当であれば同期化データを受け入れ、妥当ではない場合は警告をＰＣ２に発行するようにする。

　図１３は、第２実施形態に係るＰＬＣ監視処理の動作を示すタイミングチャートであり、マスタが感染した状態からスタートしている。なお、図１３の処理は、マスタ権がＰＬＣ１ｂからＰＬＣ１ａに戻り、ＰＬＣ１ａが制御対象５を制御している状態である。この時点でＰＬＣ１ａがウィルスに感染している場合の処理を示す。
　ＰＬＣ１がマスタとスレーブでデータを同期化するタイミングは、ＰＬＣ１が制御演算を実行し、その演算結果をデータ領域に格納するタイミングである。この制御演算のトリガとなるのは、ＰＬＣ１が制御対象５から物理情報を取得するために、ＰＩ／Ｏ４へ入力要求を発行したときである。

　ＰＬＣ１ａ（マスタ）は制御対象５を制御するための入力要求ＡをフレームとしてＰＩ／Ｏ４へ送信する（Ｓ６０１）。
　入力要求Ａを受信したＨＵＢ３は、その入力要求ＡをＰＩ／Ｏ４およびＰＬＣ１ｂ（スレーブ）へ転送し（Ｓ６０２）、ＰＬＣ１ｂは入力要求Ａを受信する（Ｓ６０３）。
　ＰＩ／Ｏ４は入力要求Ａを受信すると、その入力要求Ａに従って制御対象５の制御を実行し（Ｓ６０４）、その応答である入力応答ＡをＨＵＢ３へ送信する（Ｓ６０５）。

　ＰＩ／Ｏ４から入力応答Ａを受信したＨＵＢ３は、ＰＬＣ１ａ（マスタ）とＰＬＣ１ｂ（スレーブ）へ入力応答Ａを転送する（Ｓ６０６）。

　マスタとスレーブの両ＰＬＣ１は、通常は同じユーザプログラム１１２が格納されており、同じ入力応答を基に同じユーザプログラム１１２で演算するので、結果も同じになるはずである。しかし、どちらかがウィルスに感染していれば、プログラムの内容が異なるために、異なる結果が出力されてしまう。

　そこで、ＰＬＣ１ｂは、ＰＩ／Ｏ４から入力応答Ａを受信すると（Ｓ６０７）、受信した入力応答Ａと、ＰＬＣ１ａにおけるユーザプログラム１１２と同じユーザプログラム１１２を使って、ＰＬＣ１ａから送信される同期化データと比較するための比較用データを生成する（Ｓ６０８）。
　一方、ＰＬＣ１ａは、ＰＩ／Ｏ４から入力応答Ａを受信すると（Ｓ６０９）、ユーザプログラム１１２を用いて、ＰＬＣ１ｂへ送信するための同期化データを生成する（Ｓ６１０）。

　そして、ＰＬＣ１ａは同期化データをＨＵＢ３に向けて送信する（Ｓ６１１）。
　ＨＵＢ３は、送信された同期化データをＰＬＣ１ｂへ転送する（Ｓ６１２）。
　ＰＬＣ１ｂは、ＰＬＣ１ａから送信された同期化データと、ステップＳ６０８で生成しておいた比較用データを比較する比較処理を行う（Ｓ６１３）。
　そして、ＰＬＣ１ｂは比較処理の結果（比較結果）をＰＣ２へ送信し（Ｓ６１４）、比較結果を受信したＰＣ２は、受信した比較結果を表示装置２４０に表示する（Ｓ６１５）。

　ＰＬＣ１ａからＰＩ／Ｏ４へ発行した入力要求ＡはＨＵＢ３のネットワーク中継機能により、フィールドネットワーク７を介して、ＰＬＣ１ｂのＰＩ／Ｏドライバ１１３が受け取ることができる。ＰＬＣ１ａからＰＬＣ１ｂへの同期化データの通信は、送信フレームの宛先がＰＩ／Ｏ４ではなく、ＰＬＣ１ｂとなっているので、ＰＬＣ１ｂが自分宛のフレームとして受信する。ＰＩ／Ｏドライバ１１３とフィールドネットワーク７の構造により、ＰＬＣ１ａとＰＬＣ１ｂの間で、情報の共有が可能である。

　なお、同期化データが利用するパスは、マスタのＰＬＣ１からスレーブのＰＬＣ１へのデータのコピーだけでなく、生存監視のための用途としても用いることができる。スレーブＰＬＣ１がデータ同期化フレームを受信できないときは、マスタＰＬＣ１が停止したと考えて、マスタ権を取得する処理や、マスタＰＬＣ１に対して生存確認をする処理を行う。ＰＬＣ１は、この生存確認のための情報を同期化データとして、ステップＳ６１３の比較処理を行ってもよい。

　なお、図１３に示す処理では、比較処理の結果をＰＣ２へ送信しているが、比較用データが一致していない場合のみ、スレーブが警告をＰＣ２へ送信するようにしてもよい。
　また、図１３では、スレーブが比較処理を行っているが、ウィルスに感染しているマスタで比較処理が行われてもよい。また、図１３に示す処理は一定時間毎に行われる処理である。

　ここで、同期化データの送信に使用するフレーム（同期化フレーム）のフォーマットは図７に示すものと同一である。同期化フレームにおいては、機器番号としてデータ同期化の対象となるスレーブの番号が設定される。なお、機器番号には、その機器の番号だけでなく、ユーザプログラム１１２が実行されているメインメモリ１１０のアドレスも含んだ値になっているので、データ同期化を開始するメインメモリ１１０のアドレスの先頭も機器番号からわかるようになっている。また、コマンドはデータ同期化のためのコマンドを格納する。これはＰＩ／Ｏ４のコマンドとは異なるコマンドである。同期化フレームにおける制御データはマスタからスレーブへコピーして同期化するためのデータ（同期化データ）である。

　また、ＰＬＣ１からＰＩ／Ｏ４へ入力要求が発行されている。また、ＰＩ／Ｏ４が送信してきた入力応答のフレームには、プログラム番号が格納されている。これにより、スレーブは入力要求がどのユーザプログラム１１２を使用して演算されるべきかを知ることができる。つまり、スレーブは、プログラム番号と入力要求を手がかりに、同期化データと同じユーザプログラム１１２を使用して、同期化データと比較するためのデータ（比較用データ）を生成することができる。
　なお、１つのユーザプログラム１１２の中で複数の入力要求を発行することも考えられる。その場合には、ユーザプログラム１１２内のどの命令に対応するかを特定できるように、入力要求毎に枝番号が付与されて、入力要求が管理されてもよい。

（第２実施形態のまとめ）
　第２実施形態によれば、マスタがウィルスに感染した状態で、制御対象５を制御する状態になっても、マスタがスレーブに送信する同期化データを利用することで、ウィルスの感染を検証することができる。また、ウィルス対策パッチなどの特別な対策が不要となる。

［第３実施形態］
　ここまで、ＰＬＣ１が２つの２重系で、ＨＵＢ３が接続されている場合について説明してきたが、それ以外の場合でもＰＬＣ１で検証を行うことが可能である。
　図１４は、第３実施形態に係るＰＬＣ監視システムにおける情報の流れを示す図である。
　図１４のＰＬＣ監視システム１０ａはＰＬＣ１（１Ａ，１Ｂ，１Ｃ）が３つの３重系で、ＨＵＢ３がなくＰＩ／Ｏ４とＰＬＣ１（１Ａ，１Ｂ，１Ｃ）のそれぞれが直接接続して通信を行っている。なお、図１４において、図１と同様の構成要素については同一の符号を付して説明を省略する。
　第１実施形態と同様に、ＰＣ２がウィルスに感染し、ＰＬＣ１Ａにウィルスがダウンロードされてしまった状態を例に説明する（ウィルスに感染した機器をドットで示す）。
　制御命令が有効なものであるとき、ＰＩ／Ｏ４が制御対象５に出力を行う際の判断方法は、主に以下の２通りが考えられる。
　（ａ）前記した実施形態と同様に、ＰＬＣ１Ａ～１Ｃのうち、マスタ権を持っているＰＬＣ１の制御命令や、入力要求のみを有効な制御命令として認識する。
　（ｂ）３つ（あるいは複数）のＰＬＣ１Ａ～１Ｃからの制御命令や、入力要求をＰＩ／Ｏ４がすべて受信し、３つのＰＬＣ１Ａ～１Ｃからの制御命令や、入力要求のうち２つ以上が同じ命令であれば、その制御命令や、入力要求を有効なものとして認識し、制御対象５へ出力する。つまり、ＰＬＣ監視システム１０ａが多数決に従って有効な制御命令を判別する。そして、他の２つと異なる命令を発行したＰＬＣ１があればそれは何らかの原因（例えば、ウィルスに感染している）が考えられるので、ユーザは、そのＰＬＣ１を停止させるなどの対策を行う。なお、３つのＰＬＣ１Ａ～１Ｃから送信される制御命令や、入力要求は、同一種のユーザプログラム１１２（図２）による制御命令や、入力要求である。

　前記（ａ）、（ｂ）の場合も、ステップＳ７００でウィルスに感染したＰＬＣ１ＡはステップＳ７０１でＰＩ／Ｏ４へ制御命令を送信する。ＰＩ／Ｏ４は、この制御命令をＰＬＣ１Ｂ，１Ｃへ転送する（Ｓ７１１，Ｓ７１２）。
　同様に、ＰＬＣ１Ｂ，１Ｃは、ステップＳ７０２，Ｓ７０３でＰＩ／Ｏ４へ制御命令を送信し、ＰＩ／Ｏ４は、この制御命令を他のＰＬＣ１Ａ～１Ｃにも送信する点は同じである（Ｓ７１１，Ｓ７１２，Ｓ７２１，Ｓ７２２，Ｓ７２３）。このとき、ＰＩ／Ｏ４は、各ＰＬＣ１Ａ～１Ｃから送信された制御命令の内容について多数決をとり、最も多数の内容を有する制御命令を制御対象５へ送信してもよい。
　ここで、ＰＬＣ１Ａ，１Ｂ，１Ｃは受信した制御命令とそこに付与されたプログラム情報を基に、図３や、図４や、図７などで示した手順により検証を行ってもよい。
　また、各ＰＬＣ１Ａ，１Ｂ，１Ｃは、第１実施形態や、第２実施形態に示す処理を行い、その結果をＰＣ２へ送信する（Ｓ７３１～Ｓ７３３）。なお、この際、ＰＬＣ１Ａ，１Ｂ，１Ｃは、第１実施形態の検証処理（図５のＳ２０７、Ｓ２１３）や、検証用データ（図６のＳ３０７、Ｓ３１３）や、第２実施形態における比較処理（図１３のＳ６１３）が、３つのＰＬＣ１間のデータを用いて行われる。

（第３実施形態のまとめ）
　第３実施形態によれば、多重系ＰＬＣのうち１つがウィルスに感染していても他の健全なＰＬＣ１が検証を行うことができる。
　特に、多数決を用いることで、ウィルスに対する迅速な対応が可能となる。

　なお、第２実施形態、第３実施形態においても、ＰＬＣ１、ＰＣ２のハードウェア構成は、図２、図３に示したものと同様であり、各プログラム１１１～１１６，２１１～２１３は、メインメモリ１１０，２１０に展開され、ＣＰＵ１２０，２２０によって実行されている。

　１　　　ＰＬＣ（制御装置）
　２　　　ＰＣ（管理装置）
　３　　　ＨＵＢ（機器）
　４　　　ＰＩ／Ｏ（機器）
　５　　　制御対象
　６，７，８　フィールドネットワーク
　１０　　ＰＬＣ監視システム（制御装置監視システム）
　１１０　ＰＬＣのメインメモリ
　１１１　ＰＬＣの制御プログラム（制御部、送信側の制御部、受信側の制御部）
　１１２　ユーザプログラム（プログラム）
　１１３　ＰＩ／Ｏドライバ
　１１４　マスタ権制御プログラム
　１１５　データ生成プログラム
　１１６　ＰＬＣの検証プログラム
　１２０　ＰＬＣのＣＰＵ
　１３０　ＰＬＣの入力装置
　１４０　出力装置
　１５０　ＰＬＣの記憶装置
　１５１　監視プログラムテーブル
　２１０　ＰＣのメインメモリ
　２１１　ＰＣの制御プログラム（制御部）
　２１２　ダウンロードプログラム
　２１３　ＰＣの検証プログラム
　２２０　ＰＣのＣＰＵ
　２３０　ＰＣの入力装置
　２４０　表示装置
　２５０　ＰＣの記憶装置
　２５１　検証用データ（動作検証用のデータ）

Claims

　制御対象を制御する制御装置を複数備え、
　前記制御装置は、
　自身とは別の制御装置から、前記別の制御装置で実行されているプログラムが出力した、前記制御対象を制御する制御情報を取得し、前記取得した制御情報を基に、動作検証用のデータを生成する制御部を
　有することを特徴とする制御装置監視システム。
　前記制御装置の制御部が、
　前記生成した動作検証用のデータを基に、前記別の制御装置の動作状態を判別する
　ことを特徴とする請求項１に記載の制御装置監視システム。
　前記制御装置監視システムは、管理装置を備え、
　前記制御装置の制御部が、
　前記生成した動作検証用のデータを、前記管理装置へ送信し、
　前記管理装置が、
　受信した前記動作検証用のデータを表示装置に表示する制御部を
　有することを特徴とする請求項２に記載の制御装置監視システム。
　前記動作検証用のデータは、前記制御装置から前記制御装置が制御する制御対象へ送信される情報に含まれている出力値を含んでいる
　ことを特徴とする請求項１に記載の制御装置監視システム。
　前記制御装置の制御部が、
　前記制御装置から前記制御装置が制御する制御対象へ送信される情報を、前記プログラム単位毎に格納し、
　前記プログラム単位毎に格納されている情報を基に、前記動作検証用のデータを生成する
　ことを特徴とする請求項１に記載の制御装置監視システム。
　少なくとも２つ以上の前記制御装置と前記制御対象との間の通信経路に接続されている機器を備え、
　前記機器は、
　それぞれの前記制御装置が、前記制御対象へ、それぞれ有効かつ異なる制御を試みようとしていることを検知し、
　前記それぞれの制御装置が、１つの制御対象へ、それぞれ有効かつ異なる制御を試みようとしていることを、前記それぞれの制御装置へ通知する
　ことを特徴とする請求項１に記載の制御装置監視システム。
　前記制御装置の制御部は、
　自身で実行されているユーザプログラムを使用して、前記制御対象から送信された前記制御対象の制御に関する情報を基に、別の制御装置へ送信するための同期化データを生成し、
　前記生成した同期化データを前記別の制御装置へ送信する送信側の制御部と、
　前記別の制御装置で実行されている前記ユーザプログラムと同様のユーザプログラムを使用して、前記制御対象から送信された前記制御対象の制御に関する同じ情報を基に、前記動作検証用データとしての比較用データを生成し、
　前記別の制御装置の送信側の制御部が送信した同期化データと、自身で生成した前記比較用データとを比較することによって、前記別の制御装置の動作状態を検証する受信側の制御部と、
　を有することを特徴とする請求項１に記載の制御装置監視システム。
　３つ以上の前記制御装置と、
　前記制御装置と、前記制御装置によって制御される制御対象との間に接続されており、
　それぞれの前記制御装置から、同一種のプログラムを用いた出力情報を取得すると、
　前記取得した出力情報が一致していない場合、多数決に従って、多数の出力情報を正しい出力情報と判定する機器と、
　を有することを特徴とする制御装置監視システム。
　制御対象を制御する複数の制御装置の動作状態を監視する制御装置の監視方法であって、
　前記制御装置は、
　自身とは別の制御装置から、前記別の制御装置で実行されているプログラムが出力した、前記制御対象を制御する制御情報を取得し、前記取得した制御情報を基に、動作検証用のデータを生成する
　ことを特徴とする制御装置の監視方法。
　前記制御装置の送信側の制御部が、
　自身で実行されているユーザプログラムを使用して、前記制御対象から送信された前記制御対象の制御に関する情報を基に、別の制御装置へ送信するための同期化データを生成し、
　前記生成した同期化データを前記別の制御装置へ送信し、
　前記制御装置の受信側の制御部が、
　前記別の制御装置で実行されている前記ユーザプログラムと同様のユーザプログラムを使用して、前記制御対象から送信された前記制御対象の制御に関する同じ情報を基に、前記動作検証用データとしての比較用データを生成し、
　前記別の制御装置の送信側の制御部が送信した同期化データと、自身で生成した前記比較用データとを比較することによって、前記別の制御装置の動作状態を検証する
　ことを特徴とする請求項９に記載の制御装置の監視方法。