JP6623996B2 - 処理装置、ネットワーク装置、処理装置の制御方法、ネットワーク装置の制御方法、処理装置の制御プログラム、ネットワーク装置の制御プログラム及び記録媒体 - Google Patents

Description

本発明は、処理装置、ネットワーク装置、処理装置の制御方法、ネットワーク装置の制御方法、処理装置の制御プログラム、ネットワーク装置の制御プログラム及び記録媒体に関する。

従来から、化学等の工業プラント、ガス田や油田等の井戸元やその周辺を管理制御するプラント、水力・火力・原子力等の発電を管理制御するプラント、太陽光や風力等の環境発電を管理制御するプラント、上下水やダム等を管理制御するプラント等のプラントや工場等（以下、これらを総称する場合には「プラント」という）においては、フィールド機器と呼ばれる測定器又は操作器等の現場機器と、これらを制御する制御装置とが通信手段を介して接続された分散制御システム（ＤＣＳ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）が構築されており、高度な自動操業が実現されている。

上記のような高度な自動操業を実現するために構築されるプラントのシステム等においては、高い信頼性とリアルタイム性が要求される場合がある。例えば、プロセス制御等のプラントの制御においては、処理結果を処理の入力にフィードバックして使用するフィードバック制御等が多く用いられる。フィードバック制御等においては、処理データの欠損が発生すると、制御の安定性が低下する。

このため、プラントの制御においては、システムの可用性を向上させるため、複数の装置による冗長化構成を取る冗長化システムを用いる場合がある。冗長化システムにおいては、例えば、通常時に使用される処理装置と、この処理装置からのハートビート信号（後述）に基づき異常と判断された時に使用される他の処理装置を有する。異常時に使用される処理装置は、通常時に使用される処理装置が動作しているときには待機状態（スタンバイ状態）として制御処理を実行しない。通常時に使用される処理装置は、自装置のリソースが正常に稼働していることを報知するためのハートビート信号を所定の時間間隔で出力する。異常時に使用される処理装置は、通常時に使用される処理装置のハートビート信号を監視して、ハートビート信号に異常を検出したときに、待機状態から活性状態（アクティブ状態）に切替り、通常時に使用される処理装置の異常となったリソースを代替して制御処理を実行する（例えば、特許文献１又は特許文献２を参照）。

また、プラントの制御に用いられる制御ネットワークにおいては、制御ネットワークに接続された装置間の通信経路が正常であることを判断するために、各装置は通信を診断するためのパケットである診断通信パケットを定周期に同報送信する。診断通信パケットには、送信元の識別情報が含まれる。診断通信パケットを受信した装置は、送信元の装置をリスト化したライブリストを作成又は更新し、通信可能な装置の情報を保持する（例えば、特許文献３を参照）。

特開２０００−２１８４７６号公報 国際公開第２０１５／０９８５８９号 特開２０１５−０９２４００号公報

しかし、従来のシステムにおいては、冗長化システムを構築するために、ハートビート信号の生成処理や受信処理のように専用の処理を実行するための機能（ハードウェア又はソフトウェア）の追加が必要となり、装置コストが上昇してしまう場合があった。

また、例えば、処理を提供するリソースが正常であっても、ハートビート信号を送受信する配線等に断線等、追加した機能自体の異常が生じた場合、異常時に使用される処理装置はハートビート信号の異常を検出して、スタンバイ状態からアクティブ状態に切替り、処理の重複によるデータ不整合が生じる所謂スプリットブレインシンドローム（以下、「ＳＢ」と省略する。）が発生し、処理が不安定になる場合があった。

また、ライブリストは通信状態等において正常である装置をリスト化したものであり、冗長化システムの用途に用いられていなかった。

本発明は上記事情に鑑みてなされたものであり、安定性が高い冗長化構成を低コストで実現することができる、処理装置、ネットワーク装置、処理装置の制御方法、ネットワーク装置の制御方法、処理装置の制御プログラム、ネットワーク装置の制御プログラム及び記録媒体を提供することを目的とする。

（１）上記の課題を解決するため、本発明の処理装置は、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供部と、前記利用装置に対して処理を提供する他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された他の装置で生成されたライブリストを取得するライブリスト取得部と、取得された前記ライブリストに基づき、前記処理提供部の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替部とを備える。

（２）また、本発明の処理装置において、前記ライブリスト取得部は、複数の前記ライブリストを取得して、前記切替部は、所定の期間内で取得された複数の前記ライブリストのいずれにおいても、前記他の処理装置の中で冗長化を構成する処理装置からの前記診断通信パケットの送信が確認できないときに、前記処理提供部の状態を前記アクティブ状態に切替える。

（３）また、本発明の処理装置において、前記診断通信パケットを受信する診断通信パケット受信部と、受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成部と、生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信部とをさらに備える。

（４）また、本発明の処理装置において、前記診断通信パケット送信部は、前記自装置の処理が前記利用装置に利用される際に通信する全ての通信先に前記診断通信パケットを送信する。

（５）また、本発明の処理装置において、前記ライブリスト生成部は、前記他の処理装置を利用する際に通信する全ての通信先の前記診断通信パケットに基づき、ライブリストを生成する。

（６）上記の課題を解決するため、本発明の処理装置は、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供部と、診断通信パケットを所定の時間間隔で送信する診断通信パケット送信部と、前記ネットワークに接続された装置で生成されて所定の時間間隔で送信される、前記ネットワークに接続された装置の診断通信パケットに基づき生成されるライブリストを取得するライブリスト取得部とを備える。

（７）また、本発明の処理装置において、前記診断通信パケット送信部は、自装置の処理が前記利用装置に利用される際に通信する全ての通信先に前記診断通信パケットを送信する。

（８）また、本発明の処理装置において、取得された前記ライブリストに基づき、前記処理提供部の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態に切替える切替部をさらに備える。

（９）また、本発明の処理装置において、前記切替部は、所定の期間内で受信された前記ライブリストにおいて、前記利用装置との通信経路の通信状態を解析し、自装置との前記通信状態より前記利用装置に対して処理を提供する他の処理装置との前記通信状態の方が優位であるときに前記処理提供部の状態を前記スタンバイ状態に切替え、前記診断通信パケット送信部は、前記診断通信パケットの送信を中止する。

（１０）また、本発明の処理装置において、前記利用装置に対して処理を提供する他の処理装置から送信される前記診断通信パケットを受信する診断通信パケット受信部と、受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成部と、生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信部とをさらに備える。

（１１）上記の課題を解決するため、本発明のネットワーク装置は、プラントにおけるプロセス制御システムのネットワークに接続されるネットワーク装置であって、前記ネットワークに接続された利用装置に対して処理を提供する処理装置から所定の時間間隔で送信される診断通信パケットを受信する診断通信パケット受信部と、受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成部と、生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信部とを備える。

（１２）上記の課題を解決するため、本発明の処理装置の制御方法は、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供ステップと、前記利用装置に対して処理を提供する他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された他の装置で生成されたライブリストを取得するライブリスト取得ステップと、取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替ステップとを含む。

（１３）上記の課題を解決するため、本発明の処理装置の制御方法は、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供ステップと、診断通信パケットを所定の時間間隔で送信する診断通信パケット送信ステップと、前記ネットワークに接続された装置で生成されて所定の時間間隔で送信される、前記ネットワークに接続された装置の診断通信パケットに基づき生成されるライブリストを取得するライブリスト受信ステップとを含む。

（１４）上記の課題を解決するため、本発明のネットワーク装置の制御方法は、プラントにおけるプロセス制御システムのネットワークに接続されるネットワーク装置の制御方法であって、前記ネットワークに接続された利用装置に対して処理を提供する処理装置から所定の時間間隔で送信される診断通信パケットを受信する診断通信パケット受信ステップと、受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成ステップと、生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信ステップとを含む。

（１５）上記の課題を解決するため、本発明の処理装置の制御プログラムは、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供処理と、前記利用装置に対して処理を提供する他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された他の装置で生成されたライブリストを取得するライブリスト取得処理と、取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替処理とをコンピュータに実行させる。

（１６）上記の課題を解決するため、本発明の処理装置の制御プログラムは、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供処理と、診断通信パケットを所定の時間間隔で送信する診断通信パケット送信処理と、前記ネットワークに接続された装置で生成されて所定の時間間隔で送信される、前記ネットワークに接続された装置の診断通信パケットに基づき生成されるライブリストを取得するライブリスト取得処理とをコンピュータに実行させる。

（１７）上記の課題を解決するため、本発明のネットワーク装置の制御プログラムは、プラントにおけるプロセス制御システムのネットワークに接続されるネットワーク装置の制御プログラムであって、前記ネットワークに接続された利用装置に対して処理を提供する処理装置から所定の時間間隔で送信される診断通信パケットを受信する診断通信パケット受信処理と、受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成処理と、生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信処理とをコンピュータに実行させる。

（１８）上記の課題を解決するため、本発明の記録媒体は、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供処理と、前記利用装置に対して処理を提供する他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された他の装置で生成されたライブリストを取得するライブリスト取得処理と、取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替処理とをコンピュータに実行させる処理装置の制御プログラムを記録している。

（１９）上記の課題を解決するため、本発明の記録媒体は、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供処理と、診断通信パケットを所定の時間間隔で送信する診断通信パケット送信処理と、前記ネットワークに接続された装置で生成されて所定の時間間隔で送信される、前記ネットワークに接続された装置の診断通信パケットに基づき生成されるライブリストを取得するライブリスト取得処理とをコンピュータに実行させる処理装置の制御プログラムを記録している。

