特開 2022-174857 コントローラ

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022174857

(43)【公開日】2022-11-25

(54)【発明の名称】コントローラ

(51)【国際特許分類】

   G06F 9/48 20060101AFI20221117BHJP

   G06F 9/44 20180101ALI20221117BHJP

   G06F 9/455 20060101ALI20221117BHJP

【ＦＩ】

G06F9/48 370

G06F9/44

G06F9/455 150

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2021080863

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

(71)【出願人】

【識別番号】000006666

【氏名又は名称】アズビル株式会社

(74)【代理人】

【識別番号】110003166

【氏名又は名称】弁理士法人山王内外特許事務所

(72)【発明者】

【氏名】新海 庸平

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AC01

5B376EA17

(57)【要約】

【課題】 標準機能プログラムと制御プログラムとの相互干渉を抑制する。
【解決手段】コントローラ２は、第１のプログラム（標準機能プログラム２１３）が実行される実行環境２１と、標準機能プログラム２１３に記述されている機能以外の機能を記述した第２のプログラム（制御プログラム２３３）が実行される仮想環境２３と、を備え、仮想環境２３で利用可能なリソースは、自機が備えるリソースのうちの一部に制限されている。
【選択図】図２

【特許請求の範囲】

【請求項1】

第１のプログラムが実行される実行環境と、
前記第１のプログラムに記述されている機能以外の機能を記述した第２のプログラムが実行される仮想環境と、を備え、
前記仮想環境で利用可能なリソースは、自機が備えるリソースのうちの一部に制限されていることを特徴とするコントローラ。

【請求項2】

前記実行環境は、
第１のフレームワークと、
前記第１のフレームワーク上で動作し、前記第１のプログラムと前記仮想環境で実行される第２のプログラムとを連携して動作させる第２のフレームワークと、を有することを特徴とする請求項１記載のコントローラ。

【請求項3】

前記第２のフレームワークは、
前記仮想環境で実行される第２のプログラムに異常が発生した際、当該異常が発生した第２のプログラムを把握可能であり、当該異常の発生を把握した第２のプログラムを前記連携の対象から除外することを特徴とする請求項２に記載のコントローラ。

【請求項4】

前記第２のフレームワークは、前記第１のフレームワークと連携して動作し、
前記実行環境は、当該実行環境において使用されるデータを記録した、前記第１のフレームワークによりアクセス可能なデータベースを有し、
前記第２のプログラムは、前記第２のフレームワーク及び前記第１のフレームワークを経由することにより、前記データベースにアクセス可能であることを特徴とする請求項２又は請求項３に記載のコントローラ。

【請求項5】

前記第１のプログラムは、監視システムにより標準的に提供される標準機能を記述した標準機能プログラムであり、
前記第２のプログラムは、前記標準機能プログラムに記述されている標準機能以外の特定の機能を記述した制御プログラムであることを特徴とする請求項１から請求項４のうちいずれか１項に記載のコントローラ。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、インストールされたプログラムを実行するコントローラに関する。

【背景技術】

【0002】

一般に、コントローラには、種々の機能を実現するために作成されたプログラムがインストールされる。コントローラは、インストールされたプログラムを実行することにより、当該プログラムの記述内容に沿った種々の機能が実現される。

【0003】

コントローラにインストールされるプログラムとしては、例えば所定の機能を記述したプログラム（以下、第１のプログラムという）と、第１のプログラムに記述されている機能以外の機能を記述したプログラム（以下、第２のプログラムという）とがある。第２のプログラムは、例えば第１のプログラムを実行するだけでは実現困難な機能を記述したプログラムであり、第１のプログラムとは別に作成され、第１のプログラムがインストールされたコントローラに対して追加的にインストールされる。

【0004】

ところが、従来のコントローラでは、上述の第１のプログラムと、追加的にインストールされた第２のプログラムとが、当該コントローラが備える同一のメモリに展開されて実行される設計仕様となっている。そのため、例えば第１のプログラムを機能拡張すると第２のプログラムに影響が発生し、第２のプログラムが動作しなくなるおそれがあった。一方で、第２のプログラムで障害が発生すると、コントローラが異常な状態になり、第１のプログラムに影響を及ぼす懸念もあった。

【0005】

