JP2020149528A - コントローラシステム - Google Patents

Abstract

【課題】制御装置および制御システムのネットワーク化あるいはインテリジェント化に伴って生じ得る脅威に対する保護の確実性を高める。【解決手段】コントローラシステムは、制御対象５００を制御するための制御動作を実行する制御ユニット１００と、コントローラシステムに対するセキュリティ機能を担当するセキュリティユニット２００とを備える。セキュリティユニット２００は、コントローラシステムにおける、セキュリティに関するインシデントの有無を検知する検知手段を含む。制御ユニット１００は、検知手段によりインシデントが検知された場合には、制御モードを縮退モードに遷移させて、インシデントの解除が検知手段によって検知されるまで制御モードを縮退モードに保つ。【選択図】図７

Description

本発明は、制御対象を制御するコントローラシステムに対するセキュリティ機能に関する。

各種設備および各設備に配置される各種装置の制御には、ＰＬＣ（プログラマブルロジックコントローラ）などの制御装置が用いられる。制御装置は、制御対象の設備や機械に生じる異常を監視するとともに、制御装置自体の異常を監視することも可能である。何らかの異常が検知されると、制御装置から外部に対して何らかの方法で通知がなされる。

例えば、特開２０００−１３７５０６号公報（特許文献１）は、異常履歴が登録されたとき、または、予め定められた時間が到来したときに、予め指定された宛先に電子メールを送信するプログラマブルコントローラを開示する。

特開２０００−１３７５０６号公報

近年のＩＣＴ（Information and Communication Technology）の進歩に伴って、制御装置も様々な外部装置とネットワーク接続されるとともに、制御装置において実行される処理も高度化している。このようなネットワーク化あるいはインテリジェント化に伴って、想定される脅威の種類も増加している。したがって、このような脅威に対する制御装置および制御システムの保護が必要となっている。制御装置および制御システムに対する脅威が存在する間、その脅威から制御装置および制御システムを保護することの確実性を高くすることが求められる。

本発明は、制御装置および制御システムのネットワーク化あるいはインテリジェント化に伴って生じ得る脅威に対する保護の確実性を高めることを一つの目的としている。

本開示の一例は、コントローラシステムであって、制御対象を制御するための制御動作を実行する制御ユニットと、制御ユニットに接続され、コントローラシステムに対するセキュリティ機能を担当するセキュリティユニットとを備え、制御ユニットは、制御動作に関する制御モードとして、正常モードと、コントローラシステムの限定的な動作を実行するための縮退モードとを有し、正常モードと縮退モードとは相互に遷移可能であり、セキュリティユニットは、コントローラシステムにおける、セキュリティに関するインシデントの有無を検知する検知手段を含み、制御ユニットは、検知手段によりインシデントが検知された場合には、制御モードを縮退モードに遷移させて、インシデントの解除が検知手段によって検知されるまで制御モードを縮退モードに保つ。

上記によれば、セキュリティに関するインシデントが解除されるまで、制御ユニットは縮退モードで稼働する。セキュリティに関するインシデントが解除されていないにもかかわらず、制御ユニットが正常モードで稼働することを防止できる。したがって、制御装置および制御システムのネットワーク化あるいはインテリジェント化に伴って生じ得る脅威に対する保護の確実性を高めることができる。

好ましくは、制御ユニットは、検知手段からインシデントの検知に関するインシデント情報を取得し、インシデント情報がインシデントの解除を示す場合には、制御ユニットは、縮退モードから正常モードへ制御モードを変更し、インシデント情報がインシデントの継続を示す場合には、制御ユニットは、制御モードを縮退モードに設定する。

上記によれば、制御ユニットは、セキュリティユニットからの情報に基づいて、制御モードを正常モードまたは縮退モードに設定することができる。これにより、制御装置および制御システムのネットワーク化あるいはインテリジェント化に伴って生じ得る脅威に対する保護の確実性を高めることができる。

好ましくは、制御ユニットは、制御ユニットの再起動処理を実行する場合に、インシデント情報に基づいて、制御モードを決定する。

上記によれば、セキュリティに関するインシデントが解除されていない場合には、制御ユニットを再起動した後も制御モードは縮退モードに設定される。インシデントが解除されていないにもかかわらず、制御ユニットの再起動処理によって制御モードが正常モードに設定されることを防止できる。

好ましくは、セキュリティユニットは、インシデントの検知に関する情報を不揮発的に記憶して、コントローラシステムへの電源再投入によるコントローラシステムの再起動時に、セキュリティユニットは、セキュリティユニットに記憶された情報に基づいて、セキュリティユニットのステータスを復帰させ、制御ユニットは、セキュリティユニットのステータスに基づいて、制御モードを設定する。

上記によれば、セキュリティに関するインシデントが解除されていない場合には、コントローラシステム全体を電源再投入によりリセットしても、セキュリティユニットに記憶された情報に基づいて、制御モードは縮退モードに設定される。インシデントが解除されていないにもかかわらず、コントローラシステムの再起動処理によって制御モードが正常モードに設定されることを防止できる。

好ましくは、セキュリティユニットは、管理者権限を持つユーザからの操作をインシデント情報に優先させてインシデントの検知に関するセキュリティユニットのステータスを変更する。

上記によれば、たとえばインシデントが解除されたことが明らかな場合に、コントローラシステム１を早期に復旧させることができる。

好ましくは、縮退モードにおいて、制御ユニットは、制御動作を制限する。
上記によれば、システムの稼働を維持することができる。

好ましくは、縮退モードにおいて、制御ユニットは、制御対象の動作を制限する。
上記によれば、システムの稼働を維持することができる。

本発明によれば、制御装置および制御システムのネットワーク化あるいはインテリジェント化に伴って生じ得る脅威に対する保護の確実性を高めることができる。

本実施の形態に係るコントローラシステムの構成例を示す外観図である。 本実施の形態に従うコントローラシステムを構成する制御ユニットのハードウェア構成例を示す模式図である。 本実施の形態に従うコントローラシステムを構成するセキュリティユニットのハードウェア構成例を示す模式図である。 本実施の形態に従うコントローラシステムを構成するセーフティユニットのハードウェア構成例を示す模式図である。 本実施の形態に従うコントローラシステムを含む制御システムの典型例を示す模式図である。 セキュリティ脅威に対する対策サイクルの一例を示す模式図である。 本実施の形態に従うコントローラシステム１を含む制御システムにおける不正侵入検知時の対応の一例を示す模式図である。 生産機械および検査装置を含むラインに対する攻撃例を示す模式図である。 本実施の形態に従うコントローラシステム１におけるインシデント特性に応じた設備別の制御動作の一例を示す図である。 本実施の形態に従うコントローラシステム１におけるインシデント特性に応じた設備別の制御動作の別の一例を示す図である。 本実施の形態に従うコントローラシステム１におけるインシデント特性に応じた各設備における状態別の制御動作の一例を示す図である。 本実施の形態に従うコントローラシステム１におけるセキュリティ脅威が検知された場合の処理手順を示すフローチャートである。 本実施の形態に従うコントローラシステム１に採用されるインジケータの一例を示す模式図である。 インシデント発生後の制御システム１０の復旧において想定される事態を示した図である。 図１４に示した事態に対応するシステムの状態を示した図である。 本実施の形態に係る再稼働処理のフローを示すための図である。 本実施の形態における制御システムの再稼働処理のフローを説明するための第１の図である。 本実施の形態における制御システムの再稼働処理のフローを説明するための第２の図である。

本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。

＜Ａ．コントローラシステム１＞
まず、本実施の形態に従うコントローラシステム１の構成について説明する。

図１は、本実施の形態に係るコントローラシステム１の構成例を示す外観図である。図１を参照して、コントローラシステム１は、制御ユニット１００と、セキュリティユニット２００と、セーフティユニット３００と、１または複数の機能ユニット４００と、電源ユニット４５０とを含む。

制御ユニット１００とセキュリティユニット２００との間は、任意のデータ伝送路（例えば、ＰＣＩ Ｅｘｐｒｅｓｓ（登録商標）あるいはイーサネット（登録商標）など）を介して接続されている。制御ユニット１００とセーフティユニット３００および１または複数の機能ユニット４００との間は、図示しない内部バスを介して接続されている。

制御ユニット１００は、コントローラシステム１において中心的な処理を実行する。制御ユニット１００は、任意に設計された要求仕様に従って、制御対象を制御するための制御演算を実行する。後述のセーフティユニット３００で実行される制御演算との対比で、制御ユニット１００で実行される制御演算を「標準制御」とも称す。図１に示す構成例において、制御ユニット１００は、１または複数の通信ポートを有している。

セキュリティユニット２００は、制御ユニット１００に接続され、コントローラシステム１に対するセキュリティ機能を担当する。図１に示す構成例において、セキュリティユニット２００は、１または複数の通信ポートを有している。セキュリティユニット２００が提供するセキュリティ機能の詳細については、後述する。