（２０）上記の課題を解決するため、本発明の記録媒体は、プラントにおけるプロセス制御システムのネットワークに接続されるネットワーク装置の制御プログラムを記録した記録媒体であって、前記ネットワークに接続された利用装置に対して処理を提供する処理装置から所定の時間間隔で送信される診断通信パケットを受信する診断通信パケット受信処理と、受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成処理と、生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信処理と、をコンピュータに実行させるネットワーク装置の制御プログラムを記録している。

本発明によれば、安定性が高い冗長化構成を低コストで実現することができる、処理装置、ネットワーク装置、処理装置の制御方法、ネットワーク装置の制御方法、処理装置の制御プログラム、ネットワーク装置の制御プログラム及び記録媒体を提供することができる。

実施形態における処理システムの構成例を示す図である。 実施形態における診断通信パケットの一例を示す図である。 実施形態におけるライブリストの一例を示す図である。 実施形態における診断通信パケットの送信動作の一例を示すフローチャートである。 実施形態におけるライブリストの更新動作の一例を示すフローチャートである。 実施形態における処理装置の切替え動作の一例を示すフローチャートである。 実施形態におけるライブリストの更新の一例を示す図である。 実施形態におけるライブリストの検索結果の一例を示す図である。 実施形態における処理装置の第２の構成例を示す図である。 実施形態における処理システムのアプリ通信路の一例を示す図である。 実施形態におけるライブリストの論理的結合の一例を示す図である。 実施形態における処理装置の切替え動作の一例を示すフローチャートである。

以下、図面を参照して本発明の一実施形態における処理装置、ネットワーク装置、処理装置の制御方法、ネットワーク装置の制御方法、処理装置の制御プログラム、ネットワーク装置の制御プログラム及び記録媒体について詳細に説明する。

先ず、図１を用いて、処理システムの構成を説明する。図１は、実施形態における処理システムの構成例を示す図である。

図１において、処理システム１０は、処理装置１１、処理装置１２、端末装置１３及び端末装置１４を有する。先ずは、処理装置１１、処理装置１２、端末装置１３及び端末装置１４（以下、「処理装置等」と省略する場合がある。）の概要を説明する。処理装置等は、ネットワークで接続されたプラントにおけるプロセス制御システムを構成する装置である。処理装置等には、図示しないゲートウェイ装置等のネットワーク装置を含んでいてもよい。処理装置等は、例えば、サーバ装置、デスクトップ型ＰＣ、ノート型ＰＣ、タブレット型ＰＣ、ＰＤＡ、又はスマートフォン等の汎用コンピュータである。また、処理装置等は、プラントにおける保全情報を管理する保全情報管理サーバ、ＤＣＳ制御装置、ＦＡ（Ｆａｃｔｏｒｙ Ａｕｔｏｍａｔｉｏｎ）コンピュータ、ＰＬＣ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒ）、操作監視装置、操作卓等のプラントにおけるプロセス制御システムを構成する専用の装置であってもよい。また、処理装置等は、フィールド機器又はフィールド機器を保全する保全専用装置であってもよい。フィールド機器とは、例えば、差圧計、温度計、流量計等の物理量（圧力、温度等）の信号を入力する入力機器、又は調節弁の開度等を変更する制御信号を出力する出力機器である。また、保全専用装置は、フィールド機器に対して、例えば、ループテスト（ループ試験）、ゼロ点調整、スパン調整等の保全項目を実施させる装置である。

処理装置等は、図示しない、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、表示装置、キーボード又はマウス等の入力装置等を有するものとする。以下に説明する、処理装置１１、処理装置１２、端末装置１３及び端末装置１４の各機能は、ＲＡＭ等に記憶されたプログラムをＣＰＵが実行することによりそれぞれの装置のおける機能を実現することができる。すなわち、処理装置等の各機能は、ソフトウェアによって実現される機能モジュールである。なお、処理装置等で実行されるそれぞれのプログラムは、プログラムを提供するサーバから提供され、又は記録媒体から提供されてもよい。

処理装置１１は、ネットワーク１９で接続される端末装置１３及び端末装置１４に対して所定の処理を提供する装置（アクティブ側装置）である。処理装置１１は、処理装置１２（スタンバイ側装置）をペア装置として冗長化システムを構成する。処理装置１１が提供する処理とは、例えば、プラントにおけるプロセス制御システムを構成するコントローラが実施する典型的なプロセス制御処理であり、本実施形態においては、後述するライブリストを用いて監視する処理装置が提供するサービスである。また、この処理装置が提供する処理は、汎用的なサーバ処理としてデーモン系のサービスであっても仮想ＩＰのサービスであってもよい。監視対象の処理装置が提供するサービスは、ＯＳ１１２及びアプリ（「アプリケーション」の略。以下同様。）１１３を実行するハードウェアやハイパーバイザ（仮想化）の動作環境（プラットフォーム）によって提供される。従って、処理装置の監視は、この動作環境（プラットフォーム）が動いているか否かを監視することによって行うことができる。また、監視対象の処理装置が提供するサービスは、ＯＳ又はアプリそのものであってもよい。サービスには、例えば、データ処理、データ保存、データ送信、通信サービス、Ｗｅｂブラウザに対するＷｅｂサービス等、ネットワークを介して提供される処理等が挙げられる。処理装置が提供するサービスの監視はこれらの処理毎に行うようにしてもよい。なお、本実施形態において処理装置１１が提供する処理を利用する装置を利用装置という。端末装置１３及び端末装置１４は利用装置の一例を示す。

処理装置１１は、ネットワーク１９を介して、診断通信パケット（ＳＰ１１）をブロードキャストする。診断通信パケットとは、自装置が正常に動作していることを示す診断通信パケットの一例である。診断通信パケットを受信したネットワーク１９に接続された装置は、受信した診断通信パケットの送信元の装置（処理装置１１）の動作状態と、送信元の装置から自装置までの通信経路の通信状態が正常であることを診断することができる。診断通信パケットを受信した装置は、例えば診断通信パケットの送信元の装置を通信先として選択する等の処理を実行することが可能となる。なお、図１において診断通信パケット（ＳＰ１１）は、端末装置１３及び端末装置１４に送信されているもののみを図示している。

なお、本実施形態においては、処理装置１２、端末装置１３及び端末装置１４においても、ネットワーク１９を介して、診断通信パケット（ＳＰ１２〜ＳＰ１４）をブロードキャストするものとする。すなわち、それぞれの装置が自装置が正常に動作していることを示す診断通信パケットをネットワーク１９に接続された装置に送信する場合を例示する。

また、処理装置１１、処理装置１２、端末装置１３及び端末装置１４は、それぞれの装置において、受信した診断通信パケットに基づき、ライブリストを生成して、生成したライブリストを自らが送信する診断通信パケットのデータとしてブロードキャストするものとする。ライブリストの生成及び送信の詳細は後述する。

処理装置１２は、処理装置１１とペアになって冗長化システム（冗長化装置構成）を構成する。処理装置１２は、処理装置１１に異常が発生したときに、処理装置１１が提供する処理を代替する。処理装置１２は、処理装置１１が正常に動作しているときにはスタンバイ状態として、処理を提供しない。処理装置１２は、処理装置１１に異常が発生したときにスタンバイ状態からアクティブ状態になって処理の提供を開始することにより、処理装置１１を代替する。スタンバイ状態の処理装置を「スタンバイ側装置」、また、アクティブ状態の装置を「アクティブ側装置」という場合がある。処理装置１２は、ネットワーク１９を介して、図示しない診断通信パケット（ＳＰ１２）をブロードキャストする。

端末装置１３及び端末装置１４は、ネットワーク１９に接続された、プラントにおけるプロセス制御システムを構成するネットワーク装置の中で、上記した処理装置１１又は処理装置１２以外の装置であって、処理装置１１又は処理装置１２の通信先の一例である。図１における端末装置１３及び端末装置１４は、処理装置１１又は処理装置１２が提供する処理を利用する利用装置であって、冗長化構成を構成しないシングル構成の処理装置を例示している。端末装置１３及び端末装置１４は、ネットワーク１９を介して、診断通信パケット（ＳＰ１３及びＳＰ１４）をブロードキャストする（一部図示せず）。

次に、処理装置１１、処理装置１２、端末装置１３及び端末装置１４のそれぞれの内部構成について説明する。

処理装置１１は、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１１１、ＯＳ１１２、アプリ１１３、診断通信受信部１１４、ライブリスト生成部１１５、診断通信データ生成部１１６及び診断通信送信部１１７の機能を有する。

ＮＩＣ１１１は、ネットワーク１９を介した通信を行う通信機能の一例である。ＮＩＣ１１１は、第１の識別情報として例示するアプリ通信用アドレスと、第２の識別情報として例示する診断通信用アドレスを有する。

アプリ通信用アドレスは、ＯＳ１１２上で動作するアプリ１１３との通信を行うための識別情報であり、通信相手先のアプリ１１３をネットワーク内で一意に決める識別子である。冗長化構成を構成する場合のアプリ通信用アドレスは、アプリが動作するアクティブ側装置に設定され、アプリが動作しないスタンバイ側装置には設定されない。アクティブ側装置が、ＰＣ１１からＰＣ１２に切替わる場合、アプリ通信用アドレスはアクティブ側装置となるＰＣ１２にのみ設定される（遷移する）。アプリ通信用アドレスには、例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス、アプリケーション専用識別子等を用いることができる。アプリケーション専用識別子は、例えば、Ｖｎｅｔ（登録商標）等のネットワークに接続された機器間を通信可能にするプロセス制御用の制御バスにおける機器アドレスであってもよい。