そこで、コントローラでは、第１のプログラムと第２のプログラムとがインストールされた場合、これらのプログラムが互いに影響し合わない設計仕様とすることが要求されている。具体的には、（ａ）第２のプログラムが異常な状態になっても、第１のプログラムの実行は継続できること、（ｂ）第２のプログラムの負荷が高くなっても、第１のプログラムに影響を及ぼさないこと、（ｃ）第２のプログラムを機能拡張しても、第１のプログラムに影響しないこと、及び（ｄ）コントローラがバージョンアップしても、第２のプログラムは影響を受けないこと（第１のプログラムを機能拡張しても、第２のプログラムは正常に動作できること）等の要求を満たす必要がある。

【0006】

このような要求を満たす可能性のある技術として、仮想化技術がある。仮想化技術は、１台のコンピュータが複数のコンピュータのように振る舞える技術である。その一例として、例えば特許文献１には、仮想化技術を空調制御システムに応用した例が開示されている。この特許文献１では、室内機を制御する室内機制御部、及び室外機を制御する室外機制御部が、仮想化された制御部として制御装置に搭載される。そして、室内機制御部及び室外機制御部は、共通バスを介してセンサ類等から情報を取得し、それぞれの制御プログラムを実行することにより、室内機及び室外機を構成する各種機器の制御指令を生成する。このように、室内機制御部及び室外機制御部を室内機及び室外機とは独立して存在させることで、室内機及び室外機に高度なプログラムを搭載する必要がなくなり、室外機及び室内機の交換も容易に行うことができる。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】特開２０１５－１４１０１４

【発明の概要】

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

【0008】

しかしながら、特許文献１では、室内機制御部及び室外機制御部により実行される制御プログラムが上述の第１のプログラム又は第２のプログラムのいずれか一方に相当するとした場合、もう一方のプログラムが実行されるのかは必ずしも明確でない。また、仮にもう一方のプログラムに相当するプログラムが実行されるとしても、その主体は上述の室内機制御部及び室外機制御部であることが想定される。その場合、これらのプログラムは、室内機制御部及び室外機制御部が参照可能な同一のメモリに展開されることが想定される。

【0009】

したがって、上記特許文献１の技術をコントローラに転用しても、上述した（ａ）～（ｄ）の要求のうち、特に第１のプログラム及び第２のプログラムの実行時における要求、すなわち（ａ）第２のプログラムが異常な状態になっても、第１のプログラムの実行は継続できること、及び（ｂ）第２のプログラムの負荷が高くなっても、第１のプログラムに影響を及ぼさないこと、という要求を満たすのは依然として困難であることが想定される。

【0010】

この発明は、上記のような課題を解決するためになされたもので、第１のプログラムと第２のプログラムとの相互干渉を抑制可能なコントローラを提供することを目的とする。

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

【0011】

この発明に係るコントローラは、第１のプログラムが実行される実行環境と、第１のプログラムに記述されている機能以外の機能を記述した第２のプログラムが実行される仮想環境と、を備え、仮想環境で利用可能なリソースは、自機が備えるリソースのうちの一部に制限されていることを特徴とする。

【発明の効果】

【0012】

この発明によれば、上記のように構成したので、第１のプログラムと第２のプログラムとの相互干渉を抑制可能となる。

【図面の簡単な説明】

【0013】

【図1】実施の形態１に係るコントローラを含む監視システムの構成例を示す図である。

【図2】実施の形態１に係るコントローラの構成例を示す図である。

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

【0014】

以下、この発明の実施の形態について図面を参照しながら詳細に説明する。
実施の形態１．
図１は実施の形態１に係るコントローラを含む監視システムの構成例を示す図である。以下では、実施の形態１に係るコントローラが監視システムに適用された例を説明する。

【0015】

監視システムは、図１に示すように、１つ以上の監視対象機器１（以下、監視ポイント１という。）、１つ以上のコントローラ２、及び監視装置３を備えている。監視ポイント１は、通信線を介してコントローラ２に接続されている。また、コントローラ２は、通信線を介して監視装置３に接続されている。図１では、１つの監視ポイント１及び１つのコントローラ２を示している。

【0016】

監視ポイント１は、監視システムにおいて監視の対象となる機器である。監視ポイント１は、例えば温度センサ及び湿度センサなどの各種センサ、空調機器、並びに照明機器等で構成される。