セーフティユニット３００は、制御ユニット１００とは独立して、制御対象に関するセーフティ機能を実現するための制御演算を実行する。セーフティユニット３００で実行される制御演算を「セーフティ制御」とも称す。通常、「セーフティ制御」は、ＩＥＣ ６１５０８などに規定されたセーフティ機能を実現するための要件を満たすように設計される。「セーフティ制御」は、設備や機械などによって人の安全が脅かされることを防止するための処理を総称する。

機能ユニット４００は、コントローラシステム１による様々な制御対象に対する制御を実現するための各種機能を提供する。機能ユニット４００は、典型的には、Ｉ／Ｏユニット、セーフティＩ／Ｏユニット、通信ユニット、モーションコントローラユニット、温度調整ユニット、パルスカウンタユニットなどを包含し得る。Ｉ／Ｏユニットとしては、例えば、デジタル入力（ＤＩ）ユニット、デジタル出力（ＤＯ）ユニット、アナログ出力（ＡＩ）ユニット、アナログ出力（ＡＯ）ユニット、パルスキャッチ入力ユニット、および、複数の種類を混合させた複合ユニットなどが挙げられる。セーフティＩ／Ｏユニットは、セーフティ制御に係るＩ／Ｏ処理を担当する。

電源ユニット４５０は、コントローラシステム１を構成する各ユニットに対して、所定電圧の電源を供給する。

＜Ｂ．各ユニットのハードウェア構成例＞
次に、本実施の形態に従うコントローラシステム１を構成する各ユニットのハードウェア構成例について説明する。

（ｂ１：制御ユニット１００）
図２は、本実施の形態に従うコントローラシステム１を構成する制御ユニット１００のハードウェア構成例を示す模式図である。図２を参照して、制御ユニット１００は、主たるコンポーネントとして、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphical Processing Unit）などのプロセッサ１０２と、チップセット１０４と、主記憶装置１０６と、二次記憶装置１０８と、通信コントローラ１１０と、ＵＳＢ（Universal Serial Bus）コントローラ１１２と、メモリカードインターフェイス１１４と、ネットワークコントローラ１１６，１１８，１２０と、内部バスコントローラ１２２と、インジケータ１２４とを含む。

プロセッサ１０２は、二次記憶装置１０８に格納された各種プログラムを読み出して、主記憶装置１０６に展開して実行することで、標準制御に係る制御演算、および、後述するような各種処理を実現する。チップセット１０４は、プロセッサ１０２と各コンポーネントとの間のデータの遣り取りを仲介することで、制御ユニット１００全体としての処理を実現する。

二次記憶装置１０８には、システムプログラムに加えて、システムプログラムが提供する実行環境上で動作する制御プログラムが格納される。

通信コントローラ１１０は、セキュリティユニット２００との間のデータの遣り取りを担当する。通信コントローラ１１０としては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓあるいはイーサネットなどに対応する通信チップを採用できる。

ＵＳＢコントローラ１１２は、ＵＳＢ接続を介して任意の情報処理装置との間のデータの遣り取りを担当する。

メモリカードインターフェイス１１４は、メモリカード１１５を着脱可能に構成されており、メモリカード１１５に対して制御プログラムや各種設定などのデータを書込み、あるいは、メモリカード１１５から制御プログラムや各種設定などのデータを読出すことが可能になっている。

ネットワークコントローラ１１６，１１８，１２０の各々は、ネットワークを介した任意のデバイスとの間のデータの遣り取りを担当する。ネットワークコントローラ１１６，１１８，１２０は、ＥｔｈｅｒＣＡＴ（登録商標）、ＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）、ＤｅｖｉｃｅＮｅｔ（登録商標）、ＣｏｍｐｏＮｅｔ（登録商標）などの産業用ネットワークプロトコルを採用してもよい。

内部バスコントローラ１２２は、コントローラシステム１を構成するセーフティユニット３００や１または複数の機能ユニット４００との間のデータの遣り取りを担当する。内部バスには、メーカ固有の通信プロトコルを用いてもよいし、いずれかの産業用ネットワークプロトコルと同一あるいは準拠した通信プロトコルを用いてもよい。

インジケータ１２４は、制御ユニット１００の動作状態などを通知するものであり、ユニット表面に配置された１または複数のＬＥＤなどで構成される。

図２には、プロセッサ１０２がプログラムを実行することで必要な機能が提供される構成例を示したが、これらの提供される機能の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣ（Application Specific Integrated Circuit）またはＦＰＧＡ（Field-Programmable Gate Array）など）を用いて実装してもよい。あるいは、制御ユニット１００の主要部を、汎用的なアーキテクチャに従うハードウェア（例えば、汎用パソコンをベースとした産業用パソコン）を用いて実現してもよい。この場合には、仮想化技術を用いて、用途の異なる複数のＯＳ（Operating System）を並列的に実行させるとともに、各ＯＳ上で必要なアプリケーションを実行させるようにしてもよい。

（ｂ２：セキュリティユニット２００）
図３は、本実施の形態に従うコントローラシステム１を構成するセキュリティユニット２００のハードウェア構成例を示す模式図である。図３を参照して、セキュリティユニット２００は、主たるコンポーネントとして、ＣＰＵやＧＰＵなどのプロセッサ２０２と、チップセット２０４と、主記憶装置２０６と、二次記憶装置２０８と、通信コントローラ２１０と、ＵＳＢコントローラ２１２と、メモリカードインターフェイス２１４と、ネットワークコントローラ２１６，２１８と、インジケータ２２４とを含む。

プロセッサ２０２は、二次記憶装置２０８に格納された各種プログラムを読み出して、主記憶装置２０６に展開して実行することで、後述するような各種セキュリティ機能を実現する。チップセット２０４は、プロセッサ２０２と各コンポーネントとの間のデータの遣り取りを仲介することで、セキュリティユニット２００全体としての処理を実現する。

二次記憶装置２０８には、システムプログラムに加えて、システムプログラムが提供する実行環境上で動作するセキュリティシステムプログラムが格納される。

通信コントローラ２１０は、制御ユニット１００との間のデータの遣り取りを担当する。通信コントローラ２１０としては、制御ユニット１００に通信コントローラ２１０と同様に、例えば、ＰＣＩ Ｅｘｐｒｅｓｓあるいはイーサネットなどに対応する通信チップを採用できる。

ＵＳＢコントローラ２１２は、ＵＳＢ接続を介して任意の情報処理装置との間のデータの遣り取りを担当する。

メモリカードインターフェイス２１４は、メモリカード２１５を着脱可能に構成されており、メモリカード２１５に対して制御プログラムや各種設定などのデータを書込み、あるいは、メモリカード２１５から制御プログラムや各種設定などのデータを読出すことが可能になっている。

ネットワークコントローラ２１６，２１８の各々は、ネットワークを介した任意のデバイスとの間のデータの遣り取りを担当する。ネットワークコントローラ２１６，２１８は、イーサネット（登録商標）などの汎用的なネットワークプロトコルを採用してもよい。

インジケータ２２４は、セキュリティユニット２００の動作状態などを通知するものであり、ユニット表面に配置された１または複数のＬＥＤなどで構成される。

図３には、プロセッサ２０２がプログラムを実行することで必要な機能が提供される構成例を示したが、これらの提供される機能の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣまたはＦＰＧＡなど）を用いて実装してもよい。あるいは、セキュリティユニット２００の主要部を、汎用的なアーキテクチャに従うハードウェア（例えば、汎用パソコンをベースとした産業用パソコン）を用いて実現してもよい。この場合には、仮想化技術を用いて、用途の異なる複数のＯＳを並列的に実行させるとともに、各ＯＳ上で必要なアプリケーションを実行させるようにしてもよい。

（ｂ３：セーフティユニット３００）
図４は、本実施の形態に従うコントローラシステム１を構成するセーフティユニット３００のハードウェア構成例を示す模式図である。図４を参照して、セーフティユニット３００は、主たるコンポーネントとして、ＣＰＵやＧＰＵなどのプロセッサ３０２と、チップセット３０４と、主記憶装置３０６と、二次記憶装置３０８と、メモリカードインターフェイス３１４と、内部バスコントローラ３２２と、インジケータ３２４とを含む。

プロセッサ３０２は、二次記憶装置３０８に格納された各種プログラムを読み出して、主記憶装置３０６に展開して実行することで、セーフティ制御に係る制御演算、および、後述するような各種処理を実現する。チップセット３０４は、プロセッサ３０２と各コンポーネントとの間のデータの遣り取りを仲介することで、セーフティユニット３００全体としての処理を実現する。

二次記憶装置３０８には、システムプログラムに加えて、システムプログラムが提供する実行環境上で動作するセーフティプログラムが格納される。

メモリカードインターフェイス３１４は、メモリカード３１５を着脱可能に構成されており、メモリカード３１５に対してセーフティプログラムや各種設定などのデータを書込み、あるいは、メモリカード３１５からセーフティプログラムや各種設定などのデータを読出すことが可能になっている。

内部バスコントローラ３２２は、内部バスを介した制御ユニット１００との間のデータの遣り取りを担当する。