処理装置１１における診断通信用アドレスは、ネットワークに接続された装置個体を一意に決める識別子である。冗長化システムを構成する場合においてアクティブ状態の装置が切替っても、診断通信用アドレスは固定である。診断通信用アドレスは、アプリ通信用アドレスよりも物理層に近いアドレスを使用したＭＡＣアドレスやＩＰアドレスなどを使用することができる。診断通信パケットに処理装置１１の診断通信用アドレスを送信元を識別する情報として含ませることにより、診断通信パケットを受信した例えば端末装置１３は、処理装置１１とのパケット送受信において処理装置１１から端末装置１３へのパケット送信が正常であると判断することができる。

本実施形態では、第１の識別情報として例示するアプリ通信用アドレスと、第２の識別情報として例示する診断通信用アドレスは、同じＮＩＣ１１１を用いる。従って、例えば、アプリ通信用アドレスを用いた通信の負荷が大きい場合、診断通信用アドレスを用いた診断通信パケットの送受信が失敗する場合がある。例えば、ＩＥＥＥ ８０２．１ｐに規定されているプライオリティサービスを利用して診断通信パケットの送受信の優先度をアプリ通信の優先度より高くすることにより、アプリ通信の負荷が大きい場合でも診断通信パケットの通信の失敗を低減させることができる。

アプリ通信用アドレス等アプリ固有の識別子である第１の識別情報と、ＩＰアドレスン度の第２の識別情報を同じＮＩＣ１１１に割り振ることにより、第１の識別情報と第２の識別情報のネットワーク１９に対する可用性を同等にすることができる。例えば、ＮＩＣ１１１に接続されるＬＡＮケーブルの抜けや断線、ＮＩＣ１１１の故障等のＮＩＣ１１１関連の通信障害に対して、第１の識別情報と第２の識別情報は、同様に使用（稼働）できなくなる。これにより、ＮＩＣ１１１関連の通信障害により第２の識別情報を利用した診断通信パケットの送信ができないときには、第１の識別情報を利用したアプリケーション通信もできないことになる。従って、この通信障害によって診断通信パケットが検出できないときに、同一の第１の識別情報を割り当てられたアクティブ側アプリケーションが複数個通信できることによるＳＢの発生を防止することが可能となる。

なお、第１の識別情報は、上述のように処理装置１２が提供するアプリ通信用アドレスと共通している。端末装置１３及び端末装置１４は、共通した第１の識別情報を用いることにより、処理システム１０の冗長化構成において処理装置１１が提供する処理と処理装置１２が提供する処理を区別することなく利用することが可能となり、端末装置１３及び端末装置１４の可用性を向上させることができる。

ＯＳ１１２上で動作するアプリ１１３は、ＮＩＣ１１１を介して、端末装置１３に提供するサービスの処理を行う。アプリ１１３は、後述するライブリストに基づき、サービスを提供する相手先の装置の動作状態を把握することが可能となる。本実施形態においては、ＯＳ１１２及びアプリ１１３がサービスを提供できるか否かを、診断通信パケットが受信できたか否かで利用装置側である端末装置１３及び端末装置１４で判断する。

診断通信受信部１１４は、ネットワーク１９に接続された他の装置から送信された診断通信パケットを受信する。図１において診断通信受信部１１４は、処理装置１２、端末装置１３及び端末装置１４がそれぞれ個別に送信する診断通信パケットを受信する。診断通信パケットを送信するタイミングは、送信側の装置において定められるため、処理装置１２、端末装置１３及び端末装置１４から診断通信受信部１１４がそれぞれ個別に受信する診断通信パケットの受信タイミングは非同期となる。診断通信受信部１１４は、受信した診断通信パケットをライブリスト生成部１１５に送信する。診断通信受信部１１４は、診断通信パケットを受信する度にライブリスト生成部１１５に送信する。但し、診断通信受信部１１４は、所定の時間内に受信した診断通信パケットをまとめてライブリスト生成部１１５に送信してもよい。

ライブリスト生成部１１５は、診断通信受信部１１４から診断通信パケットを受信して、ライブリストを生成する。ライブリストとは、受信した診断通信パケットの送信元の装置の動作状態の情報と、送信元の装置から自装置までの通信経路の通信状態の情報とをリスト化したもの（ライブ情報）である。ネットワーク１９に接続している装置は、それぞれ診断通信パケットを送信するため、２つの装置間においては、診断通信パケットの送信と受信が相互に行われることになる。ライブリスト生成部１１５は、診断通信パケットを受信した装置をリスト化するため、ライブリスト生成部１１５が生成したライブリストは少なくとも処理装置１１に対する他装置からの診断通信パケットの送信において通信が正常である装置をリスト化したものとなる。

診断通信パケットは、使用される全てのアプリ通信路を網羅するように送信される。アプリ通信路とは、ネットワーク１９において処理装置と利用装置のアプリが使用する通信路であって、図示しないゲートウェイ装置等のネットワーク装置によって中継された通信路を含む。アプリ通信路がゲートウェイ装置によって中継される場合には、ゲートウェイも、診断通信パケットの送信対象となる。ライブリスト生成部１１５は、アプリ通信路において通信する全ての通信先の診断通信パケットに基づき、ライブリストを生成する。従って、アプリ通信路がゲートウェイ装置によって中継される場合には、生成されるライブリストに含まれることになる。これにより、アプリ通信路のいずれか１つが正常であれば、アクティブ側装置の診断通信パケットが受信され、一方、アクティブ側装置の診断通信パケットが全く受信されない場合、いずれのアプリ通信路も不通であるか処理装置自体が故障等して診断通信パケットを送信していないことになる。ライブリストを利用することにより、スタンバイ状態の処理装置がアクティブ状態になった場合でもＳＢの発生を防止することが可能となる。

ライブリスト生成部１１５は、生成したライブリストをアプリ１１３及び診断通信データ生成部１１６から読出し可能に記憶する。ライブリストの記憶は、例えば図示しないＲＡＭやＨＤＤに行うことができる。アプリ１１３及び診断通信データ生成部１１６は、記憶されたライブリストを任意のタイミングで読み出すようにしてもよい。

診断通信データ生成部１１６は、診断通信パケットを生成する。診断通信データ生成部１１６は、診断通信パケットに処理装置１１を識別するための情報を含める。処理装置１１を識別するための情報としては、処理装置１１の診断通信用のＩＰアドレスやＭＡＣアドレスを用いることができる。診断通信データ生成部１１６は、生成する診断通信パケットのＩＰデータ部にライブリスト生成部１１５で生成されたライブリストを含める。

診断通信送信部１１７は、診断通信データ生成部１１６で生成された診断通信パケットを、上述のように使用される全てのアプリ通信路を網羅するように送信される。診断通信送信部１１７は、診断通信パケットを、所定のタイミングでＮＩＣ１１１を介してネットワーク１９にブロードキャストする。診断通信送信部１１７が診断通信パケットを送信するタイミングは、例えば予め定められた時間間隔（送信周期）である。診断通信送信部１１７は、送信周期になったときに診断通信データ生成部１１６に対して診断通信パケットを生成するように指示して、診断通信データ生成部１１６が生成した診断通信パケットを取得してブロードキャストするようにしてもよい。なお、本実施形態では、診断通信送信部１１７は、診断通信パケットをブロードキャストするものとして説明するが、診断通信パケットを受信する装置が限定されている場合等には、ブロードキャストの代わりにマルチキャスト又はユニキャストを用いてもよい。また、診断通信送信部１１７は、ルータを越えた他のセグメントのネットワークに診断通信パケットをブロードキャスト送信（ディレクティッドブロードキャストアドレスへ送信）するようにしてもよい。

処理装置１２は、ＮＩＣ１２１、ＯＳ１２２、アプリ１２３、診断通信受信部１２４、ライブリスト生成部１２５、診断通信データ生成部１２６、診断通信送信部１２７、ライブリスト検索部１２８、装置停止検出部１２９及び切替部１２０の機能を有する。

ＮＩＣ１２１の構成は、ＮＩＣ１１１の構成と同様である。すなわち、ＮＩＣ１２１は、ＮＩＣ１１１と同様に、ネットワーク１９を介した通信を行う通信機能の一例である。ＮＩＣ１２１も、第１の識別情報として例示するアプリ通信用アドレスと、第２の識別情報として例示する診断通信用アドレスを有する。ＮＩＣ１２１のアプリ通信用アドレスは、ＮＩＣ１１１のアプリ通信用アドレスと同じアドレスである。

ＯＳ１２２及びアプリ１２３は、スタンバイ状態とアクティブ状態が切替えられる。アプリ１２３がアクティブ状態にされたときには、ＮＩＣ１２１の第１の識別情報であるアプリ通信用アドレスを用いて、処理装置１１と共通した処理が提供される。一方、アプリ１２３がスタンバイ状態にされたときには処理が提供されない。図１に図示するＯＳ１２２及びアプリ１２３の破線は、ＯＳ１２２及びアプリ１２３がスタンバイ状態であることを示している。

ＯＳ１２２及びアプリ１２３は、切替部１２０からの要求に基づきスタンバイ状態からアクティブ状態に切替えられる（遷移する）。ＯＳ１２２及びアプリ１２３がアクティブ状態に遷移することにより、アプリ１１３に代替した処理が継続される。なお、アクティブ状態から待機状態への遷移は、処理装置１２の再起動に基づくものであってもよい。

