第四章モデルデータのクラス化によるデータの活用法

全文

(1)第四章モデルデータのクラス化によるデータの活用法.

(2) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. 第4章モデルデータのクラス化によるデータの活用法 4.1. はじめに. ソフトウェアのオープンソース（OS）化による大きなメリットの一つは、仕様の公開に基づく互換性の向上にある。そこで本章ではまず、ソフトウェアの互換性獲得によるユーザーサイドのメリットを明確にする。さらに、オブジェクト指向言語を用いてモデルの定義を行うことで、静的エネルギーシミュレーションから制御系動的シミュレーションへのモデル展開、異なる開発主体間のモデル変換、最大熱負荷計算から年間動的熱負荷計算へのモデル展開を実現し、ユーザーによるモデル構築作業の軽減を可能とする。また、各ソフトウェアで統一的に利用することが可能な汎用スケジューラを開発することで、スケジューラ開発主体とスケジュール内容開発主体を明確に分離することを可能とする。. 4.2. 問題の所在と解決策. これまで、建築環境に関連する数多くのソフトウェアが開発されてきたが、ソフトウェア間でのデータ授受を可能とする内部データの明確な仕様定義を示している例は少ない。従って、各ソフトウェアは独立した存在となり、その連携は難しかった。この結果、計算対象としている建物が同一であったとしても、設計フェーズの移行に伴うソフトウェアの変更の度に、煩雑なモデル化作業が繰り返されることになり、大きな人的労力が必要となってしまっていた。図 4.1 に設計フェーズの移行とデータの引き継ぎによる作業量低減の概念を示す。フェーズが進行して詳細なシミュレーションが必要になるに従い、必要なデータは増えていくが、多くのデータは重複している。しかし、仕様の公開されていないプロプライエタリなソフトウェアの場合、これらのデータを引き継ぐ手段が存在しないため、各フェーズでソフトウェアを変更する度に、モデルの再構築作業が必要となる。一方、OS ソフトウェアのようにモデル定義の仕様が公開されている場合には、過去のフェーズで利用したデータを変換できる可能性があり、この場合には、わずかな調整作業を行うことで次のフェーズで必要となるモデル定義を行うことができる。ソフトウェア内部のデータ設備機器. 設備機器スケジュール室構成名称・用途. 室構成名称・用途壁構成. 地域. 気象. 壁構成. 最大熱負荷計算. スケジュール室構成名称・用途. 年間動的熱負荷計算. OSS : Op en Source Software. スケジュール室構成名称・用途. 気象. 壁構成. 壁構成. 年間エネルギー計算. PS : Prop rietary Software モデル再構築. モデル再構築. OSS. PS. PS. 設計フェーズ. 変換作業. 変換作業. OSS 図 4.1. 制御情報設定作業. 設備システム情報設定作業. スケジュール情報設定作業変換作業. 気象. 制御系動的計算. モデル再構築基本情報設定作業. 制御機器. OSS. PS. OSS. PS. 設計フェーズの移行とデータの引き継ぎによる作業量低減の概念. 注意すべきは、このようなモデルの展開は、図 4.1 に示したように設計フェーズと並行して一次元的に広がっているのみとは限らないということである。例えば、年間エネルギー計算を終えた後、CEC/ 4-1.

(3) 第4章. モデルデータのクラス化によるデータの活用法. AC 計算図書の作成へと向かう場合もあれば、サブシステムに特化したソフトウェアで熱源まわりのみの検討をする場合もあり、各種ニーズに従って様々なソフトウェアが利用され、分岐が生ずる。このような分岐が生ずる度にモデルの再構築が必要となるのであれば、その作業量とコストは膨大なものになり、結果としてシミュレーションソフトウェアの利用は最低限度のものとなる。HVACSIM+(J)に代表される動的シミュレーションプログラムの利用が運用段階において有効であるという指摘がある一方で、実務レベルで一向に活用が進まない大きな原因の一つは、繰り返されるこのような煩雑なモデル構築作業にあると推測できる。以上の問題を回避するためには、第一に仕様の公開が必要である。いかなるデータ形式（型）でデータがメモリ内に保存されているのか、どのような関数によって当該データを呼び出し、設定することができるのかについて、モデル変換を行う両ソフトウェアの仕様が明らかにならねばデータの移行は不可能だからである。本研究で開発するソフトウェアは、ライセンスとして GPL を採用しているため、この問題については解決済みである。第二に、データの変換可能性を保証するための簡明なデータ構造が必要である。本研究では、モデルを構成する各要素をクラスとして記述し、独立した存在とした上で、これらを階層的に組み上げて全体のモデルを作成する手段をとった。このような構造とすることで個別のデータ変換プログラムは、基本的には要素単位での変換機能の実装をすれば足りることになる。第三に、変換の際のデータの破壊を防ぐ手立てが必要である。本研究では、 Immutable インターフェースを適宜利用することで、階層分化した個別のクラスを読み取り専用のオブジェクトとして表現することを可能とし、参照渡しに起因するデータの破壊をソースコードレベルで防止した。以下、「最大熱負荷計算から年間動的熱負荷計算への展開」と「年間エネルギーシミュレーションソフトウェアからのデータ展開」という二つの実例を通して、上記の問題解決策の実装方法について報告する。. 4-2.

(4) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. 4.3. 最大熱負荷計算から年間動的熱負荷計算への展開法. 設備設計を行う際にはピーク負荷に対応するために最大熱負荷計算を行うことが通常である。一方、オフピーク時のシステム性能など、システムの個別性を反映した詳細な評価を行うためには、年間累積熱負荷を把握することができる年間動的熱負荷計算が不可欠となる。両者は目的こそ違うものの、周期的定常という仮定を置くことで後者の計算処理を抽象化した存在が前者であり、例えば、実効温度差 ETD はレスポンスファクターを用いて畳み込み演算により算出することが一般的である1)。従って、両計算を行うために必要なデータの中には、壁体構成や窓性能など、重複しているものも多い。また、地域、室内負荷条件など、前者の計算のために必要なデータの多くは後者のデフォルト値を仮設定する際の手がかりとなるものである。従って、変換に適したモデル構造を定義することができれば、前者の計算に引き続いてシームレスに後者の計算へと移ることが可能であると推測できる。本節では、最大熱負荷計算ソフトウェアの開発と年間動的熱負荷計算ソフトウェア GUI の開発を行い、オブジェクト指向言語を用いて両プログラムのモデル定義を行うことで、前者から後者へデータ展開を可能とする方法について報告する。 4.3.1. 最大熱負荷計算ソフトウェアの開発. 空気調和設備の設計にあたり、基本となる概念が「熱負荷」であり、熱負荷に基づいて各機器の容量は決定される。最大熱負荷の「最大」は、年間に数度しか生じない極めて負荷の大きい条件を意味している。この計算を行うための気象条件が最大熱負荷計算用気象条件である。そもそも、最大熱負荷計算の目的は「手早く概ね妥当な計算」を行うことであるから、理論的に唯一の計算法が存在するものではなく、例えば、手計算による最大熱負荷計算法 2) 、井上・尾島の方法 3) 、木村の方法など 4) 、いくつかの手法が存在する。本研究では「官公庁施設の建設等に関する法律5)」を受けた国土交通省による「建築設備設計基準」の要求を満たす計算法であり、実務的にデファクトスタンダードとなっている国土交通省営繕部設備課監修の「建築設備設計基準」 6)に記された手法を利用することとした。なお、本計算法は、空気調和・衛生工学会空気調和設備委員会熱負荷算法小委員会の計算法7)に基礎を置くものである。 1）. 最大熱負荷計算のフローとモデルの階層化. 図 4.2 に冷房熱負荷計算のフローとデータのクラス化の概念を示す。左方が冷房負荷計算、右方が暖房負荷計算である。計算の各段階において、外壁・内壁データ、窓データ、内部負荷データ、すきま風データなどが必要となることがわかる。これらは年間動的熱負荷計算を行う場合にも必要となるデータであり、データを保存するクラスの仕様を明確にし、構造を工夫することによって容易にデータを受け渡すことができると推測できる。しかし、従来のソフトウェアにおいては、これらのデータをどのような形で保持するかについて検討が十分でなく、例えば図 4.3 に示すように、HASP/ACLD においては、プログラム冒頭で巨大な広域実数値配列や COMMON 文を用いてデータを定義していた。従って、これらのデータを再利用するためには、プログラム全体を理解する必要があった。. 4-3.