インジケータ３２４は、セーフティユニット３００の動作状態などを通知するものであり、ユニット表面に配置された１または複数のＬＥＤなどで構成される。

図４には、プロセッサ３０２がプログラムを実行することで必要な機能が提供される構成例を示したが、これらの提供される機能の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣまたはＦＰＧＡなど）を用いて実装してもよい。あるいは、セーフティユニット３００の主要部を、汎用的なアーキテクチャに従うハードウェア（例えば、汎用パソコンをベースとした産業用パソコン）を用いて実現してもよい。この場合には、仮想化技術を用いて、用途の異なる複数のＯＳを並列的に実行させるとともに、各ＯＳ上で必要なアプリケーションを実行させるようにしてもよい。

＜Ｃ．制御システム１０＞
次に、本実施の形態に従うコントローラシステム１を含む制御システム１０の典型例について説明する。図５は、本実施の形態に従うコントローラシステム１を含む制御システム１０の典型例を示す模式図である。

一例として、図５に示す制御システム１０は、２つのライン（ラインＡおよびラインＢ）を制御対象とする。典型的には、各ラインは、ワークを搬送するコンベアに加えて、コンベア上のワークに対して任意の物理的作用を与えることが可能なロボットが配置されているとする。

ラインＡおよびラインＢのそれぞれに制御ユニット１００が配置されている。ラインＡを担当する制御ユニット１００に加えて、セキュリティユニット２００およびセーフティユニット３００がコントローラシステム１を構成する。なお、説明の便宜上、図５には、機能ユニット４００および電源ユニット４５０の記載を省略している。

コントローラシステム１のセキュリティユニット２００は、通信ポート２４２（図３のネットワークコントローラ２１６）を介して第１ネットワーク２に接続されている。第１ネットワーク２には、サポート装置６００およびＳＣＡＤＡ（Supervisory Control And Data Acquisition）装置７００が接続されているとする。

サポート装置６００は、少なくとも制御ユニット１００にアクセス可能になっており、コントローラシステム１に含まれる各ユニットで実行されるプログラムの作成、デバッグ、各種パラメータの設定などの機能をユーザへ提供する。

ＳＣＡＤＡ装置７００は、コントローラシステム１での制御演算によって得られる各種情報をオペレータへ提示するとともに、オペレータからの操作に従って、コントローラシステム１に対して内部コマンドなどを生成する。ＳＣＡＤＡ装置７００は、コントローラシステム１が扱うデータを収集する機能も有している。

コントローラシステム１の制御ユニット１００は、通信ポート１４２（図２のネットワークコントローラ１１６）を介して第２ネットワーク４に接続されている。第２ネットワーク４には、ＨＭＩ（Human Machine Interface）８００およびデータベース９００が接続されているとする。

ＨＭＩ８００は、コントローラシステム１での制御演算によって得られる各種情報をオペレータへ提示するとともに、オペレータからの操作に従って、コントローラシステム１に対して内部コマンドなどを生成する。データベース９００は、コントローラシステム１から送信される各種データ（例えば、各ワークから計測されたトレーサビリティに関する情報など）を収集する。

コントローラシステム１の制御ユニット１００は、通信ポート１４４（図２のネットワークコントローラ１１８）を介して、１または複数のフィールドデバイス５００と接続されている。フィールドデバイス５００は、制御対象から制御演算に必要な各種情報を収集するセンサや検出器、および、制御対象に対して何らかの作用を与えるアクチュエータなどを含む。図５に示す例では、フィールドデバイス５００は、ワークに対して何らかの外的な作用を与えるロボット、ワークを搬送するコンベヤ、フィールドに配置されたセンサやアクチュエータとの間で信号を遣り取りするＩ／Ｏユニットなどを含む。

同様に、ラインＢを担当する制御ユニット１００についても同様に、通信ポート１４４（図２のネットワークコントローラ１１８）を介して、１または複数のフィールドデバイス５００と接続されている。

ここで、コントローラシステム１の機能面に着目すると、制御ユニット１００は、標準制御に係る制御演算を実行する処理実行部である制御エンジン１５０と、外部装置との間でデータを遣り取りする情報エンジン１６０とを含む。セキュリティユニット２００は、後述するようなセキュリティ機能を実現するためのセキュリティエンジン２５０を含む。セーフティユニット３００は、セーフティ制御に係る制御演算を実行する処理実行部であるセーフティエンジン３５０を含む。

各エンジンは、各ユニットのプロセッサなどの任意のハードウェア要素または各種プログラムなどの任意のソフトウェア要素、あるいは、それら要素の組合せによって実現される。各エンジンは任意の形態で実装できる。

さらに、コントローラシステム１は、エンジン同士の遣り取りを仲介するブローカー１７０を含む。ブローカー１７０の実体は、制御ユニット１００およびセキュリティユニット２００の一方または両方に配置してもよい。

制御エンジン１５０は、制御対象を制御するための制御演算の実行に必要な変数テーブルおよびファンクションブロック（ＦＢ）などを保持している。変数テーブルに格納される各変数は、Ｉ／Ｏリフレッシュ処理により、フィールドデバイス５００から取得された値で周期的に収集されるとともに、フィールドデバイス５００へ各値が周期的に反映される。制御エンジン１５０での制御演算のログはログデータベース１８０に格納されてもよい。

情報エンジン１６０は、制御ユニット１００が保持するデータ（変数テーブルで保持される変数値）に対して任意の情報処理を実行する。典型的には、情報エンジン１６０は、制御ユニット１００が保持するデータを周期的にデータベース９００などへ送信する処理を含む。このようなデータの送信には、ＳＱＬなどが用いられる。

セキュリティエンジン２５０は、コントローラシステム１に発生する不正侵入の検知、検知された不正侵入に応じた処理、インシデントの発生有無判断、発生したインシデントに応じた処理などを実行する。セキュリティエンジン２５０の挙動は、セキュリティ情報２６０として保存される。したがってセキュリティエンジン２５０は、セキュリティに関するインシデントの有無を検知する検知手段に相当する。

セキュリティエンジン２５０は、セキュリティに関する何らかのイベントが発生したこと、あるいは発生しているセキュリティに関するイベントのレベルなどを、インジケータ２２４で通知する。

セーフティエンジン３５０は、コントローラシステム１において何らかの不正侵入が発生したか否かを検知する検知手段に相当する。セーフティエンジン３５０は、制御ユニット１００を介して、セーフティ制御に係る制御演算の実行に必要なセーフティＩ／Ｏ変数を取得および反映する。セーフティエンジン３５０でのセーフティ制御のログはログデータベース３６０に格納されてもよい。

ブローカー１７０は、例えば、セキュリティエンジン２５０が何らかのイベントを検知すると、制御エンジン１５０、情報エンジン１６０およびセーフティエンジン３５０の動作などを変化させる。

＜Ｄ．セキュリティ脅威に対する対策サイクル＞
本実施の形態に従うコントローラシステム１は、設備や機械を正常運転することを妨げる任意のセキュリティ脅威を検知し、必要な対策を実行可能になっている。

本明細書において、「セキュリティ脅威」は、設備や機械を正常運転することを妨げる任意の事象を意味する。ここで、「正常運転」は、システム設計通りおよび生産計画通りに、設備や機械を運転継続できる状態を意味する。なお、システム設計通りおよび生産計画通りに、設備や機械を運転継続するための、設備や機械の立ち上げ、メンテナンス、段取り替えなども付属的な処理も「正常運転」の概念には含まれる。

ＰＬＣを中心とする制御装置においては、典型的には、（１）データベースなどの上位装置からの攻撃、（２）フィールドデバイスからの攻撃、（３）サポート装置を介した攻撃、（４）メモリカードなどの制御装置に装着される記憶媒体を介した攻撃、といった４つの局面からのセキュリティ脅威が考えられる。さらに、制御装置に搭載されているすべての物理ポートは攻撃を受けるセキュリティリスクが存在している。

本実施の形態に従うセキュリティユニット２００は、これらの各局面で生じるセキュリティ脅威あるいはリスクを検知し、必要な対策が実行できるようにするための処理を実行する。

通常、セキュリティ脅威は順次進化するため、セキュリティ脅威に対する対策は継続的に実行する必要がある。このようなセキュリティ脅威に対する継続的な対策について説明する。

図６は、セキュリティ脅威に対する対策サイクルの一例を示す模式図である。図６を参照して、セキュリティ脅威に対する対策サイクルは、主として、（１）開発時の対策（ステップＳ１，Ｓ２，Ｓ９）および（２）運用時の対策（ステップＳ３〜Ｓ８）に大別される。（１）開発時の対策は、主として、制御対象の設備や機械の設計・仕様を決定する段階における対策を意味し、（２）運用時の対策は、主として、制御対象の設備や機械を運転する段階における対策を意味する。

より具体的には、まず、制御対象の設備や機械に対する脅威分析が実行される（ステップＳ１）。ステップＳ１の脅威分析においては、セキュリティ要件定義が決定される。続いて、セキュリティ機能設計が実行される（ステップＳ２）。このセキュリティ機能設計においては、暗号方式、認証方式、アクセス制限などのセキュリティ機能が設計される。