診断通信受信部１２４、ライブリスト生成部１２５、診断通信データ生成部１２６及び診断通信送信部１２７のそれぞれの機能は、処理装置１１における、診断通信受信部１１４、ライブリスト生成部１１５、診断通信データ生成部１１６、診断通信送信部１１７のそれぞれ機能と同様であるため、説明を省略する。但し、診断通信受信部１２４は、受信した診断通信パケットを、ライブリスト生成部１２５に送信するとともにライブリスト検索部１２８にも送信する。

ライブリスト検索部１２８は、診断通信受信部１２４から診断通信パケットに含まれるライブリストを取得して、取得したライブリストの中から冗長化システムを構成するペアの処理装置である処理装置１１を検索して、処理装置１１の状態を更新して記録する。処理装置１１の状態をアクティブ側装置ライブ情報と言うものとする。処理装置１２において、診断通信パケットは、処理装置１１、端末装置１３及び端末装置１４から取得されるが、ライブリスト検索部１２８は、処理装置１１が提供する処理を利用する端末装置１３及び端末装置１４から取得した診断通信パケットを検索対象とする。すなわち、ライブリスト検索部１２８は、処理装置１１が提供する処理を利用する利用装置から見た場合の処理装置１１の状態を取得して記録する。ライブリスト検索部１２８は、端末装置１３から取得した診断通信パケットの含まれるライブリストと端末装置１４から取得した診断通信パケットに含まれるライブリストのそれぞれに基づき、個別にアクティブ側装置ライブ情報の処理装置１１の状態を更新する。

また、診断通信受信部１２４が取得するライブリストは、端末装置１３及び端末装置１４からそれぞれ個別に非同期で取得されるものである。従って、ライブリスト検索部１２８は、処理装置１１の状態の更新を、それぞれの診断通信パケットを取得したタイミングで行う。上述のように、アクティブ側装置ライブ情報は、端末装置１３のライブリストと端末装置１４のライブリストのそれぞれに基づき個別に更新されるため、処理装置１１の状態の更新において書込みタイミングが問題になることがない。ライブリスト検索部１２８は、所定の時間内に診断通信パケットを受信しなかった場合、診断通信パケットを受信しなかった端末のライブリストは参照できない。従って、ライブリスト検索部１２８は、所定の時間内に診断通信パケットを受信しなかった端末のライブリストを「停止」と見做して、アクティブ側装置ライブ情報の処理装置１１の状態を「停止」に更新する。なお、アクティブ側装置ライブ情報は、装置停止検出部１２９から読み出し可能に、例えば図示しないＲＡＭ等に記録されるものとする。

装置停止検出部１２９は、記録されたアクティブ側装置ライブ情報が全て「停止」である場合、処理装置１１は停止中であると判断して、切替部１２０に対してアプリ１２３の状態をアクティブに切替えるように指示する。アクティブ側装置ライブ情報は、ライブリストに処理装置１１の「停止」が記録されていた場合、又は所定の時間内にライブリストが更新されなかった場合に、その端末装置（端末装置１３又は端末装置１４）の処理装置１１の状態が「停止」となる。装置停止検出部１２９は、端末装置１３のライブリストに基づく処理装置１１の状態と、端末装置１４のライブリストに基づく処理装置１１の状態の両方が「停止」である場合、処理装置１１が停止中であると判断する。一方、装置停止検出部１２９は、端末装置１３のライブリストに基づく処理装置１１の状態と、端末装置１４のライブリストに基づく処理装置１１の状態のいずれかが「稼働」である場合、処理装置１１は稼働中であると判断する。もし、処理装置１１が実際に停止している場合には、全てのライブリストの処理装置１１の状態は「停止」となるため、いずれかのライブリストが「稼働」である場合は、処理装置１１は稼働中であると判断することができる。これにより、装置停止検出部１２９は、処理装置１１が実際に停止している場合と、処理装置１１は実際には稼働中であるにも拘わらずネットワーク障害等によってパケット通信の一部に不具合が発生している場合とを切り分ける判断が可能となる。

切替部１２０は、装置停止検出部１２９からの指示によってアプリ１２３に対して、待機状態からアクティブ状態に切替わるように要求する処理を行う。冗長化動作とは、２台の汎用装置をネットワークで接続した冗長化装置構成において、スタンバイ側装置がアクティブ側装置に切替えられように準備している状態である。例えば、フォールトトレラントの場合では、アクティブ側装置のメモリやディスクが変更されたら、変更箇所をスタンバイ側装置にコピーして等値化する。

端末装置１３は、ＮＩＣ１３１、ＯＳ１３２、アプリ１３３、診断通信受信部１３４、ライブリスト生成部１３５、診断通信データ生成部１３６及び診断通信送信部１３７の機能を有する。また、端末装置１４は、ＮＩＣ１４１、ＯＳ１４２、アプリ１４３、診断通信受信部１４４、ライブリスト生成部１４５、診断通信データ生成部１４６及び診断通信送信部１４７の機能を有する。

また、端末装置１３のＮＩＣ１３１、ＯＳ１３２、アプリ１３３、診断通信受信部１３４、ライブリスト生成部１３５、診断通信データ生成部１３６及び診断通信送信部１３７の各機能は、処理装置１１のＮＩＣ１１１、ＯＳ１１２、アプリ１１３、診断通信受信部１１４、ライブリスト生成部１１５、診断通信データ生成部１１６及び診断通信送信部１１７の各機能に準ずる。

アプリ１３３は、処理装置１１のアプリ１１３が提供する処理又は処理装置１２のアプリ１２３が提供する処理のいずれかを利用する。アプリ１３３は、処理装置１１と処理装置１２で共通する第１の識別情報であるアプリ通信用アドレスを用いることにより、アプリ１１３が提供する処理が停止した場合でも、代替して動作するアプリ１２３が提供する処理を継続的に利用することができる。

なお、図１においては、診断通信パケットはネットワーク１９に接続されたそれぞれの装置からブロードキャストされる場合を説明したが、ネットワーク１９にルータ等のゲートウェイ装置が接続されて通信が制限されている場合、ゲートウェイ装置によって診断通信パケットの送信先を制限するようにしてもよい。

また、図１においては、処理装置１１、処理装置１２、端末装置１３及び端末装置１４の各機能がソフトウェアによって実現される場合を説明した。しかし、処理装置１１、処理装置１２、端末装置１３及び端末装置１４の各機能が有する上記１つ以上の機能は、ハードウェアによって実現されるものであっても良い。また、処理装置１１、処理装置１２、端末装置１３及び端末装置１４の各機能が有する上記各機能は、１つの機能を複数の機能に分割して実施してもよい。また、処理装置１１、処理装置１２、端末装置１３及び端末装置１４が有する上記各機能は、２つ以上の機能を１つの機能に集約して実施してもよい。
以上で、図１を用いた、処理システムの構成の説明を終了する。

次に、図２を用いて、図１で説明した、診断通信データ生成部１１６等において生成される診断通信パケットを説明する。図２は、実施形態における診断通信パケットの一例を示す図である。

図２において、診断通信パケットは、ＩＰヘッダ部とＩＰデータ部を有するＩＰパケットを示している。診断通信パケットのＩＰヘッダ部には、パケットの送信元のＩＰアドレスと宛先のＩＰアドレスが含まれる。図２は、送信元が処理装置１２であり、宛先がブロードキャストである場合を示している。送信元には、処理装置１２の診断通信用アドレスであるＩＰアドレス（１９２．１６８．１．２）が示されている。また、宛先アドレスには、ブロードキャスト用のＩＰアドレス（１９２．１６６８．１．２５５）が示されている。本実施形態では、診断通信パケットの送信元アドレスを診断通信用アドレスとすることにより、ＩＰデータ部には送信元に関する情報を入力する必要がなくなり、パケット送受信負荷を軽減することができる。

診断通信パケットのＩＰデータ部には、ライブリスト生成部１２５で生成されたライブリストの情報が入力される。診断通信パケットは、送信元の識別情報（例えば、送信元のＩＰアドレス）を含むことにより、送信元から送信されるパケット通信が正常であることを示すことができる。従って、送信元から送信されるパケット通信が正常であることを示すのみの目的の場合、診断通信パケットのＩＰデータ部にはパケットデータ量を削減するためデータを入力しない。本実施形態では、診断通信パケットのＩＰデータ部にライブリストの情報を含ませることにより、別途ライブリストをネットワーク１９に接続された他の装置に送信する場合に比べて、ライブリストを別途送信する機能を追加する必要がなく、装置コストを削減することが可能となる。また、診断通信パケットを用いることにより、ライブリストを送信するための専用のパケットの送受信が不要となり、ネットワークの通信負荷を削減することが可能となる。
以上で、図２を用いた、診断通信パケットの説明を終了する。

次に、図３を用いて、図２で説明した、診断通信パケットに含まれるライブリストを説明する。図３は、実施形態におけるライブリストの一例を示す図である。図３は、端末装置１３から送信される診断通信パケットに含まれるライブリストを示している。図３において、ライブリストは、「ＩＰアドレス」と「状態」の項目を含んでいる。

「ＩＰアドレス」は、診断通信パケットを受信した他の装置の識別情報である。図３のライブリストは、ＩＰアドレスとして、１９２．１６８．１．１〜１９２．１６８．１．２５４のネットワークの全アドレス分のデータを有している。この中で、１９２．１６８．１．１〜１９２．１６８．１．４は、ＰＣ１１〜ＰＣ１４で図示する処理装置１１、処理装置１２、端末装置１３及び端末装置１４に対して割り振られたＩＰアドレスである。１９２．１６８．１．５〜１９２．１６８．１．２５４は未使用のアドレスである。図３においては、ネットワークの全アドレス分のデータを予め用意しておくことにより、ライブリストのデータ長を固定することができ、ライブリストを受信した装置における解析が容易になる。また、ネットワークに接続される装置が増減する場合においても、ライブリストをそのまま使用することが可能となる。

