特許 7574170 状態分析装置、及び状態推定方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-18

(45)【発行日】2024-10-28

(54)【発明の名称】状態分析装置、及び状態推定方法

(51)【国際特許分類】

   G05B 23/02 20060101AFI20241021BHJP

   G06F 21/50 20130101ALI20241021BHJP

【ＦＩ】

G05B23/02 302Y

G05B23/02 302Z

G06F21/50

【請求項の数】 15

(21)【出願番号】P 2021185170

(22)【出願日】2021-11-12

(65)【公開番号】P2023072547

(43)【公開日】2023-05-24

【審査請求日】2024-02-22

(73)【特許権者】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000176

【氏名又は名称】弁理士法人一色国際特許事務所

(72)【発明者】

【氏名】甲斐 賢

(72)【発明者】

【氏名】内山 宏樹

(72)【発明者】

【氏名】石場 光朗

(72)【発明者】

【氏名】飯田 恒雄

【審査官】牧 初

(56)【参考文献】

【文献】特開２００４－１２７９８９（ＪＰ，Ａ）

【文献】国際公開第２０１８／２２０７５１（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０５Ｂ ２３／００－２３／０２

(57)【特許請求の範囲】

【請求項1】

複数のアセットを有して構成される産業制御システムの状態を推定する情報処理装置であって、
プロセッサ及びメモリを有し、
産業制御システムにおいて生じ得る状態遷移の一つ以上のシナリオを示す情報を含む状態推定モデルを記憶し、
前記アセットから発報されるアラートを時系列に並べたアラート列を前記状態推定モデルの前記シナリオと対照することにより、前記アラート列と前記シナリオとの共通性を示す指標を求めて出力する、
状態分析装置。

【請求項2】

請求項１に記載の状態分析装置であって、
前記指標は、前記状態遷移の進行の度合いを示す指標である進行度、及び前記アラート列が前記シナリオの順序に従って発報されている度合いを表す指標である発報度のうちの少なくともいずれかである、
状態分析装置。

【請求項3】

請求項２に記載の状態分析装置であって、
前記シナリオの各状態における前記進行度を設定するユーザインタフェースを提供する、
状態分析装置。

【請求項4】

請求項１に記載の状態分析装置であって、
前記シナリオ毎の前記指標をユーザインタフェースを介してユーザに提示する、
状態分析装置。

【請求項5】

請求項４に記載の状態分析装置であって、
前記状態推定モデルは複数の前記シナリオを含み、
前記シナリオを前記アラート列との前記共通性に応じてソートして、もしくは、前記共通性が大きいシナリオを強調して提示する、
状態分析装置。

【請求項6】

請求項１に記載の状態分析装置であって、
前記アセットと前記アセットを類型化した分類であるアセットクラスとを対応づけた情報、
前記アラートと前記アラートを類型化した分類であるアラートクラスとを対応づけた情報、及び、
前記シナリオと、前記状態遷移、前記アセットクラス、及び前記アラートクラスとを対応づけた情報、
を記憶し、
前記アラート列を、当該アラート列のアラートを発報した前記アセットが属するアセットクラスと前記アラートが属するアラートクラスとの組合せに対応する前記シナリオと対照することにより前記指標を求める、
状態分析装置。

【請求項7】

請求項１に記載の状態分析装置であって、
前記状態推定モデルの雛型となる情報であるベースモデルを記憶し、
前記ベースモデルを編集することにより前記シナリオを編集するユーザインタフェースを提供する、
状態分析装置。

【請求項8】

請求項６に記載の状態分析装置であって、
前記シナリオはペトリネットにより表され、プレースにアセットクラスが、トランジションに前記アセットクラスと前記アラートクラスが対応づけられる、
状態分析装置。

【請求項9】

請求項１に記載の状態分析装置であって、
前記アラート列と当該アラート列について求めた前記指標とを対応づけた情報を蓄積記憶し、
前記指標の変化の傾向に基づき前記情報と前記状態推定モデルにおける前記シナリオとの間の乖離の度合いを求める、
状態分析装置。

【請求項10】

請求項９に記載の状態分析装置であって、
前記指標は、前記状態の進行の度合いを示す指標である進行度、及び前記シナリオで定めた順序に従ってアラートの発報が生じている度合いを表す指標である発報度であり、
前記進行度の変化に対する前記発報度の変化の度合いに基づき前記乖離の度合いを求める、
状態分析装置。

【請求項11】

請求項９に記載の状態分析装置であって、
前記アラート列の各アラートを時系列順に発報して前記シナリオを辿ることにより前記指標の変化を再現し、前記指標の変化に基づき前記シナリオの前記乖離が生じている部分を特定する、
状態分析装置。

【請求項12】

請求項１１に記載の状態分析装置であって、
前記再現の様子を提示するとともに、特定した前記シナリオの前記乖離が生じている箇所を修正するユーザインタフェースを提供する、
状態分析装置。

【請求項13】

請求項１２に記載の状態分析装置であって、
前記アラート列の各アラートを時系列順に発報して修正後の前記シナリオを辿ることにより前記指標の変化を求めてユーザに提示する、
状体分析装置。

【請求項14】

複数のアセットを有して構成される産業制御システムの状態を推定する方法であって、
プロセッサ及びメモリを有する情報処理装置が、
産業制御システムにおいて生じ得る状態遷移の一つ以上のシナリオを示す情報を含む状態推定モデルを記憶するステップと、
前記アセットから発報されるアラートを時系列に並べたアラート列を前記状態推定モデルの前記シナリオと対照することにより、前記アラート列と前記シナリオとの共通性を示す指標を求めて出力するステップと、
を実行する、状態分析方法。

【請求項15】

請求項１４に記載の状態分析方法であって、
前記情報処理装置が、
前記アラート列と当該アラート列について求めた前記指標とを対応づけた情報を蓄積記憶するステップと、
前記指標の変化の傾向に基づき前記情報と前記状態推定モデルにおける前記シナリオとの間の乖離の度合いを求めるステップと、
を更に実行する、状態分析方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、状態分析装置、及び状態推定方法に関する。

【背景技術】

【0002】

企業や官公庁等の組織を狙ったサイバー攻撃による被害が深刻化している。昨今、こうしたサイバー攻撃は、社会インフラ関連システム、電気やガス等のエネルギー制御システム、工場の生産ライン等の産業制御システムにも標的を拡大してきている。産業制御システムは、停止すれば実社会に与える影響が大きく、産業制御システムを対象としたサイバー攻撃に対する対策の重要性が高まっている。

【0003】

産業制御システムを狙ったサイバー攻撃に対するセキュリティ管理手法として、例えば、特許文献１には、ガスタービンのようなセンサ及びアクチュエータから取得したデータを正常パターンと異常パターンとに分類しておき、ガスタービンへのサイバー攻撃を、センサ及びアクチュエータから取得したデータに基づき検出することが記載されている。また、検出に用いるパラメータを設定するため、データリポジトリから監視対象に適したパラメータを検索し、検索したパラメータをカスタマイズすることが記載されている。

【0004】

また、非特許文献１には、プログラマブルロジックコントローラ（ＰＬＣ:Programmable Logic Controller）がリアクタをコントロールする際に取得されるデバイスログを入力とするプロセスマイニング手法により正常状態をモデル化し、生成したモデルに基づきＰＬＣが出力するデバイスログの正常性を示す指標をコンフォーマンスチェック（conformance check）手法により求め、求めた指標によりサイバー攻撃を検出することが記載され
ている。

【先行技術文献】

【特許文献】

【0005】

【文献】米国特許２０２０／０１６９５７４号

