第五章 オブジェクト指向言語による 設備機器モジュールの抽象的定義法

第五章
オブジェクト指向言語による
設備機器モジュールの抽象的定義法
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
第5章 オブジェクト指向言語による設備機器モジュールの抽象的定義法
5.1
はじめに
第 2 章で示したように、プログラムのモジュール化はコードの再利用性を向上させ、ソフトウェア
の開発効率を高めるとともに、繰り返し使用されることによる堅牢性の向上が期待できる。モジュー
ル化されたプログラムコード群の連携を行うためには、個別のプログラムがもっている機能を抽象的
に記述することが有効であり、近年のオブジェクト指向プログラミングはこのような要求にこたえる
ものである。そこで本章では、オブジェクト指向言語を用いて設備機器の抽象的な構造を記述し、
コードの独立性や可読性を高めることによって、連携性と再利用性を確保することを目的とする。
具体的には、モジュール形式を持つ設備シミュレーションプログラムを例にとり、既往のプログラ
ムにおける機器モジュールの定義方法について問題点を把握した。明らかとなった問題は主に、ソル
バ機能やインターフェース機能と機器モジュールの結びつきが大きいことに起因するものであったた
め、この分離を目的に機器モジュールの抽象クラスを開発した。抽象クラスとは、個別具体的な機能
が記述された具体クラス群に共通する性質を抽出し、一つの概念としてまとめたクラスである。具体
的なクラスの特定を留保したまま、抽象化された概念を用いてコーディングを行うことが可能になる
ため、プログラムの各機能の結びつきを希薄化することができる。モジュール形式の設備シミュレー
ションに即して言えば、個別機器の挙動を示す物理式等が記述されたクラスが具体クラス、それらに
共通する「モジュール」としての振る舞いが記述されたクラスが抽象クラスとなる。
また、抽象クラスを利用することで、派生クラスの言語依存性の軽減を図った。従来、設備シミュ
レーションソフトウェアの多くは FORTRAN 言語で開発されてきたが、近年では、例えば JAVA 言語に
よる BEST1)、C 言語による EESLISM2)、C++言語による SPARK3)などが開発されている。また、表計算
ソフトウェアによる計算 4)に親しんだユーザーなどは、Basic 言語との親和性の高い VBA について知識
を持つと考えられる。これらのユーザーがモジュールを持ち寄り、連携をとるためにはプラット
フォームの言語依存性は小さいことが望ましい。そこで、本研究では、前述の抽象クラスと .NET
Framework の技術を用いることで、従来の主流言語である FORTRAN ならびに近年の言語である C#,
Basic, C++によって記述された機器モデルを混成させて解くことを可能とした。
開発したプログラムは、既存の設備シミュレーションプログラムとの出力値比較および実施設にお
ける BMS データとの比較を行うことで動作検証を行い、複数言語による断片的なプログラムコードが
破綻なく連成計算されることを確認した。
5-1
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
5.2
既存のプログラムにおけるモジュール定義法とオブジェクト指向言語による実装法
建築分野における代表的なモジュール形式の設備シミュレーションプログラムとしては、米国
Wisconsin 大学において開発された TRNSYS5)および米国 NBS（現 NIST）において開発され、名古屋大
学中原研究室において改良が行われた HVACSIM+(J)が挙げられる†1) 。
両プログラムともに FORTRAN 言語を用いており、個別の機器モデルは SUBROUTINE として記述され
る。図 5.1 に両プログラムにおける機器モジュール記述方法を示す。モジュールの独立性を高めるため
に SUBROUTINE の引数に一定の工夫がなされているが、いくつかの問題点が存在する。そこで、オブ
ジェクト指向言語を利用することでこれらの問題点を解消する機器モデルを開発した。以下に、問題
点および問題の解決法を記す。
TYPEn(XIN, OUT, PAR, SAVED, IOSTAT)
TYPEn(TIME, XIN, OUT, T, DTDT, PAR, INFO, ICNTRL)
XIN, OUT, PAR
SAVED
IOSTAT
T, DTDT
INFO
ICNTRL
・・・HVACSIM+(J)
・・・TRNSYS
・・・入出力およびパラメータを示す実数値配列
・・・任意の実数保存領域
・・・出力の状態ベクトル判定用整数値配列
・・・時間依存性状態変数の状態値および微分値保存用実数値配列
・・・UNIT に関する情報を示す整数値配列
・・・コントローラ制御値保存用整数値配列
図 5.1　TRNSYS および HVACSIM における機器モジュール記述法
5.2.1
モジュールの特徴づけと永続性の保証方法
TRNSYS、HVACSIM+(J)のいずれのプログラムも機器モデルを『TYPEn（n は任意の整数値）』とい
う名称をもつ SUBROUTINE として記述している。従って、構築するシステムモデル中に同一の TYPE
を複数個設置する場合（ポンプ TYPE に基づいて 1 次ポンプおよび 2 次ポンプを設置する場合等）に
は、これらを適切に区別するための方法が必要となる。両プログラムともにパラメータを意味する
PAR という実数値配列を引数として渡し、これによって TYPE を特徴づけることで対処している。こ
こで、特定の実数値配列によって特徴づけられた TYPE を特に UNIT と呼ぶ。UNIT は固有のパラメー
タを持った実体であるが、SUBROUTINE であることの制約により、それ自体に変数を保持することが
できない。従って、より上位の SUBROUTINE が各 UNIT を特徴付けるパラメータを保持することとな
る†2) 。しかし、しかし、このような構成をとると、UNIT を外部のプログラムで再現しようとする場合
に、上位 SUBROUTINE の巨大な実数値配列にアクセスする必要が生ずる。従って、外部のプログラム
において TYPE を表現した SUBROUTINE を再利用しようとしても、同一の UNIT を再現するために
は、上位 SUBROUTINE の機能を含めて移植せねばならず、プログラムの再利用性という点で問題があ
る。また、TYPE を特徴づける方法は基本的には実数値配列に限定されてしまうため、個別のモジュー
ルの機能の拡張性に限界が生じてしまう†3) 。
TYPE とは機能の『型』であり、UNIT は型をもとに生み出された『実体』であると言え、このよう
†1 この他、米 Lawrence Berkeley National Laboratory で開発が行われている SPARK もモジュール形式のシミュレーショ
ンプログラムとして挙げることができる。ただし、個別の新規モジュールをプラグインとしてプラットフォームに
追加するという仕様ではなく、特定のフォーマットに従って記された関数群を SPARK Parser プログラムが解釈し、
計算の都度、C++言語の実行ソースを吐き出すという仕様である。従って、モジュール形式ではあるものの、SPARK
プラットフォーム内部での再利用性が主たる目的であると考えられ、本研究におけるモジュールの再利用性とは性
質が異なると思われる。
†2 HVACSIM+(J)では、個別の TYPE を特徴付けるパラメータは、これらを連立して解く機能を持つ SUBROUTINE であ
る MODSIM によって一括して管理されている。
†3 例えば、外気条件に応じたフリークーリングを含む冷却塔のスケジュール設定などは、日時、実数、真偽値等を組
み合わせた複合的なデータ型となるが、これを実数配列のみで表現することは非常に困難である。
5-2
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
な対応の概念はオブジェクト指向言語における『クラス』と『インスタンス』の関係に類似してい
る。しかし、インスタンスは任意のデータ型を用いて特徴づけることが可能であるというメリットが
ある。そこで、機器一般の抽象的な存在として抽象クラスである『AbstractDevice』クラスを定義し
た。このような抽象クラスの存在により、派生クラスは自由なデータ型で自らを特徴づけられるよう
になる。また、シリアライズ（インスタンスの特徴を一列のデータに変換すること）およびデシリア
ライズ（一列のデータからインスタンスを再構成すること）の機能をクラス自身に持たせることで、
上位クラスへの依存性を低減させた。具体的にはモジュール固有の情報を XML 形式のファイルとして
読み書きするためのメソッドを定義した。派生クラスにおいて固有のデータ型のシリアライズ機能を
付加することが可能となり、個別機器モデルの構造の自由度は上昇する†1) 。このような入出力方式とす
れば、上位クラスに依存せずに機器モジュールを再構成することができるようになる。従って、例え
モジュールの編集、書き出し処理や読み取り処理を行う外部のプログラムを作成する場合など、クラ
スをそのまま再利用することが可能となり、プログラム相互の連携をとることが容易となる6)。
図 5.2 に、既往のプログラムおよび開発したプログラムにおける機器モジュール特徴づけ方法の比較
を示す。既往のプログラムにおいては、機器モジュールを特徴付ける実数値配列が上位クラスを経由
して外部ファイル等と通信をするのに対し、本プログラムにおいてはクラス自身が入出力処理を持
ち、自由なデータ型でインスタンスが特徴づけられていることがわかる。この結果、クラスの独立性
が増し、クラス間の関係性は操作が主となるため、バグ発生が抑制されると期待できる。
FORTRAN 等
オブジェクト指向言語
外部ファイル書出
外部クラス
上位SUBROUTINE
操作が主
実数値配列
***.dat
データ授受
+
操作
実数値配列
実数値配列
SUBROUTINE1
SUBROUTINE2
***.xml
シリアライズ
クラス1
クラス2
実数型変数
bool型変数
画像
ユーザー定義型変数
整数型変数
文字列型変数
日付型変数
ユーザー定義型変数
***.xml
シリアライズ
図 5.2　機器モジュール特徴づけの方法の比較
5.2.2
反復収束計算への対応
プログラムの構成をモジュール形式とすると、個別モデルの入出力関係を任意に設定することがで
きる。一方、ソルバにとってはモジュール内部の物理式などがブラックボックス化されることになる
ため、複数のモジュールが組み合わされたシステムを解析的な操作で解くことは難しくなる。従っ
て、通常は、真の解に近い初期値を設定した上で、システム内の状態変数のヤコビアン行列を用いな
がら数値計算的に解くことになる。ヤコビアン行列もまた解析的に知ることはできないことが多いた
め、有限差分によって数値計算的に求めることになる。このため、個別モジュールには、現在の計算
がヤコビアン行列を計算するためのものか、通常の計算処理のためのものかを判定するためのフラグ
が必要となる。
非オブジェクト指向言語においては、基本的に単独の関数を一つのモジュールに対応させることに
なるため、前述のフラグは関数の引数として与えられる†2) 。しかし、引数として与えられた整数値によ
†1 機器モデル一般のデータに関するシリアライズ機能は抽象クラスで定義されるため、派生クラスでは関数を override
して必要なデータのシリアライズ処理を追加する。
†2 TRNSYS においては整数配列である INFO の値を参照することで収束計算の反復回数がわかるため、これを利用して
微分値計算であるか否かの判定を行うことができる。HVACSIM+(J)においては実数値配列である SAVED に前回呼び
出し時点を記録する等の方法を取ることで、ある程度の判定を行うことができる。
5-3
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
る条件分岐文は、モジュール単体としての可読性と再利用性を減少させてしまう。また、
SUBROUTINE とモジュールが一対となっているため、機器モデルが複雑化して SUBROUTINE の分割
が必要となる場合には、モジュールがプログラム内部に分散されることになってしまう†1) 。
一方、オブジェクト指向言語においては、複数の関数をパッケージ化したクラスを定義することが
できるため、関数レベルで処理を分けることができる。そこで、反復収束計算時におけるソルバから
の要求に答え、適切なタイミングで出力計算を行うために、AbstractDevice クラスに表 5.1 のメソッド
を定義した。初回および最終の計算処理はシミュレーション開始時および終了時に一度ずつ呼び出さ
れる処理であり、外部ストリームの開閉処理や機器モデルの初期化処理などがこれに相当する。収束
計算中は時刻が一定となるため、収束計算前後の処理としては境界変数読込処理や計算結果書出処理
等が挙げられる。図 5.3 に、既往のプログラムおよび開発したプログラムにおける機器モジュールの処
理振り分けの方法の比較を示す。関連する変数との連携がクラス内部で完結することで、可読性と堅
牢性の向上が期待できる。
表 5.1　AbstractDevice クラスにおける反復収束計算関連の抽象メソッド
メソッド名称
メソッドの内容
FirstCalculation ( )
初回の計算処理
ProcessBeforeConverge ( )
収束計算前の計算処理
OutputCalculation ( )
収束計算中の計算処理
ProcessAfterConverge ( )
収束計算後の計算処理
LastCalculation ( )
最終の計算処理
IrregularStopCalculation ( )
エラー停止時の最終計算処理
FORTRAN 等
上位SUBROUTINE
機器モジュール
出力計算指令
+
計算の種類
オブジェクト指向言語
外部クラス
機器クラス
if...
処理1
else if...
処理2
else...
処理3
計算種類に応じた
関数の呼び出し
クラス内部で連携
変数A
関数1
処理1
変数B
関数2
処理2
変数C
関数3
処理3
変数D
外部SUBROUTINE
SUBROUTINEが巨大化した場合
図 5.3　機器モジュール処理振り分けの方法の比較
5.2.3
機器モジュールの追加とコンパイル
モジュール形式のプログラムの基本的戦略は、一定の規則に従ったモジュールを組み合わせること
で、汎用的な問題に対してモデル構築を可能にすることにある。 HVACSIM+(J)、TRNSYS において
は、『一定の規則に従う』とは、SUBROUTINE の引数が同一であることを指しており、図 5.1 に示し
たような特定の関数を規定している。しかし、実際のモジュールの呼び出しに際しては、関数の判別
をしなければならないために、条件分岐文が必要となる。従って、モジュールの変更、追加、削除の
ためにはモジュール以外の部分を含めたリコンパイルが必須となる。歴史の古い FORTRAN 言語にお
いてはコンパイラ相互の互換性の問題もあり、煩雑なコンパイル作業はモジュール形式のシミュレー
†1 例えば HVACSIM+(J) TYPE654 は詳細な吸収式熱源のモデルであり、15 の Subroutine と 3 の Function から構成されて
いるが、これらが一体のモジュールであることを知るには、個別の関数を読み解いていくか、別途マニュアルがな
ければ困難である。
5-4
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
ションを行う上での一つの障壁となってしまう†1) 。
一方、オブジェクト指向言語の場合、『一定の規則』が存在する場合には、これを抽象化してイン
ターフェースまたは抽象クラスとして定義することが通常である。こうした構成をとると、抽象化さ
れた機能のみが必要な上位クラス（ソルバ等）においては、抽象クラス名称あるいはインターフェー
ス名称を利用して機能を呼び出すことが可能となる。その結果、条件分岐文は不要となり、モジュー
ルはその他の機能から完全に分離される。図 5.4 に、従来のモジュール形式プログラムのモジュール呼
び出しコード（HVACSIM+(J)）と本研究で開発したプログラムのモジュール呼び出しコードを示す。
HVACSIM+(J)においては、TYPEn という SUBROUTINE を特定するために整数値 n の比較を一つずつ
行っているが、本開発プログラムにおいては、抽象クラス名称を利用して一行で表現されるているこ
とがわかる。
図 5.5 に AbstractDevice 派生クラスの開発法を示す。AbstractDevice から直接に派生させたクラスを作
成する（Template Method Pattern）か、既存のプログラムコードを AbstractDevice クラスの派生クラスで
ラップする（Adopter Pattern）ことで、新規のモジュールを定義することができる 4-7) 。
IF(ITYPE .EQ.4 01) THEN
if (time.g e.prin ti me) prin t *,' g et into type ',i type,iu ,time
CALL TYP E401(X IN,OUT,PAR(NN),SAVE D(NNN),IOS TAT)
if (time.g e.prin ti me) prin t *,' g et away from type ',itype
E LSEIF(ITYPE .EQ.402) THE N
if (time.g e.prin ti me) prin t *,' g et into type ',i type,iu ,time
CALL TYP E402(X IN,OUT,PAR(NN),SAVE D(NNN),IOS TAT)
if (time.g e.prin ti me) prin t *,' g et away from type ',itype
E LSEIF(ITYPE .EQ.403) THE N
if (time.g e.prin ti me) prin t *,‘ get in to type ’ ,itype,iu ,ti me
CALL TYP E403(X IN,OUT,PAR(NN),SAVE D(NNN),IOS TAT)
if (time.g e.prin ti me) prin t *,' g et away from type ',itype
E LSEIF(ITYPE .EQ.404) THE N
if (time.g e.prin ti me) prin t *,' g et into type ',i type,iu ,time
CALL TYP E404(X IN,OUT,PAR(NN),SAVE D(NNN),IOS TAT)
if (time.g e.prin ti me) prin t *,' g et away from type ',itype
ソルバの条件分岐は無くなり
コンパイルは不要となる
deviceTypeInstance.OutputCalculation();
図 5.4　モジュール呼び出しソースコード
左：FORTRAN　右：オブジェクト指向言語
HvacSimDevices
AbstractDevice
AbstractDevice の操作
Adopter Pattern
FluidNetwork
HeatPumpChiller
HvacSimTYPE502
NTUHeatExchanger
FangerModel
Template Method Pattern
LagrangianDataReader
図 5.5　Template Method Pattern と Adopter Pattern を
用いた機器モジュール開発法
†1 HVACSIM+(J)においては Visual Fortran および Digital Fortran でのコンパイル実績があるが、Salford Ftn95 や Linux で
主流の g77 では多くのコンパイルエラーが生じる。また、TRNSYS においては Microsoft Power Station FORTRAN
Developer Studio と Digital Visual Fortran developer studio が推奨されており、それぞれに対応したコンパイル方法がマ
ニュアルに記載されている。仮に、モジュールの追加に際して全体のリコンパイルが必要な仕様にしてしまうと、
このようなコンパイラ相互の仕様の違いに基づくエラーについてもモジュール作成者が調整作業を負担することに
なってしまう。
5-5
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
このようにして定義された派生クラスは、プログラム上 AbstractDevice クラスとして扱うことができ
るため、AbstractDevice クラスを操作する主体である、ソルバやインターフェースなどの上位クラスは
個別の具体的な機器モジュール部分とは別個のアセンブリとすることが可能となる。結果として、新
規開発した機器モジュール部分のみのコンパイル作業によって、プラグインとしてモジュールの追加
が可能となる。図 5.6 に機器モジュールの分離の概念を示す。
図 5.6　個別具体的機器モジュール分離の概念
さらに本研究においては、ソルバとモジュールの分離構造をいかし、共通言語基盤（CLI : Common
Language Infrastructure）に従ったアセンブリを利用することで、多言語混成モデルを扱うことを可能に
した。CLI とは言語非依存のプログラム開発および実行環境である。図 5.7 に CLI 環境におけるプログ
ラム実行のフローを示す。任意のプログラム言語によるソースコードは、共通中間言語（ CIL :
Common Intermediate Language）にコンパイルされた後、実行時に CLI によってネイティヴコードに変
換される。従って、AbstractDevice 派生クラスを任意の言語で開発しても、これを別個のアセンブリと
して CIL にコンパイルできれば、これらを混成させて実行することが可能となる。このように、言語
依存性が無くなることで、これまでに開発が行われた多くの FORTRAN 言語による設備機器モデルの
再利用が可能になると期待できる。
共通言語基盤（CLI）
ソース
コード
コンパイラ
CIL
（中間言語）
クラスライブラリ
プログラム
実行
プログラム中で使用されているクラス情報が
クラスライブラリから読み出されメモリへロード
実行
クラス
ローダー
JIT
コンパイラ
ネイティヴ
コード
図 5.7　CLI 環境におけるプログラム実行のフロー
5-6
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
その他の機能
5.3
前節で提案したモジュール構造に基づく設備シミュレーションプログラムの開発を行った。全体ク
ラス構成を UML（Unified Modeling Language）を用いて図 5.8 に示す。ただしプロパティおよびメソッ
ドの全てを記述することは不可能であるため、主要な要素のみを表示している。設備システムモデル
をプログラムレベルで操作するクラスである HvacModel クラスを中心として、左上方のユーザーイン
ターフェースクラス群、左下方のソルバクラス群、右方の個別機器モデル群から構成されており、
各々について抽象クラスあるいは Interface を定義することで機能の拡張性を保証している。
任意のユーザー
インターフェース
自身を登録する
<<Interface>>
IHvacModelObserver
-IHvacModelObserver を
+ HvacModel のEvent に
実装したクラス
HvacModel
+システム全体に関するプロ
イベントを通知する
解く
1
対する処理
-IHvacModelObserver を
実装したクラスの操作
1
1..*
VisualConnector
1..*
1..*
Observer Pattern
NLESolver
+RelativeErrorTolerance
+AbsoluteErrorTolerance
+SolveNLE
1
1
DeviceTypeIO
+SaveDeviceTypeToXML
+LoadDeviceTypeFromXML
1..*
1
1
1..*
HvacModelSolver
+シミュレーション条件に関す
るプロパティ群
+SolveHvacModel
1
HvacLayer
+HvacLayerName
+MaxTimeStep
+DeviceType の操作
+状態変数の操作
XMLファイルで
入出力処理
1..*
1..*
AbstractDevice
+HvacLayerName
+MaxTimeStep
+DeviceType の操作
解く
陰的微分代数方程式を 解く
1
FluidNetwork
IDESolver
+RelativeErrorTolerance
+AbsoluteErrorTolerance
+StopTime
HeatPumpChiller
NTUHeatExchanger
+SolveIDE
LevenbergMardquardt
+LoadHvacModel
HvacModelLogViewer
HvacLayerSolver
1
+HvacLayer の操作
+状態変数の操作
+EventHandler の設定
HvacLayerList
+シミュレーション条件に関す
るプロパティ群
+SolveHvacLayer
- IDEResidualErrorFunction 1
- NLEResidualErrorFunction
非線形連立代数方程式を 解く
1
パティ群
HvacModelIO
XMLファイルで
+SaveHvacModel
入出力処理
FangerModel
Dassl
LagrangianDataReader
図 5.8　開発プログラムの全体クラス構成
5.3.1
数値計算法
モジュール形式のシミュレーションを実行するためには、個別機器の入出力情報を手掛かりに状態
変数を数値計算的に解く必要がある。特に、制御系の検討を主目的とした動的シミュレーションのた
めには、対象物の時間遅れを考慮する必要があり、このためには、非線形連立代数方程式系（NLEs :
Nonlinear Equations）ソルバに加え、微分代数方程式系（IDEs : Implicit Differential Equations）のソルバ
を備えることが望ましい。
図 5.9 にソルバクラス群の関係性を UML で示す。非線形連立代数方程式を解くための NLESolver、
連立常微分方程式を解くための IDESolver をそれぞれ抽象クラスとして定義した。実装は派生クラスに
委ねられているため、新たな解法の導入が容易である。複数個の設備機器クラスを保持する HvacLayer
クラスはこれら二つのソルバクラスを利用して HvacLayerSolver クラスによって解かれる。ただし、
HvacLayerSolver クラスは直接に呼び出されず、HvacModelSolver クラスを経由して利用される。
5-7
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
1
非線形連立代数方程式を解かせる
HvacModel
解く
1
HvacModelSolver
シミュレーション条件に関
するプロパティ群
NLESolver
RelativeErrorTolerance
AbsoluteErrorTolerance
SolveNLE
SolveHvacModel
LevenbergMardquardt
1
1..*
1
HvacLayerSolver
シミュレーション条件に関 1
するプロパティ群
SolveHvacLayer
IDEResidualErrorFunction
NLEResidualErrorFunction
Template Method Pattern
陰的微分代数方程式を解かせる
1
解く
1..*
HvacLayer
HvacLayerName
MaxTimeStep
DeviceTypeの操作
IDESolver
RelativeErrorTolerance
AbsoluteErrorTolerance
StopTime
SolveIDE
Dassl
状態変数の操作
図 5.9　ソルバクラス群 UML 図
1）非線形連立代数方程式（NLEs）の解法
非線形連立代数方程式を数値計算的に解く場合、微分値を利用することが一般的である。図 5.10 を
用いて、1 状態変数、1 関数の場合について説明する。解くべき関数 f(x)の関数形状が図のように表現
された場合、f(x) = 0 となるのは x = x0 の場合である。ただし、解は未知であるため、任意の初期値 x1 を
出発点とせざるを得ない。x1 の点で微分値 f’(x)を評価すると正の値を取っており、x1 よりも少ない値を
x がとれば f(x)は、より 0 に近づくことがわかる。従って初期値である x1 を左方に進める。この操作を
繰り返し、f(x) = 0 である x0 に近似させるのが基本となる。ここで問題となるのは、x の更新量 ∆x の決
定法である。ニュートン法は、仮に問題が線形であったと仮定したら f(x) = 0 となる点を次の x の候補
とする。図中では x2 が次の候補であり、∆x2 が更新量である。
最急降下法は微分値のみに着眼して、適当な大きさの係数を乗じて次の x の候補を決定する方法であ
る。図中では x3 が次の候補であり、∆x3 が更新量にあたる。ニュートン法に比較して粗くなってしまう
が、図 5.11 のように問題の非線形性が強い場合や解が真の解から非常に遠く離れている場合には、大
域的な探索が容易なため、有効である。
f(x)
f(x)
Δx3 = -f’(x1)×α
Δx3 = -f’(x1)×α
f’(x1)
x3
x2
x0
f’(x1)
x1
Δx2
x1
入力 x
Δx2
図 5.10　ニュートン法解法図
入力 x
図 5.11　最急降下法解法図
本研究では、非線形連立代数方程式のデフォルトの解法として Levenberg-Marquardt 法8) を採用した。
Levenberg-Marquardt 法は最急降下法と Newton 法の折衷による解法である。まず、Levengerg-Marquardt
5-8
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
法の前提として最急降下法および Gauss-Newton 法に関して概説する。なお、最小化すべき数値は式 5.1
で示される重みつき誤差二乗和とする。
n
S  x =∑ wi [ y i− f i  x]
2
(5.1)
i=1
・最急降下法
最急降下法は反復の各回において S の減少量が局所的に最大となるように修正方向を決定する方法
である。修正方向ベクトル（最急降下方向）は式 5.2 で示される。修正方向に沿った修正量の決定方法
はいくつかあり、一定値とする場合、ステップ数に従って低減させていく場合（ Simulated Annealing
法：焼きなまし法）、線形探索をおこなってステップごとに変更する場合等がある。従って各ステッ
プの x の値は式 5.3 で示される。
 x=−