これらのステップＳ１およびＳ２において設計された内容が制御対象の設備や機械に反映された上で、運用が開始される。この時点では、通常は正常運転となる（ステップＳ３）。上述したように、正常運転は、設備や機械の立ち上げ、本稼働、メンテナンス、段取り替えなどの処理を含む。

このような正常運転中において、何らかの不正侵入を検知したとする。すると、セキュリティ脅威１次対応が実行される（ステップＳ４）。

ここで、本明細書において、「不正侵入の検知」あるいは「不正侵入検知」は、何らかのセキュリティ脅威となり得る現象または異常を検知することを意味する。言い換えれば、不正侵入の検知は、通常とは異なる現象または状態の発生を検知することを意味するのみであり、通常インシデントが発生しておらず（但し、インシデントの発生のリスク存在している）、また、通常とは異なる現象または状態が不正なものであるか否かを確実に判断することまではできない。そのため、不正侵入が検知されただけでは、すべての処理やイベントをブロックすることは、生産活動を維持する観点からは好ましくない。

そのため、図６に示されるセキュリティ脅威に対する対策サイクルにおいては、不正侵入が検知されると、１次的な措置として、セキュリティ脅威１次対応が実行される（ステップＳ４）。

セキュリティ脅威１次対応は、インシデント発生のリスクがある状況における１次的な措置であり、インシデント発生への進展を防止できる場合もある。仮にインシデントが発生したとしても、セキュリティ脅威１次対応を実行することで、被害を最小限に抑えることができる。本実施の形態に従うコントローラシステム１においては、事前設定することで、セキュリティ脅威１次対応を自動的に実行するようになっている。

典型的には、セキュリティ脅威１次対応は、継続、縮退、停止の３つに大別できる。
セキュリティ脅威１次対応の「継続」は、不正侵入が検知される直前と同様に稼働を続行することを意味する。但し、セキュリティ脅威をアラームなどで通知することにより、さらなる対応を迅速に取れる状態としておくのが好ましい。

セキュリティ脅威１次対応の「縮退」は、コントローラシステムの部分停止（一部のみ稼働）、性能縮小（性能低下）、機能制限などの、限定的ながら稼働を続行することを意味する。すなわち、「縮退」においては、不正侵入が検知される直前の稼働に比較して、ハード面あるいはソフト面で何らかの制限を受けながらも稼働自体は継続する。

セキュリティ脅威１次対応の「縮退」は、一般的な縮退運転（フォールバック）も含み得る。このような一般的な縮退運転は、システムの機能や性能を部分的に停止させた状態で稼働を維持することを意味する。縮退運転に切り替えた後には、利用できる機能が最低限に抑制され、あるいは、応答速度が低下するといった状態になることが多い。したがって「縮退」は、制御ユニット１００の制御動作を制限すること、制御対象の動作を制限すること、のいずれであってもよい。

セキュリティ脅威１次対応の「停止」は、安全にシステムの動作を止めることを意味する。

このようなセキュリティ脅威１次対応が実行された後に、復旧作業が実行される。図５に示すような制御システム１０においては、コントローラシステム１およびコントローラシステム１のフィールド側は、ＯＴ（Operation Technology）部門の作業者が担当し、コントローラシステム１の上位側（第１ネットワーク２および第２ネットワーク４ならびに各ネットワークに接続される装置）については、ＩＴ（Information Technology）部門の作業者が担当する。

より具体的には、ＯＴ部門の作業者は、制御対象の設備や機械に対して必要な処理を行う（現場対応）（ステップＳ５）。具体的には、設備や機械の復旧作業や監視などの作業が実行される。一方、ＩＴ部門の作業者は、発生したセキュリティ脅威に対する脅威解析およびその対策などを行う（ステップＳ６）。ＩＴ部門の作業者による対策は、暫定的なものと、恒久的なものとを含み得る場合もある。

ＯＴ部門およびＩＴ部門の作業者による対策が完了すると、試運転が実行される（ステップＳ７）。この試運転が問題なければ、運用が再開され、正常運転に復帰する（ステップＳ３）。

一方、セキュリティ脅威１次対応を実行したものの（ステップＳ４）、インシデントが発生すると、インシデント対応が実行される（ステップＳ８）。インシデント対応は、インシデントが発生した後の対応であり、現場復旧や影響範囲を限定するために緊急的に行う措置を含む。本実施の形態に従うコントローラシステム１においては、事前設定することで、インシデント対応についても自動的に実行するようになっている。

インシデント対応が実行された後に、ＯＴ部門の作業者は、制御対象の設備や機械に対して必要な処理を行う（現場対応）（ステップＳ５）とともに、ＩＴ部門の作業者は、発生したセキュリティ脅威に対する脅威解析およびその対策などを行う（ステップＳ６）。さらに、インシデントレポートが作成され（ステップＳ９）、その作成されたインシデントレポートの内容に基づいて、脅威分析（ステップＳ１）およびセキュリティ機能設計（ステップＳ２）などが再度実行される。

このように、インシデントが発生した場合には、その発生したインシデントの内容が開発段階までフィードバックされることになる。

なお、インシデントレポートは、インシデントが発生していなくても作成するようにしてもよい。

後述するように、本実施の形態に従うコントローラシステム１は、図６に示すセキュリティ脅威に対する対策サイクルを確実に実行できるような仕組みを提供する。

＜Ｅ．セキュリティ脅威１次対応＞
次に、図６に示されるセキュリティ脅威１次対応（ステップＳ４）について説明する。

（ｅ１：制御システム１０でのセキュリティ脅威１次対応）
まず、制御システム１０に生じる不正侵入（セキュリティ脅威）の検知およびそれに応じたセキュリティ脅威１次対応の一例について説明する。

図７は、本実施の形態に従うコントローラシステム１を含む制御システム１０における不正侵入検知時の対応の一例を示す模式図である。図７には、図５に示す制御システム１０において、ＳＣＡＤＡ装置７００がウィルスに感染して、第１ネットワーク２およびセキュリティユニット２００の通信ポート２４２から攻撃された例を示す。

図７に示す例では、ラインＡを担当するコントローラシステム１に対してのみ攻撃されており、ラインＢを担当する制御ユニット１００に対する攻撃はないものとする。セキュリティユニット２００は、不正侵入を検知すると、その検知した不正侵入のインシデント特性を制御ユニット１００などへ通知する。

本明細書において、「インシデント特性」は、検知された不正侵入（セキュリティ脅威）の属性（例えば、攻撃種類、攻撃特性、攻撃レベル、深刻度、緊急度など）を包含する用語である。セキュリティユニット２００のセキュリティエンジン２５０は、予め定められた検知ロジックに基づいて、検知した不正侵入（セキュリティ脅威）のインシデント特性を決定し、制御ユニット１００などへ出力する。すなわち、セキュリティユニット２００のセキュリティエンジン２５０は、検知機能により検知された不正侵入の属性を示すインシデント特性を制御ユニット１００へ通知する通知手段として機能する。

制御ユニット１００は、セキュリティユニット２００からのインシデント特性に応じた、セキュリティ脅威１次対応および／またはインシデント対応を実行する。すなわち、制御ユニット１００は、セキュリティユニット２００のセキュリティエンジン２５０から通知されたインシデント特性に応じて、制御動作を変更する。

図７には、セキュリティ脅威１次対応が実行される例を示す。具体的には、コンベア上を搬送されるワークをロボットで加工するようなラインＡを想定する。このようなラインＡにおいて、不正侵入が検知されることで、一例として、ワークを加工するロボットを安全に停止させるとともに、コンベア上の仕掛品のワークを倉庫へ退避する処理がセキュリティ脅威１次対応として実行される。

このようなセキュリティ脅威１次対応を実現するにあたって、制御ユニット１００の制御エンジン１５０は、ラインＡについて、ロボットを安全に停止するとともに、コンベア上の仕掛品を倉庫に移動する処理を実行する（ステップＳ４１）。制御エンジン１５０が出力する命令に従って、フィールドデバイス５００のロボットは安全停止（停止）し（ステップＳ４２）、フィールドデバイス５００のコンベアは搬送のスピードを低速に切り替えるとともに、仕掛品を倉庫へ移動させるための特殊仕分け処理を実行（縮退）する（ステップＳ４３）。一方、フィールドデバイス５００のＩ／Ｏユニットは、運転（動作）を継続する（ステップＳ４４）。Ｉ／Ｏユニットが周期的に更新する入出力データは、制御エンジン１５０が適切に処理を実行するために必要になるからである。

また、上述したように、図７に示すＳＣＡＤＡ装置７００からの攻撃では、ラインＢを担当する制御ユニット１００には影響はないので、ラインＢを担当する制御ユニット１００の制御エンジン１５０は運転を継続する（ステップＳ４５）。