「状態」は、「ＩＰアドレス」の項目で特定される装置が稼働中か停止中かを示すライブリストの項目である。「状態」が「○」の場合、当該装置が稼働中であることを示す。また、「状態」が「×」の場合、当該装置が停止中であることを示す。図３のライブリストにおいては、処理装置１１と処理装置１２が稼働中であり、端末装置１４が停止中であることを示している。図３は、端末装置１３から送信されるライブリストであるため、端末装置１３自身のライブリストはデータが無いことを示す「−」で示している。また、未使用のアドレスについても同様にライブリストはデータが無いことを示している。図３に示すライブリストは、図２で示したＩＰデータ部に含まれて診断通信パケットで送信される。

なお、図３においてライブリストは説明のために表形式のデータで表したが、診断通信パケットに含まれるライブリストは、他のデータ形式であってもよい。例えば、ライブリストは、ＣＳＶ（Ｃｏｍｍａ−Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ）データであってもよい。

また、図３においては、ライブリストのデータ長が固定の場合を説明したが、ライブリストのデータ長は可変であってもよい。例えば、ライブリストには、実際にネットワークに接続されている処理装置１１、処理装置１２、端末装置１３及び端末装置１４についてのライブリストが含まれ、未使用のアドレスについてのライブリストは含まれないようにすることにより、ライブリストのデータ量を削減することが可能となる。

また、ライブリストは暗号化されたデータであってもよい。また、図３におけるライブリストは、装置の状態が稼働中か停止中かを示すライブリストのみを含む場合を説明したが、ライブリストには他の情報が含まれていてもよい。ライブリストには、例えば、通信速度、パケットロス、パケット通信の成功率等の情報が含まれていてもよい。
以上で、図３を用いた、ライブリストの説明を修了する。

次に、図４を用いて、診断通信パケットの送信動作を説明する。図４は、実施形態における診断通信パケットの送信動作の一例を示すフローチャートである。なお、図４で説明する診断通信パケットの送信動作は、処理装置１１が実行するものとして説明するが、診断通信パケットの送信動作は、処理装置１２、端末装置１３及び端末装置１４において同様である。

図４において、処理装置１１は、タイマ値をリセットして、タイマをスタートさせる（ステップＳ１１）。ステップＳ１１の処理においてスタートするタイマは、次のステップＳ１２の処理において送信周期を計時するためのタイマである。

ステップＳ１１の処理を実行した後、処理装置１１は、タイマ値が送信周期になったか否かを判断する（ステップＳ１２）。送信周期とは、診断通信パケットをブロードキャストする周期である。送信周期が短いと、診断通信パケットの送信間隔が短くなり、診断通信パケットにより検出可能な不具合の発見が早くなる。一方、送信周期が長いと、診断通信パケットの送信間隔が長くなり、診断通信パケットによるネットワークの通信負荷を低減することができる。タイマ値が送信周期になっていないと判断した場合（ステップＳ１２：ＮＯ）、処理装置１１は、ステップＳ１２の処理を繰り返す。

一方、タイマ値が送信周期になったと判断した場合（ステップＳ１２：ＹＥＳ）、処理装置１１は、ライブリストを読み出す（ステップＳ１３）。ライブリストは、図１で説明したライブリスト生成部１１５において生成されて、診断通信データ生成部１１６から読み出し可能に保存されている。すなわち、ステップＳ１３の処理で読み出すライブリストは、ライブリスト生成部１１５において更新された最新の情報である。

ステップＳ１３の処理を実行した後、処理装置１１は、診断通信パケットを生成する（ステップＳ１４）。診断通信パケットは、図２で説明したように、ＩＰデータ部にステップＳ１３の処理で読み出したライブリストを入力することによって実行される。ステップＳ１４の処理を実行した後、処理装置１１は、ステップＳ１４の処理で生成した診断通信パケットをブロードキャスト送信する（ステップＳ１５）。

ステップＳ１５の処理を実行した後、処理装置１１は、診断通信パケットを送信する処理を終了（中断）するか否かを判断する（ステップＳ１６）。診断通信パケットの送信処理を終了しないと判断した場合（ステップＳ１６：ＮＯ）、処理装置１１はステップＳ１１の処理に戻り、ステップＳ１１〜ステップＳ１６の処理を繰り返す。一方、診断通信パケットを送信する処理を終了すると判断した場合（ステップＳ１６：ＹＥＳ）、処理装置１１は図４のフローチャートに示す診断通信パケットの送信動作を終了する。処理装置１１は、処理の提供中においては診断通信パケットの送信処理を継続するが、例えば、意識的に処理装置１２に処理を代替させる場合は、診断通信パケットの送信処理を終了させる。診断通信パケットの送信処理を終了すると、端末装置１３及び端末装置１４が送信するライブリストの内容から処理装置１１の停止又はネットワークからの切離しを処理装置１２が判断することができるので、処理装置１２は待機状態からアクティブ状態に遷移する。
以上で、図４を用いた、診断通信パケットの送信動作の説明を終了する。

次に、図５を用いて、ライブリストの更新動作を説明する。図５は、実施形態におけるライブリストの更新動作の一例を示すフローチャートである。図５に示すフローチャートは、診断通信パケットを送信する装置毎に並行して実行される。例えば、端末装置１３は、処理装置１１、処理装置１２及び端末装置１４からそれぞれ送信される診断通信パケットを受信するため、端末装置１３が生成するライブリストには、処理装置１１のライブリスト、処理装置１２のライブリスト及び端末装置１４のライブリストが含まれる。従って、端末装置１３のライブリストにおける、処理装置１１のライブリストの更新動作、処理装置１２のライブリストの更新動作及び端末装置１４のライブリストの更新動作はそれぞれ非同期に並行して実行される。以下の説明では、端末装置１３における処理装置１１のライブリストの更新動作について例示して説明する。端末装置１３における処理装置１２のライブリストの更新動作及び端末装置１４のライブリストの更新動作についても同様に実行される。また、処理装置１１、処理装置１２及び端末装置１４のライブリストにおける更新動作についても同様に実行される。

図５において、端末装置１３は、タイマ値をリセットして、タイマをスタートさせる（ステップＳ２１）。ステップＳ２１の処理においてスタートするタイマは、ステップＳ２４の処理において診断通信パケットの受信期限を計時するためのタイマである。

ステップＳ２１の処理を実行した後、端末装置１３は、処理装置１１の診断通信パケットが受信されたか否かを判断する（ステップＳ２２）。処理装置１１の診断通信パケットは、図４で説明した送信周期でブロードキャスト送信される。処理装置１１の診断通信パケットが受信されたと判断した場合（ステップＳ２２：ＹＥＳ）、端末装置１３は、処理装置１１のライブリストを更新する（ステップＳ２３）。ライブリストが稼働中か停止中かの情報のみである場合は稼働中の情報が維持される。しかし、診断通信パケットの受信によって取得できる他のライブリストをライブリストに記録する場合、取得した情報に基づきライブリストを更新する。

一方、処理装置１１の診断通信パケットが受信されていないと判断した場合（ステップＳ２２：ＮＯ）、端末装置１３は、タイマがタイムアップしたか否かを判断する（ステップＳ２４）。ステップＳ２４での処理で判断するタイマの値は、処理装置１１の診断通信パケットの送信周期に基づき予め定めておくことができる。例えば、処理装置１１の診断通信パケットの送信周期がＴｈｂ（秒）である場合、タイムアップの値をＴｈｂ×ｎ（ｎは１以上の整数）（秒）とする。ブロードキャストによるパケット通信は、受信確認を行わないため、処理装置１１が送信した診断通信パケットが端末装置１３に到達できない場合もある。そこで、例えば、タイムアップの値をＴｈｂ×３（秒）とすることにより、３回の診断通信パケットの受信機会をえることができ、一時的なパケットロスによる影響を少なくすることができる。タイマがタイムアップしていないと判断した場合（ステップＳ２４：ＮＯ）、端末装置１３は、ステップＳ２の処理に戻り診断通信パケットが受信を待機する。

一方、タイマがタイムアップしたと判断した場合（ステップＳ２４：ＹＥＳ）、端末装置１３は、ライブリストにおける処理装置１１のライブリストを停止中（図３における状態の項目を「×」）に更新する（ステップＳ２５）。なお、ステップＳ２５の処理においてライブリストが停止中に更新された場合であっても、ステップＳ２２の処理において診断通信パケットを再度受信した場合、ライブリストは再び稼働中に更新される。更新されたライブリストは、図４で説明したライブリストの読出しによって送信される端末装置１３の診断通信パケットのＩＰデータ部に含まれて、端末装置１３からブロードキャストされる。

ステップＳ２３の処理又はステップＳ２５の処理を実行した後、端末装置１３は、診断通信パケットの受信処理を終了するか否かを判断する（ステップＳ２６）。診断通信パケットの受信処理を終了しないと判断した場合（ステップＳ２６：ＮＯ）、端末装置１３はステップＳ２１の処理に戻り、ステップＳ２１〜ステップＳ２６の処理を繰り返す。一方、診断通信パケットの受信処理を終了すると判断した場合（ステップＳ２６：ＹＥＳ）、端末装置１３は図５のフローチャートに示す診断通信パケットの受信動作を終了する。

診断通信パケットを受信する装置は、ネットワーク接続中においては診断通信パケットの受信処理を継続するが、例えば、装置のネットワークからの切離し等を行う場合に作業者による操作によって診断通信パケットの受信処理が終了される。
以上で、図５を用いた、ライブリストの更新動作の説明を終了する。