【非特許文献】

【0006】

【文献】”Anomaly detection for industrial control systems using Process Mining”, David Myers et.al, Queensland University of Technology (QUT), Computers & Security 78 (2018), pp.103-125

【発明の概要】

【発明が解決しようとする課題】

【0007】

産業制御システムを標的とするサイバー攻撃を監視する方法として、産業制御システムを構成する機器が発報する、故障やプロセスの異常や警告を示す情報（以下、「アラート」と称する。）を収集して分析する方法がある。しかし、この方法では、発報されたアラートが、機器の故障やプロセスの異常に起因するものであるのか、それともサイバー攻撃に起因するものであるのかを、監視員等の人が切り分ける必要があり、人的負担が大きいという課題がある。

【0008】

監視にかかる人的負担を軽減する方法として、例えば、特許文献１や非特許文献１に記載されている技術を用いることが考えられる。しかし、特許文献１では、振る舞いを監視するためのパラメータの設計（DOE:Design Of Experiments parameters）を手動でセットアップするために知識や経験が要求される。また、非特許文献１では、正常状態の状態推定モデルをペトリネット（Petri net）により表現するが、ペトリネットは習得の難易度
が比較的高く、監視者等に十分な知識や経験が要求される。

【0009】

本発明はこうした背景に鑑みてなされたものであり、産業制御システムの状態を容易かつ高い精度で検出することが可能な、状態分析装置、及び状態推定方法を提供することを目的とする。

【課題を解決するための手段】

【0010】

上記目的を達成するための本発明の一つは、複数のアセットを有して構成される産業制御システムの状態を推定する情報処理装置であって、プロセッサ及びメモリを有し、産業制御システムにおいて生じ得る状態遷移の一つ以上のシナリオを示す情報を含む状態推定モデルを記憶し、前記アセットから発報されるアラートを時系列に並べたアラート列を前記状態推定モデルの前記シナリオと対照することにより、前記アラート列と前記シナリオとの共通性を示す指標を求めて出力する、

【0011】

その他、本願が開示する課題、及びその解決方法は、発明を実施するための形態の欄、及び図面により明らかにされる。

【発明の効果】

【0012】

本発明によれば、産業制御システムの状態を容易かつ高い精度で検出することができる。

【図面の簡単な説明】

【0013】

【図1】状態分析装置の一例である。

【図2A】状態分析装置が備える機能の一例である。

【図2B】状態分析装置の実現に用いる情報処理装置の一例である。

【図3A】グラフの一例である。

【図3B】プレース管理テーブルの一例である。

【図3C】トランジション管理テーブルの一例である。

【図4A】アセットクラステーブルの一例である。

【図4B】アラートクラステーブルの一例である。

【図5】状態推定モデルの一例である。

【図6】状態推定モデル生成処理の一例を説明するフローチャートである。

【図7】ベースモデル設定画面の一例である。

【図8】状態推定モデル設定画面の一例である。

【図9】状態推定モデル設定画面の一例である。

【図10】状態推定処理の一例を説明するフローチャートである。

【図11】アラート列をトランジションに読み替える処理の一例を説明する図である。

【図12A】アラート列とシナリオを照合する処理の一例を説明する図である。

【図12B】アラート列とシナリオを照合する処理の一例を説明する図である。

【図13A】状態推定結果の一例である。

【図13B】状態推定結果の一例である。

【図14】状態推定モデル更新処理の一例を説明するフローチャートである。

【図15A】進行度と発報度の傾向を分析する処理の一例を説明する図である。

【図15B】進行度と発報度の傾向を分析する処理の一例を説明する図である。

【図15C】状態推定モデル更新画面の一例である。

【図16A】故障シナリオの一例である。

【図16B】故障シナリオの一例である。

【図16C】故障シナリオの一例である。

【図17A】攻撃シナリオの一例である。

【図17B】攻撃シナリオの一例である。

【図17C】攻撃シナリオの一例である。

【発明を実施するための形態】

【0014】

以下、本発明の実施形態について図面を参照しつつ詳細に説明する。尚、以下の記載及び図面は、本発明を説明するための例示に過ぎず、説明の明確化のため、適宜、省略及び簡略化がなされている。本発明は、他の種々の形態でも実施することが可能である。とくに限定しない限り、各構成要素は単数でも複数でも構わない。

【0015】

以下の説明において、符号の前に付した「Ｓ」の文字は処理ステップの意味である。また、以下の説明において、「テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために「ＸＸテーブル」等を「ＸＸ情報」と呼ぶことがある。また、識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。

【0016】

図１に、一実施形態として説明する情報処理装置である状態分析装置１００の概略的な構成（システムフロー図）を示している。同図に示すように、状態分析装置１００は、産業制御システム（ＩＣＳ（Industrial Control System）。以下、「ＩＣＳ２」と称する
。）と、ＩＣＳ２と通信ネットワーク５を介して通信可能に接続する情報処理装置（コンピュータ）である状態分析装置１００と、を含む。

【0017】

ＩＣＳ２は、例えば、電力、ガス、水道、鉄道等の社会インフラ関連システム、電力やガス等のエネルギー関連施設の制御システム、石油、化学、鉄鋼、自動車、輸送機器、精密機械、食品、製薬、ビル管理等の工場やプラント等における監視制御システム、生産ラインや加工ライン等において用いられるＩＴシステム、ＩｏＴ（Internet of Things）システム、ＩＩｏＴ（Industrial IoT）システム等である。

【0018】

状態分析装置１００は、ＩＣＳ２の物理的／論理的な動作（稼働）状態（以下、「状態」と総称する。）を監視し、ＩＣＳ２の稼働状態に関する情報やセキュリティ侵害の有無等のＩＣＳ２の状態に関する情報を生成し、ＩＣＳ２の監視者や運用者に提供する。状態分析装置１００は、ＩＣＳ２を構成する機器（以下、「アセット」と称する。）が故障やプロセスの異常に起因して発報する異常や警告を示す情報（以下、「アラート」と称する。）を時系列に並べたデータであるアラート列に基づきＩＣＳ２の状態を分析する。尚、アセットは、例えば、センサ、アクチュエータ、コントローラ、安全計装システム、制御サーバ、エンジニアリングワークステーション、監視制御サーバ、データヒストリアン、伝送サーバ等である。

【0019】

通信ネットワーク５は、有線方式又は無線方式の通信ネットワークであり、例えば、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、各種公
衆無線通信網、専用線等である。通信ネットワーク５は、ＩＣＳ２を構成するアセットの間を通信可能に接続する通信基盤であってもよい。尚、状態分析装置１００はＩＣＳ２の構成要素であってもよい。

【0020】

図２Ａは、状態分析装置１００が備える主な機能を説明するブロック図である。同図に示すように、状態分析装置１００は、記憶部１１０、アラート受信部１２０、状態推定部１３０、推定結果出力部１４０、ベースモデル生成部１５０、状態推定モデル生成部１６０、及び状態推定モデル更新部１７０の各機能を備える。

【0021】

上記機能のうち、記憶部１１０は、アラート列１１１、状態推定モデル１１２、状態推
定結果１１３、及びベースモデル１１４を記憶する。

【0022】

アラート受信部１２０は、ＩＣＳ２を構成する装置や機器から発報（出力）されるアラートを受信し、受信したアラートを時系列に並べてアラート列１１１として記憶部１１０に管理する。また、アラート受信部１２０は、生成したアラート列を状態推定部１３０に入力する。

【0023】