また、制御ユニット１００の通信ポート１４２については、生産継続のための最小限の通信のみを許可するようにしてもよい（ステップＳ４６）。すなわち、制御ユニット１００の通信物理ポートの通信を制御するようにしてもよい。なお、制御ユニット１００の通信物理ポートに限らず、何らかの不正侵入（セキュリティ脅威）が検知されると、セキュリティユニット２００および／またはセーフティユニット３００の任意の通信物理ポートの通信を制限するようにしてもよい。

また、制御ユニット１００は、不正侵入（セキュリティ脅威）が検知を知らせるアラームをＨＭＩ８００のインジケータ８２４に表示する（ステップＳ４７）。

さらに、制御ユニット１００は、セキュリティユニット２００からインシデントの発生を受けると、インシデントレポートをＨＭＩ８００に表示してもよい（ステップＳ４８）。

図７に示すように、コントローラシステム１は、不正侵入（セキュリティ脅威）を検知すると、当該検知された不正侵入のインシデント特性に応じたセキュリティ脅威１次対応を実行できる。

（ｅ２：その他の設備／機械でのセキュリティ脅威１次対応）
上述の図７においては、コンベア上のワークに対して任意の物理的作用を与えることが可能なロボットが配置されたラインを制御対象とする制御システム１０において、ＳＣＡＤＡ装置から攻撃を受けた場合のセキュリティ脅威１次対応について例示した。しかしながら、セキュリティ脅威１次対応は、少なくとも、制御対象に含まれる設備や機械、および、インシデント特性に応じて、対応内容を異ならせることが好ましい。

（ｉ）加工機に対するデータ改ざんの攻撃
例えば、ＮＣ（Numerical Control）などによるワークの加工機に対して、加工データ（仕上がり形状などを規定したデータ）が改ざんされたような場合を想定する。この場合、加工機および加工機の周辺設備の制御に関しては、セキュリティ脅威１次対応として停止が採用され、人の安全が優先されることになる。

一方、情報通信処理に関しては、基本的には、通信を遮断して他の設備から隔離する（情報通信処理）とともに、データ改ざんの攻撃を受けた後に加工されたワークを特定する（情報処理）といったセキュリティ脅威１次対応が採用される。

（ｉｉ）充填機に対するＤＤｏＳ攻撃
例えば、缶や瓶などへの液体の充填機（ボトリングマシーン）に対するＤＤｏＳ（Distributed Denial of Service）攻撃を想定する。通常、充填機は高速に充填動作を行っているので、急停止させることは、設備に対するダメージおよび充填中の缶または瓶の後処理といった面で問題が生じ得る。一方で、ＤＤｏＳ攻撃は、外部との通信が影響を受けるだけであり、充填機自体を動作させることは可能である場合が多い。そのため、充填機は正常運転または縮退運転（例えば、搬送速度を緩やかに低下させる）といったセキュリティ脅威１次対応がとられる。

一方、制御ユニット１００における情報通信処理に関しては、基本的には、通信を遮断して他の設備から隔離する（通信処理）とともに、データ改ざんの攻撃を受けた後に加工されたワークを特定する（情報処理）といったセキュリティ脅威１次対応が採用される。

一方、情報通信処理に関しては、情報を受信する処理（すなわち、ＤＤｏＳ攻撃の対象）については遮断し、情報を送信する処理（例えば、上位サーバへの生産情報の送信）については有効化を継続する。

このように、制御対象に含まれる設備や機械、および、インシデント特性に応じて、対応内容を異ならせることが好ましい。

＜Ｆ．インシデントに応じた対応＞
次に、図６に示されるインシデント対応（ステップＳ８）について説明する。

図８は、生産機械および検査装置を含むラインに対する攻撃例を示す模式図である。図８を参照して、例えば、生産機械が製品を生産するとともに、生産機械の下流側に配置された検査装置によって生産機械が生産した製品を検査した上で出荷するようなラインを想定する。

このようなラインに対して、攻撃者は、不良品を市場に流出させることを目論んだとする。このような目論みを実現するために、攻撃者は、不良品を生産するように生産機械を改ざんし、さらに、その不良品を検出できないように検査装置を改ざんする。

このような攻撃の具体的な内容としては、例えば、検査装置に対して、良否判定ロジックを改ざんする。すなわち、検査装置が不良品であると判断しないように、良否判定ロジックを意図的に書き換えるといった攻撃がなされる。

併せて、生産機械に対して、レシピ情報および／または制御ロジックを改ざんする。すなわち、生産機械が不良品を生産するように制御内容を変更するといった攻撃がなされる。

このような攻撃を受けた場合には、インシデントの発生となり、インシデントに応じた対応が必要となる。インシデントに応じた対応についても、インシデント特性に応じてその対応内容を変化させることが好ましい。

本事例において、具体的なインシデントに応じた対応としては、以下のようなものが想定される。

・改ざんされた可能性のある検査装置を使用せずに、別の検査装置に切り替える（検査装置を冗長化しておく、あるいは、別のラインにある安全な検査装置へ製品を流す）
・改ざん前のロジック（良否判定ロジックあるいは制御ロジック）をバックアップしておき、自動的にリストアする（自動的にリストアすることで、エンドユーザが定期的にバックアップをとらなくてもよく、また、安全と判断できる過去のバックアップがどれなのかを特定できる）
・リスクが存在し得る工程の生産を停止する一方で、その他の脅威がない工程については生産を継続する（仕掛品が増加するが、全工程を止める必要はない）
・既に生産された製品の良否判定結果も疑わしいので、正規の倉庫へ保管するのではなく、再度検査を行うことで、そのまま市場へ流通させない（再検査用のラインへ流すようにしてもよいし、人手で再検査してもよい）
上述したように本実施の形態においては、検知された不正侵入（セキュリティ脅威）のインシデント特性を利用できるので、例えば、製品の良否判定が適切に実行されていることが保証できれば、生産ラインを全停止する必要はない。また、再検査の対象となる商品を絞り込むことができれば、全品回収などの被害拡大を回避できる。

＜Ｇ．インシデント特性に応じた対応＞
上述したように、本実施の形態に従うコントローラシステム１においては、セキュリティユニット２００が不正侵入（セキュリティ脅威）を検知すると、その検知された不正侵入（セキュリティ脅威）のインシデント特性を制御ユニット１００などに通知する（図７など参照）。制御ユニット１００およびセーフティユニット３００においては、インシデント特性に基づいて、セキュリティ脅威に対する適切な範囲および内容の対応が可能となる（図６のステップＳ４およびＳ８）。

本実施の形態に従うコントローラシステム１は、検知された不正侵入（セキュリティ脅威）のインシデント特性に応じて、制御ユニット１００および／またはセーフティユニット３００における制御（すなわち、セキュリティ脅威１次対応またはインシデント対応）の内容を異ならせることができる。以下、このようなインシデント特性に応じた制御内容の決定例について説明する。

図９は、本実施の形態に従うコントローラシステム１におけるインシデント特性に応じた設備別の制御動作の一例を示す図である。図１０は、本実施の形態に従うコントローラシステム１におけるインシデント特性に応じた設備別の制御動作の別の一例を示す図である。図１１は、本実施の形態に従うコントローラシステム１におけるインシデント特性に応じた各設備における状態別の制御動作の一例を示す図である。

図９には、インシデント特性として、攻撃の種類あるいは攻撃後の状態（例えば、無作為改ざん、リソース枯渇、ＤＤｏＳ攻撃など）がセキュリティユニット２００から出力される例を示す。セキュリティユニット２００から出力される各インシデント特性に応じた対応が実行されることになる。このようなインシデント特性に応じた対応は、設備や機械毎にさらに細かく設定されてもよい。

インシデント特性に応じた対応としては、設備制御についての対応、および、情報通信についての対応に大別できる。設備制御は、主として、制御ユニット１００の制御エンジン１５０および／またはセーフティユニット３００のセーフティエンジン３５０（いずれも図５参照）が担当する処理を意味し、制御対象の設備や機械の動作についての対応を意味する。情報通信は、主として、制御ユニット１００の情報エンジン１６０が担当する処理を意味し、制御ユニット１００と外部装置との間のデータの遣り取りや、制御ユニット１００内部での情報の取り扱いなどについての対応を意味する。

図９に示す制御動作のうち、「正常運転」は、システム設計通りおよび生産計画通りに、設備や機械を運転継続できる状態を意味する。「縮退」（図中には、「縮退」に「Ａ１」などの識別情報を付加して表現している。）は、コントローラシステム１の部分停止（一部のみ稼働）、性能縮小（性能低下）、機能制限などの、限定的ながら稼働を続行することを意味する。「停止」は、安全に、対象の設備や機械あるいはコントローラシステム１の動作を止めることを意味する。なお、図１０および図１１においても同様である。

図１０には、インシデント特性としては、検知された不正侵入（セキュリティ脅威）のレベル（重篤度あるいは緊急度など）がセキュリティユニット２００から出力される例を示す。各レベルは、検知された攻撃の種類あるいは攻撃後の状態などに基づいて算出される。セキュリティユニット２００から出力される各インシデント特性に応じた対応が実行されることになる。このようなインシデント特性に応じた対応は、設備や機械毎にさらに細かく設定されてもよい。