【0017】

コントローラ２は、対象とする監視ポイント１の監視及び制御を行う。コントローラ２には、上述の第１のプログラムと第２のプログラムとがインストールされており、コントローラ２はこれらのプログラムを実行することで、監視ポイント１の監視及び制御を行う。例えば、監視ポイント１が温度センサである場合、コントローラ２は、温度センサからのデータを受信し、当該データが示す温度を取得する。また、監視ポイント１が湿度センサである場合、コントローラ２は、湿度センサからのデータを受信し、当該データが示す湿度を取得する。そして、コントローラ２は、ＢＡＣｎｅｔ（Ｂｕｉｌｄｉｎｇ Ａｕｔｏｍａｔｉｏｎ ａｎｄ Ｃｏｎｔｒｏｌ Ｎｅｔｗｏｒｋ）等の通信により、例えば監視装置３からの取得要求に応じて、監視ポイント１から取得した温度又は湿度等を示すデータを当該監視装置３に送信する。コントローラ２の具体的な構成例については後述する。

【0018】

なお、ここでは説明を分かりやすくするため、上述の第１のプログラムが「標準機能プログラム」であり、第２のプログラムが「制御プログラム」である場合を例示して説明する。標準機能プログラムは、監視システムが導入される建物の多くで使用される機能（以下、標準機能という）を実現するためのプログラムである。標準機能の例としては、例えばスケジュール制御機能、最適起動停止制御機能、及び電力デマンド制御機能がある。

【0019】

スケジュール制御機能は、あらかじめ設定したスケジュールに従って、設定値を出力したり発停動作を監視ポイントへ指示する機能である。また、最適起動停止制御機能は、空調関連の監視ポイントを最適な時間だけ前倒しして起動及び停止する機能である。例えば、利用者が部屋に到着する前にあらかじめ空調機を起動させることで、利用者が部屋に到着したときに最適な室内環境を提供する。また、例えば利用者が部屋から退出する少し前に空調機を停止させることで、不要なエネルギーの消費を抑制する。また、電力デマンド制御機能は、消費電力を予測し、目標値以内に消費電力を抑えるように空調機や照明などの監視ポイントを制御する機能である。これらの機能を実現するプログラムは、監視システムにおいて使用される頻度が比較的高いため、例えば標準機能プログラムとして用意され、コントローラ２にインストールされる。

【0020】

一方、制御プログラムは、例えば監視システムが導入される建物のうち特定の建物で要求される機能であって、コントローラ２が標準機能プログラムを実行するだけでは実現困難な機能を記述したプログラムである。このような制御プログラムは、標準機能プログラムとは別に作成され、コントローラ２に追加的にインストールされる。

【0021】

監視装置３は、コントローラ２を介して、対象とする監視ポイント１の監視及び制御を行う。例えば、監視装置３は、コントローラ２からデータを受信すると、当該受信したデータが示す値（温度又は湿度等）をモニタなどの表示部（不図示）に表示して管理者に提示する。また、監視装置３は、コントローラ２から受信したデータが示す値に異常があれば、警報を発して管理者に通知する。

【0022】

なお、監視ポイント１及び監視装置３としては、既存の監視ポイント及び監視装置を用いることができる。

【0023】

次に、実施の形態１に係るコントローラ２の構成例について、図２を参照しながら説明する。なお、以下では説明を具体的にするため、実施の形態１に係るコントローラ２には、オペレーティングシステム（ＯＳ）として、Ｌｉｎｕｘ（登録商標）が搭載されているものとする。なお、図２においてオペレーティングシステムの記載は省略している。また、実施の形態１では、後述する制御プログラム２５３のプログラム言語はＰｙｔｈｏｎであるものとし、後述する仮想環境２３を構築するための仮想化技術としてＤｏｃｋｅｒが使用されているものとする。

【0024】

図２に示すように、実施の形態１に係るコントローラ２は、オペレーティングシステム上に２つの環境（実行環境２１及び仮想環境２３）が構築されている。

【0025】

（実行環境２１）
実行環境２１は、コントローラ２のメインフレームワーク２１１と、制御プログラムのフレームワーク２１２と、標準機能プログラム２１３（標準機能プログラム２１３Ａ及び２１３Ｂ）と、データベース２１４とを含んで構成されている。なお、データベース２１４には、実行環境２１（例えば標準機能プログラム２１３）により使用される各種データが保存されている。