(5) 第4章. モデルデータのクラス化によるデータの活用法. 設計用屋内条件の設定. 構造体熱通過率の設定. 設計用屋外条件の設定. 実効温度差の設定. 構造体負荷の算定. 外壁・内壁データ. 構造体熱通過率の設定. 設計用屋内条件の設定. 地中温度の設定. 設計用屋外条件の設定. NO. 外部遮蔽の有無. 構造体負荷の算定. YES. ガラスの熱通過率の設定. 外部遮蔽による補正単位面積当たりガラス面日射負荷の設定. 窓データ. ガラス熱通過率の設定. ガラス面負荷の算定. ガラス面負荷の算定照明器具の設定. 照明負荷の算定人員数の算定人体負荷の算定. 内部負荷データ人体発熱量の設定. その他の内部発熱負荷の算定事務機器等の電力消費量 NO. NO. すきま風負荷の有無 YES. すきま風量の算定. すきま風データ. すきま風量の算定. すきま風負荷の算定. すきま風負荷の有無 YES. すきま風負荷の算定余裕係数の設定間欠運転係数の設定送風機負荷係数の設定. 室内顕熱負荷の集計. 余裕係数の設定間欠運転係数の設定. 室内顕熱負荷の補正. 室内顕熱負荷の集計. 室内顕熱負荷の補正. データおよび処理をクラスとしてまとめ、データの再利用を容易とする. 室内冷房負荷. 図 4.2. 最大熱負荷計算のフローとデータのクラス化. BLOCK DATA BLOCK COMMON /CN1/TCM1(94),TCM2(90) /CN2/TCW(2,30),IGS(2,90) 1 /CN3/RL(54),RM(9),RE(27),RG(18),AM(27),RZ1(9,9),RZ2(8,9) 2 /CN4/IOR,IOW,IIW,ISC,ISE,ISP,IOUT,PI,RADI,TPR,TV1,AHR,BL(7), 3 WX(3),WXB(2) DATA TCM1/.019,.516,1.892,.052,38.7,180.6,332.,.0 ,.0 ,.0 ,2.7, * 1.2,1.3,.8,.9,.4,.53,.0 ,.0 ,.0 ,1.3,1.2,.67,.15,.95,.46,1.3, * 1.03,.0 ,.0 ,.68,.15,.64,.59,.67,1.1,.55,.86,.0 ,.0 ,.163, * .224,.095,.18,.13,.06,.069,.0 ,.0 ,.0 ,.16,.15,.12,.16,.0 , * .0 ,.0 ,.0 ,.0 ,.0 ,.048,.052,.12,.19,.15,.16,.038,.07 , * .0 ,.0 ,.036,.034,.07 ,.036,.044,.055,.0 ,.0 ,.0 ,.0 ,.040, * .032,.022,.024,.025,.043,.038,.031,.0 ,.0 ,.18,.08,.0 ,.0 / DATA TCM2/.31,998.,449.,43.,865.,567.,824.,.0 ,.0 ,.0 ,571., * 399.,744.,468.,798.,428.,370.,.0 ,.0 ,.0 ,456.,462.,384.,156., * 430.,375.,380.,435.,.0 ,.0 ,390.,246.,330.,269.,457.,480.,332., * 360.,.0 ,.0 ,350.,448.,220.,217.,69.,62.,76.,.0 ,.0 ,.0 , * 186.,155.,124.,171.,.0 ,.0 ,.0 ,.0 ,.0 ,.0 ,78.,93.,234., * 326.,171.,226.,9.3,248.,.0 ,.0 ,4.8,6.4,2.4,20. ,240.,60.,.0 , * .0 ,.0 ,.0 ,5.4,8.4,12.,11.3,11.3,9.,15.,12.,.0 ,.0 / DATA TCW/.180,.230,.183,.233,.184,.234,.187,.237,.193,.243,.183,.2 1 33,.183,.233,.183,.233,.180,.230,.183,.233,.184,.234,.187,.237,.1 2 93,.243,.0 ,.0 ,.0 ,.0 ,.0 ,.0 ,.344,.394,.350,.400,.353,.4 3 03,.359,.409,.0 ,.0 ,.0 ,.0 ,.344,.394,.350,.400,.353,.403,.3 4 59,.409,.0 ,.0 ,.0 ,.0 ,.0 ,.0 ,.0 ,.0 / DATA IGS/99,1,96,2,95,2,93,2,90,2,96,2,96,2,96,2,79,7,67,10,63,10, 154,13,41,16, 0, 0, 0, 0, 0, 0,90,1,84,4,81,5,77,6, 0,0, 0, 0,69,5, 256,7,50,8,40,10, 0, 0, 0, 0, 0, 0, 0, 0,27,26,27,26,26,27,26,27,25 3,28, 0, 0, 0, 0, 0, 0,25,28,24,28,23,28,21,28,20,27, 0, 0, 0, 0, 0 4, 0,24,28,23,29,24,29,23,30, 0, 0, 0, 0,20,25,17,24,17,22,15,24, 0 5, 0, 0, 0, 0, 0, 0, 0,25,39,25,39,25,39,24,39,24,38,27,47,33,57,19 6,16,23,38,22,36,22,34,20,34,18,31, 0, 0, 0, 0, 0, 0,22,39,22,39,22 7,39,21,39, 0, 0, 0, 0,18,34,16,30,15,29,13,27, 0, 0, 0, 0, 0, 0, 0 8, 0/ DATA RL,RM/.3993,.0398,.9337,.4023,.0516,.9137,.4095,.0824,.8605, 1 .5002,.0369,.9261,.5024,.0457,.9081,.4999,.0709,.8581,.6901, 2 .0290,.9064,.6911,.0328,.8937,.6760,.0478,.8525,.5261,.0392, 3 .9173,.5279,.0464,.9016,.5160,.0699,.8556,.5694,.0377,.9124, 4 .5708,.0437,.8981,.5555,.0648,.8542,.0 ,.0 ,.0 ,.0 , 5 .0 ,.0 ,.0 ,.0 ,.0 ,.6554,.0290,.9158,.6566,.0342, 6 .9005,.6469,.0511,.8552/. 図 4.3. 室内暖房負荷. 広域定数宣言. 壁素材熱伝導比抵抗. 壁素材容積比熱ガラス熱貫流抵抗. ガラス遮蔽係数. 照明人体重み係数. 従来のソフトウェアにおけるモデル定義例（HASP/ACLD）. 4-4.

(6) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. 本研究では、データの変換を容易とするために、熱負荷計算に必要な外壁・内壁・ガラス等の各要素をクラスとしてまとめ（図 4.4）、当該要素を特徴付けるパラメータについてはクラス自身が保持する仕様を提案する。表 4.1 に、本ソフトウェアの主要なクラスを示す。このように要素を分割し、データをプログラム内で分散的に保存することによって、巨大なプログラム全体ではなく、個別のクラスに対する操作を記述することで、データを変換することが可能となる。図 4.5 にモデル変換操作の概念を示す。最大熱負荷計算用モデル、年間動的熱負荷計算用モデルともに要素別にクラスを開発したため、要素の対応付けが明確である。各要素は自身の内部に必要なデータを保持しているため、基本的には変換対象の要素を引数とするのみで、変換に必要な情報がそろうことになる†1) 。従って、変換処理を行うクラスの各メソッドは要素ごとに完結した入出力となる。図の例では、末端の要素である A, B, D の変換を行うメソッドを定義しており、これらの要素の複合的存在である親要素の C, E の変換については、A, B, D の変換メソッドを再帰的に呼び出すことで、これを実現している。表 4.1 要素. 主要クラス一覧. クラス名称. 概要. 室. Room. 容積、内部負荷等の室のデータを保持する。構成要素は外壁および窓。. 内壁. InnerWall. 面積等の内壁のデータを保持する。構成要素は室および壁構成。. 外壁. ExternalWall. 面積、方位等の外壁のデータを保持する。構成要素は壁構成。. 壁構成. WallComposition. 素材、厚み等の壁構成のデータを保持する。. 窓. Window. 面積、方位等の窓のデータを保持する。構成要素は窓構成および日除け。. 窓構成. WindowComposition. 熱通過率、遮蔽係数等の窓構成のデータを保持する。. 日除け. SunShade. 幅、高さ、張り出し等の日除けのデータを保持する。. 全モデル. ModelDefinition. 全体モデルクラス。上述の要素を保持する。. 建物間仕切り壁（内壁）. 一般情報. 間仕切り壁（内壁）間仕切り壁（内壁）部屋部屋部屋壁壁素材情報壁素材情報素材情報. 図 4.4. 窓窓素材情報窓素材情報素材情報. 階層化された建物要素クラス. †1 いくつかの要素については必ずしも変換に全てのデータをクラスの中に埋め込むことができない。例えば壁構成を変換する際には壁の各層の素材が必要となるが、本研究のプログラムでは上階層のクラスが素材データを保持している。この場合、引数として壁構成クラスおよび壁素材クラスが与えられることになり、プログラムはやや複雑になる。しかし、全体を単一の SUBROUTINE とするよりは、依然として遙かにプログラムの理解が容易である 4-5.