∂S
∂xj
(5.2)
x j , k1=x j , k k⋅g j , k
(5.3)
・Gauss-Newton 法
式 5.1 を最小化するためには S(x)の偏微分値が 0 をとる必要があり、式 5.4 が成立する。非線形連立
代数方程式をニュートン法で解く場合、各ステップの修正量は式 5.5 で示される。ただし右辺分母は式
5.1 を 2 階編微分することで求めることができる（式 5.6）。従って各タイムステップの x の値は式 5.7
で示される。ここで計算量を削減するために、式 5.6 右辺第 2 項の 2 階編微分を省略する方法を GaussNewton 法と呼ぶ。この方法は残差(y-f(x))が小さい場合、および f の 2 階編微分値が小さく線形に近い場
合に有効であると推測できる。
∂S
=0
∂xj
 
∂S
 x k =−
/
∂xj
(5.4)
m
2
∑ ∂∂x Sx
k=1
j
k

(5.5)
2
m
m
2
∂f
∂f
∂ f
∑ ∂∂x Sx =∑ {2 ∑ [ ∂ x i wi ∂ x i − ∂ x ∂ ix wi  y i− f i  x ]}
k =1
k=1
i
j k
j
k
j
k
(5.6)
x k 1=x k  x
(5.7)
最急降下法は大域的な探索に優れている半面、解周辺での収束速度には難がある。逆に Newton 法は
解周辺での収束は速い一方で、真の値との乖離が大きい場合や非線形性が強い場合に安定性が悪い。
Levenberg-Marquardt 法は両者を折衷する方法であり、各計算ステップの修正量は式 5.8 で表現される。
真の解から離れ、非線形性の影響が大きい場合には λ を大きくとり、解に近づくにつれて λ を低減する
ことで安定かつ高速に解を求めることができる。代表的な動的シミュレーションプログラムである
HVACSIM+(J)においても折衷的な手法である調整 Powell Hybrid 法を用いている。
5-9
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
−1 
 x= A A I  A−