図１１には、各設備や機械の状態毎に各インシデント特性に応じた対応を設定する例を示す。例えば、設備毎に運転中、メンテナンス中、段取り替え中などの状態を特定するとともに、検知されたインシデント特性と、現在の状態とに基づいて、各設備に対する対応を決定してもよい。

なお、図１１には、設備や機械の状態を例示するが、これに限らず、例えば、ＰＬＣの動作状態（通常運転中、リモートアクセス中、デバッグ中など）に応じて、対応の内容を異ならせてもよい。さらに、各インシデント特性に応じた対応を状態のみに基づいて決定してもよい。すなわち、設備や機械の違いによらず、セキュリティ脅威が検知されたときの状態のみに基づいて対応を決定するようにしてもよい。

また、図１１に示すインシデント特性として、図１０に示すレベルを用いてもよい。
図９〜図１１に示すように、本実施の形態に従うコントローラシステム１においては、セキュリティユニット２００から出力されるインシデント特性に応じて、設備毎および／または状態毎に必要な対応を動的に決定できる。このような対応の内容を動的に決定することで、設備や機械の運転を継続することによる生産性の維持と、セキュリティに対する対処とを柔軟に実行できる。なお、図９〜図１１には、標準制御に関する制御動作を例示するが、セーフティ制御についても同様の制御動作を定義できる。

次に、図９〜図１１に示す「縮退」の一例について説明する。
（１）設備制御の縮退
設備制御の縮退は、範囲、機能、生産性などの面において制限を受けた状態で運転することを意味する。

範囲としては、制御対象となるゾーンを制限することができる。制御対象となるゾーンとしては、例えば、制御装置、制御装置に装着されるモジュール、制御装置に装着されるユニットなどの制御側を制限することができる。あるいは、特定の機械、ライン、フロア、工場全体といった被制御側（制御対象）を制限することができる。

機能としては、コントローラシステム１が提供する処理のうち特定の処理（例えば、情報制御、標準制御、セーフティ制御など）を制限することができる。

生産性としては、安全、安心のために一時的に生産性（例えば、ラインスピード、単位時間あたりの生産数、単位時間あたりの生産量など）を制限することができる。

（２）情報通信の縮退
情報通信の縮退は、範囲、方向、帯域、ＱｏＳ（Quality of Service）、データなどの面において制限を受けた状態で運転することを意味する。

範囲としては、例えば、通信物理ポート、通信論理ポート、ネットワーク離脱などを制限できる。

通信物理ポートを制限する場合には、制御ユニット１００およびセキュリティユニット２００にそれぞれ配置されている通信ポートのうち特定のポート使用を制限することができる。あるいは、コントローラシステム１に実装される通信ポートのうち、上位側あるいはフィールド側のみを有効化してもよい。

通信論理ポートを制限する場合には、利用可能なＴＣＰ／ＵＤＰポートを制限してもよいし、利用可能な通信プロトコルを制限してもよい。さらに、アクセスを受け付けるＭＡＣアドレスやＩＰアドレスを制限してもよい。

方向としては、例えば、各ポートにおいてデータが流れる方向を一方向のみに制限してもよい。例えば、特定のポートについて、データの受信のみ許可、あるいは、データの送信のみ許可といった具合である。このような一方向のデータのみを許可することで、何らかのセキュリティ脅威が検知されたときに、コントローラシステム１からデータが流出することを防止できる。

帯域としては、コントローラシステム１の通信負荷あるいは処理負荷を低減させるために、通信速度を制限（例えば、１Ｇｂｐｓから１００Ｍｂｐｓに変更）してもよい。

ＱｏＳとしては、通過させるパケットの優先度を動的に変化させてもよい。例えば、何らかのセキュリティ脅威が検知された場合には、通過させるパケットの優先度を高く変更してもよい。

データとしては、例えば、ＥｔｈｅｒＣＡＴなどの産業用ネットワークプロトコルにおいては、プロセスデータ通信の有効／無効の切り替えや、出力値の更新を制限（更新停止／ゼロクリア／前回値を保持など）してもよい。

上述したものに限らず、「縮退」は、正常運転に対して任意の制限が加えられた状態での運転を包含し得る。なお、「縮退」は、部分停止と見なすこともでき、「停止」は、特定の機能を全面的に停止することを包含し得るので、「縮退」を拡張した概念と見なすこともできる。

図１２は、本実施の形態に従うコントローラシステム１におけるセキュリティ脅威が検知された場合の処理手順を示すフローチャートである。図１２に示す各ステップは、制御ユニット１００のプロセッサ１０２、セキュリティユニット２００のプロセッサ２０２、およびセーフティユニット３００のプロセッサ３０２がそれぞれプログラムを実行することで実現される。

図１２を参照して、セキュリティユニット２００は、制御ユニット１００で生じる処理、および、ネットワーク上を流れるパケットなどに基づいて、不正侵入が生じているか否かを判断する（ステップＳ１００）。不正侵入が生じていなければ（ステップＳ１００においてＮＯ）、ステップＳ１００の処理が繰り返される。

不正侵入が生じていなければ（ステップＳ１００においてＹＥＳ）、セキュリティユニット２００は、検知した不正侵入（セキュリティ脅威）に対応するインシデント特性を制御ユニット１００へ通知する（ステップＳ１０２）。制御ユニット１００は、セキュリティユニット２００からのインシデント特性の通知を受けて、予め定められた動作の変更に係る条件に合致するか否かを判断する（ステップＳ１０４）。

予め定められた動作の変更に係る条件に合致すれば（ステップＳ１０４においてＹＥＳ）、制御ユニット１００は、当該合致した条件に対応する対象の設備や機械の動作を変更する（ステップＳ１０６）。

これに対して、予め定められた動作の変更に係る条件に合致しなければ（ステップＳ１０４においてＮＯ）、ステップＳ１０６の処理はスキップされる。そして、ステップＳ１００以下の処理が繰り返される。

＜Ｈ．セキュリティ情報の可視化・ユーザ支援＞
通常、セキュリティ事象は目に見えないので、特に、ＯＴ部門の作業者にとってみれば、現在どのようなステータスであるのかを把握することが難しい。そのため、本実施の形態に従うコントローラシステム１は、セキュリティ情報を可視化するとともに、不正侵入が検知されたときなどのユーザ支援を提供する。

（ｈ１：ステータス）
セキュリティユニット２００が何らかの不正侵入を検知した場合には、セキュリティユニット２００の表面に配置されたインジケータ２２４、制御ユニット１００の表面に配置されたインジケータ１２４、ＨＭＩ８００のインジケータ８２４（いずれも図５参照）などを用いて、ユーザに通知を行うようにしてもよい。この場合、不正侵入の検知前後で、点灯色変更、点灯開始、点滅開始などの任意の表示態様の変化を利用すればよい。さらに、表示だけではなく、音や音声メッセージなどを用いてもよい。

セキュリティ脅威は、セキュリティリスクに応じて定量化することもできる。本明細書において、「セキュリティリスク」は、不正侵入として検知される確率あるいは度合いを定量的に示す用語である。「セキュリティリスク」は、例えば、無作為改ざんを行うためのパケットの到来頻度やＤＤｏＳ攻撃の度合いなどにより算出できる。このような定量化されたセキュリティリスクが得られる場合には、制御ユニット１００の表面に配置されたインジケータ１２４、ＨＭＩ８００のインジケータ８２４には、算出される度合いを表示するようにしてもよい。

図１３は、本実施の形態に従うコントローラシステム１に採用されるインジケータの一例を示す模式図である。図１３には、定量化されたセキュリティリスクを表示する場合の構成例を示す。たとえばインジケータ２２４において、３つのＬＥＤが配置されている。３つのＬＥＤの点灯色は、それぞれ緑色、黄色、赤色である。リスクレベルが低いときには緑色ＬＥＤのみが点灯する。リスクレベルが中であるときには、緑色ＬＥＤおよび黄色ＬＥＤが点灯する。リスクレベルが高であるときには、緑色ＬＥＤ、黄色ＬＥＤおよび、赤色ＬＥＤが点灯する。

このように、セキュリティユニット２００は、検知手段であるセキュリティエンジン２５０による検知動作から算出されるセキュリティリスクをユーザに提示する提示手段を有している。上述したようなインジケータ２２４を配置することで、専門知識のない作業者であっても、現在のセキュリティリスクのステータスを容易に把握できる。なお、図１３に示すようなインジケータに限らず、セキュリティリスクを提示できる形態であれば、どのようなインジケータを採用してもよい。

＜Ｉ．システムの復旧時における課題＞
セキュリティリスクが発生する確率は小さいほど好ましい。しかしその一方で、ユーザにとっては、セキュリティリスクが発生したときに適切な処理を行う機会が少なくなる。このために、インジケータ２２４によって示される事象（セキュリティリスクの発生）を作業者が正確に把握できない可能性も生じうる。たとえばユーザが、黄色ＬＥＤの点灯を、コントローラシステム１の動作の異常（たとえばプログラムの暴走）と判断することも想定される。このような場合には、ユーザがシステムを誤って再起動（リセット）する可能性がある。