(7) 第4章. モデルデータのクラス化によるデータの活用法. 最大熱負荷計算用モデル. 年間動的熱負荷計算用モデル. 要素E1 要素C1. 要素E2 要素C2. 要素A1. 要素A2. 要素B1. 要素B2 変換処理を行う. 要素D1. 要素D2. static class Converter private A2 ConvertA1(A1 a1){ // A1をA2に変換する処理を記述する }. private D2 ConvertD1(D1 d1){ // D1をD2に変換する処理を記述する }. private B2 ConvertB1(B1 b1){ // B1をB2に変換する処理を記述する }. private E2 ConvertE1(E1 e1){ E2 e2 = new E2(); // E2の子要素である要素 Cの変換処理 e2.C2 = ConvertC1(c1.C1);. private C2 ConvertC1(C1 c1){ C2 c2 = new C2();. // E2の子要素である要素 Dの変換処理 e2.D2 = ConvertD1(c1.D1);. // C2の子要素である要素Aの変換処理 c2.A2 = ConvertA1(c1.A1);. // E1をE2に変換するその他の処理を記述する }. // C2の子要素である要素Bの変換処理 c2.B2 = ConvertB1(c1.B1); // C1をC2に変換するその他の処理を記述する }. 図 4.5. 2）. 要素のクラス化とデータ変換法. Immutable Interface によるデータの堅牢化. 前節に示したオブジェクトの階層化を施すことにより、特定のクラスに関連するデータはクラスの内部に保持されることになる。従って、データを広域変数とする場合と比較すれば、無関係なコードによるデータの破壊が抑制されると期待できる。しかし、クラス内のインスタンス変数へのアクセスを自由に許すのであれば、データの破壊がプログラムの構造により防止されたことにはならず、堅牢性は不十分である。そこで、Interface を利用してデータの編集可能性を制御することを可能にした。具体的にはクラスの読み取り機能のみを定義した Interface である Immutable Interface を利用した。図 4.6 に Immutable Interface の概念を示す。ボタン操作および通信機能を持った Telephone class が定義されている。また、これに対して、音声および映像の受信機能以外を遮蔽した ImmutableTelephone Interface が定義されている。ImmutableTelephone Interface を Telephone class に被せ、これを第三者に渡せば実体は Telephone class であっても、第三者にとっての機能は読み取り専用となる。従って、第三者がボタン操作などを行って Telephone class の現在の状態を変更（通信を停止等）してしまう恐れはなくなる。. 4-6.

(8) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. 図 4.6. Immutable Interface の概念. 図 4.7 に Immutable Interface の具体例を示す。コイルクラスの内部に表面積を意味する surfaceArea という実数値型のインスタンス変数を定義している（ 5 行）。 surfaceArea は、プロパティである SurfaceArea を利用して設定および取得が可能である（8~19 行）。一方、読み取り専用のコイルを意味する ImmutableCoil Interface では、Coil クラスと同様に SurfaceArea という実数値型のプロパティを定義しているが、こちらでは get アクセッサのみを定義している（25 行）。Coil クラスは ImmutableCoil Interface を実装しているため（2 行）、ImmutableCoil 型の変数に代入することが可能である。従って、 Coil クラスを ImmutableCoil 型の変数に代入して他のクラスに渡せば、読み取り専用となるため、内部のデータは破壊されることがない†1) 。 1 /// <summary>コイルクラス </summary> 2 public class Coil : ImmutableCoil 3 { /// <summary>表面積[m2]</summary> 4 5 private double surfaceArea; 6 /// <summary>表面積[m2]を取得・設定する </summary> 7 8 public double SurfaceArea 9 { 10 get 11 { 12 return surfaceArea; 13 } 14 set 15 { 16 surfaceArea =value; 17 } 18 } 19 }. 図 4.7. 20 21 22 23 24 25 26 27. /// <summary>読み取り専用コイルインターフェース </summary> public interface ImmutableCoil { double SurfaceArea { get; } }. Immutable Interface の具体例. ユーザーとのやりとりを行いながらモデルの編集作業を行う際にはインスタンス内部のデータにアクセスする必要があるが、他のプログラムへデータの変換を行う場合や構築済みのモデルを利用して計算を実行する際にはデータの編集は不要である。従って、このような計算を行う際にもデータへのアクセス手段を留保することは、データの破壊をもたらす危険性を高めるのみで実利は存在しない。一方で、Clone メソッドなどを用いてインスタンスの複製を渡す仕様にすれば、元のデータの破壊は防ぐことができるが、メモリを無駄に消費する上、単純な参照渡しを行う場合と比較して複製による計 †1 ImmutableCoil オブジェクトの受け取り側で強引に Coil クラスへとキャストすることは可能であるため、完全にデータ破壊が防止されたことにはならない。しかし、このようなキャストは推奨されないため、データの破壊はほぼ防止されたと言って良い 4-7.

(9) 第4章. モデルデータのクラス化によるデータの活用法. 算時間分、速度が遅くなる。この場合に、Immutable Interface を利用すれば、データの破壊を防ぎながら、参照型によるプログラムの速度も確保できる。本研究で開発したソフトウェアにおいては、ユーザーインターフェースを用いてモデルの編集作業を行う場合には一般のオブジェクトを用い、後述する年間動的熱負荷計算への変換プログラムおよび最大熱負荷計算実行プログラムにおいては、Immutable なオブジェクトを用いる仕様とした。 3）. 全体クラス構成および動作検証. 前節までに行った検討に基づき、最大熱負荷計算ソフトウェアを開発した。以下、本ソフトウェアを梵天丸と呼ぶ。梵天丸の全体クラス構成を図 4.8 に示す† 1) 。表 4.1 に示したとおり、ModelDefinition クラスを最上層として、階層的に各要素のクラスを配置した。各要素には、Immutable Interface を定義し、読み取り専用のオブジェクト化を可能とした。中心となるクラスである ModelDefinition クラスの Immutable Interface は ImmutableModelDefinition であり、最大熱負荷計算書の作成クラスおよび後述の年間エネルギー計算プログラムへの変換クラスへは、ImmutableModelDefinition 型のオブジェクトを渡す仕様とした。例として、最大熱負荷計算書を作成するクラスである、LoadCalculationSheetGenerator クラスにおける最大熱負荷計算書作成関数の定義を図 4.9 に示す。これらのクラス群を「Popolo.MaximumHeatLoadCalculate.Kernel」名前空間に所属させた。. この他、各要素を編集するためのユーザーインターフェースクラス群を開発し、「Popolo.MaximumHeatLoadCalculate.Control」名前空間に所属させた。要素単位でのクラス化に対応させ、編集用コントロールも要素単位での編集を目的とするクラスとすることで、汎用性の向上を図った。計算結果は PDF 形式での帳簿出力に対応させた。動作検証のため、図 4.10 に示す建築学会標準オフィスビル8)の基準階の最大熱負荷計算を行った。出力された帳簿の一部を図 4.11 に示す。計算結果はこれまでに報告が行われた結果†2) とほぼ一致しており、正常に計算が行われたことが確かめられた。この他の帳簿は APPENDIX に付する。 †1 主要なクラスのみを示した。ソースコードは APPENDIX に添付する †2 例えば、空気調和ハンドブック 4-8.

(10) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. public static v oid MakeSheet(ImmutableModelDef inition mDef inition, string f ilePath) { //最大熱負荷計算処理およびPDF作成処理 }. 図 4.9. N. S : 1/200 0. ImmutableModelDefinition の呼び出しサンプル. 5000. 10000 S. 空調機室. 階段室. EVホール. 事務室. 事務室. 湯沸かし室便所. 6.300. 6.000. 9.000. 6.000. 6.300. 33.600 部. 位. S : 1/100 0. 2500. 外壁（居室に面する部分）. 5000. 天井窓窓 600. 1.800. 窓 1.200. 1.800. 外壁（天井裏の梁の部分）. 外壁（階段・便所）. 事務室. 外壁（機械室）基準階床. 600. 6.000. 基準階天井. 内壁一般. 図 4.10. 建築学会標準オフィスビルモデル基準階仕様. 4-9. 材. 料. プラスターボード密閉空気層フォームポリスチレンコンクリートモルタルタイルフォームポリスチレンコンクリートモルタルタイルモルタルコンクリートモルタルタイルグラスウールコンクリートモルタルタイルプラスチックタイルコンクリートプラスターボード岩綿吸音板モルタルコンクリートモルタルグラスウール（機械室）. 厚さ [mm] 12 25 150 20 8 25 150 20 8 20 300 20 8 25 300 20 8 3 150 9 12 20 120 20 25.

(11) 図 4.11 建築学会標準オフィスビル基準階の最大熱負荷計算結果 4-10.

(12) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. 4.3.2. 年間動的熱負荷計算ソフトウェア GUI の開発. 年間動的熱負荷計算は、建築内外での熱移動を時間ごとに年間にわたって計算するものである。従って、最大熱負荷計算とは異なり、電子計算機による大規模な計算処理が必須となる。計算手法としては、Stephenson と Mitalas に端を発する応答係数を用いた算法 9)が一般に知られており、日本においても HASP/ACLD10)が開発されている。また、壁体等の熱容量を持つ要素を微分方程式によって表現し、差分法等を用いて解く方法も有効である。本研究では、プログラムが公開され、権利関係が明確であるという理由から、宇田川らによって開発された EESLISM11)を利用することとした。EESLISM は差分法を利用した計算法をとっている。. EESLISM は、一定の形式で記述されたテキストファイルをもとに、モデルを構築して計算を実行するプログラムである。従って、ユーザーによるモデル構築作業は、基本的にはテキストエディタによるテキスト入力によって行われる。テキストによる入力データの作成は、直接的なモデルの編集が可能であるため、熟練ユーザーにとっては簡便であるが、一方で、初心者にとっては入力規則を学習するまでに大きな時間が必要となる。また、モデルの規模が大きくなり、構造が複雑化するにつれ、熟練ユーザーにとっても構築作業は困難になると考えられる。そこで、入力データ作成作業の軽減を図り、モデルの要素をクラスに分割し、EESLISM の入力データを生成するための GUI (Graphical User Interface)を開発した。具体的には、前節で記した方法と同様に、モデル要素のデータを保持するクラスを階層状に配置し、各クラスに EESLISM 入力データ形式でのデータ書き出し機能を持たせた。以下、本ソフトウェアを EESLISM Editor と呼ぶ。図 4.12 に EESLISM Editor のクラス構成を UML 図で示す。いくつかのクラス名称は梵天丸に定義したクラス名称と重複しているが、名前空間が異なっているため、問題は生じない。梵天丸と同様に、各構成要素クラスに対して Immutable なインターフェースを用意することで、堅牢性の向上を図った。テキスト形式の EESLISM 入力データ作成処理は、各クラスが分散的に持つ仕様とした。例えば、内壁の隣接室や壁構成などに関しては内壁クラスが書き出し処理を行うこととなる。例として、図 4.13 に内壁クラスの入力データ作成処理関数を示す。壁構成情報や隣室情報が必要となるため、これらの情報を保持する室クラスやモデル定義クラスが引数として与えられる。ただし、両クラスともに Immutable インターフェースとして渡されており、クラス内部のデータが破壊される危険性を排除し 4-11.