【0026】

コントローラ２のメインフレームワーク２１１（以下、単にメインフレームワーク２１１という）は、オペレーティングシステム上で動作し、制御プログラムのフレームワーク２１２及び標準機能プログラム２１３を動作（実行）させるための土台として機能するソフトウェアである。メインフレームワーク２１１は、データベース２１４にアクセス可能である。

【0027】

標準機能プログラム２１３（標準機能プログラム２１３Ａ及び２１３Ｂ）は、標準機能を記述したプログラムである。例えば、標準機能プログラム２１３Ａは、標準機能のひとつであるスケジュール制御機能を記述したプログラムであり、標準機能プログラム２１３Ｂは、標準機能のひとつである最適起動停止制御機能を記述したプログラムである。標準機能プログラム２１３は、例えばあらかじめ設定された実行スケジュールにしたがって実行（起動）される。なお、標準機能プログラム２１３は請求項１の「第１のプログラム」を構成する。

【0028】

制御プログラムのフレームワーク２１２（以下、サブフレームワーク２１２という）は、メインフレームワーク２１１上で動作し、標準機能プログラム２１３と、後述の仮想環境２３で実行される制御プログラム２３３とを連携して動作させるソフトウェアである。サブフレームワーク２１２には、制御プログラム２３３を一意に識別するための識別子（例えばプログラムＩＤ）が登録されており、サブフレームワーク２１２は、この識別子を用いて制御プログラム２３３を識別しながら、標準機能プログラム２１３と制御プログラム２３３とを連携して動作させる。

【0029】

例えば、標準機能プログラム２１３によりある部屋の温度及び湿度を示すデータが取得され、制御プログラム２３３がこの取得されたデータを使用したい場合、サブフレームワーク２１２が双方のプログラムの間でそのデータの受け渡しを行う。また、標準機能プログラム２１３の動作結果を受けて制御プログラム２３３を実行させたいような場合にも、サブフレームワーク２１２が両者を連携して動作させる。

【0030】

また、サブフレームワーク２１２は、メインフレームワーク２１１とも連携して動作可能である。したがって、制御プログラム２３３は、サブフレームワーク２１２、及びメインフレームワーク２１１を経由して、データベース２１４にもアクセス可能である。例えばデータベース２１４に保存されているデータを制御プログラム２３３が使用したい場合、制御プログラム２３３は、サブフレームワーク２１２及びメインフレームワーク２１１を経由してデータベース２１４にアクセスする。この場合にも、サブフレームワーク２１２は上述した識別子を用いて制御プログラム２３３を識別する。

【0031】

また、サブフレームワーク２１２は、制御プログラム２３３に何らかの異常が発生した場合、どの制御プログラムで異常が発生したかを把握可能である。例えば、制御プログラム２３３は、何らかの異常が発生した場合、当該異常が発生した旨を通知するメッセージをサブフレームワーク２１２に送信する。サブフレームワーク２１２は、このメッセージを受信することにより、制御プログラム２３３に何らかの異常が発生したことを把握する。この場合、サブフレームワーク２１２は、異常のあった制御プログラム２３３を標準機能プログラム２１３との連携動作の対象から除外して処理を継続する。これにより、制御プログラム２３３に何らかの異常が発生した場合でも、標準機能プログラム２１３は処理を継続することができる。なお、サブフレームワーク２１２は、異常の発生した制御プログラム２３３に関する情報を監視装置３に送信し、監視システムの管理者に異常発生の旨を報知する。

【0032】

（仮想環境２３）
仮想環境２３は、仮想化技術の１つであるＤｏｃｋｅｒを用いてコントローラ２に構築された、制御プログラム２３３を実行するための仮想的な実行環境である。Ｄｏｃｋｅｒでは、コンテナ型仮想化と呼ばれる仕組みで仮想化を実現している。図２の例では、仮想環境２３がコンテナに相当し、この仮想環境２３で制御プログラム２３３が実行される。
なお、図２の例では、制御プログラム２３３が１つである場合を示しているが、制御プログラム２３３は複数あってもよい。

【0033】