f  x 
(5.8)
2）陰的微分代数方程式（IDEs）の解法
常微分方程式（ODE : Ordinary Differential Equations）は式 5.9 の形で表現されることが一般的であ
る。数値解法は大きく一段解法と線形多段解法に大別できる。一段解法としてはルンゲクッタ法が知
られており、線形多段解法としては Adams 法および後退微分公式（BDF : Back Differential Formula）が
一般的に知られている。代表的な動的シミュレーションプログラムである TRNSYS は Adams 法を、
HVACSIM+(J)は後退微分公式をそれぞれ用いている。本プログラムでは、後退微分公式を採用した。
・後退微分公式9
）
式 5.10 に線形多段階法の基礎式を示す。一段解法であるルンゲクッタ法が Taylor 級数展開を利用
し、ある時点での状態値のみによって積分計算を行うことに対して、線形多段解法は過去の状態値の
系列を利用する。従って、タイムステップの変化時や、計算開始時のプログラムコードは煩雑になる
ものの、ステップごとの関数評価は少なくなる。空調システムは硬い系であることが知られており、
安定的な解を求めるためには陰的な解法を用いるべきである。線形多段解法の陰的な解法としては後
退微分公式が一般的であり、式 5.11 の形で表現された陰的微分代数方程式（IDE : Implicit Differential
）
Equations）に対応した公開のソルバとして DASSL が存在する10 。本プログラムではデフォルトのソル
バとして DASSL を採用し、C#への移植を行った。
y ' = f t , y
k
k
j=0
j =0
∑  j y n − j =h ∑ B0 y ' n − j
F t , y , y ' =0
(5.9)
(5.10)
(5.11)
・動作検証
HVACSIM+(J)に定義された冷却／除湿コイルモデル（TYPE602）を解き、Popolo Dynamic Simulator
の出力と HVACSIM+(J)の出力と比較することで、IDEs ソルバの動作検証を行った。同モデルは冷却コ
イルの熱容量を考慮しながら、コイルの出口水温、出口空気乾球温度、出口空気絶対湿度の変化を計
算する動的モデルである。モデルの入出力を図 5.12 に示す。表 5.2 に主なパラメータおよび設定値一覧
を示す。入力値は実施設から取得した BMS データを用いた。冷却／除湿コイルモデルの出口水温につ
いて、HVACSIM+(J)および Popolo Dynamic Simulator で積分計算を行った結果を図 5.13 に示す。両プロ
グラムの出力は完全に一致しており、積分計算が正常に行われたことが確認できる。
5-10
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
水流量
水入口温度
乾き空気流量
空気入口乾球温度
空気入口絶対湿度
水出口温度
空気出口温度
水出口温度微分値
空気出口温度微分値
空気出口絶対湿度微分値
コイル全熱負荷
コイル顕熱負荷
コイル外表面湿り率
HVACSIM+(J)
TYPE602
冷却／除湿コイル
図 5.12　HVACSIM+(J) TYPE602 冷却／除湿コイルモデル入出力
表 5.2　コイルモデルの主要パラメータ一覧
パラメータ名称
値
8
列数 [列]
フロータイプ
シングルフロー
プレート形
1.021
113.818
125.559
0.236
4
0.000115×1.524×0.176
9.17595
8.78992
60
0.00952
0.0087
0.022
0.39
タイプ
正面積 [m2]
熱容量 [kJ/C°]
外表面積 [m2]
熱伝導率 [kW/(m·K)]
フィン数 [枚/cm]
厚さ×長さ×幅 [m]
外表面積 [m2]
内表面積 [m2]
チューブ数 [本/列]
外径 [m]
内径 [m]
中心間距離 [m]
熱伝導率 [kW/(m·K)]
コイル
フィン
チューブ
HVACSIM+(J)
Popolo
22
16
時刻
図 5.13　冷却除湿コイル出口水温の推移
5-11
21:00
20:00
19:00
18:00
17:00
16:00
15:00
14:00
13:00
12:00
11:00
10:00
9:00
10
8:00
コイル出口水温[℃]
28
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
3）NLEs と IDEs が複合された問題の解法
前述の両ソルバを用いて NLEs および IDEs を連成して解くための計算フローを図 5.14 に示す。
各ソルバは状態変数の修正量および修正方向を計算するために、関数の微分情報を必要とする。微分
情報は誤差評価関数を利用して数値計算的に求めることとし、 delegate を用いることで誤差評価関数を
引数として渡す仕様とした。シミュレーション対象となるシステム内の状態変数は非時間依存の変数
と時間依存の変数に分けられる。前者は NLEs ソルバによって解かれ、後者は IDEs ソルバによって解
かれる。IDEs ソルバに渡される誤差評価関数は、時間依存の変数が特定の値に固定されたという条件
の下、NLEs ソルバにより非時間依存の状態変数が解かれた結果の誤差を表す関数である。また、IDEs
ソルバは誤差評価関数によって評価された誤差に応じてタイムステップを増減させる。
Input
初期値ベクトル：Yinit, Y’init, Xinit
境界変数ベクトル：A, 許容誤差：Ε1, Ε2
誤差評価関数：f1(X, y, y’, A), f2(x, Y, Y’, A)
状態変数更新処理：g1(y, y’, f1), g2(x, f2)
初期値設定 Y0 = Yinit, Y’0 = Y’init, X0 = Xinit
Yes
f1(X0, Y0, Y’0, A) < Ε1
No
状態変数更新 (Ym+1, Y’m+1) = g1(Ym, Y’m, f1)
Yes
f2(X0, Ym, Y’m, A) < Ε2
No
状態変数更新 (Xn+1) = g2(Xn, f2)
f2(Xn, Ym, Y’m, A) < Ε2
No
Yes
NLEs 解 Xsol = Xn
f1(Xsol, Ym, Y’m, A) < Ε1
No
Yes
IDEs 解 Ysol = Ym, Y’sol = Y’m
Output: Ysol, Y’sol, Xsol
図 5.14　NLEs および IDEs 連成計算フロー
5-12
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
5.3.2
ユーザーインターフェース
HvacModel クラスはソースコードレベルで設備システムとの対話を行うクラスであり、設備機器モ
デルの追加・削除、入出力の連結、パラメータの設定、HvacLayer への所属等を操作する。しかし、一
般のユーザーにソースコードレベルでのモデル操作を求めることは酷であり、適切なユーザーイン
ターフェースが必要となる。
HASP/ACLD や HVACSIM+(J)においては、ユーザーインターフェースは広域変数を介してソルバ等
の他の機能と強く結び付けられていた。しかし、GUI を前提として多人数での開発を行う場合、この
ような構成をとると、個別の開発主体が考慮しなければならない範囲は増大するため、プログラムの
進化が阻害されてしまう。
本プログラムにおいては、Observer Pattern を用いることで複数開発主体によるインターフェースの
同期を可能にした。図 5.15 に Observer Pattern によるユーザーインターフェースの同期法を UML で示
す。HvacModel で行われる各種の設備モデル操作について、delegate を利用して各種のイベントを定義
し、これらのイベント通知を受ける IHvacModelObserver を Interface として定義した。HvacModel の主
な イ ベ ン ト を 表 5.3 に 示 す 。 個 別 の 開 発 者 が 開 発 す る 具 体 的 な ユ ー ザ ー イ ン タ ー フ ェ ー ス は
IHvacModelObserver を実装し、これにより HvacModel を操作する主体となると同時に、HvacModel へ
の操作履歴を観測する Observer となる。従って、他の開発主体が開発したユーザーインターフェース
を明示的に把握せずとも、自らを最新の状態に維持することができる。
図 5.16 に開発したユーザーインターフェースのサンプルを示す。見かけ上は一体化した 3 種のユー
ザーインターフェースはそれぞれ独立して存在しており、HvacModel クラスを介したイベント通知に
より同期している。それぞれが担う役割は、HvacModel クラスに定義された操作の一部分に過ぎず、
多数の主体による部分的なユーザーインターフェースの開発の積み重ねが、総体としてプログラムの
進化へ結びついていることがわかる。以下に各ユーザーインターフェースの概要を記す。
1）VisualConnector
設備機器の追加・削除、入出力の連結、パラメータの設定等をグラフィカルに操作するためのクラ
スである。
2）HvacLayerList
設備機器モデルが属する HvacLayer の追加・削除、名称変更、解く際の順序等を操作するためのクラ
スである。
3）HvacModelLogViewer
HvacModel から通知された各種イベントをログ表示するためのクラスである。
5-13
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
1
イベントを
通知する
HvacModel
IHvacModelObserver
AddObservers
DeleteObservers
操作する
各種イベント通知処理
VisualConnector
1..*
<<Interface>>
IHvacModelObserver
HvacModelLogViewer
HvacModel のEvent に対
HvacLayerList
する処理
図 5.15　Observer Pattern による
ユーザーインターフェースの同期法
表 5.3　HvacModel クラスの主なイベント
・HvacModel 初期化イベント
・HvacLayer, AbstractDevice インスタンス名称変更イベント
・HvacLayer の追加・削除イベント
・HvacLayer への AbstractDevice 追加・削除イベント
・HvacLayer, AbstractDevice 順序変更イベント
・AbstractDevice 入出力接続・切断イベント
・状態変数値変更イベント
VisualConnector
HvacLayerList
HvacModelLogViewer
図 5.16　ユーザーインターフェースの同期例
5-14
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
5.4
提案したモジュールの動作検証
本節では、実際にモジュールを連結させてシステムモデルを構築し、動作検証を行った結果につい
て報告する。
提案した抽象的設備機器クラスの存在により、派生クラスが実装する個別具体的な機能と、上位の
ソルバやインターフェースの機能との間で、ソースコードレベルでの依存関係は存在しなくなる。
従って、仮に派生クラスを複数の言語によって開発したとしても、抽象クラスを介してモデル操作が
行われるため、全体のシステムは問題無く動作するはずである。まず、この点を確認するために、複
数の言語による機器モデル定義を行い、これらを相互に接続した一般的な熱源一次システムモデルの
動作検証を行った。さらに、既存のコードを活用するという観点から、FORTRAN 言語によって開発さ
れた TRNSYS および HVACSIM+(J)のモデルの連成計算を実行した。
提案した抽象的設備機器クラスは、上位のクラスと個別機器モデルとの依存関係を消滅させるとと
もに、個別機器モデル相互の依存関係も消滅させる。従って、各機器モデルは、他の機器モデルの計
算とは独立して計算することができ、この特徴を利用すれば別個の CPU を利用した並列計算が可能と
なる。そこで、ペリメータまわりの FCU を対象に、マルチ CPU を利用した並列計算による計算速度向
上について確認した。
5.4.1
多言語混成モデルの動作検証
吸収冷温水機・冷却塔・一次ポンプから構成される、図 5.17 に示すような一般的な熱源システムの
各機器モデルを複数のプログラム言語により記述し、これらを連成して解くことで多言語混成型シ
ミュレーションの動作検証を行った。出力比較には国土交通省官庁営繕部において開発が進められて
いる LCEM ツールを用いた11)。各機器モデルの記述言語と主な入出力変数を表 5.4 に示す。各機器モデ
ルは C#で記述された抽象クラスである AbstractDevice クラスから派生させた。Basic 言語における派生
クラスの一部を記述例として図 5.18 に示す。図 5.19 および表 5.5 に開発プログラムと LCEM の出力値
の比較結果を示す。同一の物理式に従っているため、出力値はほぼ一致している。非線形連立代数方
程式の解法として前者は Levenberg-Marquardt 法を、後者は Excel の反復計算機能を用いており、この解
法の違いがわずかな出力差を生んだものと推測できる。図はガス消費および冷却塔消費電力の結果で
あるが、その他の状態変数についても概ね同様の結果となり、複数言語により記述されたモデルが正
常に連成計算されたことが確認できた。
熱源系
INV 冷却塔
VWV
T INV
吸収
冷却水 冷温水機
ポンプ
図 5.17　モデル化対象一次システム
5-15
VWV
冷水
ポンプ
INV
二
次
側
系
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
表 5.4　機器モジュールの記述言語と主な入出力変数
機器名称
言語
主な入力
主な出力
吸収冷温水機
C#
冷却水量、冷温水量
冷却水往温度
冷温水往温度目標値
冷却水還温度
冷温水往温度
ガス消費量
冷却塔
Basic
外気湿球温度
冷却水量
冷却水還温度
冷却水往温度目標値
冷却水往温度
送風機消費電力
冷却水流量
冷却水ポンプ
C++
冷却水流量
回転数
消費電力
表 5.5　開発プログラムおよび LCEM の出力誤差
熱源ガス消費
[Nm3/h]
冷却塔消費電力
[kW]
ポンプ消費電力
[kW]
平均誤差
0.000161
0.005374
0.000046
最大誤差
0.004986
0.006379
0.000978
<Serializable()> Public Class CoolingTow er
Inherits DeviceType
''' <summary>通 常 の 出 力 計 算 処 理 </summary>
Public Overrides Sub OutputCalculation()
（省略）
End Sub
''' <summary>デ シ リ ア ラ イ ズ 用 コ ン ス ト ラ ク タ </summary>
Private Sub New (ByVal info As SerializationInfo, ByVal context As StreamingContext)
MyBase.New (info, context)
End Sub
''' <summary>シ リ ア ル 化 処 理 </summary>
Public Overrides Sub GetObjectData(ByVal info As SerializationInfo, ByVal context As
StreamingContext)
MyBase.GetObjectData(info, context)
End Sub
End Class
40
5
32
4
LCEM出力[kW]
LCEM出力[N㎥/h]
図 5.18　Basic 言語における派生クラス記述例
24
16
8
ガス消費
0
3
2
1
冷却塔消費電力
0
0
8
16
24
32
40
開発プログラム出力[N㎥/h]
0
1
2
3
4
開発プログラム出力 [kW]
図 5.19　開発プログラムおよび LCEM の出力比較
5-16
5
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
5.4.2
既存コードの活用と実運転データとの比較による検証
前述のシステム構成を持つ現実の建物の BMS データとの比較を行った。また、既存資産の活用可能
性について確認を行うために、冷却塔モデルについては HVACSIM+(J)の TYPE661、ポンプモデルには
TRNSYS の TYPE3 、 熱 源 モ デ ル には TRNSYS の TYPE278 を そ れ ぞ れ 利 用 し た 。 各 TYPE と も に
FORTRAN により記述されており、オブジェクト指向言語におけるクラスの概念が無いため、Adopter
Pattern を用いて対応した。具体的には、開発済みの FORTRAN コードを.NET 対応の FORTRAN コンパ
イラでコンパイルし、AbstractDevice 派生クラス（Adopter クラス）において当該関数を呼び出す処理
を記述することで、今回開発したプログラムによる処理を可能にした。ただし、もとの FORTRAN
コードに記述された広域変数についてはこれを削除し、C#によって記述された Adopter クラスとの変数
授受で代替させた。図 5.20 に Adopter パターンを用いた既存コード利用法を示す。
図 5.21 および表 5.6 に計算結果と BMS 実績値との比較を示す。ポンプ消費電力については高負荷領
域で実績値が頭打ちとなり、傾向がモデル出力と異なっている。これは、消費電力を負荷率に対する
多項式で近似する簡易なモデルを利用したために、ポンプ以外の部位での抵抗変化を捉えることがで
きなかったことに原因があると考えられる。誤差の解消のためには、流量と圧力とのバランスを考慮
するモデルを利用する必要があるが、本報の目的は、高精度の再現性ではなくモジュールの連成にあ
るため、これ以上の検討は行わなかった。その他の出力に関してはプロットがほぼ 45 度線上に打たれ
ており、既存のコードが問題なく動作し、連成計算が行われていることが確認できた。
AbstractDeviceクラス
操作
FORTRAN
コード
派生
Adopterクラス
ソルバ
インターフェース
等
インスタンス変数 X, Y, Z
関数呼び出し
（広域変数を引数として与える）
移動
.NET対応コンパイラ
Type****のアセンブリ
広域変数X, Y, Z
40
35
30
30
BMSデータ [℃]
BMSデータ [kW]
図 5.20　Adopter パターンによる既存コード活用法
20
10
25
20
ポ ンプ 消費電力量
10
20
30
冷却塔出口水温
15
40 15
40
計算結果 [kW]
20
25
30
35
計算結果 [℃]
60
BMSデータ [℃]
BMSデータ [N㎥/h]
0
80 0
40
20
35
30
25
熱源ガ ス消費量
熱源冷却水還温度
20
0
0
20
40
60
80
20
25
30
35
計算結果 [℃]
計算結果 [N ㎥/h]
図 5.21　計算結果と BMS 実績値との比較
5-17
40
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
表 5.6　計算結果と BMS 実績値との比較
5.4.3
ポンプ
消費電力
冷却塔
出口水温
熱源ガス
消費量
熱源冷却水
還温度
最大誤差
1.42 kW
0.67 °C
3.88 Nm3/h
0.65 °C
平均誤差率
9%
3%
13%
2%
マルチ CPU による並列計算への応用例
設備システムモデルを解く場合、全ての状態変数を一挙に解くのではなく、関連性の強いモジュー
ルでグルーピングを行い、グループ毎に連成計算を行うことで計算時間を低下させることが可能であ
る。例えば、HVACSIM+(J)においては BLOCK という概念を用いて機器のグルーピングを行い、グ
ループ間の状態変数の伝達は一定間隔毎に行っている †1。本研究で開発したプログラムにおいても、レ
イヤーという概念で機器モジュールをグルーピングすることを可能とした。各レイヤーは 1 以上の機
器モジュールで構成され、機器モジュールは 1 以上のレイヤーに所属することができる。レイヤーが
処理する状態変数は一定時間毎に伝達することとした。図 5.22 にレイヤーの概念を示す。
HVACSIM+(J)では、例えば流量圧力計算、コントローラの一部、建物負荷計算などの TYPE で、広
域変数を利用して処理を行う部分が存在した。一方、本研究では、抽象的機器モジュールを定義する
ことで、機器モジュール相互の結合度を低下させている。従って、各レイヤーにおける状態変数値
は、他のレイヤーでの計算に影響されない。即ち、レイヤー毎に CPU を割り当て、独立して計算を実
行することが可能となる。図 5.23 にマルチ CPU による並列計算の概念を示す。左が従来のソフトウェ
アの計算であり、右がマルチ CPU による計算である。シングル CPU の場合、各グループの計算はシー
ケンシャルに行われる。一方、本研究では、各グループの状態変数を独立させたため、図に示すとお
り、複数の CPU により並列的に計算を実行することが可能となり、計算速度の向上が期待できる。
検証のため、単純なシステムについてシングル CPU とマルチ CPU での計算速度を比較した。図 5.24
にモデル化対象システムを示す。ペリメータ系統の FCU を想定しており、10,000m2 を下回る建築で
あっても、数百という規模で存在する可能性のある系統である。本モデルを 4 つ作成し、CPU4 台およ
び CPU1 台で計算を行った結果を図 5.26 に示す。CPU1 台の場合、一つの CPU の負荷率が上昇し、約
67 秒で計算が完了した。一方、CPU4 台の場合、全 CPU の負荷率が同時に上昇し、約 23 秒で計算が完
了した。
†1 TRNSYS (Version 14) には同様の機能は存在しない
5-18
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
本例に示すように、計算単位の独立性が確保され、並列計算が可能となることで、大規模な動的計
算を行う場合には、CPU 台数に応じた計算時間の短縮を期待することができる。
グループ1
グループ1
CPU3
グループ2
グループ2
状態変数
は独立
グループ3
状態変数
は独立
CPU2
グループ3
CPU1
CPU1
従来の計算法
並列計算
図 5.23　シングル CPU およびマルチ CPU による計算法の違い
PID
冷水二方弁操作
T
温度センサ
時定数
輸送遅れ
水配管熱容量
C
コイル熱容量
C
室熱容量
図 5.25　機器モジュール接続結果
図 5.24　モデル化対象システム
CPU 負荷率 [-]
100
シングルCPU
67[sec]
100
80
80
60
60
40
40
並列計算
23[sec]
CPU1
CPU2
CPU3
CPU3
20
20
0
CPU4
0
5
0
15
10
25
20
35
30
45
40
55
50
65
60
5
70
0
15
10
25
20
時間 [sec]
35
30
45
40
時間 [sec]
図 5.26　CPU 台数による計算時間の違い
5-19
55
50
65
60
70
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
5.5
まとめ
本章では、第 2 章で示された問題の内、プログラムのモジュール化の問題を解決するため、モ
ジュールシミュレーションプログラムにおける機器モジュールの抽象的定義法について検討を行っ
た。
プログラムコードの独立性と可読性を高め、小さなプログラムコード群の連携を実現することを目
的に、オブジェクト指向言語を用いて設備機器モジュールの抽象的な構造を記述する方法について検
討を行った。
・HVACSIM+(J)および TRNSYS を例に取り、モジュールの特徴づけと永続性の保証、反復収束計算へ
の対応、機器モジュールの追加とコンパイル、の 3 点について従来のプログラム言語におけるモ
ジュール定義方法の問題点を明らかにした。また、オブジェクト指向言語を用いた問題解決法を提
案し、設備機器を示す抽象クラスである AbstractDevice を開発した
・「永続性の保証」に関しては、派生クラス自身にシリアライズの機能を持たせることで、自由な
データ型を利用してデータを保存することを可能とした
・「反復収束計算」への対応に関しては、各機器モデルが実装すべき関数群を一つのクラスとしてま
とめることを可能とし、反復収束計算用の関数を抽象クラスで明示的に定義することで、単一関数
での条件分岐による煩雑な処理を回避させた
・「機器モジュールの追加とコンパイル」に関しては、ユーザーインターフェースやソルバーなどの
上位の機能を持つクラスと、個別具体的な機器モデルクラスを切り分けることで対応した。即ち、
上位のクラスからは機器モデルの抽象クラスにおいて定義した関数群のみを利用する仕様とするこ
とで、機器モデルの派生クラスを上位のクラス群と分離させ、独立したアセンブリとして開発する
ことを可能とした
・以上の構造を持つオブジェクト指向のモジュール形式シミュレーションプログラムを実際に開発
し、動作検証を行った。AbstractDevice 派生クラスを、C#、Basic、C++の複数言語で開発し、既存の
シミュレーションプログラムとの動作比較を行うことで、多言語で記述された機器モジュールが問
題なく連成計算されることを確認した。また、既存のプログラム資産を活用することを目的に、
FORTRAN 言語で定義された機器モジュールを C#で記述された AbstractDevice 派生クラスでラップし
て実際の建物の一次側システムを構築した。各モジュールの出力値と BMS で計測された出力値なら
びに比較対象のシミュレーションプログラムの出力値とを比較したところ、45 度線上にプロットが
並び、既存プログラム資産が有効に機能したことを確認できた
5-20
建築設備シミュレーションソフトウェアの継続的開発法に関する研究
【記号一覧】
A : S のヤコビアン行列
a : 修正量
gj : 修正方向ベクトル
j : 入力変数ベクトル番号
k : 更新ステップ数
m : 更新ステップ数
S : 二乗誤差
∆x :説明変数ベクトル
λ : 係数
5-21
第 5 章　オブジェクト指向言語による設備機器モジュールの抽象的定義法
5-1) 村上周三, 松尾陽, 坂本雄三, 石野久彌, 大塚雅之, 赤坂裕, 滝澤総, 野原文男 : 外皮・躯体と設備・機器の総合エネル
ギーシミュレーションツール「BEST」の開発, 空気調和・衛生工学会大会学術講演論文集, pp.1969~1972, 2007.09
5-2) 宇田川光弘 : 快適性評価のためのシミュレーション手法室内熱環境および空調用エネルギーシミュレーションプロ
グラム EESLISM の開発, IBEC, No.63, pp.45~51, 1991
5-3) Sowell, E. F. and W. F. Buhl : Dynamic Extension of the Simulation Problem Analysis Kernel (SPARK), Proceedings of the
USER-1 Building Simulation Conference, Ostend, Belgium, Soc. for Computer Simulation International, 1988
5-4) 時田繁, 松縄堅, 丹羽英治, 杉原善文, 岡崎徳臣 : ライフサイクルエネルギーマネージメントのための空調システムシ
ミュレーション開発 第 1 報, 空気調和・衛生工学会大会学術講演論文集, p.195, 2005
5-5) A. Fiksel, J. W. Thornton, S. A. Klein, and W. A. Beckman : Developments to the TRNSYS Simulation Program, Journal of
Solar Energy Engineering , pp.123~127, 1995
5-6) 富樫英介, 田辺新一 : 設備シミュレーションプログラムの継続的な開発とオープンなプログラム資産の蓄積につい
て, 空気調和・冷凍連合講演会, No.42, pp.175-178, 2008.4
5-7) Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, : Design Patterns - Elements of Reusable Object-Oriented
Software, 1994
5-8) 中川徹, 小柳義夫 : 最小二乗法による実験データ解析,東京大学出版会, pp.99~pp.110m 1982.05.30
5-9) U.M.アッシャー, L.R.ペツォルド, 中村眞理雄 訳 : 常微分方程式と微分代数方程式の数値解法, 培風館, 2006
5-10) K.E.Brenon, S.L.Campbell, L.R.Petzold : Numerical Solution of Initial-Value Problems in Differential-Algebraic Equations,
Society for Industrial and Applied Mathematics, 1996
5-11) 公共建築物におけるライフサイクルマネージメント 技術解説書, 社団法人公共建築協会, pp.1~4, pp.5-9, pp.20-26
5-22