図１４は、インシデント発生後の制御システム１０の復旧において想定される事態を示した図である。制御システム１０の動作時に、セキュリティインシデントが発生する。あるいはセキュリティユニット２００においてセキュリティリスクが検知される（ステップＳ１０１）。

この場合、ＦＡ（Factory Automation）装置／制御システム１０が縮退動作を行う、あるいは一時的に停止する（ステップＳ１０２）。ＩＴ部門のエンジニアは、セキュリティインシデントの解消のために復旧および対策作業を実行する（ステップＳ１０３）。

一方、ＯＴ部門のエンジニアは、制御システム１０（生産システム）を再稼働する。しかし、インシデントが解消されていない状態では、制御システム１０が誤って再稼働されることになる（ステップＳ１０４）。この場合、セキュリティ被害が拡大し、たとえば情報の漏洩、装置の故障等が生じる可能性がある（ステップＳ１０５）。

あるいは、制御システム１０が再稼働した後に、再びセキュリティインシデント（またはセキュリティリスク）が検知される（ステップＳ１０６）。この場合、ＦＡ装置／制御システム１０が再び縮退または一時的に停止する（ステップＳ１０２）。このように、ステップＳ１０２〜Ｓ１０６の処理が何度も繰り返される可能性がある。

図１５は、図１４に示した事態に対応するシステムの状態を示した図である。図１５を参照して、制御ユニット１００（図１５では「ＰＬＣ」と表記）は、制御モードとして、「Ｒｕｎ」モードおよび「Ｓａｆｅ」モードを有する。Ｒｕｎモードは正常モードである。Ｓａｆｅモードは縮退モードであり、コントローラシステム１の限定的な動作を実行するためのモードである。

セキュリティユニット２００のセキュリティエンジン２５０は、セキュリティリスクに応じたセキュリティレベル（Ｌｖ）として、「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｒｅｄ」の３つのレベルを検知する。「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｒｅｄ」は、インジケータ２２４のＬＥＤの点灯色にも対応する。Ｇｒｅｅｎレベルはセキュリティが安全なときのレベルである。Ｙｅｌｌｏｗレベルは、インシデントが検知されたときのレベルである。Ｒｅｄレベルはインシデントが発生したときのレベルである。

コントローラシステムの正常稼働時には、制御モードはＲｕｎモードであり、セキュリティレベルはＧｒｅｅｎレベルである。インシデントが検知されると、セキュリティレベルが「Ｇｒｅｅｎ」から「Ｙｅｌｌｏｗ」へと変化するとともに、制御モードがＲｕｎモードからＳａｆｅモードに遷移する。

この状態で、制御ユニット１００を復旧させたとする。制御モードはＳａｆｅモードからＲｕｎモードへと復帰する。しかし、セキュリティユニット２００で検知されるセキュリティレベルは「Ｒｅｄ」である。すなわちインシデントは解除されていない。インシデントが解除されないまま制御ユニット１００に通常の動作を行わせることによって、セキュリティ被害が拡大する可能性がある。

あるいは、制御ユニット１００を一旦復旧させることにより、制御モードをＲｕｎモードに戻しても、インシデントが解除されていないため、制御モードがＳａｆｅモードへと移行する。インシデントが解除されない間は、制御ユニット１００を復旧させてもインシデントの検知によって、制御モードは一旦Ｒｕｎモードに戻るものの、Ｓａｆｅモードへと移行する。インシデントが解除されていないにもかかわらず、制御ユニット１００の復旧を繰り返すことにより、制御モードの遷移に無限ループが生じることも起こり得る。

＜Ｊ．インシデント解除のチェック＞
本実施の形態では、制御ユニットの再稼働処理のフローの中に、インシデント解除のチェックロジックが含まれる。これによりコントローラシステムの誤った再稼働を防止できるので、セキュリティ被害（２次被害）の拡大を防ぐことができる。

図１６は、本実施の形態に係る再稼働処理のフローを示すための図である。インシデントを検知したときに、制御ユニット１００の制御モードはＲｕｎモードからＳａｆｅモードに遷移する。この点については既に説明したのでここでは説明を繰り返さない。本実施の形態では、インシデントが解除されるまで、制御モードはＲｕｎモードに遷移することができない。したがって制御モードはＳａｆｅモードのままに保たれる。

インシデントが解除された後、セキュリティレベルは「Ｇｒｅｅｎ」レベルになる。この状態で制御ユニット１００のみを復旧させる。たとえば制御ユニット１００は再起動処理を実行する。制御モードがＳａｆｅモードからＲｕｎモードへと遷移して、制御システムが正常に稼働する。セキュリティレベルがＧｒｅｅｎ以外のレベル（ＹｅｌｌｏｗまたはＲｅｄ）である状態で、制御ユニット１００を再起動（リセット）しても、制御ユニット１００の制御モードはＳａｆｅモードである。

本実施の形態では、制御モードをＳａｆｅモードからＲｕｎモードへと復帰させる際に、セキュリティレベルがチェックされる。セキュリティレベルがＧｒｅｅｎであれば、制御モードをＳａｆｅモードからＲｕｎモードに復帰することができる。逆に、インシデントの検知によって、セキュリティレベルがＧｒｅｅｎ以外のレベル（ＹｅｌｌｏｗまたはＲｅｄ）である場合、制御モードはＳａｆｅモードに保たれる。

コントローラシステム１の再起動のために、コントローラシステム１の全体の電源を一旦切って、その後にコントローラシステム１に電源を再投入することも考えられる。しかしセキュリティユニット２００は、ステータスあるいはセキュリティレベルに関する情報を不揮発的に保持する。したがって、コントローラシステム１に電源を再投入した場合、セキュリティユニット２００に記憶された情報に基づいて、セキュリティユニット２００は、セキュリティレベルを設定する。これにより、コントローラシステム１の電源切断前のセキュリティユニット２００のステータスが保持される。ステータスあるいはセキュリティレベルに関する情報は、図５に示すセキュリティ情報２６０に含まれる情報であってもよい。

制御ユニット１００は、セキュリティユニット２００のステータスに基づいて、制御モードを設定する。したがって、制御モードは電源切断前のモードに設定される。コントローラシステム１への電源再投入によるリセットが実行されても、インシデントが解除されるまでは、制御ユニット１００の制御モードをＳａｆｅモードに維持することができる。

図１７は、本実施の形態における制御システムの再稼働処理のフローを説明するための第１の図である。図１７には、インシデント解除前の制御システムの処理フローが示されている。

図１７に示すように、インシデントの検知により、制御ユニット１００の制御モードはＳａｆｅモードに移行されている。正常稼働のために、Ｒｕｎモード変更リクエストが制御ユニット１００に入力される（ステップＳ１１）。制御ランタイム部１１は、セキュリティユニット２００に対して、インシデントの確認を行う（ステップＳ１２）。セキュリティユニット２００の制御ランタイム部２１は、セキュリティエンジン２５０からインシデント情報を取得する（ステップＳ１３）。このインシデント情報は、Ｒｕｎモードへの変更が不可である（「ＮＧ」）という情報でもよく、セキュリティレベルを示す情報（セキュリティレベルが「Ｙｅｌｌｏｗ」）という情報でもよい。制御ランタイム部２１は、取得したインシデント情報を、制御ユニット１００に送信する（ステップＳ１４）。インシデント情報は、図５に示すセキュリティ情報２６０に含まれる情報であってもよい。

制御ユニット１００の制御ランタイム部１１は、インシデント情報を制御ランタイム部２１から取得する。制御ランタイム部１１は、そのインシデント情報に基づき、Ｒｕｎモード変更リクエストに対する応答を出力する（ステップＳ１５）。この応答は、Ｒｕｎモードへの変更が不可である（「ＮＧ」）という情報、あるいは、エラーの情報を含むことができる。

図１８は、本実施の形態における制御システムの再稼働処理のフローを説明するための第２の図である。図１８には、インシデント解除後の制御システムの処理フローが示されている。

まず、インシデントが解除されたことを示す情報がセキュリティユニット２００に入力される（ステップＳ２０）。このときの制御ユニット１００の制御モードはＳａｆｅモードである。

Ｒｕｎモード変更リクエストが制御ユニット１００に入力される（ステップＳ２１）。制御ランタイム部１１は、セキュリティユニット２００に対して、インシデントの確認を行う（ステップＳ２２）。セキュリティユニット２００の制御ランタイム部２１は、セキュリティエンジン２５０からインシデント情報を取得する（ステップＳ２３）。このインシデント情報は、Ｒｕｎモードへの変更が可能である（「ＯＫ」）という情報でもよく、セキュリティレベルを示す情報（セキュリティレベルが「Ｇｒｅｅｎ」）という情報でもよい。制御ランタイム部２１は、取得したインシデント情報を、制御ユニット１００に送信する（ステップＳ２４）。