状態推定部１３０は、アラート受信部１２０から入力されるアラート列を、ＩＣＳ２において生じ得る状態遷移を示す一つ以上のシナリオを示す情報を含む状態推定モデル１１２と対照することによりアラート列とシナリオとの共通性（一致性、類似性）を示す指標を求めることによりＩＣＳ２の状態を推定し、推定した結果（以下、「状態推定結果」と称する。）を状態推定結果１１３として記憶部１１０に管理する。また、状態推定部１３０は、監視者や運用者等のユーザにユーザインタフェースを介して状態推定結果を提示する。状態推定部１３０は、例えば、アラート列１１１が更新される度にＩＣＳ２の状態を推定し直す。

【0024】

ベースモデル生成部１５０は、ユーザインタフェースを介してユーザと対話を行いつつ、状態推定モデル１１２のベース（雛型）となる汎用的なモデルであるベースモデルを生成し、生成したベースモデルをベースモデル１１４として記憶部１１０に管理する。ベースモデル生成部１５０は、例えば、ＩＣＳ２が水力発電所のシステムである場合、関東に存在する水力発電所のシステムと関西に存在する水力発電所のシステムが共通に或いは汎用的に備えているアセットについて故障に至るまでの状態遷移のシナリオに基づくベースモデル１１４を生成する。

【0025】

状態推定モデル生成部１６０は、ベースモデル１１４とＩＣＳ２に関する情報とに基づき、状態推定モデル１１２を生成する。

【0026】

状態推定モデル更新部１７０は、状態推定結果１１３に基づき状態推定モデル１１２を更新する。状態推定モデル更新部１７０は、状態推定結果１１３に基づき、状態推定モデル１１２による状態推定の乖離が生じているシナリオの特定や乖離している箇所の特定を行う。また、状態推定モデル更新部１７０は、ユーザインタフェースを介したユーザとの対話処理によりシナリオの修正案を生成する。また、状態推定モデル更新部１７０は、修正案によるシナリオの修正前後の夫々における状態推定結果１１３を比較可能な状態でユーザに提示し、ユーザが修正案を許容する場合は当該修正案に基づき状態推定モデル１１２の更新を行う。

【0027】

図２Ｂは、状態分析装置１００の実現に用いる情報処理装置の例である。例示する情報処理装置１０は、プロセッサ１１、主記憶装置１２（メモリ）、補助記憶装置１３、入力装置１４、出力装置１５、及び通信装置１６を備える。情報処理装置１０の例として、パーソナルコンピュータ、オフィスコンピュータ、サーバ装置、スマートフォン、タブレット、汎用機（メインフレーム）等がある。

【0028】

情報処理装置１０は、その全部又は一部が、例えば、クラウドシステムによって提供される仮想サーバのように、仮想化技術やプロセス空間分離技術等を用いて提供される仮想的な情報処理資源を用いて実現されるものであってもよい。また、情報処理装置１０によって提供される機能の全部又は一部は、例えば、クラウドシステムがＡＰＩ（Application Programming Interface）等を介して提供するサービスによって実現してもよい。また
、情報処理装置１０によって提供される機能の全部又は一部は、例えば、ＳａａＳ（Software as a Service）、ＰａａＳ（Platform as a Service）、ＩａａＳ（Infrastructure
as a Service）等を利用して実現されるものであってもよい。

【0029】

プロセッサ１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（Field Programmable
Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＡＩ（Artificial Intelligence）チップ等を用いて構成されている。

【0030】

主記憶装置１２は、プログラムやデータを記憶する装置であり、例えば、ＲＯＭ（Read
Only Memory）、ＲＡＭ（Random Access Memory）、不揮発性メモリ（ＮＶＲＡＭ（Non Volatile RAM））等である。セキュリティ管理システム１の各構成要素において実現される機能は、プロセッサ１１が、主記憶装置１２に格納（記憶）されているプログラムを読み出して実行することにより実現される。

【0031】

補助記憶装置１３は、例えば、ＳＳＤ（Solid State Drive）、ハードディスクドライ
ブ、光学式記憶装置（ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）等）、ストレージシステム、ＩＣカード、ＳＤカードや光学式記録媒体等の非一時的な記録媒体の読取／書込装置、クラウドサーバの非一時的な記憶領域等である。補助記憶装置１３には、記録媒体の読取装置や通信装置１６を介して、非一時的な記録媒体や非一時的な記憶装置を備えた他の情報処理装置からプログラムやデータを読み込むことができる。補助記憶装置１３に格納（記憶）されているプログラムやデータは主記憶装置１２に随時読み込まれる。

【0032】

入力装置１４は、外部からの情報の入力を受け付けるインタフェースであり、例えば、キーボード、マウス、タッチパネル、カードリーダ、ペン入力方式のタブレット、音声入力装置等である。

【0033】

出力装置１５は、処理経過や処理結果等の各種情報を外部に出力するインタフェースである。出力装置１５は、例えば、上記の各種情報を可視化する表示装置（液晶モニタ、ＬＣＤ（Liquid Crystal Display）、グラフィックカード等）、上記の各種情報を音声化する装置（音声出力装置（スピーカ等））、上記の各種情報を文字化する装置（印字装置等）である。尚、例えば、情報処理装置１０が通信装置１６を介して他の装置との間で情報の入力や出力を行う構成としてもよい。

【0034】

入力装置１４と出力装置１５は、ユーザとの間での対話処理（情報の受け付け、情報の提供等）を実現するユーザインタフェースを構成する。

【0035】

通信装置１６は、他の装置との間の通信を実現する装置である。通信装置１６は、通信ネットワーク５を介して、所定の通信プロトコルに準拠した他の装置との間の通信を実現する、有線方式又は無線方式の通信インタフェースであり、例えば、ＮＩＣ（Network Interface Card）、無線通信モジュール、ＵＳＢモジュール等である。

【0036】

情報処理装置１０には、例えば、オペレーティングシステム、ファイルシステム、ＤＢＭＳ（DataBase Management System）（リレーショナルデータベース、ＮｏＳＱＬ等）、ＫＶＳ（Key-Value Store）等が導入されていてもよい。

【0037】

続いて、ベースモデル１１４について説明する。尚、状態推定モデル１１２もベースモデル１１４と同様の構成を有する。

【0038】

ベースモデル１１４は、ＩＣＳ２の状態を表す１つ以上のシナリオを、情報処理装置等による機械的な処理が可能な形式で表現した情報（データ）である。以下では、上記型式がペトリネット（Petri net）である場合を例として説明する。但し、上記型式は必ずし
も限定されない。ペトリネットは、２種類のノード(node)（プレース(place)、トランジ
ション(transition)）を有する二部有向グラフ(bipartite digraph)（以下、「グラフ」
と称する。）である。プレースは、円で表されるノードであり、条件を表す。トランジションは、棒又は箱で表されるノードであり、事象を表す。これらを結ぶアーク(arc、矢印)は、条件や事象の間の関係を表す。

【0039】

ベースモデル１１４は、シナリオを表すグラフ、シナリオを定義するプレースに関する情報が管理されるプレース管理テーブル５０、トランジション管理テーブル６０、アセットクラステーブル７０、及びアラートクラステーブル８０の各情報を含む。

【0040】

図３Ａ～図３Ｃ、及び図４Ａ～図４Ｂは、上記の各情報の具体例である。以下、各情報について順に説明する。

【0041】