(13) 第4章. モデルデータのクラス化によるデータの活用法. た。このようなクラス構成とすることによって、要素ごとで完結した分散的なプログラムの修正が可能となった。APPENDIX に、EESLISM Editor による EESLISM 入力データ作成サンプルを添付する。 /// <summary >EESLISMファイル形式の文字列に書き出す</summary > /// <param name="room">書き出しの基準となる室オブジェクト</param> /// <param name="mDef inition">モデル定義オブジェクト</param> /// <returns>EESLISMファイル形式の文字列</returns> public ov erride string ToEESLISMString(ImmutableRoom room, ImmutableModelDef inition mDef inition) { StringBuilder sBuilder = new StringBuilder(); ImmutableWallComposition wallComposition =mDef inition.GetWallCompositionFromID(this.CompositionID); //書き出しの基準室を確定 bool isRoom1 = (room.ID == roomID1); //隣室名称 if (isRoom1) sBuilder.Append("(ROOM" + roomID2.ToString() + "):" + "\t"); else sBuilder.Append("(ROOM" + roomID1.ToString() + "):" + "\t"); //壁タイプ sBuilder.Append("-" + WallComposition.WallTy peToString(wallComposition.Ty pe) + " "); //壁名称 sBuilder.Append("WALLCOMP" + wallComposition.ID + " "); //隣室温度係数を用いる場合 if (useAdjoiningRoomCoef ) { sBuilder.Append((this.Height * this.Width).ToString("F4") + " "); sBuilder.Append("c=" + adjoiningRoomCoef .ToString("F2") + " "); } //共有壁をする場合 else { //低い番号の室の場合は面積を記述 if ((roomID1 < roomID2 && isRoom1) || (roomID2 < roomID1 && !isRoom1)) sBuilder.Append((this.Height * this.Width).ToString("F4") + " "); sBuilder.Append("i=WALL" + this.ID.ToString() + " "); } //終了符 sBuilder.Append("*p ;"); //壁体名称をコメント表示 sBuilder.Append(" ! " + this.Name); return sBuilder.ToString(); }. 図 4.13. 内壁クラスの EESLISM 入力テキスト作成処理関数. 図 4.14. EESLISM Editor 操作画面. 4-12.

(14) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. モデルデータ変換法. 4.3.3. 開発した最大熱負荷計算ソフトウェアから年間動的熱負荷計算ソフトウェアへのデータ変換プログラムを開発した。既に解説したように、本研究で開発したソフトウェアは、広域変数を利用して集中的にデータを管理するという方式をとっておらず、熱負荷計算に必要な各要素ごとにクラスを作成し、データは分散的に各クラスが保持するという方式をとった。従って、データ変換にあたっても、両プログラムの巨大なデータの塊を処理するプログラムを開発する必要はなく、建築要素を表す個別の小さなクラスの変換を行うプログラムを積み重ねることで足りる。具体例として、図 4.15 に、日除けの変換関数を示す。梵天丸で開発した日除けクラスを引数とし、EESLISM Editor で開発した日除けクラスを出力する。なお、両クラス名称は一致しているが、名前空間がことなるために問題は生じない。変換にあたり、特別な注意が必要な項目がある場合には警告文を追加することで対応した。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27. /// <summary>日除けを変換する</summary> /// <param name="mSunShade">最大熱負荷計算の日除け</param> /// <param name="warningMessages">警告文</param> /// <returns>EESLISMの日除け</returns> private static EESLISM.Kernel.SunShade convertSunShade( MaximumHeatLoadCalculate.Kernel.ImmutableSunShade mSunShade, out string[] warningMessages) { //警告文 List<string> wMsgs = new List<string>(); EESLISM.Kernel.SunShade eSunShade = new Popolo.EESLISM.Kernel.SunShade(); eSunShade.Type = Popolo.EESLISM.Kernel.SunShade.SunShadeType.Grid; eSunShade.TopMargin = mSunShade.Height - mSunShade.WindowHeight - mSunShade.BottomMargin; eSunShade.LeftMargin = eSunShade.RightMargin = mSunShade.SideMargin; eSunShade.BottomMargin = mSunShade.BottomMargin; eSunShade.WindowHeight = mSunShade.WindowHeight; eSunShade.WindowWidth = mSunShade.WindowWidth; //ひさしと袖壁で張り出し幅が異なる場合はWarning if (mSunShade.PendentTop != mSunShade.PendentSide) wMsgs.Add("ひさしと袖壁で張り出し幅が異なるため、ひさしの張り出し幅を採用しました"); eSunShade.Pendent = mSunShade.PendentTop; //警告文を出力 warningMessages = wMsgs.ToArray(); return eSunShade; }. 図 4.15. 日除けオブジェクト変換関数. その他の変換関数の入出力を表 4.2 に示す。例えば、壁構成の変換のための素材データなど、変換にあたって他の要素の情報を必要とする要素が存在するが、これらについては変換前後のオブジェクトの ID 対応表を与えることで対応させた。基本的には変換前の各要素、必要な要素の ID 対応表、警告文リストを引数にして変換処理を行う仕様とした。引数として与えられた構成要素は、 Immutable Pattern を利用して読み取り専用として渡すこととしたため、データが破壊される可能性が非常に小さいことが推測できる。. 4-13.

(15) 第4章. モデルデータのクラス化によるデータの活用法. 表 4.2. 主要な変換関数の入出力一覧. 変換関数. 概要. private static EESLISM.Kernel.WallComposition convertWallComposition( MaximumHeatLoadCalculate.Kernel.ImmutableWallComposition mWallComp, Dictionary<int, int> wMaterialIDTable, out string[] warningMessages). 壁構成オブジェクトを変換する引数として壁素材 ID 対応表を持つ. private static EESLISM.Kernel.WindowComposition convertWindowComposition( MaximumHeatLoadCalculate.Kernel.ImmutableWindowComposition mWindowComp, out string[] warningMessages). 窓構成オブジェクトを変換する. private static EESLISM.Kernel.SunShade convertSunShade( MaximumHeatLoadCalculate.Kernel.ImmutableSunShade mSunShade, out string[] warningMessages). 日除けオブジェクトを変換する. private static EESLISM.Kernel.Room convertRoom( MaximumHeatLoadCalculate.Kernel.ImmutableRoom mRoom, GeneralInformation.FacilityType facilityType, Dictionary<int, int> sunShadeIDTable, Dictionary<GeneralInformation.Orientation, int>[] exSurfaceIDTable, Dictionary<int, int> windowCompIDTable, Dictionary<int, int> wallCompIDTable, out string[] warningMessages). 室オブジェクトを変換する引数として日除け ID、外表面方位 ID 、窓構成 ID、壁構成 ID 対応表を持つ. private static EESLISM.Kernel.Window convertWindow( MaximumHeatLoadCalculate.Kernel.ImmutableWindow mWindow, Dictionary<int, int> sunShadeIDTable, Dictionary<GeneralInformation.Orientation, int> exSurfaceIDTable, Dictionary<int, int> windowCompIDTable, out string[] warningMessages). 窓オブジェクトを変換する引数として日除け ID、外表面 ID、窓構成 ID 対応表を持つ. private static EESLISM.Kernel.ExternalWall convertExternalWall( MaximumHeatLoadCalculate.Kernel.ImmutableExternalWall meWall, Dictionary<GeneralInformation.Orientation, int>[] exSurfaceIDTable, Dictionary<int, int> wallCompIDTable, out string[] warningMessages). 外壁オブジェクトを変換する引数として外表面 ID、壁構成 ID 対応表を持つ. private static EESLISM.Kernel.InnerWall convertInnerWall( MaximumHeatLoadCalculate.Kernel.ImmutableInnerWall miWall, Dictionary<int, int> wallCompIDTable, Dictionary<int, int> roomIDTable, out string[] warningMessages). 内壁オブジェクトを変換する引数として壁構成 ID、室 ID 対応表を持つ. private static void addExternalSurface( MaximumHeatLoadCalculate.Kernel.ImmutableModelDefinition mModel, ref EESLISM.Kernel.ModelDefinition eModel, out Dictionary<GeneralInformation.Orientation, int>[] exSurfaceIDTable). 外表面オブジェクトを変換する最大熱負荷計算では 8 方位しか存在しないため、他の変換メソッドと入出力仕様が異なる. 表 4.2 の変換関数を利用したモデル定義全体の変換関数を図 4.16 に示す。要素ごとの変換を繰り返し、変換前後の ID を保存する単純な構造となっており、行数も僅か 100 行程度であることから、可読性が高いことがわかる。. 4-14.