制御ユニット１００の制御ランタイム部１１は、インシデント情報を制御ランタイム部２１から取得する。制御ランタイム部１１は、そのインシデント情報に基づき、制御モードをＳａｆｅモードからＲｕｎモードに変更する（ステップＳ２５）。さらに、制御ランタイム部１１は、変更リクエストに対する応答を出力する（ステップＳ２６）。この応答は、Ｒｕｎモードへの変更が可能である（「ＯＫ」）という情報を含むことができる。

このように、制御ユニット１００は、制御ユニットの再起動処理の際に、セキュリティユニット２００からのインシデント情報に基づいて、制御モードを決定する。セキュリティに関するインシデントが解除されていない場合には、制御ユニット１００を再起動した後も制御モードは縮退モードに設定される。インシデントが解除されていないにもかかわらず、制御ユニットの再起動処理によって制御モードが正常モードに設定されることを防止できる。

図１８に示したフローでは、制御ユニット１００は、インシデントが解除されたことを意味するインシデント情報に基づいて、制御モードをＲｕｎモードに変更する。しかし管理者権限を持つユーザ（セキュリティ管理者等）からの命令を上記のインシデント情報に優先させてもよい。たとえばセキュリティレベルがＹｅｌｌｏｗであってもアドミニストレータが復帰可能と判断した場合、制御ユニット１００は、アドミニストレータからの入力を受け付けることにより、制御モードをＲｕｎモードに復帰させてもよい。たとえば、セキュリティユニット２００の誤動作（誤った検知等）によりセキュリティレベルを変更した場合に、制御ユニット１００の制御モードを縮退モードから制御モードに戻すことができる。また、インシデントが解除されたことが明らかな場合に、コントローラシステム１を早期に復旧させることができる。

以上のように、本実施の形態によれば、制御ユニットを縮退モードから正常モードへと切り替える際に、インシデントが解除されているかどうかを判断する。インシデントが解除されていない場合、制御モードを縮退モードから正常モードへと遷移することはできない。これにより制御システムの誤った再稼働（インシデントが解除されないまま、制御ユニットを通常時と同様に稼働させること）を防止できるので、セキュリティ被害（２次被害）の拡大を防ぐことができる。したがって、制御装置および制御システムのネットワーク化あるいはインテリジェント化に伴って生じ得る脅威に対する保護の確実性を高めることができる。

＜Ｋ．付記＞
以上説明したように、本実施形態は以下に列挙する開示を含む。

１．コントローラシステム（１）であって、
制御対象を制御するための制御動作を実行する制御ユニット（１００）と、
前記制御ユニット（１００）に接続され、前記コントローラシステム（１）に対するセキュリティ機能を担当するセキュリティユニット（２００）とを備え、
前記制御ユニット（１００）は、前記制御動作に関する制御モードとして、正常モードと、前記コントローラシステム（１）の限定的な動作を実行するための縮退モードとを有し、前記正常モードと前記縮退モードとは相互に遷移可能であり、
前記セキュリティユニット（２００）は、
前記コントローラシステム（１）における、セキュリティに関するインシデントの有無を検知する検知手段（２５０）を含み、
前記制御ユニット（１００）は、前記検知手段（２５０）により前記インシデントが検知された場合には、前記制御モードを前記縮退モードに遷移させて、前記インシデントの解除が前記検知手段（２５０）によって検知されるまで前記制御モードを前記縮退モードに保つ、コントローラシステム（１）。

２．前記制御ユニット（１００）は、前記検知手段（２５０）から前記インシデントの検知に関するインシデント情報を取得し、
前記インシデント情報が前記インシデントの解除を示す場合には、前記制御ユニット（１００）は、前記縮退モードから前記正常モードへ前記制御モードを変更し、
前記インシデント情報が前記インシデントの継続を示す場合には、前記制御ユニット（１００）は、前記制御モードを前記縮退モードに設定する、１．に記載のコントローラシステム（１）。

３．前記制御ユニット（１００）は、前記制御ユニット（１００）の再起動処理を実行する場合に、前記インシデント情報に基づいて、前記制御モードを決定する、２．に記載のコントローラシステム（１）。

４．前記セキュリティユニット（２００）は、前記インシデントの検知に関する情報を不揮発的に記憶して、
前記コントローラシステム（１）への電源再投入による前記コントローラシステム（１）の再起動時に、前記セキュリティユニット（２００）は、前記セキュリティユニット（２００）に記憶された前記情報に基づいて、前記セキュリティユニット（２００）のステータスを復帰させ、
前記制御ユニット（１００）は、前記セキュリティユニット（２００）の前記ステータスに基づいて、前記制御モードを設定する、１．から３．のいずれかに記載のコントローラシステム（１）。

５．前記セキュリティユニット（２００）は、管理者権限を持つユーザからの操作を前記インシデント情報に優先させて、前記インシデントの検知に関する前記セキュリティユニット（２００）のステータスを変更する、１．から４．のいずれかに記載のコントローラシステム（１）。

６．前記縮退モードにおいて、前記制御ユニット（１００）は、前記制御動作を制限する、１．から５．のいずれか１項に記載のコントローラシステム（１）。

７．前記縮退モードにおいて、前記制御ユニット（１００）は、前記制御対象の動作を制限する、１．から５．のいずれかに記載のコントローラシステム（１）。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ コントローラシステム、２ 第１ネットワーク、４ 第２ネットワーク、１０ 制御システム、１１，２１ 制御ランタイム部、１００ 制御ユニット、１０２，２０２，３０２ プロセッサ、１０４，２０４，３０４ チップセット、１０６，２０６，３０６ 主記憶装置、１０８，２０８，３０８ 二次記憶装置、１１０，２１０ 通信コントローラ、１１２，２１２ ＵＳＢコントローラ、１１４，２１４，３１４ メモリカードインターフェイス、１１５，２１５，３１５ メモリカード、１１６，１１８，１２０，２１６，２１８ ネットワークコントローラ、１２２，３２２ 内部バスコントローラ、１２４，２２４，３２４，８２４ インジケータ、１４２，１４４，２４２ 通信ポート、１５０ 制御エンジン、１６０ 情報エンジン、１７０ ブローカー、１８０，３６０ ログデータベース、２００ セキュリティユニット、２５０ セキュリティエンジン、２６０ セキュリティ情報、３００ セーフティユニット、３５０ セーフティエンジン、４００ 機能ユニット、４５０ 電源ユニット、５００ フィールドデバイス、６００ サポート装置、７００ ＳＣＡＤＡ装置、８００ ＨＭＩ、９００ データベース、Ｓ１〜Ｓ１０６ ステップ。

Claims (7)

1. コントローラシステムであって、
   制御対象を制御するための制御動作を実行する制御ユニットと、
   前記制御ユニットに接続され、前記コントローラシステムに対するセキュリティ機能を担当するセキュリティユニットとを備え、
   前記制御ユニットは、前記制御動作に関する制御モードとして、正常モードと、前記コントローラシステムの限定的な動作を実行するための縮退モードとを有し、前記正常モードと前記縮退モードとは相互に遷移可能であり、
   前記セキュリティユニットは、
   前記コントローラシステムにおける、セキュリティに関するインシデントの有無を検知する検知手段を含み、
   前記制御ユニットは、前記検知手段により前記インシデントが検知された場合には、前記制御モードを前記縮退モードに遷移させて、前記インシデントの解除が前記検知手段によって検知されるまで前記制御モードを前記縮退モードに保つ、コントローラシステム。
2. 前記制御ユニットは、前記検知手段から前記インシデントの検知に関するインシデント情報を取得し、
   前記インシデント情報が前記インシデントの解除を示す場合には、前記制御ユニットは、前記縮退モードから前記正常モードへ前記制御モードを変更し、
   前記インシデント情報が前記インシデントの継続を示す場合には、前記制御ユニットは、前記制御モードを前記縮退モードに設定する、請求項１に記載のコントローラシステム。
3. 前記制御ユニットは、前記制御ユニットの再起動処理を実行する場合に、前記インシデント情報に基づいて、前記制御モードを決定する、請求項２に記載のコントローラシステム。
4. 前記セキュリティユニットは、前記インシデントの検知に関する情報を不揮発的に記憶して、
   前記コントローラシステムへの電源再投入による前記コントローラシステムの再起動時に、前記セキュリティユニットは、前記セキュリティユニットに記憶された前記情報に基づいて、前記セキュリティユニットのステータスを復帰させ、
   前記制御ユニットは、前記セキュリティユニットの前記ステータスに基づいて、前記制御モードを設定する、請求項１から請求項３のいずれか１項に記載のコントローラシステム。
5. 前記セキュリティユニットは、管理者権限を持つユーザからの操作を前記インシデント情報に優先させて、前記インシデントの検知に関する前記セキュリティユニットのステータスを変更する、請求項１から請求項４のいずれか１項に記載のコントローラシステム。
6. 前記縮退モードにおいて、前記制御ユニットは、前記制御動作を制限する、請求項１から請求項５のいずれか１項に記載のコントローラシステム。
7. 前記縮退モードにおいて、前記制御ユニットは、前記制御対象の動作を制限する、請求項１から請求項５のいずれか１項に記載のコントローラシステム。

Images