図３Ａは、ベースモデル１１４のグラフ４０の例である。同図に示すように、例示するベースモデル１１４は、シナリオＸ４１とシナリオＹ４２の２つのシナリオを含む。このうちシナリオＸ４１は、ＩＣＳ２の状態を示すプレース「Ｐ＿Ｘ０」、「Ｐ＿Ｘ１」、「Ｐ＿Ｘ２」、及び「Ｐ＿Ｘ３」と、状態の遷移の条件を示すトランジション「Ｔ＿Ｘ１」、「Ｔ＿Ｘ２」、及び「Ｔ＿Ｘ３」とが、アークで接続された構造を有する。また、シナリオＹ４２は、ＩＣＳ２の状態を、シナリオＸ４１とは異なる観点から定義したプレース「Ｐ＿Ｙ０」、「Ｐ＿Ｙ１」、「Ｐ＿Ｙ２」、及び「Ｐ＿Ｙ３」と、状態の遷移の条件を示すトランジション「Ｔ＿Ｙ１」、「Ｔ＿Ｙ１’」、「Ｔ＿Ｙ２」、「Ｔ＿Ｙ３」、及び「Ｔ＿Ｙ３’」とが、アークで接続された構造を有する。

【0042】

例示するシナリオＸ４１は、「Ｐ＿Ｘ０」から「Ｐ＿Ｘ３」へと直線的に状態が遷移していくのに対し、例示するシナリオＹ４２は、トランジション「Ｔ＿Ｙ１」或いは「Ｔ＿Ｙ１’」のいずれか一方が成立（ＯＲ条件が成立）した場合にのみ、「Ｐ＿Ｙ０」から「Ｐ＿Ｙ１」への遷移が起きるという構造を含む。また、シナリオＹ４２は、トランジション「Ｔ＿Ｙ３」と「Ｔ＿Ｙ３’」の両方が成立（ＡＮＤ条件が成立）した場合に「Ｐ＿Ｙ２」から「Ｐ＿Ｙ３」へと遷移するという構造を含む。

【0043】

図３Ｂは、例示するベースモデル１１４のプレース管理テーブル５０である。同図に示すように、プレース管理テーブル５０は、シナリオ５１、プレース５２、及び進行度５３の各項目を有する１つ以上のエントリ（レコード）で構成される。

【0044】

上記項目のうち、進行度５３には、ＩＣＳ２の状態の進行の度合いを示す指標である進行度が格納される。同図に示すシナリオＸ４１の例では、進行度として、プレース「Ｐ＿Ｘ０」に「０」が、「Ｐ＿Ｘ１」に「１／３」が、「Ｐ＿Ｘ２」に「２／３」が、プレース「Ｐ＿Ｘ３」に「３／３＝１」が、夫々設定されている。

【0045】

図３Ｃは、例示するベースモデル１１４のトランジション管理テーブル６０である。同図に示すように、例示するトランジション管理テーブル６０は、シナリオ６１、トランジション６２、アセットクラス６３、及びアラートクラス６４の各項目を有する１つ以上のエントリ（レコード）で構成される。

【0046】

上記項目のうち、アセットクラス６３には、ＩＣＳ２のアセットを類型化する指標であるアセットクラスが格納される。アラートクラス６４には、アラートを類型化する指標であるアラートクラスが格納される。トランジション管理テーブル６０のトランジション６２毎のエントリは、アセットクラス６３から対応するアラートクラス６４のアラートが発報された場合に対応するエントリのトランジション６２が発火することを示している。

【0047】

このように、トランジション管理テーブル６０において、各シナリオは、アセットを類型化したアセットクラスとアラートを類型化したアラートクラスによって定義（表現）されている。そのため、アセットのアセットクラスへの割り当てと、アラートのアラートクラスへの割り当てを適切に行うことで、本実施形態の状態分析装置１００は多様な形態を取り得るＩＣＳ２に広く適用することができる。また、ＩＣＳ２の構成や機能が変化した場合は柔軟に対応することができ、ＩＣＳ２の運用を容易にすることができる。

【0048】

図４Ａは、例示するベースモデル１１４のアセットクラステーブルである。同図に示すように、アセットクラステーブル７０は、サブクラス７１、アセットクラス７２、説明７３の各項目を有する一つ以上のエントリ（レコード）で構成される。

【0049】

上記項目のうち、サブクラス７１には、アセットクラスの分類単位であるサブクラス（物理サブクラス、論理サブクラス）が格納される。アセットクラス７２には、当該サブクラスに属するアセットクラスの識別子であるアセットクラスＩＤが格納される。本例では、物理サブクラスに「ＡＳＣ１」～「ＡＳＣ５」の各アセットクラスが定義され、論理サブクラスに「ＡＳＣ６」～「ＡＳＣ１１」の各アセットクラスが定義されている。説明７３には、各アセットクラスを説明する情報が格納される。

【0050】

このように、アセットクラスを物理サブクラスと論理サブクラスに分けて、即ち、アセットクラスを物理的な観点と論理的な観点に分けて定義することで、観点毎の状態変化の特徴に則したシナリオを適切に定義することができ、状態分析装置１００によるＩＣＳ２の状態推定の精度を向上することができる。

【0051】

図４Ｂは、例示するベースモデル１１４のアラートクラステーブルである。同図に示すように、アラートクラステーブル８０は、サブクラス８１、アセットクラス８２、アラートクラス８３、説明８４の組合せからなる１つ以上のエントリ（レコード）で構成される。

【0052】

上記項目のうち、サブクラス８１には、「物理サブクラス」又は「論理サブクラス」が格納される。アセットクラス８２には、アセットクラスＩＤが格納される。アラートクラス８３には、アラートクラスの識別子であるアラートクラスＩＤが格納される。説明８４には、当該アラートクラスの説明が格納される。本例では、サブクラス８１の物理サブクラスに「ＡＬＣ１」～「ＡＬＣ２７」のアセットクラス８２が対応づけられ、サブクラス８１の論理サブクラスに「ＡＬＣ２８」から「ＡＬＣ４５」のアセットクラス８２が対応づけられている。

【0053】

このように、アラートクラスを物理サブクラスと論理サブクラスに分けて、即ち、アラートクラスを物理的な観点と論理的な観点に分けて定義することで、観点毎の状態変化の特徴に則したシナリオを適切に定義することができ、状態分析装置１００によるＩＣＳ２の状態推定の精度を向上することができる。

【0054】

続いて、以上に例示したベースモデル１１４に基づき生成される状態推定モデル１１２について説明する。

【0055】

図５は、状態推定モデル１１２の例である。状態推定モデル１１２は、ＩＣＳ２毎に生成される。例示する状態推定モデル１１２は、アセット９１、アラート９２、アセットクラス９３、及びアラートクラス９４の各項目を有する１つ以上のエントリ（レコード）で構成される。

【0056】

上記項目のうち、アセット９１には、ＩＳＣ２のシステムを構成するアセットの識別子
であるアセットＩＤが格納される。アラート９２には、当該アセットが出力するアラートの識別子であるアラートＩＤが格納される。アセットクラス９３には、当該アセットに対応するアセットクラスのアセットクラスＩＤが格納される。アラートクラス９４には、当該アセットクラスに対応するアラートクラスのアラートクラスＩＤが格納される。

【0057】

図６は、状態推定モデル生成部１６０がユーザインタフェースを介して監視者や運用者等のユーザとの間で対話処理を行いつつ状態推定モデル１１２を生成する処理（以下、「状態推定モデル生成処理Ｓ６００」と称する。）を説明するフローチャートである。以下、同図とともに状態推定モデル生成処理Ｓ６００について説明する。

【0058】

まずユーザは、対象となるＩＳＣ２のアセットの一覧を洗い出す（Ｓ６０１）。尚、例えば、多重系によりコントローラが２台で冗長構成されている場合、ユーザは、第１コントローラ、第２コントローラ等の別々のコントローラとしてアセットを洗い出す。