(16) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98. /// <summary>最大熱負荷計算モデルからEESLISMモデルへ変換する</summary> /// <param name="mModel">最大熱負荷計算モデル</param> /// <param name="warningMessages">変換エラーリスト</param> /// <returns>EESLISMモデル</returns> public static EESLISM.Kernel.ModelDefinition MHLModelToEESLISMModel( MaximumHeatLoadCalculate.Kernel.ImmutableModelDefinition mModel, out string[] warningMessages) { //変換時の警告 List<string> warningMsgs = new List<string>(); string[] wMsgBuff; //ID対応表を用意 Dictionary<int, int> wMaterialIDTable = new Dictionary<int, int>(); Dictionary<int, int> wallCompIDTable = new Dictionary<int, int>(); Dictionary<int, int> windowCompIDTable = new Dictionary<int, int>(); Dictionary<int, int> sunShadeIDTable = new Dictionary<int, int>(); Dictionary<int, int> roomIDTable = new Dictionary<int, int>(); Dictionary<GeneralInformation.Orientation, int>[] exSurfaceIDTable;. ID対応表定義. //変換するモデルを用意 EESLISM.Kernel.ModelDefinition eModel = new Popolo.EESLISM.Kernel.ModelDefinition(); //名称設定 eModel.SimulationProperty.Name = mModel.GeneralInfo.Name;. 外表面方位変換基本16方位の内、必要な方位のみを変換する. //外表面データを追加 addExternalSurface(mModel, ref eModel, out exSurfaceIDTable); //壁素材を変換 ImmutableWallMaterial[] materials = mModel.GetWallMaterial(); foreach (ImmutableWallMaterial wm in materials) { int newID = eModel.AddWallMaterial(new WallMaterial(wm)); wMaterialIDTable.Add(wm.ID, newID); }. 壁素材クラスは共通のものを利用するため、ID対応表の作成のみ. //壁構成を変換 MaximumHeatLoadCalculate.Kernel.ImmutableWallComposition[] wallComps = mModel.GetWallComposition(); foreach (MaximumHeatLoadCalculate.Kernel.ImmutableWallComposition wc in wallComps) { int newID = eModel.AddWallComposition(convertWallComposition(wc, wMaterialIDTable, out wMsgBuff));. 壁構成変換. //警告文を保存 warningMsgs.AddRange(wMsgBuff); wallCompIDTable.Add(wc.ID, newID); } //窓構成を変換 MaximumHeatLoadCalculate.Kernel.ImmutableWindowComposition[] windowComps = mModel.GetWindowComposition(); foreach (MaximumHeatLoadCalculate.Kernel.ImmutableWindowComposition wc in windowComps) { int newID = eModel.AddWindowComposition(convertWindowComposition(wc, out wMsgBuff)); //警告文を保存 warningMsgs.AddRange(wMsgBuff); windowCompIDTable.Add(wc.ID, newID); }. 窓構成変換. //日除けを変換 MaximumHeatLoadCalculate.Kernel.ImmutableSunShade[] sunShades = mModel.GetSunshade(); foreach (MaximumHeatLoadCalculate.Kernel.ImmutableSunShade ss in sunShades) { int newID = eModel.AddSunShade(convertSunShade(ss, out wMsgBuff)); //警告文を保存 warningMsgs.AddRange(wMsgBuff); sunShadeIDTable.Add(ss.ID, newID); }. 日除け変換. //室を変換 MaximumHeatLoadCalculate.Kernel.ImmutableRoom[] rooms = mModel.GetRoom(); foreach (MaximumHeatLoadCalculate.Kernel.ImmutableRoom rm in rooms) { EESLISM.Kernel.Room eRoom = convertRoom(rm, mModel.GeneralInfo.Type, sunShadeIDTable, exSurfaceIDTable, windowCompIDTable, wallCompIDTable, out wMsgBuff); //用途に応じてスケジュールを設定 setRoomSchedule(ref eRoom, eModel, mModel.GeneralInfo.Type, rm.AirStateSummer, rm.AirStateWinter); int newID = eModel.AddRoom(eRoom);. 窓変換. //警告文を保存 warningMsgs.AddRange(wMsgBuff); roomIDTable.Add(rm.ID, newID); } //内壁を変換 MaximumHeatLoadCalculate.Kernel.ImmutableInnerWall[] iWalls = mModel.GetInnerWall(); foreach (MaximumHeatLoadCalculate.Kernel.ImmutableInnerWall iWall in iWalls) { eModel.AddInnerWall(convertInnerWall(iWall, wallCompIDTable, roomIDTable, out wMsgBuff)); //警告文を保存 warningMsgs.AddRange(wMsgBuff); } warningMessages = warningMsgs.ToArray(); return eModel; }. 図 4.16. モデル定義全体の変換関数. 4-15. 内壁変換.

(17) 第4章. モデルデータのクラス化によるデータの活用法. 期間計算を行うためには、照明・人体・機器発熱・空調のスケジュール設定を行う必要がある。そこで、BECS/CEC/AC で事務所の計算を行う際のスケジュールを利用し、最大熱負荷計算で設定した値を乗じてデフォルトのスケジュールが自動生成される仕様とすることでデータ入力作業の軽減を図った。図 4.17 にデフォルトのスケジュール設定を示す。また、家具等の熱容量のデフォルト値としては、単位容積あたり 3 ×4.186 kJ/K を与えた。照明発熱スケジュール. 120%. 人体発熱スケジュール. 100% 80% 60% 40% 20% 0%. 機器発熱スケジュール. 120%. 100%. 80%. 80%. 60%. 60%. 40%. 40%. 20%. 20%. 0%. 0%. 0:00. 2:00. 4:00. 6:00. 空調スケジュール. 120%. 100%. 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00. 図 4.17. 外気カット. 0:00. 2:00. 4:00. 6:00. 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00. デフォルトスケジュール設定. 4.3.1 節で作成した建築学会標準オフィスビルモデルを EESLISM Editor へ書き出し、年間の動的熱負荷計算を実行した結果を図 4.18 に示す。図 4.19 に熱負荷デュレーションカーブを示す。ただし、ダクトからの空気漏洩や予冷負荷等を考慮して最大熱負荷計算では計算過程で各種係数がかけられている。図中の補正前負荷はこの係数を無視した計算結果である。冬季暖房運転時には立ち上がり時に大きな蓄熱負荷が生じ、年間で 33 時間ほど過負荷となることがわかる。また、最大熱負荷計算結果との比較によって、殆どの時間は低部分負荷での運転となることも推測できる。このように、動的年間熱負荷計算を行うことで、最大熱負荷計算のみでは把握することができない、低負荷時を含めた建物の特性を知ることができるが、従来のソフトウェアではこれらの計算の間に連続性がなかった。一方、本研究で開発したソフトウェアでは、前述したクラス構成をとることによって、一切の追加的作業を行わずにデータの移行を可能としたため、従来と同一の作業量で、より広い検討を行うことが可能となった。冷房負荷最大冷房負荷補正前最大冷房負荷. 60000. 60000. 最大暖房負荷 : 55607[W]. 50000. 暖房負荷最大暖房負荷補正前最大暖房負荷. 40000 40000 負荷[W]. 負荷[W]. 20000 0 Ｊａｎ. Feb. Mar. Apr. May. Jun. Jul. Aug. Se. Oct. Nov. 30000 20000. De. -20000. 10000. -40000. 0. 最大冷房負荷 : 35410[W]. 0. -60000. 200. 400. 600. 800. 1000. 1200. 1400. 1600. 時間[h]. 図 4.18. 標準ビル年間動的熱負荷計算結果. 図 4.19. 4-16. 標準ビル年間熱負荷デュレーションカーブ.