次に、図６を用いて、処理装置１２の切替え動作を説明する。図６は、実施形態における処理装置１２の切替え動作の一例を示すフローチャートである。

図６において、処理装置１２は、待機状態（スタンバイ状態）であるか否かを判断する（ステップＳ３１）。スタンバイ状態であるか否かは、例えば、切替部１２０が保持するアプリ１２３の状態によって判断することができる。スタンバイ状態で無いと判断した場合（アクティブ状態である場合）（ステップＳ３１：ＮＯ）、処理装置１２は、図６のフローチャートに示す切替え動作の処理を終了する。

一方、スタンバイ状態であると判断した場合（ステップＳ３１：ＹＥＳ）、処理装置１２は、冗長化のペアを構成する処理装置１１のライブリストが、取得した全ての診断通信パケットに含まれるライブリストにおいて停止中であるか否かを判断する（ステップＳ３２）。具体的に、処理装置１２は、処理装置１１、端末装置１３及び端末装置１４からライブリストを含む診断通信パケットを受信するため、処理装置１２は、処理装置１１、端末装置１３及び端末装置１４から送信されたライブリストを検索して処理装置１１のライブリストを確認する。

取得された全てのライブリストにおいて処理装置１１のライブリストが停止中であると判断した場合（ステップＳ３２：ＹＥＳ）、処理装置１２は、スタンバイ状態からアクティブ状態に切替る（ステップＳ３３）。具体的には、処理装置１２の切替部２０がスタンバイ状態からアクティブ状態に切替えることによりアプリ１２３を稼働中にして、アプリ１１３の処理の代替を開始する。なお、一旦アクティブ状態となった処理装置１２は、ステップＳ３１において常にスタンバイ状態で無いと判断することになる。アクティブ状態となった処理装置１２を再びスタンバイ状態に遷移させるには、例えば装置の再立ち上げ（リセット処理）において行う。

一方、取得された全てのライブリストにおいて処理装置１１のライブリストが停止中ではないと判断した場合（ステップＳ３２：ＮＯ）、処理装置１２は、ステップＳ３１の処理に戻り、ステップＳ３１〜ステップＳ３２の処理を繰り返す。
以上で、図６を用いた、処理装置１２の切替え動作の説明を終了する。

次に、図７を用いて、図５のステップＳ２５の処理における端末装置１３のライブリストの更新を説明する。図７は、実施形態におけるライブリストの更新の一例を示す図である。

図７において、端末装置１４のライブリストは、稼働中から停止中に更新されている。すなわち、端末装置１３のライブリストは、端末装置１４のライブリストのみが更新された状態で更新される。ライブリストの更新を各装置のライブリスト毎に行うことにより、ライブリストの更新負荷を低減することができる。
なお、図７に示したようなライブリストは、例えば端末装置１３の図示しない表示装置に表示されるようにしたり、印字装置から印字されるようにしたりしてもよい。
以上で、図７を用いた、端末装置１３のライブリストの更新の説明を終了する。

次に、図８を用いて、処理装置１２のライブリスト検索部１２８において実施されるライブリストの検索結果を説明する。図８は、実施形態におけるライブリストの検索結果の一例を示す図である。

図８において、ライブリスト検索部１２８は、冗長化のペアを構成する処理装置１１のライブリストを、端末装置１３のライブリストと端末装置１４のライブリストから検索して検索結果をリスト化する。図示するＩＰアドレスの項目の（１９２．１６８．１．３）は、端末装置１３のライブリストから取得したライブリストであることを示し、ライブリストは状態の項目に示す稼働中であることを示している。また、ＩＰアドレスの項目の（１９２．１６８．１．４）は、端末装置１４のライブリストから取得したライブリストであることを示し、ライブリストは状態の項目に示す稼働中であることを示している。図８に示すような検索結果をリスト化することによって、図６のステップＳ３２の処理において、ペア装置を構成する処理装置１１のライブリストが、取得された全ての診断通信パケットに含まれるライブリストにおいて停止中であるか否かを判断することが容易となる。また、検索結果は、例えば処理装置１２の図示しない表示装置に表示されるようにしたり、印字装置から印字されるようにしたりしてもよい。
以上で、図８を用いた、ライブリストの検索結果の説明を終了する。

次に、図９を用いて、処理装置の第２の構成例を説明する。図９は、実施形態における処理装置の第２の構成例を示す図である。

図９において、処理装置１１ａは、ＮＩＣ１１１、ＯＳ１１２、アプリ１１３、診断通信受信部１１４、ライブリスト生成部１１５、診断通信データ生成部１１６、診断通信送信部１１７、ライブリスト抽出部１１８、ライブリスト比較／判断部１１９、切替部１１０の機能を有する。なお、処理装置１１ａにおける、ＮＩＣ１１１、ＯＳ１１２、アプリ１１３、診断通信受信部１１４、ライブリスト生成部１１５、診断通信データ生成部１１６及び診断通信送信部１１７のそれぞれの機能は、処理装置１１におけるそれぞれの機能と同様の機能であるため、説明を省略する。

ライブリスト抽出部１１８は、診断通信受信部１１４において受信した診断通信パケットに含まれるライブリストを取得して、取得したライブリストの中から、アプリ通信路の通信状態を抽出する。アプリと利用装置との通信路は、アプリから利用装置への送信に係る通信路と利用装置からアプリへの送信に係る通信路に分類することができる。ライブリスト抽出部１１８は、受信した診断通信パケットの中から、アプリ通信路の通信状態を送信方向毎に抽出する。

ライブリスト比較／判断部１１９は、ライブリスト比較機能とライブリスト判断機能を有する。ライブリスト比較機能は、抽出したアプリ通信路の通信状態を論理的に結合する。論理的な結合とは、各装置のアプリ通信路の通信状態を比較するために、各装置の診断通信パケットの受信状態の情報を、共通の項目である送信装置毎に１つの表にまとめることであり、詳細は図１１を用いて説明する。論理的に結合されたアプリ通信路の通信状態は、処理装置１１ａが提供するアプリ１１３を利用装置である端末装置１３及び端末装置１４が利用する場合のアプリ通信路の状態と、処理装置１２が提供するアプリ１２３を端末装置１３及び端末装置１４が利用する場合のアプリ通信路の状態とを比較容易にする。通信路の状態の比較は、例えばそれぞれのアプリを利用する場合の通信可能なアプリ通信路の数で比較することができる。通信可能なアプリ通信路の数が多いアプリの方が利用装置に対する可用性が高くなる。ライブリスト抽出部１１８が出力した診断通信パケットの受信状態の情報から、ライブリスト比較／判断部１１９のライブリスト比較機能が結合されたアプリ通信路の通信状態の情報を生成して、その通信状態を比較する。

ライブリスト比較／判断部１１９のライブリスト判断機能は、冗長化ペアを構成する処理装置において、アクティブ状態にする処理装置とスタンバイ状態にする処理装置を判断する。具体的には、ライブリスト比較／判断部１１９は、ライブリスト抽出部１１８から取得した結合された通信路の情報に基づき、処理装置１１ａ３と、その冗長化ペアを構成する処理装置１２のいずれをアクティブ状態又はスタンバイ状態にするかを判断する。ライブリスト判断機能は、例えば、アプリ１１３およびアプリ１２３の通信相手である端末装置１３及び端末装置１４に対するアプリ通信路において、処理装置１１ａ３と処理装置１２の中で正常に通信が可能な数（正常数）を比較して、より正常数が多い装置をアクティブ状態にし、他をスタンバイ状態にさせると判断する。ライブリスト比較／判断部１１９は、判断結果を切替部１１０に対して出力する。

切替部１１０は、ライブリスト比較／判断部１１９の判断に基づき、アプリ１１３の稼働を維持するか、アプリ１１３を停止させるかの切替えを行う。処理装置の第２の構成例である処理装置１１ａは、処理装置１１が不具合等により停止する以外は原則稼働を継続するのに対して、自発的に停止できる点において異なる。処理装置１１ａは、自発的に停止することにより、利用装置の可用性を向上させることが可能となる。

なお、本実施形態では、ライブリスト比較／判断部１１９は、アプリ通信路の正常数の単純比較を判断基準として自発的に停止する場合を説明したが、判断基準はこれに限定されるものではない。例えば、ライブリスト比較／判断部１１９は、アプリと利用装置の通信における通信速度やアプリと利用装置とのネットワーク距離、処理装置の稼働時間、エネルギー効率、故障実績等、他の要因を判断基準としてもよい。
以上で、図９を用いた、処理装置の第２の構成例の説明を終了する。

次に、図１０を用いて、アプリ通信路を説明する。図１０は、実施形態における処理システムのアプリ通信路の一例を示す図である。

図１０において、処理装置１１、処理装置１２、端末装置１３及び端末装置１４はそれぞれ診断通信パケットを通信経路で送受信する。例えば、処理装置１１と端末装置１３のパケット送信は通信経路Ａを用いる。同様に、処理装置１１と端末装置１４の通信経路をＢ、処理装置１２と端末装置１３の通信経路をＣ、処理装置１２と端末装置１４の通信経路をＤ、端末装置１３と端末装置１４の通信経路をＥ、処理装置１１と処理装置１２の通信経路をＦとする。通信経路Ａ〜Ｆにおける送信方向を１及び２の符号を付して示している。例えば、Ａ１は処理装置１１から端末装置１３の方向、Ａ２はその逆方向である。