【0059】

続いて、ユーザは、ベースモデル１１４を編集せずにそのまま状態推定モデル１１２の生成に利用するか否かを決定する（Ｓ６０２）。ユーザが状態推定モデル１１２を編集して利用すると決定した場合（Ｓ６０２：ＮＯ）、ユーザは、ベースモデル１１４を編集し（Ｓ６０３）、その後、処理はＳ６１１，Ｓ６２１の双方に進む。ユーザがベースモデル１１４を編集せずにそのまま利用すると決定した場合（Ｓ６０２：ＮＯ）、処理はＳ６１１，Ｓ６２１の双方に進む。

【0060】

図７は、ユーザがベースモデル１１４を編集する際に状態分析装置１００が提供するユーザインタフェース（以下、「ベースモデル設定画面７００」と称する。）の例である。同図に示すように、ベースモデル設定画面７００は、シナリオ一覧表示領域７１０、シナリオ表示領域７２０、プレース属性一覧表示領域７３０、及びトランジション属性一覧表示領域７４０を含む。

【0061】

シナリオ一覧表示領域７１０には、ベースモデル１１４が含むシナリオが一覧型式で表示される。ユーザは、例えば、シナリオ一覧表示領域７１０から、１つのシナリオを選択して編集することができる。また、ユーザは、例えば、シナリオ一覧表示領域７１０にて所定の操作を行うことで、シナリオの追加や削除を行うことができる。

【0062】

シナリオ表示領域７２０には、ベースモデル１１４に含まれるシナリオに対応するグラフ（ペトリネットを可視化したグラフ）が表示される。ユーザは、シナリオ表示領域７２０にてグラフを参照することにより、シナリオの内容を容易に確認することができる。またユーザは、表示されているグラフに対して所定の操作を行うことによりシナリオを容易に編集することができる。

【0063】

プレース属性一覧表示領域７３０には、ベースモデル１１４に含まれる全てのシナリオのプレースの一覧と、各プレースのシナリオの進行度を示す値が表示される。ユーザは、例えば、プレース属性一覧表示領域７３０において、プレースや進行度を容易に確認することができる。またユーザは、シナリオ表示領域７２０に示したペトリネットを確認しつつ、プレース属性一覧表示領域７３０において所定の操作を行うことで、プレースに関する情報を容易に編集することができる。

【0064】

トランジション属性一覧表示領域７４０には、ベースモデル１１４に含まれる全てのシナリオのトランジションの一覧と、各トランジションに対応する、アセットクラス及びアラートクラスが表示される。ユーザは、トランジション属性一覧表示領域７４０において、トランジションを構成するアセットクラスとアラートクラスを容易に確認することができる。またユーザは、シナリオ表示領域７２０に示したペトリネットの構造を確認しつつ
、トランジション属性一覧表示領域７４０において所定の操作を行うことで、トランジションに関する情報を容易に編集することができる。

【0065】

図６に戻り、Ｓ６１１では、ユーザは、アセットに対して論理サブクラスの割り当てを行う。また、Ｓ６２１では、ユーザは、アセットに対して物理サブクラスの割り当てを行う。

【0066】

図８は、Ｓ６１１とＳ６２１の両ステップにおいて、ユーザに提供されるユーザインタフェース（以下、「状態推定モデル設定画面８００」と称する。）である。同図に示すように、状態推定モデル設定画面８００は、ＩＣＳネットワーク表示領域８１０、論理サブクラス割り当て表示領域８２０、及び物理サブクラス割り当て表示領域８３０を含む。

【0067】

ＩＣＳ２を構成するネットワーク（以下、「ＩＣＳネットワーク」と称する。）の分類（以下、「レベル」と称する。）が表示される。レベルの例として、例えば、ＩＳＡ９９の「Purdue model」がある。「Purdue model」では、ＩＣＳを、「Level0（物理プロセス）」、「Level1（インテリジェントデバイス）」、「Level2（制御システム）」、「Level3（製造オペレーティングシステム）」、「Level4（ビジネスロジステックスシステム）」に分類する。多くのＩＣＳでは、こうしたレベル分けを軸としてシステム設計がなされることが多い。そのため、監視者や運用者等のユーザは、ＩＣＳネットワーク表示領域８１０に表示されているレベルから、対応するアセットを容易に想定することができる。

【0068】

論理サブクラス割り当て表示領域８２０において、ユーザは、ＩＣＳネットワークのレベル毎に、各レベルに含まれているアセットの一覧を確認しつつ設定を行うことができる。論理サブクラス割り当て表示領域８２０において、ユーザは、各アセットに「レ」を設定することにより論理サブクラスを割り当てることができる。尚、各アセットには、論理サブクラスを１つ以上割り当てることができる。ユーザは、論理サブクラス割り当て表示領域８２０を利用して、アセットの追加や削除を行うこともできる。

【0069】

物理サブクラス割り当て表示領域８３０において、ユーザは、各アセットに対し「レ」を設定することにより物理サブクラスを割り当てることができる。尚、各アセットには、物理サブクラスを１つ以上割り当てることができる。ユーザは、物理サブクラス割り当て表示領域８３０を利用して、アセットの追加や削除を行うこともできる。

【0070】

尚、論理サブクラス及び物理サブクラスの割り当てに際し、ユーザがアセットを入力した際、状態推定モデル生成部１６０が、入力されたアセットの製品名や型式に基づき、それらの論理サブクラスや物理サブクラスの割り当ての候補を表示するようにしてもよい。

【0071】

図６に戻り、Ｓ６１２では、ユーザは、ＩＣＳ２の制御フローの洗い出しを行う。また、Ｓ６１３では、ユーザは、アラートクラスの論理サブクラスの割り当てを行う。一方、Ｓ６２２では、ユーザは、アラートクラスの物理サブクラスの割り当てを行う。

【0072】

図９は、Ｓ６１２、Ｓ６１３、及びＳ６２２の各ステップにおいて、状態分析装置１００が提供するユーザインタフェース（以下、「状態推定モデル設定画面９００」と称する。）の例である。同図に示すように、状態推定モデル設定画面９００は、ＩＣＳ機能表示領域９１０、制御フロー表示領域９２０、論理サブクラス割り当て表示領域９３０、及び物理サブクラス割り当て表示領域９４０を含む。

【0073】

ＩＣＳ機能表示領域９１０には、ＩＣＳ２が提供する機能の一覧が表示される。ＩＣＳ２が提供する機能の一覧は、標準的な方法で予め割り当てられているものである。ユーザは、ＩＣＳ機能表示領域９１０において、ＩＣＳ２が提供する機能一覧を確認するととも
に、所定の操作を行うことで機能の追加や削除を行うことができる。

【0074】

制御フロー表示領域９２０には、２つ以上のアセットを利用して１つの機能を実現する際の制御フローを、メッセージの、送信元、送信先、及び内容を組合せたシーケンス図により表した図が表示される。ユーザは、制御フロー表示領域９２０を利用して、ＩＣＳ機能表示領域９１０にて選択したＩＣＳ２の機能を実現するアセットとメッセージを設定する。

【0075】

論理サブクラス割り当て表示領域９３０では、ユーザは、制御フロー表示領域９２０で入力したメッセージに関わるアラートを、アラートクラスの論理サブクラスに割り当てる。ユーザは、論理サブクラス割り当て表示領域９３０を利用し、１つの制御フローにおけるアセットが発報するアラートに対し、論理サブクラスのアラートクラスを割り当てる。

【0076】