制御プログラム２３３は、既に述べたように、例えば監視システムが導入される建物のうち特定の建物で要求される機能であって、標準機能プログラムを実行するだけでは実現困難な機能を記述したプログラムである。制御プログラム２３３は、あらかじめ設定されたスケジュールに従って実行される場合と、標準機能プログラム２１３の動作結果を受けて実行される場合とがある。制御プログラム２３３がどのようなタイミングで実行されるかは、上述のサブフレームワーク２１２にあらかじめ設定されており、制御プログラム２３３は、このタイミングに従ってサブフレームワーク２１２に呼び出されることで実行される。なお、制御プログラム２３３は請求項１の「第１のプログラムに記述されている機能以外の機能を記述した第２のプログラム」を構成する。

【0034】

なお、Ｄｏｃｋｅｒでは、仮想環境ごとに利用可能なリソース（例えばＣＰＵ及びメモリ）を制限することができる。そして、実施の形態１でも、仮想環境２３で利用可能なリソース（例えばＣＰＵ及びメモリ）が、コントローラ２が備えるリソースのうちの一部に制限されている。例えば、仮想環境２３で利用可能なＣＰＵ（仮想ＣＰＵ）の使用率、及び、仮想環境２３で利用可能なメモリ（仮想メモリ）の使用量が、所定の使用率及び所定の使用量にそれぞれ制限されている。

【0035】

ここで、仮想環境２３で利用可能なリソースに制限がない場合、多数の制御プログラム２３３が実行されたり、規模の大きな制御プログラム２３３が実行されたりすることで、制御プログラム２３３の負荷が高まり、仮想環境２３で多くのリソースが使用されることがある。その結果、実行環境２１で利用可能なリソースが減少し、実行環境２１における標準機能プログラム２１３の実行に影響を及ぼすおそれがある。そこで、コントローラ２では上述のように、仮想環境２３で利用可能なリソース（例えばＣＰＵ及びメモリ）を、コントローラ２が備えるリソースのうちの一部に制限する。これにより、コントローラ２では、実行環境２１で必要なリソースが確保され、仮に制御プログラム２３３が異常な状態になったり、制御プログラム２３３の負荷が高くなっても、標準機能プログラム２１３に影響を及ぼすことなく、標準機能プログラム２１３の処理を継続することができる。

【0036】

また、実施の形態１に係るコントローラ２では、当該コントローラ２をバージョンアップする際にも以下のような効果を奏する。

【0037】

例えば、エンジニアは、コントローラ２をバージョンアップする際、実行環境２１に含まれるメインフレームワーク２１１及びデータベース２１４を更新する。このとき、コントローラ２では、実行環境２１と仮想環境２３とが別の環境として構築されているため、エンジニアは、仮想環境２３で実行される制御プログラム２３３を更新する必要はなく、制御プログラム２３３の動作確認をする必要もない。

【0038】

この点、従来のコントローラでは、実行環境と仮想環境とを別の環境として構築するという構成ではなかったため、コントローラ（メインフレームワーク及びデータベース）をバージョンアップすると、それまでに作成した制御プログラムがバージョンアップ後も正常に動作するかをエンジニアが確認する必要があった。しかし、実施の形態１に係るコントローラ２では、実行環境２１と仮想環境２３とが別の環境として構築されているため、コントローラ２をバージョンアップしても、エンジニアは上記のような制御プログラム２３３の動作確認は不要となる。これにより、実施の形態１に係るコントローラ２では、制御プログラム２３３の保守にかかる工数を従来よりも低減でき、過去に作成した制御プログラム２３３の流用も容易となる。

【0039】

また、制御プログラム２３３を更新（機能拡張）するときは、エンジニアは制御プログラム２３３を更新するが、必要に応じて、制御プログラム２３３の更新とともに、仮想環境２３にライブラリを追加する。

【0040】

例えば仮想環境２３には、制御プログラム２３３の実行に必要な各種ライブラリが登録されているが、制御プログラム２３３に新たに追加した機能を実現するためのライブラリが仮想環境２３に登録されていない場合には、エンジニアは仮想環境２３に当該必要なライブラリを新たに追加することで、制御プログラム２３３の更新（機能拡張）を行う。この場合も、コントローラ２では、仮想環境２３と実行環境２１とが別の環境として構築されているため、エンジニアは、標準機能プログラム２１３を停止させたりすることなく、制御プログラム２３３の更新を行うことができる。

