IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ダイキン工業株式会社の特許一覧

<>
  • 特許-制御ソフトウェア生成システム 図1
  • 特許-制御ソフトウェア生成システム 図2
  • 特許-制御ソフトウェア生成システム 図3
  • 特許-制御ソフトウェア生成システム 図4
  • 特許-制御ソフトウェア生成システム 図5
  • 特許-制御ソフトウェア生成システム 図6
  • 特許-制御ソフトウェア生成システム 図7
  • 特許-制御ソフトウェア生成システム 図8
  • 特許-制御ソフトウェア生成システム 図9
  • 特許-制御ソフトウェア生成システム 図10
  • 特許-制御ソフトウェア生成システム 図11
  • 特許-制御ソフトウェア生成システム 図12
  • 特許-制御ソフトウェア生成システム 図13
  • 特許-制御ソフトウェア生成システム 図14
  • 特許-制御ソフトウェア生成システム 図15
  • 特許-制御ソフトウェア生成システム 図16
  • 特許-制御ソフトウェア生成システム 図17
  • 特許-制御ソフトウェア生成システム 図18
  • 特許-制御ソフトウェア生成システム 図19
  • 特許-制御ソフトウェア生成システム 図20
  • 特許-制御ソフトウェア生成システム 図21
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-31
(45)【発行日】2023-11-09
(54)【発明の名称】制御ソフトウェア生成システム
(51)【国際特許分類】
   F24F 11/63 20180101AFI20231101BHJP
   G06F 8/36 20180101ALI20231101BHJP
   F24F 11/46 20180101ALI20231101BHJP
   G05B 19/05 20060101ALN20231101BHJP