物理サブクラス割り当て表示領域９４０では、ユーザは、各アセットに物理サブクラスのアラートクラスを割り当てる。ユーザは、物理サブクラス割り当て表示領域９４０を利用し、アセットの夫々について、アセットが発報するアラートの物理サブクラスのアラートクラスを割り当てる。

【0077】

尚、論理サブクラス及び物理サブクラスの割り当てにおいては、ユーザがアラートを入力した際、状態推定モデル生成部１６０が、入力されたアラートの種類やフォーマットに基づき、それらの論理サブクラスや物理サブクラスの割り当ての候補をユーザに提供するようにしてもよい。

【0078】

図６に戻り、Ｓ６３０では、アセットの洗い出し、アセットクラスの割り当て、アラートの洗い出し、及びアラートクラスの割り当てが完了し、ユーザは、その結果を状態推定モデル１１２として、状態推定モデル１１２に保存する。以上で状態推定モデル生成処理Ｓ６００は終了する。以上のように、状態分析装置１００が提供するユーザインタフェースを利用して、ユーザは、状態推定モデル１１２を効率よく生成することができる。

【0079】

図１０は、状態推定部１３０が状態推定モデル１１２を用いてＩＣＳ２の状態を推定する処理（以下、「状態推定処理Ｓ１０００」と称する。）を説明するフローチャートである。以下、同図とともに状態推定処理Ｓ１０００について説明する。

【0080】

状態推定部１３０は、アラート受信部１２０がＩＣＳ２から受信したアラート列を取得する（Ｓ１０１１）。

【0081】

続いて、状態推定部１３０は、取得したアラート列に、アラート列の識別子であるアラート列ＩＤを付与する（Ｓ１０１２）。

【0082】

続いて、状態推定部１３０は、取得したアラート列を構成する各アラートを、状態推定モデル１１２に基づきアラートクラスに変換し、変換して得られた各アラートクラスを、トランジション管理テーブル６０に基づきトランジションに変換する（Ｓ１０１３）。尚、１つのアラートに対して、複数のトランジションが対応する場合、状態推定部１３０は、当該一つのアラートを全てのトランジションに対応づける。

【0083】

図１１は、Ｓ１０１１～Ｓ１０１３までの処理を説明する図である。例えば、２つのアセット「ＡＳ１」、「ＡＳ２」がアラートを発報したとする。この場合、状態推定部１３０は、取り込み開始時刻と現在時刻との間に発報された３つのアラート「Ｔ１」、「Ｔ２」、「Ｔ３」をアラート列１１１１として取り込む。尚、取り込み開始時刻とは、アラート列がいずれか１つのシナリオが起きていると判定するのに十分な長さの開始時刻をいう
。例えば、ＩＣＳ２がオーバーホールにより全面改修される場合には、オーバーホールが行われた時刻が取り込み開始時刻となる。また例えば、アセットが故障しアセットの取り換えが行われた場合、アセットを取り換えた時刻が取り込み開始時間となる。

【0084】

状態推定部１３０は、当該アラート列１１１１に対してアラート列ＩＤを付与することにより、同図に示す変換後のアラート列１１１２を生成する。状態推定部１３０は、アセットが発報したアラートに対してアセットの種類に応じたアセットクラスを割り当て、アラートの種類に応じたアラートクラスを割り当てる。また、状態推定部１３０は、アセットが発報したアラートに、対応するシナリオとトランジションを対応づける。

【0085】

図１０に戻り、続いて、状態推定部１３０は、状態推定モデル１１２の各シナリオについて、Ｓ１０１４～Ｓ１０１６の処理を繰り返し実行する。

【0086】

まずＳ１０１５では、状態推定部１３０は、変換後のアラート列１１１２を、状態推定モデル１１２で定めたシナリオと照合する。

【0087】

Ｓ１０１６では、状態推定部１３０は、Ｓ１０１５の結果として、進行度及び発報度を求める。ここで進行度とは、プレース管理テーブル５０に示した進行度５３の値である。発報度とは、シナリオで定めた順番通りにアラート列が起きている度合いを表す指標である。尚、発報度としては、例えば、プロセスマイニングとして知られる「conformance checking」の「fitness値」を用いることができる。

【0088】

図１２Ａ及び図１２Ｂは、図１０のＳ１０１５～Ｓ１０１６の処理を説明する図である。図１２Ａは、図１１の時刻Ｔ１における各シナリオ（シナリオＸ４１、シナリオＹ４２）のトランジションの発火状態を、また、図１２Ｂには、図１１の時刻Ｔ３におけるトランジションの発火状態を例示している。

【0089】

図１２Ａの例では、シナリオＸ４１のトランジション「Ｔ＿Ｘ１」が発火し、アラートを発報したアセット「ＡＳ１」のトークンが「Ｐ＿Ｘ０」から「Ｐ＿Ｘ１」に遷移している。また、シナリオＹ４２のトランジション「Ｔ＿Ｙ２」が発火し、アセット「ＡＳ１」のトークンが「Ｐ＿Ｙ０」から「Ｐ＿Ｙ２」に遷移している。この例の場合、時刻Ｔ１におけるアセット「ＡＳ１」の進行度、発報度は次のようになる。
[数１]
シナリオＸ４１でのアセット「ＡＳ１」の（進行度、発報度）＝（1/3、1）
[数２]
シナリオＹ４２でのアセット「ＡＳ１」の（進行度、発報度）＝（2/3、1/2）

【0090】

図１２Ｂの例では、シナリオＸ４１のトランジション「Ｔ＿Ｘ２」が発火しているが、シナリオＹ４２では何も発火しておらず、アラートを発報したアセット「ＡＳ１」のトークンが「Ｐ＿Ｘ１」から「Ｐ＿Ｘ２」に遷移している。この例の場合、時刻Ｔ３におけるアセット「ＡＳ１」の進行度、発報度は次のようになる。
[数３]
シナリオＸ４１でのアセット「ＡＳ１」の（進行度、発報度）＝（2/3、1）
[数４]
シナリオＹ４２でのアセット「ＡＳ１」の（進行度、発報度）＝（2/3、1/2）

【0091】

この例では、時刻Ｔ３において、シナリオＸ４１及びシナリオＹ３０のいずれも進行度は「２／３」で同等であるが、発報度の比較から、シナリオＸ４１の状態遷移のほうがシナリオＹ４２の状態遷移よりも起きている可能性が高いと推定される。

【0092】

尚、以上では、アセット「ＡＳ１」が発火した場合における状態遷移を例示したが、同様の方法でユーザは各アセットの各時刻における進行度と発報度を知ることができる。

【0093】

図１０に戻り、続いて、Ｓ１０１７では、状態推定部１３０は、照合したアラート列、進行度、及び発報度を記載した画面（以下、「推定結果表示画面１３００」と称する。）を、ユーザインタフェースを介してユーザに提示する。

【0094】

図１３Ａに時刻Ｔ１における推定結果表示画面１３００の例を、図１３Ｂに時刻Ｔ３における推定結果表示画面１３００の例を夫々示す。

【0095】

図１３Ａに示すように、アセット「ＡＳ１」が発報したアラート「ＡＬ１」により、シナリオＸ４１及びシナリオＹ４２の夫々の進行度と発報度が表示されている。また図１３Ｂに示すように、アセット「ＡＳ１」が発報したアラート「ＡＬ３」により、シナリオＸ４１での進行度と発報度が更新され、シナリオＹ４２での進行度と発報度が表示されている。尚、各時刻における進行度が同じ値であった場合は、発報度の昇順又は降順にソートして情報を表示するようにしてもよい。また、同図に示すように、発報度が大きいほうの値（進行度、発報度）を強調表示（本例では太線枠付きで表示）するようにしてもよい。