(18) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. 4.4. 年間エネルギーシミュレーションソフトウェアからのデータ展開. エネルギーシミュレーションモデルと制御系シミュレーションモデルとの大きな違いはコンポーネントの入出力構造にある。例として、HASP/ACSS12)および HVACSIM+(J)13)におけるコイルモデルの入出力構造を図 4.20 に示す。エネルギーシミュレーションにおいては、理想的な制御を仮定して所要熱量を求めるため、入力として負荷が与えられ、出力として制御量である冷水流量が計算される。一方、制御系の計算では制御設定値の良否の検討こそがシミュレーションの主目的となるため、制御量である冷水流量が入力、制御結果である除去熱量が出力となる。しかし、モデルに設定する物理パラメータには違いが無いため、前者のデータを移行することで後者において利用可能なモデルが作成可能であると推測できる。本節では、年間エネルギー計算ソフトウェアの開発を行い、制御系動的計算ソフトウェアへの展開法について述べる。また、仕様が公開された異なる開発主体によるソフトウェア間でのデータ展開の例として、本開発ソフトウェアから LCEM ツール14)へのデータ展開についても実践する。なお、データ展開の対象となる制御系動的計算ソフトウェアの詳細については第 4 章において報告する。冷却コイル負荷冷水入口温度空気入口状態空気流量. コイルモデル物理パラメータ. 冷水入口温度空気入口状態空気流量冷水流量. コイルモデル物理パラメータ. 図 4.20. 4.4.1. 過負荷判定冷水出口温度冷水流量 ACSS. 除去熱量冷水出口温度空気出口状態 HVACSIM+(J). ACSS および HVACSIM+(J)のコイル入出力構造. 年間エネルギー計算ソフトウェアの開発. 建築の年間エネルギー計算は、年間の熱負荷データ（プログラムにより作成することが一般的）を処理するために、設備システム側で必要とされるエネルギー量を計算するものである。本節では、年間エネルギー計算ソフトウェアの開発およびその動作検証について報告する。 1）. 開発したソフトウェアの概要. エネルギー計算の基本的な計算フローは、現実のシステムと同様に、以下の通りである。・空気を媒体として、室で発生した顕熱負荷および潜熱負荷を除去する・空気の熱は冷温水コイルにおいて水に移動させる・コイルの熱は、熱源において、冷媒に移動させる・水熱源の場合は冷媒の熱を冷却水に移動させ、冷却塔を介して大気中に放出させる・空気熱源の場合には熱源内部の熱交換器を利用して直接に大気中に放出させる以上のフローを物理モデルおよび特性モデルを利用して数式表現し、各熱移動において必要となる動力を積算する。ただし、上記のフローは常に成立せず、熱移動が不可能な場合（過負荷）が存在する。現実世界では、過負荷状態となる場合、入力である顕熱負荷および潜熱負荷が除去不可能となり、室空気状態が設定空気状態と乖離する。乖離の結果、建物内外空気状態差が小さくなり、負荷は減少する。結果としていずれかの点で空気状態および負荷は均衡する。設備システムシミュレーションと建築の熱負荷計算とを連成させることで、過負荷状態での均衡点 4-17.

(19) 第4章. モデルデータのクラス化によるデータの活用法. を計算することは可能であるが、計算結果の解釈が難しくなり、プログラムコードも煩雑となるという問題がある。従って、本研究では過負荷の大きさ（設定値と実現値との差分に基づく不足熱量：以下、未処理負荷と呼ぶ）を積算し、これを利用して計算結果を解釈する仕様とした。これは BECS/CEC/AC と同様の仕様である。後述する制御系動的シミュレーションソフトウェアや他のソフトウェアへの展開が容易となるよう、設備システムを構成する要素をクラスとして別個に定義した。この際に、主にユーザーとの対話を行いながらデータを保持するクラスと、設定されたデータに従って主に計算処理を行うクラスとをセットにすることで、ユーザーインターフェース部分と実際の計算処理部分とを切り分けた。前者はデータの正しさ（温度や物理性能の妥当性）を確認するほか、データの入出力機能を持つ。表 4.3 に主要な構成要素と対応するクラス名称を示す。表 4.3 クラス名称（計算処理）. 要素. 主要構成要素一覧. クラス名称（構造保持）. 概要. 室. Room. RoomStructure. 室の情報を保持するクラス. コイル. Coil. CoilStructure. 冷温水コイルの計算を行うクラス。対数平均温度差および対数平均エンタルピー差を利用して乾面、湿面の各面で収束計算を行う. AHU. AHU. AHUStructure. AHU の計算を行うクラス。冷温水コイルおよびファンをメンバーに持ち、各室の風量調整も行う. RoomUnit RoomUnit. RoomUnitStructure. RoomUnit の計算を行うクラス。冷温水コイルおよびファンをメンバーに持ち、AHU による熱除去が不足した場合に起動する. ファン. Fan. FanStructure. 空気の搬送動力を計算するクラス. ポンプ. Pump. PumpStructure. 水の搬送動力を計算するクラス. 熱源. AbstractHeatSource. HeatSourceStructure. 熱源抽象クラスであり、各種熱源としての実装は派生クラスで行う。ポンプをメンバーとしてもつ. 冷却塔. CoolingTower. CoolingTowerStructure. 湿り伝熱を解くことで冷却塔の計算を行うクラス。ポンプをメンバーとして持つ。. 図 4.21 に、UNO メイン画面を示す。ツールバーの各アイコンは、左から順に初期設定、 AHU、 RoomUnit、室、ポンプ、熱源、熱源群、冷却塔、スケジュールに対応しており、各要素の設定を行うことで全体の計算が可能となる。. 図 4.21. UNO メイン画面. 4-18.

(20) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. ・AHU VAV および CAV 方式の選択、室負荷除去の是非の設定（外気負荷のみを担当することが可能）、全熱交換器の設定、加湿方式の選択（水加湿・蒸気加湿・加湿無し）が可能である。後述するスケジューラを利用することで、最大風量補償、最小風量補償、給気空気状態制御、代表室状態制御の設定、外気カットおよび外気冷房の起動が設定可能である。冷暖設定を行うことで、2 管式、4 管式に対応することができる。また、乗数を設定することで同一仕様の AHU 系統の所要熱量を定数倍して上流である熱源へ伝えることが可能である。冷温水コイルについては定格能力をもとに伝熱面積を推定する仕様とした。図 4.22 に AHU のユーザーインターフェースを示す。. 図 4.22 AHU のユーザーインターフェース. ・室 AHU および室内ユニットの設定、最大風量および最小風量比の設定が可能である。 FCU は設置台数が可能である。また、乗数を設定することで同一仕様の室系統の所要熱量を定数倍して上流である AHU に伝えることが可能である。図 4.23 に室のユーザーインターフェースを示す。・ポンプ定格流量および定格出力を設定することが可能であり、定流量、バイパス制御、インバータ制御の各制御に応じてデフォルトの特性を定めた。増段方式は並列および台数が可能である。図 4.24 にポンプのユーザーインターフェースを示す。. 図 4.24. 図 4.23. 室のユーザーインターフェース. 4-19. ポンプユーザーインターフェース.

(21) 第4章. モデルデータのクラス化によるデータの活用法. ・冷却塔定格の能力を設定することで物理モデルを逆算し、湿り伝熱係数 [kW/K]を推定する仕様とした。スケジュール設定により、任意の期間についてフリークーリング稼動の是非、稼動条件、冷却水出口温度を設定すること可能である。図 4.25 に冷却塔のユーザーインターフェースを示す。. 図 4.25. 冷却塔のユーザーインターフェース. ・熱源熱源には定格能力を設定することとし、各熱源モデルに定義した無次元の特性に従って計算を行う仕様とした。また、熱源群としての挙動として、冷熱源および温熱源の発停および出口水温をスケジュールで設定することを可能とした。図 4.26 に熱源および熱源群のユーザ０インターフェースを示す。. 4-20.

(22) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. 2）. 動作検証. 日本建築設備士協会空気調和設備シミュレーション研究会のモデルビル 15)を利用し、開発したソフトウェアの動作検証を行った。図 4.27 にモデル化対象建物の平面図および断面図を示す。外壁から 5m をペリメータゾーン、内部をインテリアゾーンとする。コアと事務室は内壁によって分けられている。表 4.4 に壁構成を示す。階高は 3600mm、天井高は 2600mm である。各階、事務室の南北外壁に 8mm の熱線吸収ガラスの窓がそれぞれ 55m2 のずつ設けられている。家具等の熱容量は、12.5 kJ/m3-K とする。計算は、最上階、2~11 階、1 階の 3 フロアについて、天井裏、北側ペリメータ、南側ペリメータ、インテリアの 4 ゾーンに分割して行うこととする。また、コア部分については厳密な室温計算は行わず、隣室温度差係数を 0.4 として計算する。表 4.5 に運転条件を示す。2 管式であるため冷暖房期間が決められており、中間期は非空調とする。空調期間中の目標湿度は 40%とし、加湿方式は水方式とする。図 4.28 にシステム系統図を示す。表 4.6 に機器仕様を示す。AHU 系統と FCU 系統があり、前者は、インテリアゾーンの全負荷と両ゾーンの外気負荷を処理する。後者は、ペリメータゾーンの室内発熱負荷を処理する。ポンプおよびファンの回転数制御によって水量および風量ともに変流量とする。なお、ボイラの定格ガス消費量については文献に記載が無かったため、類似の建物モデルの仕様を援用した。事務室事務室事務室. N コア部分. コア部分. 38,400. 3,600. 2F 1F B1F. 3,600. 3,600 3,600. 2F～12Fのプランは 1Fと同一とする. 事務室 5,800. 12F 11F 10F. 5,800. 50,000. 事務室事務室機械室. 3,600. 50,000. 図 4.27. モデル化対象建物の平面図および断面図表 4.4. 素材. 厚み [mm]. 熱伝導率 [W/m-K]. コンクリート. 150. 1.3. 硬質ウレタンフォーム. 15. 0.024. 石膏ボード. 12. 0.15. 石膏ボード. 24. 0.15. 軽量コンクリート. 100. 0.69. プラスチックタイル. 3. 0.16. 硬質ウレタンフォーム. 20. 0.024. コンクリート. 150. 1.3. コンクリート. 150. 1.3. 吹付け岩綿. 50. 0.044. 部位. 外壁. 屋根. 壁構成. 空気層岩綿吸音板. 部位. 石膏ボード内壁. 1 階床. 熱抵抗=0.1 19. 素材. 0.055. 4-21. 厚み [mm]. 熱伝導率 [W/m-K]. 24. 0.15. 空気層. 熱抵抗=0.1.