アプリ通信路は、端末装置１３及び端末装置１４が使用する通信路であり、図１０に示したＡ〜Ｆの通信経路の中で、通信経路Ａ〜Ｅである。ライブリスト抽出部１１８は、アプリ通信路の双方向についてのライブリストを抽出する。すなわち、ライブリスト抽出部１１８は、Ａ〜Ｅの通信路の双方向についての正常数をカウントする。一方、通信路Ｆについては、端末装置１３及び端末装置１４アプリの通信には用いないため、ライブリスト抽出部１１８は、通信路の状態を抽出しない。
以上で、図１０を用いた、アプリ通信路の説明を終了する。

次に、図１１を用いて、ライブリストの論理的結合について説明する。図１１は、実施形態におけるライブリストの論理的結合の一例を示す図である。

図１１（Ａ）は、図１０における通信路Ａ１が不通となった場合のライブリストの論理的結合を示している。図１１（Ａ）及び（Ｂ）は、ブロードキャストによって送信される処理装置１１のライブリスト（ＬＬ１１）、処理装置１２のライブリスト（ＬＬ１２）、端末装置１３のライブリスト（ＬＬ１３）、端末装置１４のライブリスト（ＬＬ１４）を示している。図１１（Ａ）において、端末装置１３のライブリスト（ＬＬ１３）は、処理装置１１からの診断通信パケットが不通になるため、「診断通信送信者」の項目の「ＰＣ１１」において「診断通信受信有無」の項目が「×」となっている。なお、図示「−」は、アプリ通信路として成立しない経路を意味する。

ライブリストＬＬ１１〜ＬＬ１４を論理的に結合させたものが、矢印右側の論理的結合テーブルＴＢ１１である。論理的結合テーブルＴＢ１１は、ライブリストの「診断通信送信者」の項目を「送信側」、それぞれのライブリストの生成者を「受信側」としてまとめたものである。論理的結合テーブルＴＢ１１において、「送信側」が「ＰＣ１１」、「受信側」が「ＰＣ１３」の状態は「×」となる。

ここで、送信側が処理装置１１（ＰＣ１１）である場合、通信路の正常数は、３となる。一方、送信側が処理装置１２（ＰＣ１２）である場合、通信路の正常数は、４となる。従って、処理装置１１がアプリ１１３を用いてサービスを提供する場合に比べて、処理装置１２がアプリ１２３を用いてサービスを提供する場合の方が正常数を増やすことができるので、図９のライブリスト比較／判断部１１９は、アプリ１１３を停止状態とする。アプリ１１３を停止状態とすることにより、冗長化動作によってアプリ１２３がアクティブになる。

図１１（Ｂ）は、図１０における通信路Ａ２が不通となった場合のライブリストの論理的結合を示している。図１１（Ｂ）において、処理装置１１のライブリスト（ＬＬ１１）は、端末装置１３からの診断通信パケットが不通になるため、「診断通信送信者」の項目の「ＰＣ１３」において「診断通信受信有無」の項目が「×」となっている。また、端末装置１３のライブリスト（ＬＬ１３）は、処理装置１１に対して送信できないため、ライブリスト（ＬＬ１３）の内容が不明となる。

ここでライブリストＬＬ１１〜ＬＬ１４を論理的に結合させたものが、論理的結合テーブルＴＢ１１である。論理的結合テーブルＴＢ１１において、「送信側」が「ＰＣ１３」、「受信側」が「ＰＣ１１」の状態は「×」となる。

ここで、送信側が処理装置１１（ＰＣ１１）である場合、通信路の正常数は、２となる。一方、送信側が処理装置１２（ＰＣ１２）である場合、通信路の正常数は、３となる。従って、処理装置１１がアプリ１１３を用いてサービスを提供する場合に比べて、処理装置１２がアプリ１２３を用いてサービスを提供する場合の方が正常数を増やすことができるので、図９のライブリスト比較／判断部１１９は、アプリ１１３を停止状態とする。アプリ１１３を停止状態とすることにより、冗長化動作によってアプリ１２３がアクティブになる。

なお、図１１は、処理装置１１に係る通信路Ａが不通となった場合であるため、論理的結合テーブルＴＢ１１を使用しない場合であっても、処理装置１１を停止状態とする判断は容易であるが、例えば、処理装置１１に係る通信路と処理装置１２に係る通信路の両方が一部不通になった場合の冗長化動作については容易には判断できない。論理的結合テーブルＴＢ１１を用いて予め定められた条件を適用することにより冗長化動作の判断を容易に自動化することが可能となる。
以上で、図１１を用いた、ライブリストの論理的結合についての説明を終了する。

次に、図１２を用いて、処理装置１１ａの切替え動作を説明する。図１２は、実施形態における処理装置の切替え動作の一例を示すフローチャートである。

図１２において、処理装置１１ａは、アクティブ状態（アクティブ状態）であるか否かを判断する（ステップＳ４１）。アクティブ状態であるか否かは、例えば、切替部１１０が保持するアプリ１１３の状態によって判断することができる。アクティブ状態で無いと判断した場合（スタンバイ状態である場合）（ステップＳ４１：ＮＯ）、処理装置１１ａは、図１２のフローチャートに示す切替え動作の処理を終了する。

一方、アクティブ状態であると判断した場合（ステップＳ４１：ＹＥＳ）、処理装置１１ａは、取得したライブリストを論理的結合させる（ステップＳ４２）。ステップＳ４２において結合させるライブリストは図１１で説明した通り、ライブリスト（ＬＬ１１〜ＬＬ１４）である。

ステップＳ４２の処理を実行した後、処理装置１１ａは、アプリ通信路の解析を実行する（ステップＳ４３）。アプリ通信路の解析は、例えば、図１１で説明したアプリ通信路の正常数の比較である。但し、アプリ通信路の解析方法はアプリ通信路の正常数の比較に限定されるものではない。例えば、アプリ通信路の通信速度やアプリと利用装置とのネットワーク距離、処理装置の稼働時間、エネルギー効率、故障実績等、他の要因を判断基準としてもよい。

ステップＳ４３の処理を実行した後、処理装置１１ａは、解析結果に基づき、自装置による処理の提供に比べて処理装置１２における代替処理の提供の方が有利か否かを判断する（ステップＳ４４）。ステップＳ４３の処理における判断は、アプリ通信路の正常数の比較等、ステップＳ４３の処理における解析の内容に応じる。

代替処理の提供の方が有利であると判断した場合（ステップＳ４４：ＹＥＳ）、処理装置１１ａは、自装置の状態をアクティブ状態からスタンバイ状態に切替える（ステップＳ４５）。自装置の状態をアクティブ状態からスタンバイ状態に切替える方法は、図９で説明した切替部１１０によるアプリ１１３（及びＯＳ１１２）の状態切替えによって行うことができる。

一方、代替処理の提供の方が有利であると判断しなかった場合（ステップＳ４４：ＮＯ）、処理装置１１ａは、図１２のフローチャートに示す切替え動作の処理を終了する。すなわち、処理装置１１の稼働状態が維持される。

なお、一旦スタンバイ状態となった処理装置１１ａを再びアクティブ状態に遷移させるには、例えば装置の再立ち上げ（リセット処理）において行う。
以上で、図１２を用いた、処理装置１１ａの切替え動作の説明を終了する。

なお上述した処理システムにおいては、処理装置、処理装置、端末装置の動作をそれぞれの機能で分けて説明したが、これらの機能は同一装置内において動作するものであってもよい。また、これらの機能は、同一処理システム内において分散して実行されるものであってもよい。

以上説明したように、実施形態の処理装置は、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供部と、前記利用装置に対して処理を提供する他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された他の装置で生成されたライブリストを取得するライブリスト取得部と、取得された前記ライブリストに基づき、前記処理提供部の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替部とを備えることにより、安定性が高い冗長化構成を低コストで実現することができる。

また、実施形態の処理装置の制御方法は、プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する処理提供ステップと、前記利用装置に対して処理を提供する他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された他の装置で生成されたライブリストを取得するライブリスト取得ステップと、受信した前記ライブリストに基づき、前記処理提供部の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替ステップとを含むことにより、安定性が高い冗長化構成を低コストで実現することができる。

なお、本実施形態における処理における各ステップは、実行の順序を限定したものではなく、各ステップが任意の実行順序で実行されるようにしてもよい。

また、本実施形態は以下の態様において実施されてもよい。
例えば、本実施形態を、プロセス制御システムのネットワーク通信機能に用いることができる。本実施形態は、プロセス制御システムにおいて、制御処理装置同士、又は制御処理装置と操作監視装置をネットワークで接続したシステムにおいて利用することができる。

また、本実施形態は、アプリ通信用アドレスと診断通信用アドレスを自動的に割り当てて管理するシステムにおいても適応することができる。例えば、ＦＯＵＮＤＡＴＩＯＮ Ｆｉｅｌｄｂｕｓプロトコル（ＨＳＥ： Ｈｉｇｈ Ｓｐｅｅｄ Ｅｔｈｅｒｎｅｔ）、Ｖｎｅｔ／ＩＰ（登録商標）プロトコル等のシステムである。Ｖｎｅｔ／ＩＰプロトコルの場合は、アプリ通信用アドレスにＶｎｅｔアドレスを使用し、診断通信用アドレスにＩＰアドレスを使用している。

また、本実施形態で説明した装置を構成する機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、当該記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本実施形態の上述した種々の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ））のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現するもの、いわゆる差分ファイル（差分プログラム）であっても良い。

以上、本発明の実施形態について、図面を参照して説明してきたが、具体的な構成はこの実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲においての種々の変更も含まれる。