【0096】

図１０に戻り、Ｓ１０１８では、状態推定部１３０は、状態推定処理Ｓ１０００を終了する事象（例えば、ユーザによる終了指示の受け付け）が生じているか否かを判定する。上記事象が生じていなければ（Ｓ１０１８：ＮＯ）、処理はＳ１０１１に戻る。上記事象が生じていれば、状態推定部１３０は、状態推定処理Ｓ１０００を終了する。

【0097】

以上に説明したように、状態推定部１３０は、状態推定処理Ｓ１０００を実行することによりＩＣＳ２の状態を推定し、その結果を記載した推定結果表示画面１３００をユーザに提示するので、ユーザは、各時刻においてＩＣＳ２で起きている状態を容易に把握することができる。また、推定結果表示画面１３００には、最新の推定結果だけでなく、過去の時点における推定結果も表示されるので、ユーザは、表示される進行度と発報度の時系列的な変化を把握することができ、それによりＩＣＳ２の状態を精度よく特定することができる。また、ユーザは、ＩＣＳ２のアセットやアラートの情報を順序良く入力していくだけで、ＩＣＳ２に適した状態推定モデル１１２を作成することができ、ＩＣＳ２の監視にかかるユーザの負担を軽減することができる。

【0098】

図１４は、状態推定モデル更新部１７０が行う処理（以下、「状態推定モデル更新処理Ｓ１４００」と称する。）を説明するフローチャートである。以下、同図とともに状態推定モデル更新処理Ｓ１４００について説明する。

【0099】

Ｓ１４１１では、状態推定モデル更新部１７０は、状態推定部１３０による状態推定結果１１３を蓄積する。

【0100】

Ｓ１４１２では、状態推定モデル更新部１７０は、状態推定結果１１３に基づき、進行度と発報度の傾向を分析する。

【0101】

Ｓ１４１３では、状態推定モデル更新部１７０は、発報度の傾向が下がってきたか否かを判定する。発報度の傾向が下がっていなければ（Ｓ１４１３：ＮＯ）、Ｓ１４１１の処理に戻る。発報度の傾向が下がっていれば（Ｓ１４１４：ＹＥＳ）、処理はＳ１４１４に進む。

【0102】

図１５Ａ及び図１５Ｂは、状態推定モデル更新部１７０が行う、進行度と発報度の傾向を分析する処理を説明する図である。

【0103】

図１５Ａは、状態推定結果１１３の例である。同図に示すように、状態推定結果１１３は、アラート列ＩＤ１５１１、シナリオ１５１２、進行度１５１３、及び発報度１５１４の各項目を有するアラート列毎の複数のエントリ（レコード）で構成される。

【0104】

図１５Ｂに示すグラフ（以下、「傾向分析グラフ１５２０」と称する。）は、Ｘ軸を進行度とし、Ｙ軸を発報度として値をプロットしたグラフである。例えば、発報度が「１」のまま進行度が進む場合（符号１５２１で示すプロット群）、状態推定モデル更新部１７０は、シナリオとアラート列が一致していると判定する。一方、進行度が進むときに発報度が「０」に近い値を取り続ける場合（符号１５２２で示すプロット群）、状態推定モデル更新部１７０は、シナリオとアラート列との間にずれが生じていると判定する。状態推定モデル更新部１７０は、例えば、傾向分析グラフ１５２０に基づき、このようにして発報度の傾向が下がってきたことを検出する。

【0105】

図１４に戻り、続いて、Ｓ１４１４では、状態推定モデル更新部１７０は、発報度の傾向が下がってきたシナリオを特定する。

【0106】

続いて、状態推定モデル更新部１７０は、アラート列を再現（リプレイ）し、シナリオの修正箇所を特定する（Ｓ１４１５）。

【0107】

続いて、状態推定モデル更新部１７０は、特定した修正箇所を修正したシナリオ（以下、「修正後シナリオ」と称する。）を生成する（Ｓ１４１６）。

【0108】

続いて、状態推定モデル更新部１７０は、アラート列を用いて修正後シナリオにおける進行度と発報度をシミュレーションする（Ｓ１４１７）。

【0109】

図１５Ｃは、Ｓ１４１４～Ｓ１４１７の処理に際し、ユーザに提供されるユーザインタフェース（以下、「状態推定モデル更新画面１５３０」と称する。）の例である。

【0110】

同図に示すように、状態推定モデル更新画面１５３０は、シナリオ一覧表示領域１５３１、修正前シナリオ表示領域１５３２、修正後シナリオ表示領域１５３３から構成される。

【0111】

シナリオ一覧表示領域１５３１は、傾向分析グラフ１５２０で発報度の傾向が下がってきた場合（符号１５２２）に該当するシナリオを一覧で表示する。ユーザは、シナリオ一覧表示領域１５３１を確認し、発報度の傾向が下がってきたシナリオを把握する。

【0112】

修正前シナリオ表示領域１５３２には、アラート列を再現し、トークンの発火の様子をシミュレーションした内容が表示される。ユーザは、修正前シナリオ表示領域１５３２を確認し、シナリオには定義されているが、実際には発火していないプレース１５４１を特定する。例えば、ユーザは、プレース１５４１にマウスポインタを合わせて右クリック等することにより表示される操作メニューを利用して当該プレースを削除し、前後のプレースを繋げるように修正を行う。

【0113】

修正後シナリオ表示領域１５３３には、アラート列を再現した場合の修正後シナリオの進行度と発報度が表示される。

【0114】

図１４に戻り、続いて、Ｓ１４１８では、状態推定モデル更新部１７０は、ユーザから修正後シナリオを許容するか否かの入力を受け付ける。ユーザから修正後シナリオを許容できない旨の入力を受け付けた場合（Ｓ１４１８：ＮＯ）、処理はＳ１４１５に戻る。ユ
ーザから修正後シナリオを許容できる旨の入力を受け付けた場合（Ｓ１４１８：ＹＥＳ）、処理はＳ１４１９に進む。

【0115】

Ｓ１４１９では、状態推定モデル更新部１７０は、修正後シナリオの内容に状態推定モデル１１２を更新する。以上で状態推定モデル更新処理Ｓ１４００は終了する。

【0116】

このように、状態分析装置１００は、状態推定モデル更新処理Ｓ１４００を実行することにより、発報度の傾向が下がってきたことを検出し、シナリオの修正箇所を特定してユーザとの対話処理によりシナリオを修正し、修正後シナリオにおける進行度と発報度をシミュレーションしてシナリオを適切に更新する。そのため、例えば、状態推定モデル１１２の詳細な技術詳細を把握していないユーザでも、発報度の傾向が下がってきたことを容易に捉えることができ、発報度が下がってきたシナリオを特定し、シナリオの修正が必要な箇所を特定してシナリオを修正し、修正後シナリオをシミュレーションすることによりシナリオを適切に更新することができる。

【0117】

続いて、状態推定モデル１１２の例を示しつつ、故障シナリオや攻撃シナリオの識別方法について具体的に説明する。

【0118】

図１６Ａ～図１６Ｃは、機器が故障した場合のシナリオ（以下、「故障シナリオ」と称する。）の例である。

【0119】

図１６Ａに示す故障シナリオ１６１０は、単体の装置Ａにおいて異常が進行するケースを示したものである。スタートＳから開始し、トランジション「異音アラート」が発火すると、状態はプレース「すり減り」に遷移する。また、トランジション「温度上昇アラート」が発火すると、状態はプレース「温度上昇」に遷移する。次に、トランジション「チョコ停アラート」が累積して１０回発火すると、状態はプレース「チョコ停」に遷移する。次に、トランジション「メンテアラート」が発火すると、状態はプレース「利用不可」に遷移する。そして、装置Ｂでのトランジション「装置Ａからの応答異常アラート」が発火すると、装置Ａの状態は最終的な故障Ｇに至る。