(23) 第4章. モデルデータのクラス化によるデータの活用法. 表 4.5. 運転条件. 項目. 条件. 運転時間. 平日. 熱源. 冷房期間. 5月 6月 7月 8月. 23 23 23 23. 8:00～13:00. 暖房期間. 6/1～9/30. 1月 2月 3月 4月. 室内温度設定値. 土曜. 8:00～18:00. 11/1～4/30 成行 25 25 25. 9月 10 月 11 月 12 月. 0.2 人/m2 として%表示（平日）人間. 8 50. 9. 10. 11. 100 100 100. 15. 0.2 人/m2 として%表示（土曜）. 12. 13. 14. 16. 17. 18. 19. 8. 9. 10. 11. 12. 13. 14. 75. 75. 100 100 100. 75. 38. 13. 50. 100. 100. 100. 63. 25. 13. 25W/m2 として%表示（平日）照明. 8 50. 9. 10. 11. 100 100 100. 13. 14. 16. 17. 18. 19. 8. 9. 10. 11. 12. 13. 14. 85. 85. 100 100 100. 75. 50. 25. 50. 100. 100. 100. 75. 50. 25. 運転開始から 9:00 まで. 全熱交換器. 夏期：6/1 – 9/30. 15. 25W/m2 として%表示（土曜）. 12. 外気カット. 冬期：12/1 – 3/30. 表 4.6 機器. 25 成行 23 23. 機器仕様一覧. 仕様（定格条件）. 機器. 仕様（定格条件）. 遠心冷凍機. 能力：1143 kW 入口温度：7 °C 出口温度：13 °C 消費電力：259 kW. ボイラ. 能力：1128 kW （仮定）入口温度：44 °C 出口温度：50 °C 消費ガス量：121 m3. 冷却水ポンプ. 流量：3900 L/min 揚程：30 m 消費電力：30 kW. 冷水一次ポンプ. 流量：2640 L/min 揚程：15 m 消費電力：11 kW. 温水一次ポンプ. 流量：2640 L/min 揚程：10 m 消費電力：7.5 kW. 南側ペリメータ用冷温水二次ポンプ. 流量：580 L/min 揚程：30 m 消費電力：5.5 kW. 北側ペリメータ用冷温水二次ポンプ. 流量：580 L/min 揚程：30 m 消費電力：5.5 kW. インテリア用冷温水二次ポンプ. 流量：1530 L/min 揚程：30 m 消費電力：15 kW. ファンコイルユニット 24 台/フロア. 能力：1.67 kW 風量：340 m3/h 水量：4 L/min 消費電力：30 W/台. 能力：52 kW 水量：124 L/min 中間階用エアハンドリングユニット給気ファン：7700 m3/h, 5.5 kW （10 台）外気ファン：3840 m3/h, 1.5 kW 排気ファン：3070 m3/h, 1.5 kW 冷却塔ファン. 風量：1970 m3/min 消費電力：3.7 kW × 2 台. 能力：65 kW 水量：155 L/min 最上階用給気ファン：9700 m3/h, 5.5 kW エアハンドリングユニット外気ファン：3840 m3/h, 1.5 kW 排気ファン：3070 m3/h, 1.5 kW 能力：53 kW 水量：127 L/min 1 階用給気ファン：7900 m3/h, 5.5 kW エアハンドリングユニット外気ファン：3840 m3/h, 1.5 kW 排気ファン：3070 m3/h, 1.5 kW 全熱交換器. 4-22. 消費電力：0.4 kW/台.

(24) 建築設備シミュレーションソフトウェアの継続的開発法に関する研究. F. VAV ユニット. RA. T. AHU. EA. F. T. F 南側ペリメータ系統 FCU FCU. T. 北側ペリメータ系統 FCU FCU. OA. P P P INV. B. R P P. 図 4.28. システム系統図. 年間冷暖房負荷[GJ] (±SD). 日本建築設備士協会空気調和設備シミュレーション研究会において、国内外の 10 のエネルギーシミュレーションプログラムを利用して本モデルビルの計算が行われており、結果の比較が可能である。図 4.29 および図 4.30 に、各プログラムで計算した年間冷暖房負荷および年間熱源エネルギー消費量を示す。ただし、ガスの単位発熱量は 41.1 MJ/Nm3 とした。冷暖房負荷については、開発したプログラムの計算結果は 10 のプログラムの計算結果の平均値前後の値を取っていることがわかる。年間エネルギー消費量に関しても電力消費量については平均値前後の値となった。ガス消費量についてはやや大きめの値となったが、文献に定格ガス消費量についての記載が無く、類似の建物モデルにおけるボイラの仕様を援用したことが原因と考えられる。 3000. 冷却. 加熱 2475. 2422 2400. 2158. 2253. 2120. 2244. 2120. 2193. 2271. 2265. 2252. 2262. 1800 1200 600. 884 518 309. 458. 288. 216. 468. 444. 429. 431. 510. 272. 0 A. B. C. D. E. 年間エネルギー消費量[GJ] (±SD). 図 4.29 1500. 電力. F. G. H. I. J. 平均. UNO. 年間冷暖房負荷計算結果. ガス 1204. 1200 900 600. 744 600. 661. 848. 832. 763. 705. 611 621. 522. 518 358. 267. 259. 300. 733. 799 662. 706. 667. 666 718 535. 341. 0 A. B. C. 図 4.30. D. E. F. G. H. I. 年間熱源エネルギー消費量計算結果 4-23. J. 平均. UNO.

(25) 第4章. モデルデータのクラス化によるデータの活用法. 4.4.2. データの展開. 制御系動的シミュレーションソフトウェアへのデータ展開および異なる開発主体のエネルギー計算ソフトウェアへのデータ展開を行った。 1）. 制御系動的シミュレーションソフトウェアへのデータ展開法. 第 5 章で報告する制御系動的シミュレーションソフトウェア「 Popolo-Dynamic Simulator」へのデータ展開を行った。図 4.31 に年間エネルギー計算ソフトウェアから制御系動的シミュレーションソフトウェアへのデータ展開の概念を示す。前述の通り、本研究で開発した年間エネルギー計算ソフトウェアは、モデル内の各要素を別個のクラスとして定義しており、各種のデータはそれぞれのクラスに所属しているため、他の要素とは独立した存在である。一方、制御系動的シミュレーションソフトウェアはモジュール形式の構造を取ることが一般的であり、本研究で開発したソフトウェアも、機器一般を示す概念である AbstractDevice という抽象クラスを利用してモジュール化を行った（詳細は第 5 章で記す）。従って、AbstractDevice から派生したクラスの機能の実装は、各派生クラスに委ねられており、自由である。この特徴を活かし、年間エネルギー計算ソフトウェア内部の各要素を示すクラスを抜き出し、AbstraceDevice 派生クラスでラップすることで他のモジュールとの連成計算を行うことを可能とした。. 具体例として、図 4.32 に UNO コイルモデルクラスを AbstractDevice 派生クラスでラップしたコードを示す。3 行目では、クラス定義を行っており、AbstractDevice クラスから派生させていることがわかる。10 行目は UNO に定義された CoilStructure のオブジェクトの宣言であり、UNO のクラスを内包する構造であることがわかる。77 行～100 行が、主な計算処理であり、モジュールに渡された入力値リストを UNO のコイルオブジェクトにそのまま渡し、コイルオブジェクトの出力をモジュールの出力として設定していることがわかる。GetInputValue(int index) 関数はモジュールへの入力値を取得する処理、SetOutputValue(int index) 関数はモジュールの出力値を設定する処理である。制御系のシミュレーションを行うことが目的であるため、 Coil クラスの UpdateStateWithWaterFlowRate(double waterFlowRate) 関数を呼び出すことで、成り行きでのコイル出口状態を計算している。 4-24.