【FI】
F24F11/63
G06F8/36
F24F11/46
G05B19/05 A
【請求項の数】 5
(21)【出願番号】P 2022043583
(22)【出願日】2022-03-18
(65)【公開番号】P2023137390
(43)【公開日】2023-09-29
【審査請求日】2023-01-30
(73)【特許権者】
【識別番号】000002853
【氏名又は名称】ダイキン工業株式会社
(74)【代理人】
【識別番号】110001427
【氏名又は名称】弁理士法人前田特許事務所
(72)【発明者】
【氏名】中神 嵩俊
(72)【発明者】
【氏名】中山 浩
(72)【発明者】
【氏名】稲生 明弘
(72)【発明者】
【氏名】朝田 有亮
【審査官】町田 豊隆
(56)【参考文献】
【文献】特開平11-094328(JP,A)
【文献】特開2005-134110(JP,A)
【文献】特開2020-181616(JP,A)
【文献】特開2017-048958(JP,A)
【文献】特開2020-067270(JP,A)
【文献】国際公開第2006/085406(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
F24F 11/63
G06F 8/36
F24F 11/46
G05B 19/05
(57)【特許請求の範囲】
【請求項1】
予め定義した標準空調システム構成について、制御を機能ごとに分割し且つ入出力を変数で定義した制御プログラムである機能ブロックのうち、機器制御用の第1機能ブロックの1つ以上の組み合わせで表現される複数の制御パターン候補を記憶した記憶部(110)と、
所望の空調システム構成情報及び所望の制御仕様を入力として、前記複数の制御パターン候補の中から1つの制御パターンを選択し、選択した制御パターンの前記第1機能ブロック同士の間の入出力を前記変数を用いてつなぎ合わせることで制御ソフトウェア(151)を生成する生成部(120)と、
を備え、
前記第1機能ブロックには、当該第1機能ブロックで使用するセンサ情報、及び当該第1機能ブロックでの不具合を検知する保守運用プログラムを含む第2機能ブロックの少なくとも一方が関連づけられており、
前記生成部(120)は、前記制御ソフトウェア(151)を生成すると同時に、選択した前記制御パターンに対応するセンサ情報(152)又は保守運用ソフトウェア(153)の少なくとも一方を出力する、
制御ソフトウェア生成システム。
【請求項2】
請求項1の制御ソフトウェア生成システムにおいて、
前記第1機能ブロックには、少なくとも、当該第1機能ブロックでの不具合を検知する前記保守運用プログラムを含む前記第2機能ブロックが関連づけられており、
前記保守運用プログラムは、制御対象の機器に対する指令値と、当該機器に関する状態量の計測値とに基づいて、当該状態量の目標値の設定ミスを検出する、
制御ソフトウェア生成システム。
【請求項3】
請求項1又は2の制御ソフトウェア生成システムにおいて、
前記所望の空調システム構成情報は、熱源システムの情報であって、少なくとも、チラー台数、チラー熱源種類、配管構成、及びポンプ台数を含む
制御ソフトウェア生成システム。
【請求項4】
請求項1~3のいずれか1項の制御ソフトウェア生成システムにおいて、
前記所望の空調システム構成情報は、エアサイドシステムの情報であって、少なくとも、モータダンパ数、配管方式、及び加湿方式を含む、
制御ソフトウェア生成システム。
【請求項5】
請求項1~4のいずれか1項の制御ソフトウェア生成システムにおいて、
前記複数の制御パターン候補は、省エネ性及びイニシャルコストのそれぞれに関する情報を含み、
前記所望の制御仕様として、省エネ性又はイニシャルコストのどちらを優先させるかが入力される
制御ソフトウェア生成システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、制御ソフトウェア生成システムに関する。
【背景技術】
【0002】
アプライド空調システムでは、ユーザー毎のニーズに対応し、現場毎に多数の機器を組み合わせてシステムを構築する。アプライド空調システムの導入のためには、設備設計、機器選定、計装設計、施工、試運転等多くの工程を実施する必要があるが、物件毎にシステム構成や機器の組み合わせが異なるため、特に補器やセンサの選定、配置を含む計装設計、施工の工程で多くの工数を必要とする。また、各機器を制御する制御システムについても、一品一葉で作製される場合が多く、制御システムを動作させるための制御ソフトウェアの構築にも多くの時間が費やされてきた。
【0003】
特許文献1には、制御ソフトウェアを効率的に生成するために、仕様に合わせて、モジュール化したソフトを組み合わせることにより、ソフトウェアの作成を行うソフトウェア作成システムが開示されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2019-61459号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、特許文献1のソフトウェア作成システムでは、ユーザー毎のニーズに対応した制御ソフトウェアを構築することができない。
【0006】
本開示の目的は、ユーザー毎のニーズに対応した制御ソフトウェアを構築できるようにすることにある。
【課題を解決するための手段】
【0007】
本開示の第1の態様は、記憶部(110)と、生成部(120)とを備える制御ソフトウェア生成システムである。記憶部(110)は、予め定義した標準空調システム構成について、制御を機能ごとに分割し且つ入出力を変数で定義した制御プログラムである機能ブロックのうち、機器制御用の第1機能ブロックの1つ以上の組み合わせで表現される複数の制御パターン候補を記憶する。生成部(120)は、所望の空調システム構成情報及び所望の制御仕様を入力として、前記複数の制御パターン候補の中から1つの制御パターンを選択し、選択した制御パターンの前記第1機能ブロック同士の間の入出力を前記変数を用いてつなぎ合わせることで制御ソフトウェア(151)を生成する。前記第1機能ブロックには、当該第1機能ブロックで使用するセンサ情報、及び当該第1機能ブロックでの不具合を検知する保守運用プログラムを含む第2機能ブロックの少なくとも一方が関連づけられている。前記生成部(120)は、前記制御ソフトウェア(151)を生成すると同時に、選択した前記制御パターンに対応するセンサ情報(152)又は保守運用ソフトウェア(153)の少なくとも一方を出力する。
【0008】
第1の態様では、所望の空調システム構成情報や制御仕様に応じて、複数の制御パターン候補の中から制御パターンを選択して制御ソフトウェア(151)を生成するので、ユーザー毎のニーズに対応した制御ソフトウェア(151)を構築できる。また、制御ソフトウェア(151)の作成等の工数を削減できるため、工期及びコストを低減できる。
【0009】
本開示の第2の態様は、第1の態様において、前記保守運用プログラムは、制御対象の機器に対する指令値と、当該機器に関する状態量の計測値とに基づいて、当該状態量の目標値の設定ミスを検出する。
【0010】
第2の態様では、制御ソフトウェア(151)に対応する保守運用ソフトウェア(153)を構築することができる。
【0011】
本開示の第3の態様は、第1又は第2の態様において、前記所望の空調システム構成情報は、熱源システムの情報であって、少なくとも、チラー台数、チラー熱源種類、配管構成、及びポンプ台数を含む。
【0012】
第3の態様では、熱源システムを制御する制御ソフトウェア(151)を構築することができる。
【0013】
本開示の第4の態様は、第1~第3のいずれか1つの態様において、前記所望の空調システム構成情報は、エアサイドシステムの情報であって、少なくとも、モータダンパ数、配管方式、及び加湿方式を含む。
【0014】
第4の態様では、エアサイドシステムを制御する制御ソフトウェア(151)を構築することができる。
【0015】
本開示の第5の態様は、第1~4のいずれか1つの態様において、前記複数の制御パターン候補は、省エネ性及びイニシャルコストのそれぞれに関する情報を含み、前記所望の制御仕様として、省エネ性又はイニシャルコストのどちらを優先させるかが入力される。
【0016】
第5の態様では、省エネ性及びイニシャルコストに関するユーザー毎のニーズに対応した制御ソフトウェア(151)を構築することができる。
【図面の簡単な説明】
【0017】
図1図1は、実施形態に係る制御ソフトウェア生成システムの構成図である。
図2図2は、実施形態に係る制御ソフトウェア生成システムで用いる機能ブロックの入出力を例示する模式図である。
図3図3は、実施形態に係る制御ソフトウェア生成システムにおいて制御ソフトウェアを生成する様子を例示する模式図である。
図4図4は、実施形態に係る制御ソフトウェア生成システムによる制御ソフトウェア生成の処理手順を示すフロー図である。
図5図5は、実施形態に係る制御ソフトウェア生成システムで用いる標準空調システム構成及び制御パターン候補のデータベースの構成を例示する図である。
図6図6は、実施形態に係る制御ソフトウェア生成システムにおける空調システム構成情報と標準空調システム構成との関係を例示する図である。
図7図7は、実施形態に係る制御ソフトウェア生成システムにおける制御仕様と制御パターン候補との関係を例示する図である。
図8図8は、実施形態に係る制御ソフトウェア生成システムにおいて、二次側圧力によるポンプVFD制御の機能ブロックを組み合わせて制御ソフトウェアを生成する様子を例示する模式図である。
図9図9は、図8に示す機能ブロックの1つと対応するプログラムの一例を例示するフロー図である。
図10図10は、実施形態に係る制御ソフトウェア生成システムにおいて、送水温度による熱源台数制御の機能ブロックを組み合わせて制御ソフトウェアを生成する様子を例示する模式図である。
図11図11は、図10に示す機能ブロックの1つと対応するプログラムの一例を例示するフロー図である。
図12図12は、実施形態に係る制御ソフトウェア生成システムで用いる制御用機能ブロック(第1機能ブロック)と保守運用用機能ブロック(第2機能ブロック)との関係を例示する図である。
図13図13は、実施形態に係る制御ソフトウェア生成システムで用いる保守運用用機能ブロックの一例と対応するプログラムを例示するフロー図である。
図14図14は、実施形態に係る制御ソフトウェア生成システムで用いる保守運用用機能ブロックの他例と対応するプログラムの一例を例示するフロー図である。
図15図15は、変形例1に係る制御ソフトウェア生成システムによる制御ソフトウェア生成の処理手順を示すフロー図である。
図16図16は、変形例1に係る制御ソフトウェア生成システムで用いる標準空調システム構成及び制御パターン候補のデータベースの構成を例示する図である。
図17図17は、変形例1に係る制御ソフトウェア生成システムにおける空調システム構成情報と標準空調システム構成との関係を例示する図である。
図18図18は、変形例1に係る制御ソフトウェア生成システムにおける制御仕様と制御パターン候補との関係を例示する図である。
図19図19は、変形例2に係る制御ソフトウェア生成システムによる制御ソフトウェア生成の処理手順を示すフロー図である。
図20図20は、変形例2に係る制御ソフトウェア生成システムで用いる標準空調システム構成及び制御パターン候補のデータベースの構成を例示する図である。
図21図21は、変形例2に係る制御ソフトウェア生成システムにおける制御仕様と制御パターン候補との関係を例示する図である。
【発明を実施するための形態】
【0018】
(実施形態)
以下、本開示の実施形態について図面を参照しながら説明する。尚、以下の実施形態は、本質的に好ましい例示であって、本発明、その適用物、或いはその用途の範囲を制限することを意図するものではない。また、各図面は、本開示を概念的に説明するためのものであるから、理解容易のために必要に応じて寸法、比又は数を誇張又は簡略化して表す場合がある。
【0019】
<システム構成>
本実施形態に係る制御ソフトウェア生成システム(100)は、図1に示すように、主に、記憶部(110)と、生成部(120)とを備える。
【0020】
記憶部(110)は、予め標準として定義した複数のシステム構成(以下、標準空調システム構成、又は単に標準システムという)について、制御を機能ごとに分割し且つ入出力を変数で定義した制御プログラムである機能ブロックのうち、機器制御用機能ブロック(第1機能ブロック)の1つ以上の組み合わせで表現される複数の制御パターン候補を記憶する。記憶部(110)は、例えば、標準空調システム構成及び制御パターン候補の第1データベース(110A)と、機能ブロックの第2データベース(110B)とを有してもよい。第2データベース(110B)は、例えば、一次ポンプVFD制御の機能ブロック(FB#A、FB#M)、熱源台数制御の機能ブロック(FB#C、FB#D、FB#I、FB#J、FB#K、FB#N)、冷却水ポンプVFD制御の機能ブロック(FB#L、FB#M)等を含む。図2に例示するように、機能ブロックFB#Aは、変数Input_A1、Input_A2、Input_A3を入力として、変数Output_Aを出力する制御プログラムである。
【0021】
生成部(120)は、所望の空調システム構成情報(第1入力)及び所望の制御仕様(第2入力)を入力として、複数の制御パターン候補の中から1つの制御パターンを選択し、選択した制御パターンの機器制御用機能ブロック同士を組み合わせて制御ソフトウェア(151)を生成する。第1入力は、例えば、熱源システムにおけるチラー台数、チラー熱源種類(空冷/水冷)、配管構成、ポンプ台数等である。制御ソフトウェア(151)は、対象機器の台数制御やVFD(variable frequency drive)値の制御などを行う。
【0022】
生成部(120)は、例えば、システム構成判定部(121)と、制御パターン選択部(122)と、制御ソフトウェア生成部(123)とを有してもよい。システム構成判定部(121)は、第1入力の内容に該当する標準空調システム構成があるかどうか判定する。制御パターン選択部(122)は、第1入力の内容に該当する標準空調システム構成に関し、第2入力の内容に該当する制御パターンを選択する。制御パターン選択部(122)は、例えば、一次ポンプVFD制御をどのように実施するかについて、二次側圧力を使用する制御パターン候補、及びバイパス流量を使用する制御パターン候補の2候補のなかから制御パターンを選択する。制御ソフトウェア生成部(123)は、選択した制御パターンの機器制御用機能ブロック同士の間の入出力を、当該入出力を定義する変数を用いてつなぎ合わせることで制御ソフトウェア(151)を生成する。
【0023】
制御ソフトウェア生成部(123)は、例えば、機能ブロックFB#A、FB#Mを組み合わせて一次ポンプVFD制御用ソフトウェアを生成し、機能ブロックFB#C、FB#D、FB#I、FB#J、FB#K、FB#Nを組み合わせて熱源台数制御用ソフトウェアを生成し、機能ブロックFB#L、FB#Mを組み合わせて冷却水ポンプVFD制御用ソフトウェアを生成する。図3に例示するように、機能ブロックFB#Aの出力(変数:Output_A)を、機能ブロックFB#Mの入力(変数:Input_M1)として用いる場合、制御ソフトウェア生成部(123)は、Input_M1にOutput_Aの値が入力されるように処理を行う。尚、入出力を変数を用いてつなぎ合わせる方法は特に限定されるものではなく、変数名の置き換えに代えて、数値を代入してもよい。
【0024】
本実施形態の制御ソフトウェア生成システム(100)の記憶部(110)(第2データベース(110B))において、機器制御用機能ブロックには、当該ブロックで使用するセンサ情報、及び当該ブロックでの不具合を検知する保守運用プログラムを含む保守運用用機能ブロック(第2機能ブロック)の少なくとも一方が関連づけられる。これにより、生成部(120)は、制御ソフトウェア(151)を生成すると同時に、選択した制御パターンに対応するセンサ情報(152)又は保守運用ソフトウェア(153)の少なくとも一方を出力することができる。
【0025】
尚、制御ソフトウェア生成システム(100)は、ソフトウェア処理として実現してもよいし、或いは、専用回路で構成してもよい。ソフトウェア処理として実現する場合、例えば、CPU、内部メモリ(RAM等)、外部メモリ(ROM、ハードディスク等)を備えるコンピュータにおいて、生成部(120)の処理内容を実行するプログラムを外部メモリに記憶させ、当該プログラムを内部メモリに適宜ロードし、CPUで当該プログラムに従って演算を行うようにしてもよい。
【0026】
<システム動作>
本実施形態の制御ソフトウェア生成システム(100)による制御ソフトウェア生成の処理においては、図4に示すように、まず、ステップS101において、制御ソフトウェア生成システム(100)の入力機器(キーボード、タッチパネル等)を通じてユーザーが所望の空調システム構成情報を入力する。次に、ステップS102において、システム構成判定部(121)は、入力された空調システム構成情報が、記憶部(110)(第1データベース(110A))に記憶された標準空調システム構成に含まれるかどうかを判定する。
【0027】
図5に例示するように、記憶部(110)には、様々な標準空調システム構成(標準システム)が登録されており、各標準システムは、複数の制御パターン候補を有し、各制御パターン候補は、機器制御用機能ブロック(第1機能ブロック)の1つ以上の組み合わせで表現される。例えば、制御パターン1は、機能ブロック(FB#)A、C、D、H、I、J、K、N、M、Wの組み合わせで表現される。従って、前述のように、機器制御用機能ブロックに、当該ブロックで使用するセンサ情報が関連づけられる場合、図5に示すように、制御パターン毎に対応するセンサ情報(152)が設定される。
【0028】
空調システム構成情報として、例えば、熱源システムにおけるチラー熱源種類(空冷/水冷)、配管構成、チラー台数、ポンプ台数等が入力されると、図6に例示するような、空調システム構成情報と標準空調システム構成との関係に基づき、システム構成判定部(121)は、入力されたシステム構成情報と合致する標準システムを選択する。例えば、チラー熱源種類が「空冷」、配管構成が「一次ポンプ-デディケート」、チラー台数が「1」、ポンプ台数が「1」であると入力された場合、標準システムaが選択される。
【0029】
入力された空調システム構成情報が、標準空調システム構成に含まれないとステップS102で判定された場合、制御ソフトウェア生成の処理は終了する。
【0030】
一方、入力された空調システム構成情報が、標準空調システム構成に含まれるとステップS102で判定された場合、ステップS103において、制御ソフトウェア生成システム(100)の入力機器を通じてユーザーが所望の制御仕様(各機器の制御方法)を入力する。次に、ステップS104において、制御パターン選択部(122)は、ステップS101で入力された空調システム構成情報が該当する標準システムに関し、当該標準システムで実現可能な複数の制御パターン候補の中から、ステップS103で入力された制御仕様に対応する制御パターンを選択する。
【0031】
制御仕様として、例えば、熱源システムにおける熱源台数制御方式、一次ポンプVFD制御方式等が入力されると、図7に例示するような、制御仕様と制御パターン候補との関係に基づき、制御パターン選択部(122)は、入力された制御仕様と対応する制御パターンを選択する。図7に示す関係において、例えば、熱源台数制御方式が「流量による台数制御」、一次ポンプVFD制御方式が「二次側圧力によるVFD制御」であると入力された場合、制御パターン1が選択される。
【0032】
制御パターン選択部(122)により制御パターンが選択されると、引き続きステップS104において、制御ソフトウェア生成部(123)は、選択した制御パターンの機器制御用機能ブロック同士の間の入出力を、当該入出力を定義する変数を用いてつなぎ合わせることで制御ソフトウェア(151)を生成する。制御ソフトウェア(151)の具体例については後述する。
【0033】
その後、ステップS105において、制御ソフトウェア生成部(123)は、ステップS104で生成した制御ソフトウェア(151)に加えて、ステップS104で選択した制御パターンに対応するセンサ情報(152)又は保守運用ソフトウェア(153)の少なくとも一方を出力する。ここで、記憶部(110)(第2データベース(110B))に記憶されている機器制御用機能ブロックには、当該ブロックで使用するセンサ情報、及び当該ブロックでの不具合を検知する保守運用プログラムを含む保守運用用機能ブロックが関連づけられている。これにより、選択した制御パターンに対応するセンサ情報(152)や保守運用ソフトウェア(153)の出力が可能となる。機器制御用機能ブロックに関連づけられるセンサ情報(制御に必要なセンサ情報)とは、例えば、センサの種類(圧力センサ、温度センサ等)、センサ取り付け位置(末端差圧の測定位置、送水温度の測定位置等)などである。保守運用ソフトウェア(153)は、対象機器に対する設定値ミスなどの不具合検知を行う。保守運用ソフトウェア(153)の具体例については後述する。
【0034】
尚、ステップS105において、ステップS101で入力された空調システム構成情報が該当する標準システムで実現可能な複数の制御パターン候補(機能ブロックの組み合わせ)の一覧(図5参照)を出力してもよい。
【0035】
<制御ソフトウェア>
図8に例示するように、制御ソフトウェア生成部(123)は、例えば、機能ブロックFB#A、FB#M、FB#Wを組み合わせて、二次側圧力によるポンプVFD制御を行う制御ソフトウェア(151)を生成してもよい。機能ブロックFB#Aは、二次側圧力からVFD指令値を演算して出力するプログラムである。機能ブロックFB#Mは、機能ブロックFB#Aからの出力値を入力として、各機器の状態により各機器へのVFD指令値を決定して出力するプログラムである。機能ブロックFB#Wは、機能ブロックFB#Mからの出力値を入力として、各機器へのVFD指令値に対して上下限を設定して制限し、その結果を各機器に出力するプログラムである。
【0036】
図8に示す制御ソフトウェア(151)を構成する機能ブロックのうち、例えば機能ブロックFB#Aの処理においては、図9に示すように、まず、ステップS201において、ポンプが運転中かどうかを判定し、運転中であれば、ステップS202において、二次側圧力センサ異常を示すアラートが未発報かどうかを判定する。アラートが未発報であれば、機能ブロックFB#Aは、ステップS203において、二次側差圧が目標値となるように、PI制御を用いてポンプVFD指令値の演算を行い、ステップS201に戻る。一方、ステップS201でポンプが運転中ではないと判定された場合、或いは、ステップS202でアラートが未発報ではないと判定された場合、機能ブロックFB#Aは、ステップS204において、ポンプVFD指令値を0%(最小値)に設定し、ステップS201に戻る。機能ブロックFB#Aは、所定の時間間隔でステップS201~S204の処理を繰り返し実施する。
【0037】
図10に例示するように、制御ソフトウェア生成部(123)は、例えば、機能ブロックFB#G、FB#J、FB#I、FB#K、FB#Nを組み合わせて、送水温度による熱源台数制御を行う制御ソフトウェア(151)を生成してもよい。機能ブロックFB#Gは、往き温度と往還温度差とから運転台数の増減を判定するプログラムである。機能ブロックFB#Jは、各機器の稼働時間を計算するプログラムである。機能ブロックFB#Iは、運転指令と運転状態との不一致(状態不一致)又は手動操作によって制御対象外の機器を決定するプログラムである。機能ブロックFB#Kは、機能ブロックFB#G、FB#J、FB#Iからの出力を入力として、稼働時間や制御対象外の機器に基づき運転又は停止させる機器を決定するプログラムである。機能ブロックFB#Nは、機能ブロックFB#Kからの出力を入力として、各機器に対して運転指令を出力すると共に、制御対象外の機器に対して手動による運転指令を可能とするプログラムである。
【0038】
図10に示す制御ソフトウェア(151)を構成する機能ブロックのうち、例えば機能ブロックFB#Gの処理においては、図11に示すように、まず、ステップS301において、往き温度センサ異常を示すアラートが未発報かどうかを判定し、アラートが未発報であれば、ステップS302において、還り温度センサが、異常を示すアラートを発報していないかを判定し、アラートが未発報であれば、ステップS303において、空調システムが冷房中か暖房中かを判定する。冷房中であれば、機能ブロックFB#Gは、ステップS304において、往き温度が目標値(冷房時)よりも大きいか判定し、大きければ、ステップS305において、運転台数の増段判定を行い、ステップS301に戻る。ステップS304で往き温度が目標値(冷房時)よりも大きくないと判定された場合、機能ブロックFB#Gは、ステップS306において、往還温度差が目標値(冷房時)よりも小さいか判定し、小さければ、ステップS307において、運転台数の減段判定を行い、ステップS301に戻る。
【0039】
尚、ステップS301若しくはS302でアラートが未発報ではないと判定された場合、又はステップS306で往還温度差が目標値(冷房時)よりも小さくないと判定された場合、ステップS301に戻る。
【0040】
また、ステップS303で空調システムが暖房中であると判定された場合、機能ブロックFB#Gは、ステップS308において、往き温度が目標値(暖房時)よりも小さいか判定し、小さければ、ステップS309において、運転台数の増段判定を行い、ステップS301に戻る。ステップS308で往き温度が目標値(暖房時)よりも小さくないと判定された場合、機能ブロックFB#Gは、ステップS310において、往還温度差が目標値(暖房時)よりも大きいか判定し、大きければ、スステップS310で往還温度差が目標値(暖房時)よりも大きくないと判定された場合、ステップS301に戻る。
【0041】
機能ブロックFB#Gは、所定の時間間隔でステップS301~S311の処理を繰り返し実施する。
【0042】
<保守運用ソフトウェア>
保守運用ソフトウェア(153)の生成に用いる保守運用プログラムを含む保守運用用機能ブロックは、図12に例示するように、機器制御用機能ブロックに関連づけられる。例えば、機器制御用機能ブロックA、B、E、Fにはそれぞれ、保守運用用機能ブロックO、P、Q、Rが関連づけられる。また、機器制御用機能ブロックC、Dには、関連付けられた保守運用用機能ブロックは存在しない。保守運用用機能ブロックに含まれる保守運用プログラムは、例えば、制御対象の機器に対する指令値と、当該機器に関する状態量の計測値とに基づいて、当該状態量の目標値の設定ミスを検出してもよい。
【0043】
図8に示す制御ソフトウェア(151)を構成する機能ブロックのうち、例えば機能ブロックFB#Aに関連付けられた保守運用用機能ブロックに含まれる保守運用プログラムの処理フローを図13に例示する。機能ブロックFB#A(図9参照)では、二次側圧力が目標圧力で安定するようにポンプVFD指令値(0~100%)をPI制御する。すなわち、二次側圧力目標値>二次側圧力計測値のときは、VFD指令値を増大させ、二次側圧力目標値<二次側圧力計測値のときは、VFD指令値を減少させる。二次側圧力目標値、並びにPI制御の比例係数や積分時間は予め設定される。
【0044】
図13に示す保守運用プログラムは、二次側圧力によるポンプVFD制御の設定値(目標値)の設定ミスを検出する。具体的には、まず、ステップS401において、二次側圧力センサ異常を示すアラートが未発報かどうかを判定し、未発報であれば、ステップS402において、ポンプが全台運転中かどうかを判定し、全台運転中であれば、ステップS403において、VFD指令値が100%かどうかを判定する。VFD指令値が100%であれば、ステップS404において、所定の時間が経過しても、二次側圧力の目標値が計測値よりも大きいかどうかを判定し、大きければ、ステップS405において、二次側圧力の目標値(上限)の設定ミスの可能性があると判定して異常を示すアラートを発報して、ステップS401に戻る。
【0045】
ステップS401でアラートが未発報ではないと判定された場合、ステップS403でVFD指令値が100%ではないと判定された場合、或いは、ステップS404で二次側圧力の目標値が計測値よりも大きくないと判定された場合、そのままステップS401に戻る。
【0046】
ステップS402でポンプが全台運転中ではないと判定された場合、ステップS406において、ポンプが最小台数で運転中かどうかを判定し、最小台数で運転中であれば、ステップS407において、VFD指令値が0%かどうかを判定する。VFD指令値が0%であれば、ステップS409において、所定の時間が経過しても、二次側圧力の計測値が目標値よりも大きいかどうかを判定し、大きければ、ステップS409において、二次側圧力の目標値(下限)の設定ミスの可能性があると判定して異常を示すアラートを発報して、ステップS401に戻る。
【0047】
ステップS406でポンプが最小台数で運転中ではないと判定された場合、ステップS407でVFD指令値が0%ではないと判定された場合、或いは、ステップS408で二次側圧力の計測値が目標値よりも大きくないと判定された場合、そのままステップS401に戻る。
【0048】
図13に示す保守運用プログラムでは、所定の時間間隔でステップS401~S409の処理を繰り返し実施する。
【0049】
図10に示す制御ソフトウェア(151)を構成する機能ブロックのうち、例えば機能ブロックFB#Gに関連付けられた保守運用用機能ブロックに含まれる保守運用プログラムの処理フローを図14に例示する。機能ブロックFB#G(図10参照)では、送水温度による熱源台数制御を行う。すなわち、往き温度に応じて熱源の増段、往還温度差に応じて熱源の減段を行う。往き温度目標値及び往還温度差目標値は予め設定される。
【0050】
図14に示す保守運用プログラムは、送水温度による熱源台数制御の往き温度目標値の設定ミスを検出する。具体的には、まず、ステップS501において、往き温度センサ異常を示すアラートが未発報かどうかを判定し、アラートが未発報であれば、ステップS502において、熱源が全台運転中かどうかを判定し、全台運転中であれば、空調システムが冷房中か暖房中かを判定する。冷房中であれば、ステップS504において、往き温度が目標値(冷房時)よりも大きいか判定し、大きければ、ステップS505において、往き温度目標値の設定ミスの可能性があると判定して異常を示すアラートを発報して、ステップS501に戻る。
【0051】
ステップS501でアラートが未発報ではないと判定された場合、ステップS502で熱源が全台運転中ではないと判定された場合、或いは、ステップS504で往き温度が目標値(冷房時)よりも大きくないと判定された場合、そのままステップS501に戻る。
【0052】
ステップS503で空調システムが暖房中であると判定された場合、ステップS506において、往き温度が目標値(暖房時)よりも小さいか判定し、小さければ、ステップS507において、還り温度目標値の設定ミスの可能性があると判定して異常を示すアラートを発報して、ステップS501に戻る。一方、ステップS506で往き温度が目標値(暖房時)よりも小さくないと判定された場合、そのままステップS501に戻る。
【0053】
図14に示す保守運用プログラムでは、所定の時間間隔でステップS501~S507の処理を繰り返し実施する。
【0054】
<実施形態の特徴>
本実施形態の制御ソフトウェア生成システム(100)は、記憶部(110)と、生成部(120)とを備える。記憶部(110)は、予め定義した標準空調システム構成について、制御を機能ごとに分割し且つ入出力を変数で定義した制御プログラムである機能ブロックのうち、機器制御用機能ブロックの1つ以上の組み合わせで表現される複数の制御パターン候補を記憶する。生成部(120)は、所望の空調システム構成情報及び所望の制御仕様を入力として、複数の制御パターン候補の中から1つの制御パターンを選択し、選択した制御パターンの機器制御用機能ブロック同士の間の入出力を、当該入出力を定義する変数を用いてつなぎ合わせることで制御ソフトウェア(151)を生成する。機器制御用機能ブロックには、当該機能ブロックで使用するセンサ情報、及び当該機能ブロックでの不具合を検知する保守運用プログラムを含む保守運用用機能ブロックの少なくとも一方が関連づけられている。生成部(120)は、制御ソフトウェア(151)を生成すると同時に、選択した制御パターンに対応するセンサ情報(152)又は保守運用ソフトウェア(153)の少なくとも一方を出力する。
【0055】
本実施形態の制御ソフトウェア生成システム(100)によると、所望の空調システム構成情報や制御仕様に応じて、複数の制御パターン候補の中から制御パターンを選択して制御ソフトウェア(151)を生成するので、ユーザー毎のニーズに対応した制御ソフトウェア(151)を構築できる。また、制御ソフトウェア(151)の作成を含むエンジニアリングの工数を削減できるため、工期及びコストを低減できる。さらに、予め定めた制御パターン候補の中から選択した制御パターンについて、自動的に制御ソフトウェア(151)が構築されると共に、対応するセンサ情報(152)又は保守運用ソフトウェア(153)が出力されるため、ヒューマンエラーを減らして品質を向上させることができる。
【0056】
本実施形態の制御ソフトウェア生成システム(100)において、保守運用プログラムは、制御対象の機器に対する指令値と、当該機器に関する状態量の計測値とに基づいて、当該状態量の目標値の設定ミスを検出してもよい。このようにすると、制御ソフトウェア(151)に対応する保守運用ソフトウェア(153)を構築することができる。
【0057】
本実施形態の制御ソフトウェア生成システム(100)において、所望の空調システム構成情報が、熱源システムの情報であって、少なくとも、チラー台数、チラー熱源種類、配管構成、及びポンプ台数を含むと、熱源システムを制御する制御ソフトウェア(151)を構築することができる。
【0058】
(変形例1)
本変形例が前記実施形態と異なる点は、図1に示す制御ソフトウェア生成システム(100)により、エアサイドシステムを制御する制御ソフトウェア(151)を生成することである。
【0059】
本変形例においては、図15に示すように、まず、ステップS601において、制御ソフトウェア生成システム(100)の入力機器(キーボード、タッチパネル等)を通じてユーザーが所望の空調システム構成情報を入力する。次に、ステップS602において、システム構成判定部(121)は、入力された空調システム構成情報が、記憶部(110)(第1データベース(110A))に記憶された標準空調システム構成に含まれるかどうかを判定する。
【0060】
図16に例示するように、記憶部(110)には、様々な標準空調システム構成(標準システム)が登録されており、各標準システムは、複数の制御パターン候補を有し、各制御パターン候補は、機器制御用機能ブロック(第1機能ブロック)の1つ以上の組み合わせで表現される。例えば、制御パターン1は、機能ブロック(FB#)A、F、G、N、X、AD、AGの組み合わせで表現される。従って、機器制御用機能ブロックに、当該ブロックで使用するセンサ情報が関連づけられる場合、図16に示すように、制御パターン毎に対応するセンサ情報(152)が設定される。
【0061】
空調システム構成情報として、例えば、エアサイドシステムにおけるモータダンパ(MD)数、配管方式、及び加湿方式等が入力されると、図17に例示するような、空調システム構成情報と標準空調システム構成との関係に基づき、システム構成判定部(121)は、入力されたシステム構成情報と合致する標準システムを選択する。例えば、MD数が「1MD」、配管方式が「2管式」、加湿方式が「なし」であると入力された場合、標準システムaが選択される。
【0062】
入力された空調システム構成情報が、標準空調システム構成に含まれないとステップS602で判定された場合、制御ソフトウェア生成の処理は終了する。
【0063】
一方、入力された空調システム構成情報が、標準空調システム構成に含まれるとステップS602で判定された場合、ステップS603において、制御ソフトウェア生成システム(100)の入力機器を通じてユーザーが所望の制御仕様(各機器の制御方法)を入力する。次に、ステップS604において、制御パターン選択部(122)は、ステップS601で入力された空調システム構成情報が該当する標準システムに関し、当該標準システムで実現可能な複数の制御パターン候補の中から、ステップS603で入力された制御仕様に対応する制御パターンを選択する。
【0064】
制御仕様として、例えば、エアサイドシステムにおける給気温度設定制御方式、給気温度制御方式、加湿制御方式、ファン回転数制御方式等が入力されると、図18に例示するような、制御仕様と制御パターン候補との関係に基づき、制御パターン選択部(122)は、入力された制御仕様と対応する制御パターンを選択する。図18に示す関係において、例えば、給気温度設定制御方式が「室内温度による給気温度設定制御」、給気温度制御方式が「給気温度によるバルブ・ダンパ制御」、ファン回転数制御方式が「室内温度によるファン回転数制御」であると入力された場合、制御パターン1が選択される。
【0065】
制御パターン選択部(122)により制御パターンが選択されると、引き続きステップS604において、制御ソフトウェア生成部(123)は、選択した制御パターンの機器制御用機能ブロック同士の間の入出力を、当該入出力を定義する変数を用いてつなぎ合わせることで制御ソフトウェア(151)を生成する。
【0066】
その後、ステップS605において、制御ソフトウェア生成部(123)は、ステップS604で生成した制御ソフトウェア(151)に加えて、ステップS604で選択した制御パターンに対応するセンサ情報(152)又は保守運用ソフトウェア(153)の少なくとも一方を出力する。ここで、記憶部(110)(第2データベース(110B))に記憶されている機器制御用機能ブロックには、当該ブロックで使用するセンサ情報、及び当該ブロックでの不具合を検知する保守運用プログラムを含む保守運用用機能ブロックが関連づけられている。これにより、選択した制御パターンに対応するセンサ情報(152)や保守運用ソフトウェア(153)の出力が可能となる。
【0067】
尚、ステップS605において、ステップS601で入力された空調システム構成情報が該当する標準システムで実現可能な複数の制御パターン候補(機能ブロックの組み合わせ)の一覧(図16参照)を出力してもよい。
【0068】
以上に説明した本変形例によると、前記実施形態と同様の効果に加えて、次のような効果を得ることができる。すなわち、所望の空調システム構成情報が、エアサイドシステムの情報であって、少なくとも、モータダンパ数、配管方式、及び加湿方式を含むため、エアサイドシステムを制御する制御ソフトウェア(151)を構築することができる。
【0069】
(変形例2)
本変形例が前記実施形態と異なる点は、図1に示す制御ソフトウェア生成システム(100)において、記憶部(120)に記憶される複数の制御パターン候補が、省エネ性及びイニシャルコストのそれぞれに関する情報を含み、所望の制御仕様(第2入力)として、省エネ性又はイニシャルコストのどちらを優先させるかが入力されることである。
【0070】
本変形例においては、図19に示すように、まず、ステップS701において、制御ソフトウェア生成システム(100)の入力機器を通じてユーザーが所望の空調システム構成情報を入力する。次に、ステップS702において、システム構成判定部(121)は、前記実施形態のステップS102と同様に、入力された空調システム構成情報が、記憶部(110)(第1データベース(110A))に記憶された標準空調システム構成に含まれるかどうかを判定する。
【0071】
図20に例示するように、記憶部(110)には、様々な標準空調システム構成(標準システム)が登録されており、各標準システムは、複数の制御パターン候補を有し、各制御パターン候補は、機器制御用機能ブロック(第1機能ブロック)の1つ以上の組み合わせで表現される。例えば、制御パターン1は、機能ブロック(FB#)A、C、D、H、I、J、K、N、M、Wの組み合わせで表現される。従って、機器制御用機能ブロックに、当該ブロックで使用するセンサ情報が関連づけられる場合、図20に示すように、制御パターン毎に対応するセンサ情報(152)が設定される。また、本変形例では、複数の制御パターン候補が、省エネ性及びイニシャルコストのそれぞれに関する情報を含む。具体的には、各標準システムにおいて、複数の制御パターン候補の中から、省エネ性優先の制御パターン、及びイニシャルコスト優先の制御パターンがそれぞれ1つずつ設定される。
【0072】
入力された空調システム構成情報が、標準空調システム構成に含まれないとステップS702で判定された場合、制御ソフトウェア生成の処理は終了する。
【0073】
一方、入力された空調システム構成情報が、標準空調システム構成に含まれるとステップS702で判定された場合、ステップS703において、制御ソフトウェア生成システム(100)の入力機器を通じてユーザーが所望の制御仕様を入力する。本変形例では、所望の制御仕様として、省エネ性優先か又はイニシャルコスト優先かを選択して入力する。
【0074】
次に、ステップS704において、制御パターン選択部(122)は、ステップS701で入力された空調システム構成情報が該当する標準システムに関し、当該標準システムで実現可能な複数の制御パターン候補の中から、ステップS703で入力された制御仕様(省エネ性優先又はイニシャルコスト優先)に対応する制御パターンを選択する。
【0075】
制御仕様として、省エネ性優先又はイニシャルコスト優先が選択されると、図21に例示するような、省エネ性又はイニシャルコストと制御パターン候補との関係に基づき、制御パターン選択部(122)は、選択された省エネ性優先又はイニシャルコスト優先と対応する制御パターンを選択する。図21に示す関係において、例えば、イニシャルコスト優先が選択された場合、制御パターン3が選択される。尚、図21には、省エネ性優先又はイニシャルコスト優先以外の他の制御仕様(熱源台数制御方式など)も記載しているが、本変形例では、これらの他の制御仕様は入力項目ではない。
【0076】
制御パターン選択部(122)により制御パターンが選択されると、引き続きステップS704において、制御ソフトウェア生成部(123)は、選択した制御パターンの機器制御用機能ブロック同士の間の入出力を、当該入出力を定義する変数を用いてつなぎ合わせることで制御ソフトウェア(151)を生成する。
【0077】
その後、ステップS705において、制御ソフトウェア生成部(123)は、ステップS704で生成した制御ソフトウェア(151)に加えて、ステップS704で選択した制御パターンに対応するセンサ情報(152)又は保守運用ソフトウェア(153)の少なくとも一方を出力する。ここで、記憶部(110)(第2データベース(110B))に記憶されている機器制御用機能ブロックには、当該ブロックで使用するセンサ情報、及び当該ブロックでの不具合を検知する保守運用プログラムを含む保守運用用機能ブロックが関連づけられている。これにより、選択した制御パターンに対応するセンサ情報(152)や保守運用ソフトウェア(153)の出力が可能となる。
【0078】
尚、ステップS705において、ステップS701で入力された空調システム構成情報が該当する標準システムで実現可能な複数の制御パターン候補(機能ブロックの組み合わせ)の一覧(図20参照)を出力してもよい。
【0079】
以上に説明した本変形例によると、前記実施形態と同様の効果に加えて、次のような効果を得ることができる。すなわち、複数の制御パターン候補は、省エネ性及びイニシャルコストのそれぞれに関する情報を含み、所望の制御仕様として、省エネ性又はイニシャルコストのどちらを優先させるかが入力されるので、省エネ性及びイニシャルコストに関するユーザー毎のニーズに対応した制御ソフトウェア(151)を構築することができる。
【0080】
(その他の実施形態)
以上、実施形態及び変形例を説明したが、特許請求の範囲の趣旨及び範囲から逸脱することなく、形態や詳細の多様な変更が可能なことが理解されるであろう。また、以上の実施形態及び変形例は、適宜組み合わせたり、置換したりしてもよい。さらに、以上に述べた「第1」、「第2」、…という記載は、これらの記載が付与された語句を区別するために用いられており、その語句の数や順序までも限定するものではない。
【産業上の利用可能性】
【0081】
以上に説明したように、本開示は制御ソフトウェア生成システムについて有用である。
【符号の説明】
【0082】
100 制御ソフトウェア生成システム
110 記憶部
120 生成部
151 制御ソフトウェア
152 センサ情報
153 保守運用ソフトウェア
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21