【0120】

図１６Ｂに示す故障シナリオ１６２０は、ＩＣＳ２の冗長系システムにおいて、複数の異常が進行するケースを示したものであり、装置Ａが通信装置ａと通信装置ｂで通信を冗長化するケースを示したものである。スタートＳから開始し、トランジション「通信装置ａアラート」が発火すると、状態はプレース「通信装置ａ異常」に遷移する。或いは、トランジション「通信装置ｂアラート」が発火すると、状態はプレース「通信装置ｂ異常」に遷移する。次に、装置Ｂにてトランジション「装置Ａからの応答異常アラート」が発火すると、装置Ａのプレース「通信異常」に遷移する。更に装置Ｂにてトランジション「装置Ｃに切り替えアラート」が発火すると、装置Ａの状態は最終的な故障Ｇに至る。

【0121】

図１６Ｃに示す故障シナリオ１６３０は、ＩＣＳ２の構成要素である、装置Ａから装置Ｅにおいて、装置Ａが異常となった場合にその異常が次第にほかの装置Ｂから装置Ｅに伝搬するというケースを示したものである。スタートＳから開始して、装置Ａでトランジション「異常アラート」が発火すると、状態はプレース「装置Ａ異常状態」に遷移する。次に、装置Ｂでトランジション「異常アラート」が発火すると、状態はプレース「装置Ｂ異常状態」に遷移する。次に、装置Ｃでトランジション「異常アラート」が発火すると、状態はプレース「装置Ｃ異常状態」に遷移する。或いは、装置Ｄでトランジション「異常アラート」が発火すると、状態はプレース「装置Ｄ異常状態」に遷移する。更に装置Ｅでトランジション「異常アラート」が発火すると、状態はプレース「装置Ｅ異常状態」に遷移し、最終的なシステム全体の故障Ｇとなる。

【0122】

状態推定モデル１１２として以上の故障シナリオを用いることで、状態分析装置１００アラート列に基づきＩＣＳ２における故障の状態を推定することができる。

【0123】

図１７Ａ及び図１７Ｂは、サイバー攻撃が行われた場合のシナリオ（以下、「攻撃シナリオ」と称する。）の例である。

【0124】

図１７Ａに示す攻撃シナリオ１７１０では、ＩＣＳ２を構成する装置Ａから装置Ｃにおいて、サイバーキルチェーンの水平移動と呼ばれる攻撃が発生するケースを示したものである。スタートＳから開始し、装置Ａでトランジション「ＮＷ接続／切断アラート」が発火すると装置Ａのプレース「探査された状態」に遷移する。或いは、装置Ｂ或いは装置Ｃで同様のアラートが発火すると、夫々の装置について、状態はプレース「探査された状態」に遷移する。次に、装置Ａ、装置Ｂ、及び装置Ｃのうちの少なくともいずれかでトランジション「ＣＰＵ負荷アラート」は発火すると、状態はプレース「侵入された状態」に遷移する。更に、装置Ａ、装置Ｂ、及び装置Ｃのうちの少なくともいずれかでトランジション「モード変更アラート」が発火すると、状態はプレース「異常動作」に遷移する。更に、装置Ａ、装置Ｂ、及び装置Ｃのうちの少なくともいずれかでトランジション「異常アラート」が発火すると、状態は最終的なサイバー攻撃の成功Ｇに至る。

【0125】

図１７Ｂに示す攻撃シナリオ１７２０では、装置Ａがランサムウェアに感染し、ハードディスク（以下、「ＨＤＤ」と称する。）が使用不能になるケースを示したものである。スタートＳから開始し、装置Ａでトランジション「プログラム起動アラート」が発火すると、プレース「実行された状態」に遷移する。次にトランジション「ＨＤＤ負荷アラート」が発火すると、状態はプレース「ＨＤＤ暗号化状態」に遷移する。更にトランジション「起動不能アラート」が発火すると、状態はプレース「利用不可状態」に遷移する。更に、装置Ｂにおけるトランジション「装置Ａからの応答異常アラート」が発火すると、状態は最終的なサイバー攻撃の成功Ｇに至る。

【0126】

図１７Ｃに示す攻撃シナリオ１７３０では、サイバーキルチェーンと呼ばれる攻撃のコマンド＆コントロールが実行されたときのケースを示したものである。ファイアウォールでトランジション「外部接続／切断アラート」が発火すると、装置Ａ、装置Ｂ、及び装置Ｃのいずれかについて、状態がプレース「コマンドを受け取った状態」に遷移する。次に、装置Ａ、装置Ｂ、及び装置Ｃのいずれかでトランジション「ＨＤＤ負荷アラート」が発火すると、各装置の状態は、プレース「攻撃実行状態」に遷移する。更に装置Ａ、装置Ｂ、装置Ｃのいずれかでトランジション「異常アラート」が発火すると、状態は最終的なサイバー攻撃の成功Ｇに至る。

【0127】

状態推定モデル１１２としてこれらの攻撃シナリオを用いることで、状態分析装置１００はアラート列に基づきＩＣＳ２のサイバー攻撃による状態を推定することができる。

【0128】

以上、本発明の一実施形態について説明したが、本発明は上記の実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記実施形態の構成の一部について、他の構成の追加や削除、置換をすることが可能である。

【0129】

また、上記の各構成、機能部、処理部、処理手段等は、それらの一部又は全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサが夫々の機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、ＩＣカ
ード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

【0130】

また、以上に説明した各情報処理装置の各種機能部、各種処理部、各種データベースの配置形態は一例に過ぎない。各種機能部、各種処理部、各種データベースの配置形態は、これらの装置が備えるハードウェアやソフトウェアの性能、処理効率、通信効率等の観点から最適な配置形態に変更し得る。

【0131】

また、前述した各種のデータを格納するデータベースの構成（スキーマ（Schema）等）は、リソースの効率的な利用、処理効率向上、アクセス効率向上、検索効率向上等の観点から柔軟に変更し得る。

【符号の説明】

【0132】

２ ＩＣＳ（産業制御システム）、５ 通信ネットワーク、４０ グラフ、４１ シナリオＸ、４２ シナリオＹ、５０ プレース管理テーブル、６０ トランジション管理テーブル、７０ アセットクラステーブル、８０ アラートクラステーブル、１００ 状態分析装置、１１０ 記憶部、１１１ アラート列、１１２ 状態推定モデル、１１３ 状態推定結果、１１４ ベースモデル、１２０ アラート受信部、１３０ 状態推定部、１４０ 推定結果出力部、１５０ ベースモデル生成部、１６０ 状態推定モデル生成部、１７０ 状態推定モデル更新部、Ｓ６００ 状態推定モデル生成処理、７００ ベースモデル設定画面、８００ 状態推定モデル設定画面、９００ 状態推定モデル設定画面、Ｓ１０００ 状態推定処理、１３１０ 状態推定結果、１３２０ 状態推定結果、Ｓ１４００
状態推定モデル更新処理、１５３０ 状態推定モデル更新画面

【図1】

【図2A】

【図2B】

【図3A】

【図3B】

【図3C】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図13A】

【図13B】

【図14】

【図15A】

【図15B】

【図15C】

【図16A】

【図16B】

【図16C】

【図17A】

【図17B】

【図17C】