(26) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75. /// <summary>UNOコイルモデルのAdopterクラス</summary> [Serializable] public class UNOCoilDevice : AbstractDevice, ISerializable { /// <summary>シリアライズ用バージョン情報</summary> private const double SC_VERSION = 1.0; /// <summary>UNO Coil構造クラス</summary> private CoilStructure unoCoilStruct; /// <summary>UNO Coilクラス</summary> private Coil unoCoil; /// <summary>UNOCoilDeviceクラスの概要を取得する</summary> public override string Summary { get { return "対数平均温度差および対数平均温度差に基づくコイルモデル"; } } /// <summary>UNO Coilモデルを設定・取得する</summary> public CoilStructure CoilStructure { get { return unoCoilStruct; } set { unoCoilStruct = value; } } /// <summary>コンストラクタ</summary> public UNOCoilDevice() { //6入力 : 発停、入口乾球温度、入口絶対湿度、風量、入口水温、水量 //4出力 : 出口乾球温度、出口絶対湿度、出口水温、交換熱量 InitializeDevice(6, 4, 0, 0); //名称設定 Name = "コイル"; //入力変数情報設定 SetInputInformation(0, new InputInformation("発停", "1で起動、それ以外で停止", 0, HvacModel.InputType.FixedVariableInput)); SetInputInformation(1, new InputInformation("入口乾球温度[℃]", "", 25, HvacModel.InputType.SSolvedVariableInOut)); SetInputInformation(2, new InputInformation("入口絶対湿度[kg/kg(DA)]", "", 0.002, HvacModel.InputType.SSolvedVariableInOut)); SetInputInformation(3, new InputInformation("風量[kg/s]", "", 0, HvacModel.InputType.FixedVariableInput)); SetInputInformation(4, new InputInformation("入口水温[℃]", "", 7, HvacModel.InputType.SSolvedVariableInOut)); SetInputInformation(5, new InputInformation("水量[kg/s]", "", 0, HvacModel.InputType.FixedVariableInput)); //出力変数情報設定 SetOutputInformation(0, SetOutputInformation(1, SetOutputInformation(2, SetOutputInformation(3,. new new new new. OutputInformation("出口乾球温度[℃]", "", 0, false)); OutputInformation("出口絶対湿度[kg/kg(DA)]", "", 0, false)); OutputInformation("出口水温[℃]", "", 0, false)); OutputInformation("交換熱量[kW]", "", 0, false));. } /// <summary>UNOCoilDeviceの複製を返す</summary> /// <returns>UNOCoilDeviceの複製</returns> public override object Clone() { UNOCoilDevice ud = (UNOCoilDevice)base.Clone(); ud.unoCoilStruct = (CoilStructure)this.unoCoilStruct.Clone(); return ud; }. 図 4.32. 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150. /// <summary>出力を計算する</summary> public override void OutputCalculation() { bool operating = (1 == GetInputValue(0)); double dbtIn = GetInputValue(1); //入口乾球温度[℃] double ahdIn = GetInputValue(2); //入口絶対湿度[kg/kg(DA)] double aFlow = GetInputValue(3); //風量[kg/s] double wTemp = GetInputValue(4); //入口水温[℃] double wFlow = GetInputValue(5); //水量[kg/s] if (operating) { unoCoil.SetInletAirState(MoistAir.GetAirStateFromDBAH(dbtIn, ahdIn)); unoCoil.AirFlowRate = aFlow; unoCoil.WaterInletTemperature = wTemp; unoCoil.UpdateStateWithWaterFlowRate(wFlow); } else unoCoil.ShutOff(); //出力設定 SetOutputValue(0, SetOutputValue(1, SetOutputValue(2, SetOutputValue(3,. unoCoil.OutletAirState.DryBulbTemperature); unoCoil.OutletAirState.AbsoluteHumidity); unoCoil.WaterOutletTemperature); unoCoil.RejectLoad);. } /// <summary>初回の処理</summary> public override void FirstCalculation() { //コイルオブジェクトが作成可能かテスト string[] wMsg, eMsg; if (!unoCoilStruct.HasStructuralErrors(out wMsg, out eMsg)) { //コイルオブジェクトを作成する unoCoil = unoCoilStruct.MakeCoil(); } else { string msgs = ""; foreach (string msg in wMsg) msgs += msg + "\r\n"; foreach (string msg in eMsg) msgs += msg + "\r\n"; throw new DeviceException(msgs); } } /// <summary>デシリアライズ用コンストラクタ</summary> /// <param name="sInfo"></param> /// <param name="context"></param> public UNOCoilDevice(SerializationInfo sInfo, StreamingContext context) : base(sInfo, context) { //バージョン情報 double version = sInfo.GetDouble("SC_VERSION"); //UNO Coilクラス unoCoilStruct = (CoilStructure)sInfo.GetValue("unoCoil", typeof(CoilStructure)); } /// <summary>シリアル化処理</summary> /// <param name="info"></param> /// <param name="context"></param> public override void GetObjectData(SerializationInfo info, StreamingContext context) { //親クラスの処理を呼び出し base.GetObjectData(info, context); //バージョン情報 info.AddValue("SC_VERSION", SC_VERSION); //UNO Coilクラス info.AddValue("unoCoil", unoCoilStruct); } }. コイルモデル Adopter クラス（抜粋） 4-25. //出口乾球温度[℃] //出口絶対湿度[kg/kg(DA)] //出口水温[℃] //交換熱量[kW].

(27) 第4章. 2）. モデルデータのクラス化によるデータの活用法. 他のエネルギーシミュレーションソフトウェアへのデータ展開法. 仕様ないしはソースコードの公開は、異なるソフトウェア開発主体間でのデータの互換を可能とすると考えられる。そこで、国土交通省官庁営繕部が主体となって開発が進められている LCEM ツールへのデータ展開を試行した。 LCEM ツールは表計算プログラムのセル群を機器モデルとして定義し、セル群の連結によってシステムを定義するシミュレーションプログラムである。ユーザーによる自由なモジュール接続と、新規の機器モデル開発を可能とするために、他の機器モデルとの入出力部分（通信部）を一定のフォーマットに統一している。例として、図 4.33 に LCEM ツールのコイルモデルの通信部を示す。緑の線で囲った部分が通信部であり、機器モデルが実装すべき入出力関係が定義されている。配管エラー状態送水判定 0:停止 1:運転送水モード 0:停止 1:冷房 2:暖房総水量（l/m）水量（l/m/台）冷温水往温度( ℃) 冷温水還温度( ℃). 0 1 1 65 7.0 12.8. 属性接続台数. 1. 通信部（抽象的機器仕様）. 加熱・冷却コイル（ユニット形空調機）エラー状態送水判定 0:停止 1:運転コイルモード 0:送風 1:冷 2:暖送水モード 0:停止 1:冷房 2:暖房風量 m3/h 水量 ℓ/min コイル入口冷温水温度 ℃ コイル出口冷温水温度 ℃ コイル入口空気温度 ℃ コイル入口空気エンタルピー kJ/kg コイル入口空気絶対湿度 kg/kg' コイル出口空気温度 ℃ コイル出口空気エンタルピー kJ/kg コイル出口空気絶対湿度 kg/kg' 判定 [0 or 1]. CHC(U)-XX1-300XX-40 0 1 1 1 4,000 65 7.00 12.76 29.00 64.61 0.0139 17.00 44.951 0.0110 0. コイル制御初期化 [0 or 1]. 演算部（個別具体的機器の処理実装）. 0. 送水モード水量－ ℓ/min 水量＋ [ℓ/min] コイル出口冷温水温度－ ℃ コイル出口冷温水温度＋ ℃ コイル出口飽和空気エンタルピー－ kJ/kg コイル出口飽和空気エンタルピー＋ kJ/kg コイル入口飽和空気エンタルピー kJ/kg 冷却／加熱負荷 kW. 図 4.33. 1 65 65 12.76 12.76 35.80 35.80 22.5 26.2. ユニット形空気調和機（外気導入部）エラー状態運転状態 0:停止 1:運転コイルモード 0:送風 1:冷 2:暖室運転要求 0:停止 1:冷房 2:暖房 3:混在運転モード 1:冷房 2:暖房外気カット制御（有=1／無=0）空調機風量V（m3/h）要求給気温度コイル入口空気温度（℃）コイル入口空気ｴﾝﾀﾙﾋﾟ（kJ/kg'）コイル入口空気絶対湿度（kg/kg'）コイル出口空気温度（℃）コイル出口空気ｴﾝﾀﾙﾋﾟ（kJ/kg'）コイル出口空気絶対湿度（kg/kg'）給気温度（℃）給気露点温度（℃）給気エンタルピ（kJ/kg'）給気絶対湿度（kg/kg'）還気温度（℃）還気露点温度（℃）還気エンタルピ（kJ/kg'）還気絶対湿度（kg/kg'）給気ファン発熱上昇制御用絶対湿度外気量外気冷房判定. 0 1 1 1 1 0 4,000 20 29.0 64.61 0.0139 17.0 44.95 0.0110 14.0 13.2 38.0 0.0095 26.8 13.2 51.1 0.0095. LCEM ツールコイルモデル通信部. LCEM ツールで定義されているコイルモデルは濡れ面係数に基づくモデルであるが、本研究で開発した UNO では等価単純コイルとして解くコイルモデルを採用している。しかし、上記の通り、通信部仕様を満たす限り、内部の演算処理は自由となっているため、 LCEM ツールと互換性のある形でモデルを書き出すことは可能であると考えられる。そこで、LCEM ツールのコイルモデルと同一の通信部を持った LCEM ツール用の等価単純コイルモデルを新規に開発した。図 4.34 に開発した等価単純コイルモデルを示す。演算部の処理は UNO に定義されたコイルと同一であるため、当然、計算結果は一致する。従って、UNO のコイルモデルが持っている物理データ（コイル表面積、熱通過率、バイパスファクター）を表計算プログラムの指定セルに書き出すことで、計算結果の整合性は保たれる。これにより、ユーザーは利用する計算ソフトウェアを容易に変更することが可能となった。同様に、新規に開発した冷却塔モデルを図 4.35 に示す。LCEM ツールの冷却塔モデルは特性式に基づくモデルであり、UNO で採用した湿り伝熱を解くモデルとは異なるが、通信部仕様の一致により互換性を獲得することができた。. 4-26.

第四章 モデルデータのクラス化によるデータの活用法

第四章モデルデータのクラス化によるデータの活用法