１０ 処理システム
１１、１２ 処理装置
１１０、１２０ 切替部
１１１、１２１、１３１、１４１ ＮＩＣ
１１２、１２２、１３２、１４２ ＯＳ
１１３、１２３、１３３、１４３ アプリ
１１４、１２４、１３４、１４４ 診断通信受信部
１１５、１２５、１３５、１４５ ライブリスト生成部
１１６、１２６、１３６、１４６ 診断通信データ生成部
１１７、１２７、１３７、１４７ 診断通信送信部
１１８ ライブリスト抽出部
１１９ ライブリスト比較／判断部
１２８ ライブリスト検索部
１２９ 装置停止検出部
１３、１４ 端末装置

Claims (19)

1. プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する他の処理装置と冗長化され、前記他の処理装置に異常が生じた場合に前記他の処理装置が提供する処理を代替する処理装置であって、
   前記他の処理装置が提供する処理を提供可能な処理提供部と、
   前記他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された自装置以外の他の装置で生成されたライブリストを取得するライブリスト取得部と、
   取得された前記ライブリストに基づき、前記処理提供部の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替部と
   を備える、処理装置。
2. 前記ライブリスト取得部は、複数の前記ライブリストを取得して、
   前記切替部は、所定の期間内で取得された複数の前記ライブリストのいずれにおいても、前記他の処理装置からの前記診断通信パケットの送信が確認できないときに、前記処理提供部の状態を前記アクティブ状態に切替える、請求項１に記載の処理装置。
3. 前記診断通信パケットを受信する診断通信パケット受信部と、
   受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成部と、
   生成されたライブリストを、前記自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信部と
   をさらに備える、請求項１又は２に記載の処理装置。
4. 前記診断通信パケット送信部は、前記自装置の処理が前記利用装置に利用される際に通信する全ての通信先に前記診断通信パケットを送信する、請求項３に記載の処理装置。
5. 前記ライブリスト生成部は、前記他の処理装置を利用する際に通信する全ての通信先の前記診断通信パケットに基づき、ライブリストを生成する、請求項３又は４に記載の処理装置。
6. プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供可能な他の処理装置が冗長化され、自装置に異常が生じた場合に前記自装置が提供する処理が前記他の処理装置によって提供される処理に代替される処理装置であって、
   前記利用装置に対して処理を提供する処理提供部と、
   診断通信パケットを所定の時間間隔で送信する診断通信パケット送信部と、
   前記ネットワークに接続された自装置以外の装置で生成されて所定の時間間隔で送信される、前記ネットワークに接続された自装置を含む装置の診断通信パケットに基づき生成されるライブリストを取得するライブリスト取得部と、
   取得された前記ライブリストに基づき、前記処理提供部の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態に切替える切替部と
   を備える、処理装置。
7. 前記診断通信パケット送信部は、自装置の処理が前記利用装置に利用される際に通信する全ての通信先に前記診断通信パケットを送信する、請求項６に記載の処理装置。
8. 前記切替部は、所定の期間内で取得された前記ライブリストにおいて、前記利用装置との通信経路の通信状態を解析し、自装置との前記通信状態より前記利用装置に対して処理を提供する他の処理装置との前記通信状態の方が有利であるときに前記処理提供部の状態を前記スタンバイ状態に切替え、
   前記診断通信パケット送信部は、前記診断通信パケットの送信を中止する、請求項６又は７に記載の処理装置。
9. 前記利用装置に対して処理を提供する他の処理装置から送信される前記診断通信パケットを受信する診断通信パケット受信部と、
   受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成部と
   をさらに備え、
   前記診断通信パケット送信部は、生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する、請求項６から８のいずれか一項に記載の処理装置。
10. プラントにおけるプロセス制御システムのネットワークに接続され、請求項１から５のいずれか一項に記載の処理装置、又は請求項６から９のいずれか一項に記載の処理装置から処理が提供されるネットワーク装置であって、
    請求項１から５のいずれか一項に記載の処理装置、及び請求項６から９のいずれか一項に記載の処理装置から所定の時間間隔で送信される診断通信パケットを受信する診断通信パケット受信部と、
    受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成部と、
    生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信部と
    を備える、ネットワーク装置。
11. プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する他の処理装置と冗長化され、前記他の処理装置に異常が生じた場合に前記他の処理装置が提供する処理を代替する処理装置の制御方法であって、
    前記他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された自装置以外の他の装置で生成されたライブリストを取得するライブリスト取得ステップと、
    取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替ステップと
    を含む、処理装置の制御方法。
12. プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供可能な他の処理装置が冗長化され、自装置に異常が生じた場合に前記自装置が提供する処理が前記他の処理装置によって提供される処理に代替される処理装置の制御方法であって、
    前記利用装置に対して処理を提供する処理提供ステップと、
    診断通信パケットを所定の時間間隔で送信する診断通信パケット送信ステップと、
    前記ネットワークに接続された自装置以外の装置で生成されて所定の時間間隔で送信される、前記ネットワークに接続された自装置を含む装置の診断通信パケットに基づき生成されるライブリストを取得するライブリスト取得ステップと、
    取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態に切替える切替ステップと
    を含む、処理装置の制御方法。
13. プラントにおけるプロセス制御システムのネットワークに接続され、請求項１から５のいずれか一項に記載の処理装置、又は請求項６から９のいずれか一項に記載の処理装置から処理が提供されるネットワーク装置の制御方法であって、
    請求項１から５のいずれか一項に記載の処理装置、及び請求項６から９のいずれか一項に記載の処理装置から所定の時間間隔で送信される診断通信パケットを受信する診断通信パケット受信ステップと、
    受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成ステップと、
    生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信ステップと
    を含む、ネットワーク装置の制御方法。
14. プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する他の処理装置と冗長化され、前記他の処理装置に異常が生じた場合に前記他の処理装置が提供する処理を代替する処理装置の制御プログラムであって、
    前記他の処理装置が提供する処理を提供可能な処理提供処理と、
    前記他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された自装置以外の他の装置で生成されたライブリストを取得するライブリスト取得処理と、
    取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替処理と
    をコンピュータに実行させる、処理装置の制御プログラム。
15. プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供可能な他の処理装置が冗長化され、自装置に異常が生じた場合に前記自装置が提供する処理が前記他の処理装置によって提供される処理に代替される処理装置の制御方法であって、
    前記利用装置に対して処理を提供する処理提供処理と、
    診断通信パケットを所定の時間間隔で送信する診断通信パケット送信処理と、
    前記ネットワークに接続された自装置以外の装置で生成されて所定の時間間隔で送信される、前記ネットワークに接続された自装置を含む装置の診断通信パケットに基づき生成されるライブリストを取得するライブリスト取得処理と、
    取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態に切替える切替処理と
    をコンピュータに実行させる、処理装置の制御プログラム。
16. プラントにおけるプロセス制御システムのネットワークに接続され、請求項１から５のいずれか一項に記載の処理装置、又は請求項６から９のいずれか一項に記載の処理装置から処理が提供されるネットワーク装置の制御プログラムであって、
    請求項１から５のいずれか一項に記載の処理装置、及び請求項６から９のいずれか一項に記載の処理装置から所定の時間間隔で送信される診断通信パケットを受信する診断通信パケット受信処理と、
    受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成処理と、
    生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信処理と
    をコンピュータに実行させる、ネットワーク装置の制御プログラム。
17. プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供する他の処理装置と冗長化され、前記他の処理装置に異常が生じた場合に前記他の処理装置が提供する処理を代替する処理装置の制御プログラムを記録した記録媒体であって、
    前記他の処理装置が提供する処理を提供可能な処理提供処理と、
    前記他の処理装置から所定の時間間隔で送信される診断通信パケットに基づき、前記ネットワークに接続された自装置以外の他の装置で生成されたライブリストを取得するライブリスト取得処理と、
    取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態から前記処理を提供するアクティブ状態に切替える切替処理と
    をコンピュータに実行させる処理装置の制御プログラムを記録した、記録媒体。
18. プラントにおけるプロセス制御システムのネットワークに接続された利用装置に対して処理を提供可能な他の処理装置が冗長化され、自装置に異常が生じた場合に前記自装置が提供する処理が前記他の処理装置によって提供される処理に代替される処理装置の制御方法であって、
    前記利用装置に対して処理を提供する処理提供処理と、
    診断通信パケットを所定の時間間隔で送信する診断通信パケット送信処理と、
    前記ネットワークに接続された自装置以外の装置で生成されて所定の時間間隔で送信される、前記ネットワークに接続された自装置を含む装置の診断通信パケットに基づき生成されるライブリストを取得するライブリスト取得処理と、
    取得された前記ライブリストに基づき、前記処理の提供の状態を、前記利用装置に対する処理の提供を待機するスタンバイ状態に切替える切替処理と
    をコンピュータに実行させる処理装置の制御プログラムを記録した、記録媒体。
19. プラントにおけるプロセス制御システムのネットワークに接続され、請求項１から５のいずれか一項に記載の処理装置、又は請求項６から９のいずれか一項に記載の処理装置から処理が提供されるネットワーク装置の制御プログラムを記録した記録媒体であって、
    請求項１から５のいずれか一項に記載の処理装置、及び請求項６から９のいずれか一項に記載の処理装置から所定の時間間隔で送信される診断通信パケットを受信する診断通信パケット受信処理と、
    受信された前記診断通信パケットに基づき、ライブリストを生成するライブリスト生成処理と、
    生成されたライブリストを、自装置の診断通信パケットの一部として、所定の時間間隔で送信する診断通信パケット送信処理と、
    をコンピュータに実行させるネットワーク装置の制御プログラムを記録した、記録媒体。

Images