【0041】

特に、標準機能プログラム２１３を作成するエンジニアと、制御プログラム２３３を作成するエンジニアとは、別のエンジニアである場合も多く、そのため、制御プログラム２３３の更新が標準機能プログラム２１３の動作に与える影響を予測することが困難な場合も多い。一方で、監視システムでは、仮に制御プログラム２３３の更新に不備があったとしても、標準機能プログラム２１３の動作は止めてほしくないという要望もある。

【0042】

この点、実施の形態１に係るコントローラ２では、実行環境２１と仮想環境２３とが別の環境として構築されているため、エンジニアは、標準機能プログラム２１３の動作を継続させた状態で、標準機能プログラム２１３の動作に影響を与えることなく、制御プログラム２３３の更新を行うことができる。

【0043】

以上のように、実施の形態１によれば、コントローラ２は、第１のプログラム（標準機能プログラム２１３）が実行される実行環境２１と、第１のプログラムに記述されている機能以外の機能を記述した第２のプログラム（制御プログラム２３３）が実行される仮想環境２３と、を備え、仮想環境２３で利用可能なリソースは、自機が備えるリソースのうちの一部に制限されている。これにより、実行環境２１で必要なリソースが確保され、仮に制御プログラム２３３が異常な状態になったり、制御プログラム２３３の負荷が高くなっても、標準機能プログラム２１３に影響を及ぼすことなく、標準機能プログラム２１３の処理を継続することができる。すなわち、標準機能プログラム２１３と制御プログラム２３３との相互干渉を抑制可能となる。

【0044】

また、実行環境２１は、第１のフレームワーク（メインフレームワーク２１１）と、第１のフレームワーク上で動作し、標準機能プログラム２１３と仮想環境２３で実行される制御プログラム２３３とを連携して動作させる第２のフレームワーク（サブフレームワーク２１２）と、を有する。これにより、コントローラ２では、標準機能プログラム２１３と制御プログラム２３３とが連携して動作可能となる。

【0045】

また、サブフレームワーク２１２は、仮想環境２３で実行される制御プログラム２３３に異常が発生した際、当該異常が発生した制御プログラム２３３を把握可能であり、当該異常の発生を把握した制御プログラム２３３を連携の対象から除外する。これにより、制御プログラム２３３に何らかの異常が発生した場合でも、標準機能プログラム２１３は処理を継続することができる。

【0046】

また、サブフレームワーク２１２は、メインフレームワーク２１１と連携して動作し、実行環境２１は、実行環境２１において使用されるデータを記録した、メインフレームワーク２１１によりアクセス可能なデータベース２１４を有し、制御プログラム２３３は、サブフレームワーク２１２及びメインフレームワーク２１１を経由することにより、データベース２１４にアクセス可能である。これにより、コントローラ２では、制御プログラム２３３が実行環境２１に設けられたデータベース２１４にアクセスして処理を行うことができる。

【0047】

なお、本願発明はその発明の範囲内において、実施の形態の任意の構成要素の変形、若しくは実施の形態において任意の構成要素の省略が可能である。例えば、上記の説明では、コントローラ２のオペレーティングシステム（ＯＳ）としてＬｉｎｕｘ（登録商標）が搭載され、制御プログラム２３３のプログラム言語がＰｙｔｈｏｎであり、仮想環境２３を構築するための仮想化技術としてＤｏｃｋｅｒ（コンテナ型仮想化）が使用されている例を説明したが、これらはあくまで一例であって、ここで例示した構成に限られない。また、上記の説明では、第１のプログラムが標準機能プログラムであり、第２のプログラムが制御プログラムである場合を例示したが、第１のプログラム及び第２のプログラムは上記で例示したプログラムに限られず、第２のプログラムが、第１のプログラムに記述されている機能以外の機能を記述したプログラムであればよい。

【符号の説明】

【0048】

１ 監視対象機器（監視ポイント）
２ コントローラ
３ 監視装置
２１ 実行環境
２３ 仮想環境
２１１ メインフレームワーク（第１のフレームワーク）
２１２ 制御プログラムのフレームワーク（サブフレームワーク、第２のフレームワーク）
２１３ 標準機能プログラム（第１のプログラム）
２１４ データベース
２３３ 制御プログラム（第２のプログラム）

【図1】

【図2】