コンピュータ支援設計(CAD)は、何十年にもわたって、商業利用されている。CADシステムは、設計情報の形成、編集、表示及び検索を自動化する効率的な方法を提供する。CADシステムの能力は、知識集約型のプログラミング技術の利用により向上し、エンジニアリング及び/又は設計規則を形式化及び符号化して、設計プロセスの一部を自動化する、又は、潜在的な設計エラーを検出するべく実行することができる。知識集約型のシステムの一般的な例としては、多くの商用ワードプロセッサに適用されている文法チェック機能が挙げられ、英文法の多くの規則が符号化されて、自動的にテキスト文書に適用されて、潜在的な誤りをハイライトし、正しいアクションを提案する。
本明細書に記載するシステム及び方法は、その土地の状態、工法規則及び建築基準法等の多数の設計制限に従った太陽エネルギーシステム設計の自動レイアウト、評価及び最適化に対する、知識集約型のCAD技術の適用に関する。好ましい実施形態は、AutoCAD(登録商標)のような、既存のCADシステムに対するソフトウェアのカスタマイズを統合したセットとして実装される。または、本明細書に記載されるシステム及び方法は、全く新しいスタンドアローンのソフトウェアプログラムとして実装されてもよい。
本明細書に記載される本発明の好ましい一実施形態では、所定の作業場所における設置に適したソーラーコレクタのレイアウトを設計する方法及びシステムを提供する。実施形態は、様々なデータオブジェクトを生成及び編集し、このようなオブジェクトを、付随する特性及びレイアウト制限を伴う予め規定された"構造"の様々なタイプで分類する。構造の種類又はカテゴリは、(1)壁、屋根及び換気扇等の設置現場の物理的構造、(2)敷地境界、区画の境界、電線の敷設権、洪水が起きる土地、環境を配慮したエリア、特定の地震帯、公共設備の地役権等の設置現場の無形資産又は非物理的構造、並びに(3)太陽エネルギーシステム構成要素及び配置、を含んでもよい。分類の一部として、又は分類に加えて、実施形態は、固有特性又は付随する特性をオブジェクトに対して、生成する、割り当てる又は編集するシステム及び方法を含んでもよい。固有の構造的特性としては、高さ、重さ、コスト等のオブジェクトそのものに固有の特性が含まれる。付随する特性は、どのようのオブジェクトが、その他のオブジェクトとインタラクション(対話)するかの規定を含む。外因性特性の例としては、オブジェクトと別の隣接するオブジェクトとの間の最小距離(セットバック)を確立するセットバック規定が含まれる。
例えば、特定の法域では、敷地境界から30フィート以内に、構造物を設置することが許可されていない場合がある。一実施形態に係るシステムを使用することにより、ユーザーは、最初に、次のようにして、"敷地境界"構造分類を生成してもよい。ユーザーは、(1)"敷地境界"と名付けた新たな種類の構造分類を形成する、(2)敷地境界の構造分類の視覚的表示として、黒色の点線を設定する、(3)"セットバック"と称される特性を規定し、"敷地境界"構造分類に割り当てる、(4)この構造分類に、例えば、30フィートといった初期値を割り当てる、(5)特定の設計における利用、又は、あらゆるプロジェクト設計における一般利用に対する構造分類データベース内に、この構造分類規定を格納する。
次に、設計者は、予め規定された構造分類の"敷地境界"を、以下のように使用してもよい。設計者は、(1)設置現場の表示を、実施形態として生成する又は取り込む、(2)設置現場表示において、予め規定された分類である"敷地境界"に、1以上の幾何的要素(例えば、線)を割り当てる、(3)必要に応じて、オブジェクトの"セットバック"の値を、例えば、20フィートに変更する、(4)"敷地境界"と記されたオブジェクトのセットバック規定に準拠した、ソーラーコレクタのレイアウトを含む、太陽光システム設計を生成するように実施形態に命令する。
ソーラーコレクタレイアウトを生成するプロセスの一部として、本発明の好ましい実施形態は、(1)設計規則を生成する、(2)1以上の太陽エネルギーシステム設計の代替案を生成するべく、上記したオブジェクトに、設計規則を適用する、(3)1以上の設計代替案の配置又は物理的レイアウトの画面表示及び/又は紙表示を生成する、(4)部品点数、最大能力、コスト及びエネルギー生成のような1以上の設計の1以上のバージョンの概要を生成する、(5)ユーザーに柔軟性を提供する、並びに、顧客、設計、法的及び製造者の要求に対処することを確かにするメカニズムとして、ユーザー順守又は修正マニュアルに対する修正、又は設計規則の無効化等のソフトウェア符号化された設計ルールに対する例外を追跡する、及び(6)設計者が、設計代替案及び設計修正案の相対的な利点をリアルタイムで評価する、及び設計最適化を助けることを可能とする、可視化された情報を生成すること、を行うための方法及びシステムを提供する。
好ましい一実施形態に係る方法の動作は、(1)設置現場を表す情報を、知識集約型太陽CADシステムに取り込む、又は、CADシステムを使用して、設置現場を表す幾何的表現を生成する、(2)分類又はカテゴリ化によって、設置現場を表す関係する幾何的要素のそれぞれを、所定のデータオブジェクト種の1以上のインスタンスとして関連付け、それぞれの特性を調整する、(3)例えば、プロジェクトレイアウトを目的とする設置現場のエリアのような"作業エリア"を指定する、(4)ソーラーコレクタの種類及び設置サイズのような設計設定を選択する、(5)設置現場のデータ表示及びそれに付随する特性に従って、自動的に設計を生成する、(6)1以上の測定基準に従って設計を評価する、(7)設計代替案の生成及び比較を行う、(8)設計修正及び設計代替案の選択による、設計の最適化を行う、及び(9)設計上の例外規定のような、設計例外事項のリストの生成、を含む。
関連付けは、設置現場表示における特定の幾何オブジェクトを分類することによって行われてもよく、例えば、構造物の種類のインスタンスを、"屋根"又は"換気扇"といったように分類してもよい。このような分類は、幾何的オブジェクトを、特定の特性及び、太陽エネルギーシステムの自動設計を実行するのに使用されるレイアウト制限と関連付けるべく行われる。設置現場の特性、レイアウト制限、設計設定、モジュール特性及び制限、性能目標等に関連する更なる設計規則及び特性を、規定してもよい。この符号化された情報の全てが、ツールによって使用され、設計者による設定、プロジェクト制限、工学的慣例、建築基準法等に従った太陽モジュール設置に対する設計が、自動的に生成される。そして、配線図、部品表、説明、規約、概要、監査報告、その他の提出物、又は以下に示す表1に従った出力のような関連情報が生成される。
上記したように、ツールは、レイアウト生成に関して1以上の特定の境界を規定できる能力を設計者に提供することにより、レイアウト生成の制御を提供してもよい。ユーザーは、(例えば、分類されたオブジェクトの特性のような、その他の特性及び規則に整合して)ソーラーコレクタの設置が許される場所の境界に対応する作業領域を1以上規定してもよい。ユーザーは、例えば、ソーラーコレクタモジュールのレイアウトを設置現場の一部、例えば、屋根の南側に面した部分に制限するといったように、作業エリアを使用してもよい。ユーザーはまた、1以上のレイアウトアパーチャ(aperture)を規定してもよく、レイアウトアパーチャのそれぞれは、ユーザーが規定した異なる設計設定のセットに準拠すべきレイアウトにおける境界に対応していてもよい。異なる設計設定を有するアパーチャを使用することにより、ユーザーが、例えば、一種類のモジュールを屋根の一領域に配置し、別の種類のモジュールを屋根の別の領域に配置するといったことが可能となる。
ある実施形態では、設計者が、上述したように、構造の分類、レイアウトの生成、そして、レイアウトの修正といったプロセスを経るに従って、設計プロセスに関するメタデータが生成されてもよい。このメタデータは、多くの形式をとってもよく、また、設計者が行った及び行うべき動作についての情報を含んでもよく、監督者、共同設計者及びダウンストリームのユーザー、及び設計の受取人にとって有用な設計情報を含んでもよい。
ある実施形態では、このメタデータの一部又は全てが、設計者に、ソフトウェアにおける符号化された規則に対する例外といった形式で表示されるユーザーインターフェースが提供されてもよい。規則は、顧客の要求、国の法律及び規整、工学的制約、ソーラーコレクタ製造ガイドライン等から生成されていてもよい。例外としては、プロジェクト作業エリアのロケーションのような特性情報が提供できない場合が含まれる。設計者は、この例外の情報を、様々な方法でやり取りしてもよく、例えば、規則を適用することで、例外リストから項目を取り除く、又は、規定の適用を無効化するといった方法でやり取りしてもよい。メタデータの一部又は全てを、共通のストレージ又は参照によって、設計と関連付けてもよい。その後、ダウンストリームユーザー及び自動化システムを含む設計の処理者が、情報にアクセスしてもよい。情報は、また、要約、エクスポート、暗号化、されてもよく、また、システムによって演算されてもよい。例外のリストは、ユーザーにとっての"ToDo(やるべきことの)リスト"として機能してもよく(ユーザーインターフェースにおいても同様に称されていてもよい)、ソフトウェア規則が対処されるシーケンスと同時に、確かにソフトウェア規則が対処されることを確かにする、ユーザーに柔軟性を与える。例外、及び、それらがどのように扱われたかの情報は、後の再検討のために、履歴として維持することができ、契約書が、通常でない又は非標準選択肢を反映したものであることを確かめる一助となる。
ある実施形態では、特定の設置現場に対して、ソーラーコレクタレイアウト設計の複数のバージョンを見る、生成する及び操作するためのシステム及びユーザーインターフェースを提供してもよい。複数のバージョンの使用により、例えば、設計者が、入力(例えば、設計設定及び/又は特徴、又はプロジェクト特性)を素早く且つ容易に変更することができ、同じプロジェクトに対する代替設計選択肢(例えば、様々な種類のPVモジュールを使用することによるコストへの影響)に対応する生成された出力(例えば、代替レイアウト案、コスト、性能データ)を見ることができる。複数のバージョンを提供することにより、設計者は、ユーザー入力における変更に基づいて異なるレイアウトを迅速にモデル化でき、またその結果を評価することが可能となる。ある実施形態では、設計者は、一のバージョンから別のバージョンへと迅速に移動することができ、また、別の実施系形態では、設計者が、1つのアクションで複数のバージョンに影響を与えることを可能としてもよい。複数のバージョンは、複数の要素、特性又は設計規則の1以上のセットを共有してもよく、このようにすることにより、一のバージョンに適用された変化を、関連する複数のバージョンに適用可能としてもよい。例えば、新たに発見された現場の構造を追加するといったような、設置現場に一般的な変更を行う場合、複数のバージョンについても同様な変更を反映させてもよい。複数のバージョンは、例えば、1つのファイル又は複合ファイルに情報を位置させることによって、情報を共有してもよい。
[1.序論]
本明細書に記載する原理は、一般的な太陽エネルギー収集設備に適用可能である。パネル、吸収体及び反射体といった様々な種類の太陽エネルギー収集器、及び、太陽電池(PV)モジュール、太陽熱吸収装置、集光型太陽熱発電(CSP)等のその他のエネルギー変換技術が、使用されてもよい。ソーラーコレクタは、そのまま取り付けられてもよいし、又は、様々な種類の搭載システムに配置されてもよい。搭載システムとしては、タイル状システム、固定システム及び追跡システムが含まれる。システムは、公共の電力設備にオングリッド接続されるように設計される、及び/又はオフグリッドシステムに接続させるように設計されていてもよい。ソーラーコレクタ及び搭載システムは、地面、屋根の上、壁、駐車場の建物等に、様々な形態で取り付けられてもよい。説明を容易にするため、本明細書では、大部分をPVモジュールの設置に関連して説明している。しかしながら、実施形態は、上述したように、ソーラーコレクタ全般に適用可能である。
PV設備の設計タスクには、一般的に、簡単ではない共依存の複数のプロセスが含まれる。このようなプロセスとしては、例えば、(1)入手可能性、コスト、効率、電力条件等に基いて、特定のPVモジュールを選択する、(2)設置現場におけるPVモジュールの配置(レイアウト)を生成する、(3)設置したPVモジュールに対する配線図(ルーティング図)を生成する、(4)複雑なプロジェクト固有の入力に基いて、電力生成、電力変換効率等のプロジェクトの生産能力を見積もる、(5)プロジェクトの部品表(BOM)、契約書等のダウンストリームにおける書類を作成する、等が含まれる。無論、上記の全てが、地方の規制、国の法律等に沿って実行されなければならない。大規模太陽光プロジェクトにおいて実行される典型的な段階のシーケンスが、表2に示されている。
設備のサイズが大きくなればなるほど、例えば、モジュールの数が増えれば増えるほど、上記のプロセスを実行する難しさが増加する。例えば、所定の行に1つのモジュールを追加するといったような、表向きは些細な変更であっても、配線接続形態及び/又はその他のモジュールの配置に対して大きな影響を与える場合があり、したがって、生成されるシステム設計及びシステムの出力(出力電力等)に対しても大きな影響がある。このような複雑性が存在することから、モジュールの再配置、追加又は除去を含むレイアウトの最適化又は修正は、難しく、特に、大規模なプロジェクトでは、試行錯誤のプロセスと似通ったものになってしまう。一般的に、10〜20週かけてプロジェクト設計が終了する、又は、何ヶ月かを経て契約を締結する時には、レイアウトに元々使用することを考えていた構成要素が、市場ではすでに手に入らなくなってしまい、大幅な設計変更が必要になってしまうかもしれない。
設置現場の設計過程における、退屈な及び複雑な作業は、自動化ツールを使用することにより、削減することができる。具体的には、ソフトウェア又はその他のコンピュータに実装されるツールが本明細書に記載され、これらは、工学的慣例、設計者の好み及び設置現場の状態に対応する符号化された情報に基づいて、設置現場の設計を自動的に生成する。このようなツールの一部は、例えば、AutoCAD.DWGファイルのような、設置現場のCAD表示を、開始点として使用する。このファイルは、設置現場のベクトル又はビットマップ表示を含んでもよく、典型的には、線、ポリライン、曲線、正方形、矩形、スプライン、記号、多角形、その他の二次元又は三次元の形、面、立体、画像データ等の幾何的オブジェクトの集合によって、表示が行われる。この表示では、一般的に、幾何的オブジェクトには意味情報がほとんど又は全く添付されておらず、この表現における情報は、設置現場の物理的特徴に対応する形状及び大きさに限定されてもよい。例えば、換気扇を有する屋根の2D平面図表示は、大きな矩形(屋根)を形成する4つの線のセットと、小さな正方形(換気扇)を形成する4つの線のセットとによって構成されており、小さな正方形が、大きな矩形に内包された表示となっている。CADの従来のツール、及びある実施形態では、ユーザーが、このような、幾何的オブジジェクトの初期表示を生成することができる機能を提供してもよい。これに替えて、ユーザーは、コンピュータファイルのような格納場所から、幾何的オブジジェクトの初期表示を取り込んでもよい。
ある実施形態では、表示で使用されるオブジェクトを分類する(例えば、カテゴリ化又はタグ付け)メカニズムが提供されてもよく、オブジェクトを、構造種類のような、モジュールレイアウト生成に関係する意味情報と関連付けてもよい。例えば、上記の線のセットを、ユーザーは、事前に存在する構造物の種類である"屋根"のインスタンスとして、分類してもよい。システムは、オブジェクトを、屋根とモジュールレイアウトとの間の関係に対応する意味情報のセットと関連付けるのに、この分類を利用してもよい。この情報は、屋根に固有の物理的特性、例えば、"ピッチ=17度"及び"高さ=30.0フィート"、及び/又は、屋根に付帯する特性(例えば、"エッジセットバック=1.0フット")と、関連付けられていてもよい。このような特性は、多くの場合、ユーザーによって編集可能であり、同じ汎用型の異なるインスタンスによって変化してもよく、また、司法域(例えば、都市計画法など)によって変化してもよい。構造分類のリストの例が、表3に示されており、また、構造特性のリストの例が、表4に示されている。
同様に、ユーザーが、設置現場の表示における別のオブジェクト(又は複数のオブジェクトのセット)を、構造種類"換気扇"のインスタンスとして分類してもよい。その後で、システムは、オブジェクトを、"高さ=3フィート"といったように、換気扇に対応する構造特性と関連付ける。ある実施形態では、事実上、無限数のオブジェクトを、様々な特性を有する構造の様々な種類で分類してもよい。これら様々な構造の幾つかについて、構造特性を、カテゴリ的に予め定めてもよく(特定の分類又は種類のインスタンスそれぞれに対して、適用可能であって且つ不変である)、その他の構造特性は、単なる初期値、インスタンス固有の値であってもよい。ユーザーは、高さのような数多くの構造特性を、必要に応じて及び/又は適宜調整してもよく、全体的な構造種類に対応する構造特性のような、その他の構造特性については、ユーザーが編集できる、又はできないようにしてもよい。このように、分類されたオブジェクトは、その他の分類されたオブジェクトと共通の及び/又は固有の構造特性を有してもよい。
特定のオブジェクトに関連付けられた意味情報は、特定の構造分類の全てのインスタンスに対して通常は不変である、一般化された設計規則に対応していてもよい。例えば、屋根として分類されるオブジェクトは、システムよって、例えば、"コレクタレイアウト可能=yes"といったように、適切な構造レイアウト制限と関連付けられてもよく、どのようにモジュールを屋根の上又は周辺に配置するかに関するその他の設計規則と関連付けられてもよい。以下に説明するように、ある実施形態では、設計規則は、少なくともソフトウェアの最初の使用の際に、無効化されてもよいが、規則の必要条件からの変更を追跡するために、例外事項のリストはそのまま維持される。
このようにして、ユーザーがアクションを分類することにより、オブジェクトの元の単純な幾何的表示に、例えば、より高い階層の追加の構造的情報を割り当てて、自動化設計システムに使用させてもよい。加えて、システムは、オブジェクトが、構造のインスタンスとして自動的に分類され、構造特性及び設計特性に値が割り当てられるようなメカニズムを提供してもよい。形状再設定アルゴリズム、学習アルゴリズム、又はその他のエキスパートシステムを使用して、オブジェクトの分類及び値の割り当てを実行してもよい。また、幾何的オブジェクトを、前処理段階で補正、例えば修正して、分類、構造割り当て又はレイアウト処理におけるより良い状態又は位置にオブジェクトを配置してもよい。エンジンは、例えば、試作分類といった設計者からの入力を、オブジェクト修正の基本として使用してもよい。例えば、設計者が、4つの線を"屋根"として分類することを試みているが、4つの線が完全に閉じた形を形成しない場合には、ソフトウェア修正エンジンが、線の終点が共有されるように、適切にオブジェクトを修正することを試みてもよい。
ある実施形態では、分類されたオブジェクト、その分類、例えば、構造特性のセットのような符号化された情報、及び以下に記載するようなその他の情報を使用するレイアウトエンジンソフトウェアモジュールのような、レイアウト構成要素を提供して、モジュール設置設計を生成してもよい。例えば、"屋根"として分類されたオブジェクトが、"レイアウト可能=yes"というレイアウト規則と関連付けられていてもよく、それにより、レイアウトエンジンは、"屋根"として印を付けられ分類されたオブジェクト間の境界領域に、ソーラーコレクタを設置することを考えてもよい。同様に、換気扇が、分類又は特定のインスタンスとして、レイアウト規則"レイアウト可能=no"と関連付けられていてもよく、したがって、レイアウトエンジンは、"換気扇"と印が付けられているオブジェクトに対応する領域には、モジュールを配置できないと知ることができる。屋根のように、そこにモジュールの配置が許されるオブジェクトには、明示的に"作業エリア"と称して、モジュールが配置されてもよい場所(その他のレイアウト規則と矛盾せずに)であることを示してもよく、この場合、ユーザーが個別に、作業エリアを定義する必要はない。
レイアウトプロセスに対するより大きな制御を有効にするメカニズムを、ユーザーに提供してもよい。ユーザーは、例えば、明示的に、1以上のユーザー生成作業領域を定義することによって、モジュール配置が許可される境界の範囲を狭めてもよい。ユーザー生成作業領域は、ユーザーによって生成された幾何的オブジェクトであってもよく、例えば、"レイアウト可能=yes"を含むレイアウト規則の特定のセットと関連付けられていてもよい。レイアウトエンジンソフトウェアモジュールは、明示的な、例えばユーザーが生成した作業エリア、明示的な作業エリアの一方、又は両方内に含まれるロケーションにのみ、ソーラーコレクタを配置することを考えるように設定されてもよい。これは、例えば、設計者が、屋根の一部に制限して、ソーラーコレクタを配置することを望んでいる場合に有用であり、屋根の所望の部分にのみ作業エリアを作成すればよい。
ユーザーはまた、モジュールの種類又はソーラーコレクタレイアウトの方位のような様々な設計設定を設定可能であってもよく、さらに、表示の異なるエリアに、異なる選択を行うことが可能であってもよい。表5には、設計設定のサンプルのリストが示されている。例えば、ユーザーは、設計設定の特定のセットが適用される境界を、例えば、1以上のアパーチャを規定することにより、規定できるようにしてもよい。アパーチャ(aperture)は、ユーザーが生成した幾何的オブジェクトによって表される境界又は外枠である。システムは、例えば、"PVモジュール=SD305"及び/又は"傾き=45度"といった設計設定を含む設計設定のセットと、アパーチャとを関連付けてもよい。レイアウトエンジンは、割り当てられたアパーチャの設計設定、関連する構造特性、レイアウト規則、及びその他の適用可能な特性及び設計規則に従った所定のアパーチャの境界内に、例えば、PVモジュールであるソーラーコレクタを配置するように設定されていてもよい。幾つかのケースでは、ユーザーは、1以上のアパーチャを規定してもよく、レイアウトエンジンは、設置現場の様々な領域において、レイアウトの設計設定の異なるセットを使用してもよい。設計者が、1種類のモジュール、例えば、SD305sを、屋根のあるエリアにおいて、南北の方向に向けて配置することを望んでおり、また、別のモジュール、例えば、SP225sを、屋根の別のエリアにおいて、東西に向けて配置することを望んでいる場合には、別々のアパーチャを使用することが有用である。別の例として、作業エリアの異なる領域におけるモジュールの行間を、異なる間隔に設定する目的で、複数のアパーチャを不均一にレイアウトしてもよい。また、ある実施形態では、作業領域内(例えば、作業領域内のみ)のソーラーコレクタの設置が許可された領域内にソーラーコレクタのレイアウトが生成されてもよく、また、ソーラーコレクタの配置に関するアパーチャの設計設定、オブジェクト及び構造の特性、及びレイアウト規則又はこれに関連付けられた制限に従ったレイアウトアパーチャ内に、ソーラーコレクタのレイアウトが生成されてもよい。
ある例では、ユーザーによって規定されたアパーチャ同士が重なってしまう、又は、相関してしまう場合が発生する。このような場合は、アパーチャの競合を解消する規則が利用されてもよい。例えば、競合解消ルールでは、アパーチャ2よりも、アパーチャ1を優先させるよう規定してもよい。レイアウトエンジンは、アパーチャ2に従って設置されるモジュールよりも、アパーチャ1に従って設置されるモジュールを優先させる。これは、設計者が規定したアパーチャの境界が重なっている場合、又は、設計者が、例えば、PVモジュールであるソーラーコレクタを、凹形状の屋根の両側(すなわち、逆V字型又はV字型の屋根の対向する壁)に配置したいと望んでいる場合には、有用である。コレクタ及びその搭載構造は、高さがあるため、2つの屋根部分の交差点(すなわち、V字の底部)に、モジュール配置する際には、競合が発生すると考えられる。屋根部分の1つが、他方よりも太陽光を受ける場合には、設計者は、アパーチャを、太陽光が照射される部分及び陰になる部分に設定したいと考える。ユーザーは、競合が発生した場合には、2つのアパーチャに対して優先順位を付けることが可能であってもよく、レイアウトエンジンは、陰になるアパーチャの設計設定よりも、太陽光があたるアパーチャ分の設計設定を優先させて、それに従ってモジュールを配置する。このようにすることにより、この設置におけるモジュール平均の電力生成を、全体として増加させることが可能になる。例えば、ユーザーがアパーチャを規定するシーケンスに従って、初期設定の優先順位をアパーチャに割り当ててもよく、又は明示的に優先順位を設定してもよい。
レイアウトを含む設計の結果は、表示され、保存され、印刷され、送信され、又は利用されてもよい。部品表、レンダリング、財務分析、契約、契約条件、エネルギー予測、コスト分析、部品リスト、シミュレーション等の、レイアウトに関する追加情報が、符号化された情報及び生成されたレイアウトに基づいて生成されてもよい。
以下の動作を実行するソフトウェア制御は、CADソフトウェアの一部として含まれていてもよい。これに替えて又はこれに追加して、専用のエンジン、ライブラリ又はプラグインを、スタートアップで又はオンディマンドで、CADソフトウェアにロードしてもよい。これに替えて、専用の又は新しいソフトウェアプログラムを、本発明の実施形態の実装専用に書いてもよい。CADソフトウェア環境においてオブジェクトの生成、選択及び操作に対する多くのメカニズムが、当技術分野では知られており、このようなメカニズムとしては、例えば、クリック選択、ドラッグ選択、シート選択、アイコン上でのクリック及び右クリック、ツールバー、ポップアップ、オブジェクト等が含まれる。Joe Sutphin著、「AutoCAD 2006 VBA:A Programmer's Reference」、101プロダクション(2005)、ISBN9781590595794では、このような方法を数多く開示しており、その内容は、参照により、本明細書に組み込まれる。
[2.システム動作及びユーザーインターフェース]
図1は、ソーラーコレクタレイアウトが設計される設置現場を、概略的に示した図である。簡略化のため、本明細書で説明される実施形態は、ソーラーコレクタの例として、太陽電池(PV)モジュールを使用している。PVモジュールは、建物100の屋根101の上に配置される。屋根101は、換気扇102、配線管103、通路、配管105、大型冷暖房空調設備(HVAC)104、天窓、エレベータ機械、階段等の一連の物理的構造物を有すると考えられる。これらを、幾何学的に、屋根101の上に投影させる(上部から下部を見る鳥瞰図として)と、構造物は、屋根に対して、立体的/二次元的(例えば、換気扇102)に、又は線形的/一次元的(例えば、配線管103)に表されてもよい。所定の構造は、例えば、換気扇は矩形の伏図といったように、屋根の上に規則的な伏図として表されてもよく、これに替えて、構造を不規則な伏図で表してもよい。屋根の構造としては、無形のもの、例えば、風の強い又は上昇気流が存在するエリア106を含んでもよい。屋根101及び屋根に設けられている構造のそれぞれは、ソーラーコレクタ設置設計に関連する特徴のセットを有してもよい。例えば、PVモジュールは、通常、換気扇の上、又は、換気扇102から所定のセットバック内には配置されず、セットバックは、規則、顧客の規定事項又は設計選択肢によって規定されていてもよい。同様に、PVモジュールは、通常、風速が大きいエリア106内、又は、屋根101の角又は縁から特定の距離の範囲内には配置されない。
屋根の構造物はまた、屋根101上に配置されるPVモジュールの相対的な性能を決定してもよい。例えば、屋根101が、多くの場合、南側(105で示されている)からの太陽光に最も晒されると仮定すると、(大型冷暖房空調設備(HVAC)104によって、少なくとも部分的に太陽光が邪魔される)位置Bに配置されるPVモジュールよりも、位置Aに配置されるPVモジュールの方が、平均してより多くの電力を生成すると考えられる。
図2は、コンピュータ支援設計(CAD)システム200のユーザーインターフェースの一例で表示された、図1の設置現場を示した図である。CADシステム200は、設置現場の2D又は3Dの視覚的表示を含んでもよい。典型的な表示では、設置現場の構造物についての3次元情報を含む。簡便のため、実施形態は、2次元の平面図204を参照して説明される。視覚的表示は、線、線分、ポリライン、円弧、曲線、縁、正方形、矩形、多角形等の幾何的実体により構成されてもよい。これらの幾何的実体は、境界で囲まれたエリアを規定するよう閉じていてもよいし、開いていてもよいし、自交していてもよいし、平面的であっても非平面的であってもよいし、孔、複雑な表面及び幾何学的トポグラフィーを含んでもよい。これらの幾何的オブジェクトは、物理的な設置現場の、物理的構造又は非物理的構造に対応していてもよい。例えば、表示204には2つの多角形が示しされており、それぞれ、図1の換気扇構造102に対応する参照番号202で示された有界エリアを規定している。線分及び曲線203のセットは、図1の配線管103の構造に対応している。視覚的表示は、最初に、AutoCAD.DWGといった特定のファイル形式を使用して、CADソフトウェアに読み込まれてもよい。これに替えて、視覚的表示を、標準的なCAD描画ツールを使用して、CADソフトウェアによって生成してもよい。CADソフトウェアにおける視覚的表示204は、設置現場の一部のみを表示してもよいし、設置現場を超えた領域まで表示してもよい。
この時点では、CADソフトウェアにおける設置現場の表示には、非常に少ない意味情報しか添付されていなくてもよい。例えば、純粋な形状以外、有界エリア202を形成している4つの線分は、意味情報と関連付けられていなくてもよい、又は、対応する換気扇構造102に関する意味のみを有していてもよい。PVモジュール設計に関する換気扇構造の特徴、例えば、典型的なセットバック、又は一日又は一年のうちの様々な時間に形成される影(例えば、形成されると予測される影)といった特性は、この表示に組み込まれていなくてもよい。同様に、屋根の外形に対応する線201は、CADソフトウェアにおいて、設置現場の屋根101と、意味的に関連付けられていなくてもよい。むしろ、CADソフトウェアの観点からすると、視覚的表示は、単純に、大きさの情報のみを有する幾何的オブジェクトの集合であり、互いに、外部の設置現場、又はソーラーコレクタ設置設計と関連する意味情報が取り除かれたものであると考えられる。これに替えて、視覚的表示は、例えば、GPSデータのような意味情報が、オブジェクトに付加されていてもよい。このデータは、プロセスにおける後の段階で使用されてもよい。
図3は、視覚的表示及び視覚的表示内の幾何的オブジェクトに、意味情報が付与されるプロセスを示した図である。実施形態の分類要素は、"データ処理能力のない"幾何的オブジェクト、例えば、大きさの情報しか有していないオブジェクトを、自動的に又はユーザーによって、構造の特定の種類のインスタンスとして分類することにより、この分類を実行する。構造の種類のインスタンスとしての分類の一部として、オブジェクトは、追加の構造特性のセットと関連付けられてもよく、このセットには、ソーラーコレクタ設置設計に関連する高さ、セットバック等の構造特性が含まれていてもよい。システムは、分類及び特性を使用して、オブジェクトを、分類されたオブジェクトとその他のオブジェクトとの間のインタラクションの可能性、及び生成されたソーラーコレクタ設計に対する影響に対応するレイアウト規則と関連付けてもよい。これらの構造的特性は、レイアウトエンジンがレイアウト規則をオブジェクトに適用するといったように、ソフトウェアによって認識され、利用され及び操作されてもよい。
例えば、ポリライン201は、例えば、"屋根"のような、構造の1種類と関連付けられてもよい。この分類は、屋根の上へのPVモジュールの設置に関するレイアウト規則に関係していてもよい。レイアウトエンジンによってこのような規則が呼び出されると、特定の屋根の構造的特性(例えば、地面からの垂直方向の高さ及び屋根のピッチ)に作用してもよい。オブジェクトに関連付けられた特性は、その他のオブジェクト特性との対応又は相関関係によって決定されてもよい。例えば、屋根に対する換気扇の高さ(これは、換気扇による影の屋根に対する影響を計算する時に有用な情報である)は、換気扇の絶対的な最大高度、及び換気扇が位置する点における屋根の絶対的な高さ(これは、屋根の特性である高さ及びピッチから自明的に決定することができる)を示す構造特性から、決定することができる。このようにして、オブジェクト分類及び構造の特性を含む符号化された情報は、設置現場の物理的構造の特徴の完全な又は部分的な仕様を形成して(又は関連付けられて)いてもよく、仕様は、PVモジュールのレイアウト設計と関係している。具体的には、ソーラーコレクタレイアウト設計と関連する物理的構造の特徴は、その物理的構造内又は周辺にソーラーコレクタを自動的に配置するための、情報のセットの少なくとも一部を含む又は構成する。予め規定される構造分類及びクラスは、物理的特徴及び非物理的特徴を含んでもよく、例えば、敷地境界、不動産区画境界、建築規制指定、電線の敷設権、洪水が起きる土地、環境を配慮したエリア、又は特定の地震帯のような特徴を含んでもよい。
特に、幾何的オブジェクトの中には、PVモジュール設置の許可を提供する構造種類のインスタンスとして分類されるものが存在してもよく、例えば、屋根として分類される幾何的オブジェクトは、屋根の表面にPVモジュールを配置することを許可するレイアウト規則と関連付けられていてもよい。このように、"屋根"としてオブジェクトを分類することは、間接的に、そのオブジェクトを作業エリアとして扱うことにつながる場合がある。同様に、オブジェクトの中には、PVモジュールの配置を通常は許可しない又は禁止する構造として分類されるもの存在し、例えば、池又は空調ユニットとして分類された幾何的オブジェクトは、障害物又は障害物の予め規定された境界内、例えば、距離内に、PVモジュールを配置することを通常は許可しないレイアウト規則と関連付けられていてもよい。PVモジュールの配置に対するその他のレイアウト規則を規定してもよく、建築規制及び建築法、風条件、温度条件、及びモジュール配置に対する電力及び熱生成制限の適用を実体化する制限を、所与の構造に対して及びその付近に対して規定してもよい。
構造の所定の種類と関連付けられる構造特性の形式及び内容は、対応するオブジェクトの形成の前に形成されてもよいし、前もって存在するものであってもよい。物理的構造の分類、及びそれに対応する符号化された情報は、予め規定しておいてもよい。例えば、屋根又はその他の表面に対応する特性及び初期値のセット、及び、それらに適用される設計規則は、データベース及び/又は分類規定の一部に格納されていてもよい。(表3〜4参照。)特定のオブジェクトが屋根として分類されると、分類規定がインスタンス化されて、そのオブジェクトと関連付けられてもよい。無論、ソフトウェアは、更なる構造の種類を、設計者が規定することができ、分類に使用することができるようなメカニズムを提供してもよい。所定の種類のオブジェクトに対して、特性及びレイアウト制限の初期値を含む初期値又は予め存在する符号化情報が、設計者又は管理者によって修正されてもよい。符号化された情報の修正は、レイアウト生成の前に行ってもよいし、及び/又は、レイアウト生成の後に行ってもよい。レイアウトが生成された後に行われる構造特性のような特定の符号化された情報の修正は、データの新たなセットに基づくレイアウトの自動再生成をトリガしてもよい。
オブジェクトが分類され、修正される、又は、特性と関連付けられるメカニズム又はユーザーインターフェースの制御は、様々であってよい。例えば、図3に示すように、ユーザーは、屋根101に対応するポリライン201を選択してもよい。そして、ユーザーは、"屋根"又は"分類・・・"と記載されたツールバー又はアイコンをクリックする、又は同様のコマンドをメニューから選択してもよい。ユーザーは、また、ポリライン201上でポインタツールを使用して右クリックし、ポリライン201を選択すると同時に、屋根と分類することを可能とするコンテキストメニュー310を開いてもよい。選択及び分類の間に、この選択又は分類を示すように、オブジェクトの表示が変更されてもよい。例えば、色を変更してもよく、線の太さ又はスタイルを、変更してもよい(本例では、ポリライン201は点線で示されている)。ユーザーインターフェースにおけるオブジェクトに対するアクションの実行に関する制御には多くの種類が存在することは、当分野では周知である。複数のオブジェクトを、同じ種類の構造、例えば、"屋根"のインスタンスとして分類してもよく、この場合には、システムは、複数の屋根を含む設置現場に対するレイアウトを生成する。特徴の異なる種類又はサブ種類を、様々に表現してもよく、例えば、ユーザーインターフェースにおいて、別々の描画層に配置してもよいし、及び/又は、異なる色又は線の太さで表してもよい。また、オブジェクトの分類を解除する制御を提供してもよい。
無効な又は不完全な設置現場の幾何的形状を自動的に修正するメカニズムを採用してもよい。例えば、一実施形態において、設計規則が、"屋根"は、閉じた多角形で表示されるべきであると規定しているとする。設置現場表示における屋根に対応する幾何的情報が、4つの線分で構成されており、共通の終点が近接してはいるが、一致していない(すなわち、閉じた形状をしていない)と仮定する。この幾何的表示では、線分の終点を一致させない限り、処理エラーとなる又は不正確な結果を生成すると考えられる。一実施形態において、分類している間に、前処理幾何的要素に対して、メカニズムが提供され、例えば、終点が一致していない線分を、終点が共有される線分へと互いに近づけるように、特定の角度内に収めるような変換が行われる。非意味的幾何的データの修正のための幾何的アルゴリズムが存在する。
ソフトウェアはまた、ユーザーが、所与のオブジェクトと関連付けられた編集可能な特性のような、符号化された情報の一部又は全てを見る及び/又は修正することが可能となる制御を提供してもよい。例えば、ユーザーインターフェースは、そのオブジェクトと関連付けられた構造特性の一部又は全ての表現を表示するための特性ロールアップ、ツールバー又はパレット311を含んでもよい。屋根に対する構造特性の一部、例えば、垂直方向高さ312は、ユーザーが調整可能であってもよい。屋根の、例えば、平方メートル単位の生成された面積、といった、PVモジュールの設置に使用されるその他の構造特性を、ソフトウェアによって計算してもよく、例えば、レイアウト制限、構造特性等とのインタラクションによって決定される。所与のオブジェクトに適用可能なレイアウト規則の表示のようなその他の情報、例えば、特定のオブジェクトが、PVモジュールの設置に好適であるといった表示は、ユーザーに表示又は可視化されなくてもよい。ユーザーインターフェースにおいて、オブジェクトの特性を修正するための制御には様々な種類が存在する。
ある実施形態では、構造分類の階層構造を含んでもよい。例えば、構造は、設置可能表面、立体障害物、線形障害物3つのカテゴリに分けられてもよい。各カテゴリは、構造の複数の種類を含んでもよい。例えば、設置可能表面としては、屋根、野原、壁等を含んでもよい。立体障害物としては、換気扇、柱、冷暖房空調設備(HVAC)、くぼみ、木、屋根の昇降口、アンテナ、衛星アンテナ、階段、排水管、塔屋、屋根の窓、天窓、梁、観察点、通気孔、バルブ等を含めてもよい。線形状の障害物としては、通路、機器、延長ジョイント、壁、配線管、パイプ等が含まれる。構造物の種類それぞれは、サブ種類を含んでもよく、例えば、アンテナ障害物は、サブ種類として、アウトラインアンテナ、ポイントアンテナ等を含んでもよく、配線管は、サブ種類として、電気配線、水配管、支持配線、垂直配線、導水管等を含んでもよい。障害物は、その固有の幾何的形状(例えば、階段)に応じて、立体又は線形のいずれかに分類されてもよい。
図4は、第2障害物が分類されて、意味的情報と関連付けられるプロセスを示した図である。ここでは、屋根の上に設けられている換気扇に対応する複数の線のセット又はポリライン202は、立体障害物として分類されている。すなわち、コンテキストメニュー310及び特性パレット311を使用して、"HVACユニット"のサブ種類"換気扇"と分類される。ここで、点線は、ユーザーが、この特定のオブジェクトを選択したことを表す視覚的手掛かりとして使用されている。特性パレット311は、同様な構造特性のサンプルを示しており、また、換気扇についての現在の値、例えば、高さ、セットバック、サブ種類等も示している。パレット311は、図4において、オブジェクト202が構造カテゴリ(又は分類)の立体障害物315、種類HVAC317、及びサブ種類換気扇319に分類されたことを示している。このようにして、物理的設置現場に対応する複数のオブジェクトが分類されてもよい。ある配置では、上述したようなユーザーが手動でオブジェクトを分類することを必要とするのではなく、システムが、例えば、設置現場の表示の帰納的分析、又は利用可能なメタデータに基づいて、最初に自動的にオブジェクトを分類するのを試みてもよく、例えば、予め生成されたCAD図面の層において"天窓"と名付けられたオブジェクトを、自動的に"天窓"として分類してもよい。システムはその後で、ユーザーによる修正及び認証を許可又は要求してもよい。システムは、GPSデータのような幾何的オブジェクトに関する情報を使用して、自動的にオブジェクトを分類してもよい。
全ての特性を、表示における特定の構造又は幾何的オブジェクトと関連付ける必要はない。例えば、ソフトウェアは、設置現場ロケーション(郵便番号)、設置現場の方位(北向きの矢印)、縮尺、測定の単位、国、顧客情報(顧客の名前、住所等)といった、プロジェクト全体の特性情報を利用及び設定可能としてもよい。プロジェクト特性情報は、連絡先、法的資格、財務状況、電気利用情報、電気料金、及びエネルギー消費量の情報を含む顧客特性情報を含み、予め設定されていてもよい。その他のプロジェクトの特性情報として、土壌の種類、気候条件、設計温度、設計地震負荷、動作特徴、負荷限界、電気配線条件等が含まれてもよい。この情報は、設計者によって手動で入力されてもよいし、顧客のアカウント情報を保持するのに使用される顧客関係管理(CRM)システムのような外部のデータソースとつながるリンクを通じて、この情報がアクセスされてもよい。表6には、プロジェクトの特性情報のリストの例が示されている。例えば、全体のレイアウト規則といったプロジェクト設計の規則は、特定の構造物とは独立して作用してもよく、例えば、公共電力設備にPVシステムを接続する際の規制である電力接続規則等が挙げられる。予め規定されるプロジェクト設計規則は、電気設備基準、敷地セットバック必要条件、安全要求事項、配線必要条件、設計規則又は成功事例、ヒューズ設定条件等の使用を規定してもよい。公共電気グリッド、私有電気グリッド又はその他の規格に接続されるレイアウトを生成する際に、このような規制的規則を採用してもよい。
モジュールの種類は、例えば、モジュール特性、モジュール間の間隔、電圧、配線条件、重さ等の特定のモジュール固有の情報と関連付けられていることから、設計で使用されるモジュールの種類は、レイアウトエンジンがどのように動作するかについても影響を与える。モジュール固有の情報の一部は、モジュールの種類、搭載システム、インバータタの種類等の特定の種類と関連付けられていてもよい。様々なモジュール設計規則を、モジュール毎に、モジュールの列毎に、及び/又はモジュール‐サブアレイベースで、適用してもよい。例えば、特定のモジュールは、最小のモジュール間距離及び動作温度、又は特定の配線構造を要求してもよく、例えば、1列(ストリング)あたりのモジュールの数が、温度の関数であってもよい。表7には、モジュール特性のリストの例が示されている。
図5Aに示すように、使用されるモジュール502の種類及び/又は搭載システムの種類、モジュールの行及び列を配置する方位503、タイル状に配置する開始点504(又は原点)、インバータの種類(選択肢が損愛する場合)等を含む設計設定情報を、規定してもよい。また、動作全体特性、設計設定、及び/又はモジュール特性の1以上を、ユーザーが修正可能であってもよい。例えば、真北の方角に対するモジュールの方位(角度)は、503に示すように、適当な制御部に、数字で入力してもよい。これに替えて、方位を、屋根の外縁のような既存の線を選択し、モジュールの方位が、選択された線と同じであることを示すことによって設定してもよい。レイアウトの開始点を、例えば、適当な制御部に、座標を入力504することによって設定してもよく、及び/又は、506に示すように、マウス又はタッチスクリーンのようなポインティングデバイスを使用して、可視的表示における1点を選択することにより設定してもよい。コンテキストメニュー520のような制御部が、ソーラーコレクタ設置レイアウトエンジンを起動するべく、提供されてもよい。
図5Bに示すように、レイアウトエンジンは、関係する符号化された情報に基づいて及び従って、ソーラーコレクタの設計を生成するように起動されてもよく、符号化された情報としては、構造分類、構造特性、作業エリア、設計設定、全体特性、モジュール特性、レイアウト規則、設計規則等が含まれる。PVモジュールの場合、レイアウトには、視覚表示に示される複数のPVモジュールの物理的配置が含まれてもよく、付随する配線システム、搭載システム、ハードウェア、設置の適切なオペレーションのための電子部品等の配置も含まれてもよい。ある場合には、PVモジュールは、全オブジェクトに対する規則及び制限の全て(実質的に全て)に従ってPVモジュールが配置されてもよい。このようなPVモジュールレイアウトを生成するのに、数多くの方法及びシステムを使用してもよい。特に、システムのレイアウトエンジン構成要素は、タイリングアルゴリズムを使用して、レイアウトを生成してもよい。
図6Aのフローチャートに示されるように、ある1つのアルゴリズムの下、あらゆる幾何的オブジェクトを含む設置現場の視覚表示は、まず、設置現場における物理的構造についての(特に、大きさについての)データを収集することによって、最初に規定され(605)てもよい。これは、GPSベースの測量機器を使用して設置現場で行ってもよく、又はこれに替えて、CADソフトウェアを使用して、代表的な幾何的オブジェクトを生成してもよい。この段階は、段階610と交互に行ってもよい。段階610において、視覚表示におけるオブジェクトは、構造で分類されて、構造特性に適切な値が設定される。これは、ユーザーが手動で行ってもよいし、自動化された構造認識を使用してシステムが自動で行ってもよい。ユーザーは、1以上のオブジェクトを、PVモジュールの設置が許される又は望まれる領域、例えば、野原や屋根のような領域を提供する構造として分類する。段階612において、ユーザーは、1以上の作業エリア、例えば、PVモジュールレイアウトが望まれると推測される領域を、所有者の指示に基づいて、規定してもよい。作業エリアを明示的に規定してもよく、それについては以下に説明する。615において、設計設定、プロジェクト特性、及びその他の符号化された情報を、設定又は修正してもよい。
620において、まず、複数のPVモジュールを、1以上の作業エリアにわたって、障害物又はその他の干渉する構造(例えば換気扇)を考慮することなく、タイル状に配置してもよい。作業エリアとしては、配置が許可されると分かっているオブジェクト、例えば、屋根表面が挙げられる。これは、明示的な作業エリアにわたって、例えば、PVモジュールを支持する構造として分類されているオブジェクトにわたって、複数のPVモジュールを配置することにより、操作可能としてもよい。タイル状に配置するタイリングは、関連するモジュール設計規則及び特性に従う規定された空間に、グリッド又はアレイを形成することにより行ってもよい。タイリングは、行間隔、隣接する行間のオフセット量、曲線の道又は土地の境界線のような不規則な外縁等を含むように、パラメータ的に変化してもよい。また、タイリングは、個々のモジュール(個別に様々に指定された長さ又は幅を有する)に対応するように行われてもよく、また、任意の配置(例えば、モジュールが、同一の搭載構造又は追跡メカニズムと接続されている場合)における複数モジュールの集合体を表していてもよい。加えて、タイリングの周期的な中断を設けて、側道、設置義務である消防車が侵入可能な道路、又はその他の種類の設計規則を規定するようにしてもよい。ある実施形態では、レイアウトされるモジュールオブジェクトに対応する幾何的オブジェクトを、図6Bに示すように、実際に生成して、可視的表示内に配置してもよい。これに替えて又はこれに加えて、レイアウトは、モジュールが表現されているデータ構造において、論理的であってもよい。いずれの場合にせよ、幾何的オブジェクトは、関係するモジュール種類のインスタンスとして分類され、特定の構造特性及びレイアウト制限と関連付けられる。
図6Aに戻り、625では、システムが、タイル状に配置された複数モジュールについて、2回目のパスを実行し、特性に適用される1以上の設計規則に反して配置されているモジュールに、不適格であるとの印を付してもよい。例えば、図6Bに示すように、屋根201の表面全体が、モジュールでタイル状に覆われたとする。2回目のパスでは、モジュールそれぞれを考慮して、規則に違反して配置されている(すなわち、表示及びオブジェクトの規則に従っていない)モジュールに印を付ける。これは、例えば、配置されたモジュールそれぞれを検証するようにループ化し、モジュールそれぞれに対して、全ての設計規則を検証するようループ化し、規則との不一致を探すべく関係するものを適用することによって、動作させることができる。したがって、換気扇202の物理的伏図内、又は、換気扇202からのセットバックの伏図内に位置するモジュールには、不適格であると印を付けてもよい。同様に、風速の大きいゾーン内の特定の距離の範囲内に位置するモジュール、例えば、図1の106にも、不適格であると印を付けてもよい。不適格であるとされたモジュールは、グレー表示をして、自動的に取り除き、別の階層に移動させてもよいし、データ構造における"適格"なモジュールに対する変更を行ってもよい。不適格であるとの印付けは、ソフトウェアデータ構造における特性又はフィールド内に"不適格?"と明示的に行ってもよいし、プロセス実行において非明示的に行ってもよい。ユーザーは、不適格とされたモジュールに対してアクセス可能であってもよいし、アクセス不可能としてもよい。不適格とするにも様々なレベルが存在してもよく、あるモデルでは、設計者が取り消しを無効にすることができないように、厳密に不適格としてもよいし、別のモデルでは、設計者が配置を元の場所に戻すことを許容する程度に、緩く不適格又は好ましくないとしてもよい。様々なレベルの適法性を、別々の色、層等を使用して維持してもよい。このようなレイアウトプロセスで得られる結果は、設置現場に対する設計規則及び特性に一致したPVモジュールレイアウトとなる。図5Bに示すように、網掛け線で示されている530に配置されているモジュールは、規則に従って配置されている。参照番号533で示されているエリアにはモジュールが存在していないが、これは、これに関連付けられたエリアが、障害物の物理的境界の内側に存在しているからである。システムは、1以上の不適格となるモジュールを選択し、それらを通常の配置に戻す能力を有してもよい。ある場合には、構造特性に対して適用される規則の少なくとも1つに違反して実行されてもよい。灰色で網かけされた535に配置されたモジュールは、選択的であるセットバック必要条件を満たしていないことから、緩く不適格であると言える。以下に説明するように、設計者は、このように緩く不適格であるとされたモジュールをオンとする、又は、元に戻してもよい。
例えば、モジュールが、換気扇に近接し過ぎて配置されるといったように、あるモジュール配置は、その他のモジュールとの関係に関わらず不適格となる。しかしながら、不適格であるとする設定は、その他のモジュールに対してのみ明確であってもよく、再帰的に特定されるものであってもよい。例えば、グリッド接続されるPVの設置は、予め決められた数のモジュールを、電気的に直列に配線接続する必要がある。例えば、SunPower305モジュールが、北カリフォルニアで使用され、600VのDCインバータと接続される場合、各列(ストリング)に、12個のモジュールを接続しなければならない。
このように、厳密に不適格であるモジュールを取り除いた後、システムは、残ったモジュールに対して更なる"パス"を実行して、例えば、モジュール間接続規則のような設計規則を満たさない更なるモジュールが存在するかのチェックを、再帰的に又は回帰的に実行してもよい。このようなモジュールは、図5Bでは、グレー表示されている。
図6Aに戻り、630では、レイアウトが自動的に生成された後で、ユーザーには、少なくとも1つのオブジェクト又はプロジェクト全般を修正するオプションが示される。ユーザーが配置を修正することを可能とするユーザーインターフェースの制御部分は、様々であってもよい。不適格なモジュールは、表示の別の階層に配置されてもよく、及び/又は、図5Bに示すように、異なる色又はスタイルで示されてもよい。ユーザーは、不適格であるとされたモジュールの層を適格であると変更してもよいし、その反対の変更を行ってもよい。ユーザーは、右クリックをする又はモジュールを選択して、そのモジュールのステータスを変更してもよい。また、適格に配置されたモジュールの消去を可能としてもよく、完全な消去、又は、モジュールを"消去済み"階層に移動させることを含んでもよい。消去されたモジュールは、必要に応じて、復元されてもよい。アクションの取り消し、又は、例えば、モジュールのインスタンス化し直しのような、取り消したアクションのやり直しを可能とする制御を提供してもよい。取り消し及びやり直しについては、以下にさらに説明する。
制御は、規則又は分類を変更する能力、及び自動レイアウトをやり直す能力を含むように、提供されていてもよい。システムの修正コンポーネントは、一度は配置されたが後に取り除かれた(規則を満たさなかったため)タイルの置き換えを可能とするユーザーインターフェース、又はその他のメカニズムを提供してもよい。また、配置されたモジュールを、レイアウトから取り除くメカニズムを提供してもよい。
635に示すように、レイアウトをユーザーが変更を行うと、変更されたレイアウトは、関係する設計規則及び特性に対して矛盾した状態となる、又は、不一致が存在する場合がある。例えば、ユーザによって特定のポイントにモジュールを手動で追加すると、セットバックに関する設計規則を破ってしまうことが考えられる。このように、追加、置き換え又は削除といった、レイアウトの修正は、レイアウトの再計算、レイアウトに対するルーティング/配線構造の再計算等を必要とする場合がある。レイアウトの修正、又はレイアウト規則の不一致は、以下に詳細に説明する、例外事項のリストに明記されてもよい。
640において、生成されたレイアウトに対して更なるアクションをユーザーが実行可能なように、ユーザーインターフェースの制御を提供してもよい。例えば、レイアウトを保存、印刷及び/又は送信してもよい。また、レイアウト情報を、オブジェクトの規則及び分類と共に、更なる構成要素を生成するのに使用してもよい。例えば、ユーザーが選択したモデルのソーラーコレクタの効率、及び、屋根の面積が受ける光の量に関するエネルギー予測シミュレーション規則、緯度及び高さといった可視化表示における構造物に関するエンコードされた情報を使用して、電力出力のような特定のモジュールレイアウト性能を、シミュレーションしてもよい。シミュレーション結果は、表示されてもよいし、設計者が利用可能なようにしてもよい。別の例では、モジュール及び関連する部品(配線及び電気インバータ等)の数及びコストを集計して、部品表、コスト計算、請求書等を作成するのに使用してもよい。ある実施形態では、典型的なレイアウト設計プロセスに関連して記載される、複数の種類の書類又は提出物が、ダウンストリームの出力として、自動的に生成されてもよい。
[3.ユーザー規定作業エリア]
上記で説明したシステムは、構造分類によって規定される明示的な作業エリアを使用して、屋根のような許可された表面又はオブジェクト上に、ソーラーコレクタ、特にPVモジュールを配置するレイアウトを適用する。更に又はこれに替えて、システムは、ユーザーに、モジュールの配置が許可されている領域として作業エリアを規定する及び利用することに対する明示的な管理権を与えることにより、よりきめの細かい制御を可能とするユーザーインターフェースを提供してもよい。
具体的には、図7Aに示されるように、システムは、例えば、明示的な作業エリアのような、モジュールレイアウトを制限する又は拡張するための、1以上のユーザー生成境界を、ユーザーが規定できるようにしてもよい。作業エリアは、物理的な設置現場のロケーションに対応するモジュール設置可能な領域の境界、範囲又はセットを表していてもよい。作業エリアは、物理的設置現場に対応するオブジェクトのセット又は1つのオブジェクトと、同一の広がりを持っていてもよい。これに替えて、701のように、レイアウトが許可されるオブジェクトの部分のみをカバーするように、作業エリアが設定されてもよい。作業エリアは、複数のオブジェクトにまたがって設定されてもよく、複数の作業エリアが規定されてもよい。ポインティングデバイス(例えば、マウス、タッチパッド、ジョイスティック又はタッチスクリーン)、又はキーボードショートカットを使用して、"作業エリア"アイコンを選択し、四角形、ポリライン又はその他のオブジェクトを描くことによって、明示的な作業エリア701を形成してもよい。ユーザーは、四角形をドラッグする及び"作業エリア"ツールバーアイコンをクリックすることを含む、又は、コンテキストメニューを使用することを含む、幾何的オブジェクトを規定するあらゆる方法によって、作業エリアを規定してもよい。例示した実施形態では、オブジェクトは、ユーザーによって、明示的な作業エリアとして印を付され(又は、関連付けされ)てもよい。必ずしもそうする必要はないが、ユーザーが生成した作業エリアは、例えば、建物の表面、野原といったオブジェクト、又は視覚的表示全体と同一の広がりを有していてもよい。ユーザーが生成した作業エリアは、明示的な作業エリアに加えて又は替えて、使用されてもよい。
ある場合では、レイアウトエンジンは、屋根又は野原といった非明示的な作業エリアと、明示的な作業エリアとの交差点にのみ、PVモジュールを配置するように設定されていてもよい。別のケースでは、明示的作業エリアは、その他の設置可能オブジェクト又は非明示的な作業エリアを考慮することなく(又は、この考慮に加えて)、設置可能エリアを規定してもよい。オブジェクトに対する初期設置規則を無効にするのに、明示的作業エリアを使用してもよい。これにより、設計者は、モジュールを屋根の一部にのみ配置するか否かといった、モジュールの配置場所に対する制御権を持つことができる。例えば、図7Aに示すように、設計者が、屋根201の西側の部分にのみオブジェクトを配置したいと考えている場合には、設計者は、作業エリア701を形成することができる。ある場合には、生成されるレイアウトにおいて、モジュールが、屋根201と作業エリア701との交差部分にのみ配置される。すなわち、モジュールは、ロケーションA(配線管203に対する規則のようなその他の規則に一致する)に配置されるが、ロケーションBには配置されない。このようなレイアウトの一例が、図7Bに示されている。
レイアウトエンジンによって明示的作業エリアを実装する1つのアルゴリズムは次のようであってもよい。図6Aの620に示すように、設置可能オブジェクト(屋根又は野原のような)及び明示的作業エリアの両方が含まれるロケーションにのみ、モジュールをタイル状に配置する。そして、方法は、上記のように進められてもよい。これに替えて、625において、モジュールを、許可される全ての面上にタイル状に配置した後、明示的な作業エリアの境界の外側になってしまったモジュールに印を付ける及び/又は取り除いてもよい。
ユーザーは、作業エリアの境界を移動させる又は調整することによって、作業エリアを修正することができる。作業エリアの修正に伴って、前に生成されたレイアウトの自動再計算又は再生成が実行されてもよいし、実行されなくてもよい。
[4.アパーチャ]
作業エリアに加えて、又はこれに替えて、システムは、ユーザーが、例えば、レイアウトアパーチャのような、設計設定の1以上のローカライズされたセットを適用するために、1以上の境界を規定可能としてもよい。複数のアパーチャを使用することにより、設計者は、所望のレイアウトに対して、異種の領域を形成することができ、レイアウトプロセスに対して、制御の別の階層を提供するのに使用することができる。上述のレイアウトエンジンでは、モジュールをレイアウトするのに、設計設定の1つのセット(例えば、モジュール種類、方位、開始点等)を使用していた。これに替えて、ユーザーインターフェースは、ユーザーが、1以上のアパーチャを規定可能とし、アパーチャのそれぞれが、1つの境界を含むようにしてもよい。複数のアパーチャを、設計設定の異なる種類の独立したセットと関連付けてもよい。異なるアパーチャは、異なる範囲を有していてもよく、1つのアパーチャの境界内におけるPVモジュールのレイアウトは、(例外もあるが)典型的には、少なくとも一部、アパーチャと関連付けられたユーザーが規定する設計設定によって決定されてもよい。
図8Aに示すように、ユーザーは、第1アパーチャ801を規定してもよい。アパーチャの境界801は、屋根201のような1つのオブジェクトと、及び/又は、明示的又は非明示的作業エリアと同一の外延を有してもよい。または、図8Aに示すように、アパーチャ境界801は、屋根201のような設置可能オブジェクトの一部分のみをカバーしてもよい。アパーチャ境界801はまた、モジュールが設置されてもよい1以上の作業エリア及び/又はオブジェクトを範囲に含んでもよい。第1アパーチャ801は、702から705に示すように、そのアパーチャに関連付けられた設計設定のセットを有してもよい。アパーチャの設計設定としては、PVモジュールの種類又はモデル、真北の方向に対するモジュールの方位、行間の距離、傾斜角度、搭載方法、ストリング出力電圧、行間オフセット、アパーチャの大きさ及び形状、タイル開始点及びその他の特性を含んでもよい(更なる例については、表5を参照)。ある実施形態では、ユーザーは、設計設定の一部又は全てを変更してもよいし、初期設定のまま続けてもよい。同様に、作業エリア及び/又は屋根201のような設置可能オブジェクトの全体又は一部を含むように、第2アパーチャ802を生成してもよい。第2アパーチャ802は、関連付けられた設計設定の異なるセットを有してもよい。アパーチャは、ユーザーによって形成されてもよいし、自動的に規定されても、予め規定されてもよい。例えば、特定の作業エリア全体、又は、作業現場の表示全体を含むように、一般的な初期アパーチャを、初期値として最初に規定してもよい。これに替えて、ソフトウェアは、ユーザーに、レイアウトエンジンを動作させる前に少なくとも1つのアパーチャを規定するように要求してもよい。例えば、幾何的オブジェクトを選択して、ツールボックスアイコンをクリックする、又は、805に示すようにコンテキストメニューを使用することにより、アパーチャを生成してもよい。アパーチャの規則を調整するのに複数の制御方法が適用されていてもよく、例えば、ユーザーは、アパーチャにおけるモジュールレイアウトの方位を示すために、線形参照オブジェクトを選択することができる。
ある場合には、アパーチャと作業エリアとが交差する又は重なる部分に配置されたモジュールの配置は、アパーチャの設計設定に依存する。例えば、図8Aに示すように、屋根201と同一の広がりを有している作業エリアが(明示的に又は非明示的に)形成されたと仮定する。レイアウトエンジンが起動されると、モジュールは、第1アパーチャ801の設計設定に従って、ロケーションAに配置されてもよいし、第2アパーチャ802と関連付けられた設計設定に従って、ロケーションBに配置されてもよいが、ロケーションCは、アパーチャ内に位置していないことから、ロケーションCにはモジュールは配置されない。ある場合には、ロケーションDのように、アパーチャは重なってもよく、この場合は、ロケーションDには、アパーチャの設計設定の2つ以上のセットが適用されることを意味する。このような場合、システムは、アパーチャ競合解消規則を利用してもよく、これについては、図9を参照して以下に詳細に説明する。また、ロケーションEは、作業エリア内でないことから、ロケーションEには、モジュールは配置されない。図8Bには、上記の説明に従ってレイアウトされた例が示されており、第1アパーチャ801を優先させて、領域Dにおける競合が解消されたレイアウトが示されている。アパーチャの競合解消規則については、以下に詳細に説明する。
アパーチャを使用することにより、例えば、図8A及び図8Bに示すように、ユーザーは、屋根のような、1つの作業領域又はオブジェクトの第1部分に対して設計設定及び特性の1セットを規定することができ、同じ作業エリア又はオブジェクトの第2の部分に対して、設計設定及び特性の第2セットを規定することが可能となることから、有用である。例えば、ソーラーコレクタが、同じ屋根上の2つの部分に配置され、1つの部分は平らであるが、もう1つの部分は傾斜している場合に、設計者は、それぞれに対して2つの異なる垂直方向に対する搭載角度、南向きに対する方位、PVモジュールのモデル、及び/又は、2種類の屋根に適した搭載システムを選択してもよい。同様に、屋根の一方の面が、他方の面と比べて強い風を受ける場合には、ユーザーは、風が強い方の面に対して第1アパーチャを形成し、風に強いモジュール及び搭載システムを含む設計設定を使用してもよく、風が強くない方の屋根の面に対して第2アパーチャを形成して、風に対してさほど耐性を有さないモジュール及び搭載システムを適用してもよい。アパーチャは、ユーザーによって、(ユーザーが規定した作業エリアとして)移動及び調整可能であってもよく、これにより、設計者が、レイアウトの代替案を素早く可視化することができるようになる。
アパーチャによって、モジュール配置に対する設計設定の異なるセットを提供できるようになることから、隣接する又は重なるアパーチャでは、配置における不一致が生じる場合がある。アパーチャの重複の程度が大きい場合も存在する。アパーチャにおける不一致を解決する規則を使用して、モジュール配置における矛盾点を解消してもよい。不一致解決規則の単純な形の一例は、アパーチャを生成順番でランク付けすることであり、最初に形成されたアパーチャ又は最後に形成されたアパーチャが、一番優先されるようにする。または、辞書式順序を利用してもよい。ユーザーには、明示的にアパーチャの優先順位を変更可能な制御が提供される。優先順位変更の方法の一つは、優先順位を規定しているユーザー編集可能な設計設定とアパーチャそれぞれとの関連付けを行うことであり、例えば、"優先順位=2"とする。初期設定のアパーチャが存在する場合には、それに対して、最も低い優先順位を割り当ててもよい。
アパーチャ不一致解決規則に従って、様々な方法で、モジュールレイアウトを生成することができる。例えば、アパーチャに対して上述のような優先順位が付与され、配置における不一致が生じた場合には、最も高い優先順位のアパーチャにおける配置が優先される。
例えば、各アパーチャ境界内に少なくとも一部位置しているオブジェクト及び構造物に、上述のような方法を適用することで、優先順位を考慮することなく、規定された全てのアパーチャに対して、独立した部分的なレイアウトが生成されてもよい。この計算は、並列に実行されてもよい。アパーチャに重複が生じない場合には、2つの部分的なレイアウトを結合させたものを、最終的なレイアウトとして、出力デバイスに、保存、格納又はレンダリングしてもよい。重複が存在する場合には、不一致解決規則に基づいて、配置されたモジュール間の不一致を解消してもよい。不一致が発生しているモジュールのある場合には、低い優先順位のアパーチャからのモジュールを取り除き、低い優先順位のアパーチャに対応する部分的な設置レイアウトを修正又は調整してもよい。図9Aには、レイアウトの一方法が示されている。900でプロセスが開始し、まず初めに901において、設置現場データ(例えば、境界及び構造の物理的大きさのデータ)が入力し、次に、902では、オブジェクトを分類し、作業エリア及びアパーチャを生成する。904では、アパーチャそれぞれ内に、モジュールのレイアウトを生成し、906では、各アパーチャ内に配置されたモジュールを分析して、別のモジュール及び/又は別のアパーチャと、配置に関する不一致が生じていないかを確認する。908では、アパーチャの優先順位規則を使用して不一致を解消し、910において、前述のようにユーザーがモジュール配置を修正可能とする。このプロセスは、912で終了するが、上記の段階に対して、数多くの中間に位置する追加のプロセス、及び同様な段階の繰り返しを行ってもよいことは、明らかである。
これを達成する別の方法は、優先順位の高いものから低いものへと各アパーチャの解析を行い、優先順位の高いアパーチャの一部に既に配置されているモジュールと配置における不一致が生じない限りにおいて、そのアパーチャ内に可能なモジュールの配置を(上記のように)行う。典型的なPVモジュールの配置は、そのアパーチャ内で交差する(又はアパーチャ内に収容される)構造物に適用されるアパーチャの設計設定、構造特性、モジュール特性及びプロジェクト特性に応じて、所定のアパーチャの境界内で実行される。この方法では、連続した設置レイアウトのセットが生成され、連続したレイアウトのそれぞれは、現在の及び優先順位の高いアパーチャ全ての設計設定と一致している。連続した設置レイアウトは、デバイス又は媒体にレンダリング又は格納されてもよい。
図9Bには、分類されたオブジェクト、作業エリア及び競合しているアパーチャに従って、モジュールをレイアウトするプロセスの別の例が示されている。プロセスは930で開始し、初めに、931において、ユーザーは、オブジェクトを分類し、1以上の作業エリア及び/又はアパーチャを生成する(若しくは、初期設定の又は明示的な作業エリア及びアパーチャを使用してもよい)。ある実施形態では、アパーチャは、後に行う不一致解決における優先順位を決定づけてもよい、生成の相対的な順番と関連付けられていてもよい。
932において、モジュールは、上記の相対的優先順位付け規則に従って決定されてもよい1番目の"第1"アパーチャにおける規則に従って、モジュールを配置する。明示的か非明示的かに関わらず、第1アパーチャ及び作業エリアの境界内にのみ、モジュールが配置されてもよい。明示的な作業エリアが規定されている場合には、アパーチャ、配置可能な面、及び明示的作業エリアの交差点にのみ、モジュールが配置されてもよい。明示的な作業エリアが規定されていない又は使用されない場合には、アパーチャと、屋根のような配置可能オブジェクトによって規定される作業エリアとの交差部分に、モジュールが配置されてもよい。933において、例えば、換気扇に対するセットバック必要条件を満たしていないといった、1以上の設計規則に合致しないモジュールには、不適格との印が付与された後、消去される又は有効化されているレイアウトからは取り除かれる。
934において、2番目に高い優先順位が付与されたアパーチャ(が存在する場合には)に対して、段階932及び段階933が繰り返される。しかしながら、通常必要とされる作業エリアの交差点に加えて、第1アパーチャにすでに配置されているモジュールと競合が生じない場合には、第2アパーチャ内にもモジュールを配置してもよい。これは、上記の配置段階(932)と同様に行うことができ、例えば、第1アパーチャと一致しない条件のモジュールは、決して配置しないようにする。これに替えて、第1アパーチャにおけるモジュール又は設計設定を考慮することなく、第2アパーチャにモジュールを配置してもよく、その後で、第1アパーチャに配置されたモジュール(又は、それらに付与されている設計設定)と一致しないモジュールが発見された場合には、(段階933と同様な段階の間に)そのようなモジュールを取り除く。
935において、3番目に高い優先順位が付与されているアパーチャ(存在する場合)に対して、段階932及び段階933を繰り返す。第1アパーチャ又は第2アパーチャに配置されたモジュール及び設計設定と不一致が生じない場合にのみ、第3アパーチャの規則に従って、モジュールが第3アパーチャ内に配置される。必要であれば、936に示すように、残りの全てのアパーチャに対して、このプロセスを繰り返してもよい。937において、又はこれよりも前の段階において、ユーザーは、モジュールの配置を修正可能であってもよく、修正に伴って、上記の段階に基づいて、レイアウトの一部又は全ての再生成が実行されてもよい。上記したように、追加の段階を間に挟んで実行してもよいし、938においてプロセスが終了する前に、上記の段階を要求に応じて繰り返してもよい。最終的なレイアウトを、コンピュータデバイスに表示してもよいし、レンダリング又は格納してもよい。
[5.プロジェクト階層化及び格納]
プロジェクトの設置現場、構造及びその分類、及びソーラーコレクタのレイアウトを含む、太陽光設備プロジェクト設計は、プロジェクト状態情報によって特徴づけられてもよい。プロジェクト状態情報は、一般的に、特定のソーラーコレクタ設計設定を更に必要とせずに、再生成をするのに使用可能な情報を含む。例えば、プロジェクト状態情報の典型的な使用により、不揮発性メモリに設計を保存することができるようになる。特定の設計に対して、"保存"機能又は制御を起動すると、プロジェクト状態情報がハードディスクに書き込まれるようにしてもよい。そして、ソフトウェアプログラムが停止(動作しているメモリの全てを消去する)してた後、再開する。ユーザーは、"開く"機能又は制御を選択して、ソフトウェアに、保存したプロジェクト状態情報を指し示す。ソフトウェアは、示されたプロジェクト状態情報を読み込み操作を行って、太陽光設備設置プロジェクトを再生成してもよい。
ある場合には、特定の設計が表示されている時のソフトウェアの動作メモリの全コンテンツを、"プロジェクト状態情報"として認識させることができ、これによって特定の設計を十分に特定することができる。プロジェクト状態情報を使用する1つの利点としては、動作メモリ(又はその他のデータ)のサブセットのみを使用する点であり、プロジェクト状態情報のサイズ及び複雑性の両方を低減することができる。例えば、所与の設計が、全てがモジュール種類T10であり、1000×1000のサブアレイに配置される百万個のコレクタを含むレイアウトを含むとする。このような設計を保存する一つの方法は、関係する特性情報(例えば、"モジュール種類=T10"、ロケーション、方位等)のコピーをそれぞれが有する"コレクタ"データ構造を百万個割り当てて格納することである。これに替えて、システムは、単純に"1000×1000のT10モジュールのサブアレイ、方位0度"の状態情報を格納してもよい。このように、プロジェクト状態情報をコンパクトな表示形態にすると、保存する際に便利であり、また修正も容易になる。例えば、設計者が、全てのモジュールについてT10から別の種類への変更を考えているとすると、最初の例の場合では、100万個のデータ構造を全てスキャンし、それに対して変更を実行しなければならない。一方で、2番目の例の場合には、状態情報に1つの変更を行うだけで、修正を実行することができる。
ある実施形態では、所定の設計に対するプロジェクト状態情報は、設計を再生成するのに使用されるデータのような、設計入力の全てを含む。例えば、プロジェクト状態情報は、幾何的オブジェクト、これら幾何的オブジェクトの構造物としての分類、分類されたオブジェクトそれぞれに対する構造特性、設計設定、作業エリア規定、アパーチャ規定及び付随する設計設定、プロジェクト特性等を含む設置現場の表示のような入力情報を含んでもよい。プロジェクト状態情報はまた、生成されたレイアウト情報に対するユーザー修正のような、その他の種類の入力を含んでもよい。例えば、ユーザーが特定のモジュールのステータスを"不適格"から"適格"へと変更した場合などの、ユーザーが生成されたレイアウトに対してモジュールを手動で追加した場合、そのモジュールの状態は、プロジェクト状態情報に反映させてもよい。
プロジェクト状態情報はまた、生成されたレイアウト、生成されたレイアウトの性能及びコスト特徴等の出力情報を含んでもよい。例えば、特定の設計についての部品表は、設計入力、例えば、設計設定の関数であるから、設計の出力であるといえる。例えば、出力情報をキャッシュしておくことにより、必要となる計算量を低減することができると考えられる。
プロジェクト状態情報の効率的な管理は、難しい場合がある。特に、ある実施形態では、プロジェクト状態情報は、"不一致"情報のために提供されてもよく、例えば、ユーザーが、PowerGuardモジュールを、T10と指定されたアパーチャ境界内に配置する場合などが挙げられる。システムが、ユーザーによる両方のアクションを有効にする場合には、プロジェクト状態情報を表現する効率的で強力な表示があれば便利である。
そこで、ある実施形態では、プロジェクト状態情報を、データ構造で表現される階層構造要素の配置として認識してもよい。ある条件下では、階層構造は、サブ要素が、固有の親オブジェクトに割り当てられるツリー状構造に似たものであってもよい。別の場には、階層構造は、特定のオブジェクトが1以上の親オブジェクトを有するような階層構造の、一般的なグラフのインスタンスであってもよい。
図10A及び図10Bは、ソーラーコレクタレイアウト設計ツールによって使用されてもよい、プロジェクト状態情報階層構造を示している。具体的には、図10Aに示すように、プロジェクト1000全体は、設置現場表現1001を含み、設置現場表現1001は、1以上の構造1002を含んでもよい。構造1002はそれぞれ、構造特性を含んでもよい。
設置現場表示は、複数の作業エリア1005を含んでもよく、図10Aに示されるように、2つの作業エリアを含んでもよい。各作業エリア1005は、1以上のアパーチャ1010を含んでもよく、例えば、第1作業エリア1005は、1010において2つのアパーチャを含んでもよい。これは、設置現場表示において、アパーチャ1010が、所定の作業エリア1005の境界内に収まっている場合である。複数の作業エリアと重複している1つのアパーチャである場合には、アパーチャオブジェクト1010は、複数の作業エリア間で共有されていてもよいし、複製されていてもよい。これに替えて、作業エリア1005に対する子供のオブジェクトとして、(アパーチャ全体ではなく)作業エリアアパーチャの交差点を使用するように、階層構造を調整してもよい。
ある実施形態では、上記したように、ソーラーコレクタが、アパーチャ1010と作業エリア1005との交差部分に配置される。各アパーチャ、又は、作業エリアとアパーチャの交差部は、アパーチャ1010内に、コレクタの1以上のサブアレイ1015を含んでもよい。所定のアパーチャ1010におけるサブアレイ1015の数及び構成は、アパーチャの境界内及び周辺に位置する障害物構造を含む、複数の変数の関数であってもよい。例えば、アパーチャを二等分するような線形障害物(例えば、壁のような)によって、アパーチャ1010内におけるコレクタのレイアウトが、壁の両側にそれぞれ配置される2つのサブアレイ1015に分割される。ある実施形態では、サブアレイ1015は、四角形の形状であってもよいし、別の実施形態では、形状に関係なく、アパーチャ1010内の隣接するコレクタのグループからサブアレイ1015を形成してもよい。別の実施形態では、サブアレイ1015を形成するのに、配線条件又は出力条件等のその他の規則1004を使用してもよい。
所定のサブアレイ1015をさらに、コレクタ1025の列1020へと分割してもよい。ある条件下では、PVモジュールで考えられるように及び上述したように、選択されたモデルに応じて、必要とされる出力電圧を生成するために、所定の数のコレクタを、例えば直列でといったように特定の態様で、互いに配線する必要がある。したがって、例えば、所定のサブアレイの要求される出力電圧が、最大出力にして150Vである場合、サブアレイを形成するのに使用された特定のモジュールの最大出力がそれぞれ、15Vであるとすると、設置するためには、モジュールを10個一列(ストリング)にしてグループ化する必要がある。各列におけるコレクタが直列に配線されて、サブアレイの各列は、サブアレイの別の列と並列に接続されてもよい。所定のサブアレイ1010は、複数の列(ストリング)1020から構成される。これら列1020のそれぞれは、複数のコレクタ1025から構成されている。
図10Bに示すように、所与のソーラーコレクタは、要素の階層構造を有してもよい。例えば、PVモジュールは、複数のセル列1030で構成されていてもよく、セル列のそれぞれは、一連のセル1035(図10Aに示すサブアレイ1015が、複数モジュール1025の列1020によって構成されているのと同様に)を含む。例えば、15Vのモジュールは、3つのセル列が並列に配線されたものであってもよく、セル列のそれぞれは、1.5Vのセルが10個直列に接続された構成を含む。
階層構造の各層における要素それぞれは、特性のセットと関連付けられていてもよい。例えば、所与の列の特性として、モジュールの数、列の位置等が含まれてもよい。特定の作業エリア、アパーチャ、プロジェクト及び構造と関連付けられてもよい特性の幾つかは、上記で例示した。1つの要素の特性は、完全に表示されてもよいし、特性の別のセットを参照して表示されてもよい。例えば、特性の初期値は、階層構造で表されているデータ構造の親の要素から引き継いだものであってもよく、これらの初期値は、所与の子供に格納されている特性の値を優先させ、無効化されてもよい。
特性と同様に、レイアウトエンジンによって採用される構造レイアウト規則のような設計規則は、階層構造における各要素と関連付けられていてもよい。図10Aの1004に示すように、構造の特定のインスタンスに固有でない設計規則は、プロジェクト又は設置現場に広く関連付けられていてもよい。設計規則も、特定のレイアウト又は設計エンジンから受け継がれたものであってもよく、プロジェクト状態情報階層構造に表示されなくてもよい。また、設計設定も、階層構造における各要素と関連付けられていてもよい。プロジェクト設計設定も、プロジェクト要素と関連付けられていてもよい。階層データ構造は、特性、設計設定及び規則の分類における柔軟性を提供する。例えば、ユーザーによって配置された又は修正されたコレクタは、付随する特性を有する構造1002として分類されてもよく、階層構造の別のレベル(1025に示されているように)又は両方に維持されてもよい。
ある実施形態では、例えば、プロジェクトを保存及び検索するのに使用するべく、プロジェクト状態情報を表示するためにソフトウェアによって使用されるデータ構造は、要素、特性及びそれに関連付けられた設計規則の集合間の階層的関係として表現されていてもよい。例えば、プロジェクト状態情報は、XML型の形式で表示されてもよく、最上階層の設置現場のノードは、構造及びその分類のリストを含んでもよい。設置現場ノードは、また、複数の作業エリアノードを含んでもよく、作業エリアノードは、複数のアパーチャノードを含んでもよい。アパーチャノードのそれぞれは、サブアレイノード等を含んでもよい。レイアウトを再生成するのに十分な情報を、データ構造内に含むという意味では、プロジェクト階層データ構造は、設計プロジェクトの状態を表しているとも言える。
[6.プロジェクト例外]
ある実施形態では、上述したように、設計者が、構造の分類、レイアウトの生成、及びレイアウトの修正といったプロセスを進めると、設計プロセスに関するメタデータが生成されてもよい。メタデータは、例えば、構造特性、設計設定、バージョン情報のような、プロジェクト状態情報に適用される規則から決定されてもよい。このメタデータは、多くの形式であってもよく、設計者が行った動作、及び設計者が行うべき動作に関する情報、管理者、共同設計者、ダウンストリームのユーザー及び設計を受け取る者にとって有用な設計情報を含んでもよい。システムは、メタデータ及びその他のデータを使用して、"例外"のリストを生成してもよく、リストは、例外的条件をメタデータにエンコードしたものであって、例えば、プロジェクト状態情報そのもの、設計出力に反映されたプロジェクト情報、又はその他の条件によって規則が破られる場合を示している。例外的条件及び対応する例外は、ユーザーによる不作為、規制の違反、ソーラーコレクタ製造業者の仕様に対する違反、顧客の要求に対する違反、設計原理に対する違反、物理空間制限に対する違反、会社の設計規則に対する違反等と関連していてもよい。
リストにより、設計者は、適正なアクションを最終的に実行すると同時に、設計欠陥のような例外的条件を見過ごすことなく、設置設計を生成する場合に、より柔軟に一連のアクションを実行することができる。例外リストを使用することにより、特に、特定の順番でワークフローを実行することを強要されず、設計者が選択した順番でアクションを実行することが可能になる。例外リストは、別のアクションを実行する前に、特にユーザーに例外事項(又は例外条件)を対処することを要求することなく、ユーザーに提示されてもよい。例外リストは、特定の例外に対処すべきか否かを設計者が決定する機能を提供してもよい。例外リストはまた、疑いのあるモジュール配置等の、設計についての重要な情報を示す単純なインターフェースを提供してもよい。ユーザーは、例外を効率的に(少なくとも一時的に)無視して、"やるべきことのリスト"の一部としてユーザーがスケジュールした時点に扱われるようにしてもよい。ユーザーは、例えば、ユーザーインターフェースにおいて、例外又は例外リストを、動作を邪魔しないものとして、所定の例外を無視するオプションを提供してもよい。また、ユーザーには、失われている情報を提供する、又は生成されたレイアウト又はユーザーが修正したレイアウトから不適格なモジュールを取り除くことによって、例外条件に対するソフトウェアの例外事項に従うオプションが与えられてもよい。メタデータ及び例外は、契約の例外事項のような、ダウンストリームにおける書類を生成及び維持するのに有用である。
ある実施形態では、例外事項を含むメタデータの一部又は全てが、共有ストレージ又は上記のデータ構造階層構造への参照によって、設計と関連付けられていてもよい。その後、自動化システムを含むダウンストリームのユーザー及び設計の処理者は、メタデータを使用してもよい。メタデータは、集約、エクスポート、暗号化、されてもよく、また、システムによって演算されてもよい。生成されたメタデータ及び例外は、特に、契約における例外事項に関する情報、設計者に対する注意、及び設置現場表示又はレイアウトにおけるエラーを含んでもよい。
図11に示すように、ユーザーインターフェース1100は、設計に関するメタデータの一部又は全てが、例外のリスト1105の形で設計者に表示されるようにしてもよい。表示には、レイアウト、リスト又は設計例外、及び例外事項を操作することが可能な制御が含まれてもよい。例外は、設計者の一部に対してアクションが必要であることを示してもよい。ある例外事項の場合には、例外が生成されてはいるが、設計者は、要求された情報を提供しなかったことに対する設計プロセスにおける障害を受けるとことが無いようにすることもできる。例えば、ある実施形態では、郵便番号で近似することができる設置現場のロケーションは、レイアウトに影響を与える設置現場特性である。これは、異なる郵便番号が、異なる規制制度を暗に意味しており、例えば、屋根に載せる負荷、セットバック等に関して異なる規制が課されることが考えられる。したがって、設計規則は、郵便番号の提供を要求してもよい。このような場合に、設計者が、設置場所に対する郵便番号を指定し忘れると、この情報の不足が、設計に関するメタデータとして通知されて、郵便番号例外1110が生成されてもよい。郵便番号例外1110が未決の間であっても、設計者は、初期設定値の郵便番号又はシステムによって提供された規則制度を使用して、オブジェクトの分類、及びレイアウト又はダウンストリームにおける書類作成を進めることができる。
これに替えて、システムは、例外が存在ししている間は、ユーザーは、それと無関係のアクションを実行可能なようにしてもよく、レイアウト生成、シミュレーション又はダウンストリームの書類作成のような特定の動作を許可する前に、設計者に例外の対処をするように要求してもよい。例えば、設計者は、郵便番号を入力する前にオブジェクトの分類を継続することは許されるが、レイアウトを生成することは許されない。別の例としては、その他のメタデータが、設計継続が許されないような致命的な状態を示してもよい。例えば、設計者が換気扇の上にモジュールを配置した場合には、システムは、エラー例外1115を生成してもよい。設計者は、最終的な設計が生成される前に、この例外1115に対処する。ユーザーが例外に対処していない場合(すなわち、無視している場合)には、その例外は、管理者がレビューするために、例外リスト1105に残される。ユーザーによるある種の対処、例えば、要求されたもの又は変更に一致させることは、例外リストの項目から除外されてもよい。例えば、無効化、又は、要求された情報又は変更に一致させることを明示的に拒否するような、ユーザーによるその他の対処の場合には、例外の修正及び例外の保守が必要となり、ユーザーは、例外履歴における入力を無効化する。これは、修正、管理者のレビュー、契約書作成等で将来の有用となる。その他の種類の例外については、以下に記載する。
設計者は、設計者に対応を要求する例外事項について、様々な態様で対処してもよい。例えば、設計者は、設置現場の郵便番号を入力することにより、郵便番号例外1110に対処することを選択してもよい。この例外に対しては複数の方法で対処が可能であり、例えば、上記したようなプロジェクト特性を入力するメカニズムを使用して対処可能である。これに替えて、例外1110そのものを、これを対処するメカニズムと関連付けてもよい。例えば、郵便番号例外1110が、郵便番号を入力するフィールドを含み、プロジェクトと関連付けられていてもよい。ユーザーが例外に対処すると、システムは、情報を再計算又は再生成する。例えば、ユーザーが値を郵便番号例外に入力すると、システムは、その郵便番号を有効化して、例えば、新たなロケーション情報でレイアウトを再生成してもよい。例外に応答して、ユーザーは、例外的条件又は規則違反を是正するのに十分なコンプライアンス情報を提供してもよく、そのような情報としては、プロジェクト特性、顧客特性、設計設定、作業エリア境界及びアパーチャ境界が含まれてもよい。ある実施形態では、コンプライアンス情報を認識して、プロジェクト状態情報又はその他の設計情報を修正するべく情報を使用してもよい。コンプライアンス情報を受信した後、システムは、対応する例外を除去してもよい。
システムはまた、ダウンストリームのユーザー及びプロセスに有用な設計に関する情報又はメタデータを反映する例外を含んでもよい。例えば、設計者が、(オンサイトの検査官によって規定された)"不適格な風の領域"として分類された構造と重複した構造に、モジュールを配置すると、除外例外1120が生成される。上記したように、この除外例外が設計者に示されて、設計者は、規則に従うように、例えば、例外を除去又は改善するように(例えば、対象となっている特定のモジュールを取り除くことにより)、制御を操作してもよい。これに替えて又はこれに加えて、除外例外を含む例外の一部は、設計と共に維持される又は設計と関連付けられてもよく、それにより、設計を使用する次のプロセスを実行可能としてもよい。例えば、別のソフトウェアプログラムが、除外例外情報を使用して、設計者と顧客との間で交わされる契約書の条項の一部として記載されてもよい、契約上の例外のリストを生成してもよい。例えば、水漏れがある屋根の領域にモジュールが配置されたことに対応する例外1120は、水漏れのある屋根の領域に配置されたモジュールに対する設計者の品質保証を制限する契約上の特別な条項を生成するために、ダウンストリームのプロセスで使用されてもよい。
また、例外の中には、設計者以外の人物又は権限を持つものが、レビュー及び追加の許可を必ず行うように設計されていてもよい。例えば、最大設計重量の95%の重量負荷がある屋根と関連する例外1125は、設計者の管理者による承認を必要としてもよい。設計者が、少なくとも特定の指定されたアクションに関して実行を続ける前に、管理者又は別のユーザーによる例外の承認を要求してもよい。これに替えて、システムは、このような承認を必ず伴う例外の全てついてのリストを生成してもよく、このリストは、設計のダウンストリームプロセスの一部として使用されて、ユーザーが、例外が存在したとしても少なくとも一部のタスクを進められるようにする。後で行う、例外事項の修正、無効化、又は無効化の許可(例えば、管理者による)に伴って、ユーザーが間で行った仕事が無駄にならないように、関連するソーラーコレクタのレイアウトの再生成を行ってもよい。
ある実施形態では、上記の例外及び対処の組み合わせの一部又は全てを実装してもよい。例えば、例外に応じて、システムが設計者に対して利用可能とする適格な対処には、"例外無視"、"自動レイアウト修正"、"例外無効化"、"コレクタ消去"、"レイアウト再生成"、"値入力及び再計算"、"管理者へのフラグ"、"例外に従う"等の変形例が含まれてもよい。例えば、ユーザーは、ソフトウェア制御によって、例外的条件を取り除くことに合わせたプロジェクト状態情報又は設計の修正によって、システムが自動的に例外的条件の修正を試みる段階を実行する命令を発行してもよい。
ある実施形態では、ユーザーの認証を含む例外への対応の一部として行われた動作を含む、ユーザーの対処を記録してもよい。対処の記録は、例外と関連付けられて、所定のプロジェクトと共に格納され、ダウンストリームのユーザー等にエクスポートされてもよい。別の実施形態では、ユーザーの入力又は推進事項のあるなしに関わらず、例外事項の存在を再評価してもよく、例外的条件がもはや存在しない場合には、システムは、その例外事項を除去してもよい。
図12には、例外を実装するプロセスが示されている。1205−1210において、システムは、入力認証ループに入ってもよい。1205において、設計者は、設置現場情報を入力し、オブジェクトを構造として分類し、構造特性、及びその他の設計特性及び設定を入力してもよい。1210において、システムは、幾何的オブジェクト、及び、プロジェクト状態情報におけるその他の入力情報に規則を適用することにより、設計者の入力を分析及び認証してもよい。認証エンジンは、プロジェクトの種類に固有の認証ルールを使用してもよく、又は一般化されてもよい。認証規則は、プロジェクト階層構造と共に格納されてもよいし、プロジェクトの外部に配置されていてもよい。認証エンジンによって、不一致が通知されると、この不一致が例外リストに掲載されて、例えば、1212において、コンピュータメモリのデータ構造に配置されてもよい。上記したように、例外事項は、ユーザーに表示されてもよい。ユーザーは、例外リストに配置された例外事項に対処するかを選択する、又は、ユーザーは更なる特性、分類及びその他の情報を入力してもよい。
入力認証ループ1205‐1210は、ユーザーが1215においてレイアウトを生成させるまで、継続させてもよい。このように構成した場合、システムは、レイアウト認証修正ループ1215‐1220‐1225‐1230に入ってもよい。1220に示すように、生成されたレイアウトが分析されて、設計設定、構造及びプロジェクト特性、レイアウト規則、所望の出力、及びその他の符号化された情報の基準と合致しているかの認証が行われてもよい。生成されたレイアウトから生じた変更又は逸脱が、例外として再び表示され、1222において例外リストに配置されてもよい。1225において、ユーザーには、上記したように、レイアウトを修正する機能が表示される。修正する機能には、特性又は設定の変更、例外への対処(これは、特性又はレイアウトにおける変更を伴う)、モジュールの追加又は削除等が含まれる。
1230に示すように、ユーザーのアクションが、認証エンジンによって認証されてもよい。1232では、ユーザーのアクションによって生じた例外が、例外リストに再び追加されてもよい。ある場合には、ユーザーによる変更が、レイアウトの再生成をトリガすることがある。例えば、ユーザーが、セットバック特性を大きくすると、大きくなったセットバックに合うように、レイアウトが再生成されてもよい。例外の種類に応じて、1225‐1230のループ(ユーザー入力が認証されてレイアウトの再生成無しに例外事項が生成される)、又は、1215‐1220‐1225‐1230ループ(ユーザー入力によって、レイアウトの再生成が発生する)を、必要に応じて又は設計者の要求に応じて、繰り返してもよい。
1235において、例外及び例外に対処するためにとられた動作を含むプロセスを通じて生成されたメタデータの一部又は全ては、存在する場合には、格納されてもよいし、ダウンストリームユーザー対して利用可能としてもよい。例えば、契約書の条項のリストを、契約の除外例外の全てから生成してもよく、承認が必要な例外事項の全てのリストが生成されて、適切な認証実体に転送されてもよい。ユーザーインターフェースは、ソーラーコレクタ設置設計による設計規則の違反に関連した例外的条件に対応する契約例外事項のリストを提供してもよく、契約例外又は条件は、契約書に組み込むべき条項を特定するのに十分な情報を提供する。通常は、メタデータ、例外、又はユーザーのアクションが、プロジェクト状態情報の一部として含まれる。
[7.プロジェクトのバージョン]
ある実施形態では、特定の設置現場に対するソーラーコレクタレイアウト設計の複数のバージョンを閲覧、生成及び操作するためのシステム及びユーザーインターフェースを提供する。複数のバージョンが扱えるようになると、例えば、設計者は、別のモジュール、別の構造分類、別の作業エリア及び/又はアパーチャ境界、別の入力又は設計設定のその他の種類を選択した場合のレイアウト及びその他の出力を素早く容易に見ることができるようになる。複数のバージョンにより、設計者が、様々な入力変更による出力の変化をインタラクティブに見ることができるようになる。ある実施形態では、設計者が、1つのバージョンから別のバージョンへの移動を迅速にできるようにし、別の実施形態では、設計者が、1つのアクションで複数のバージョンに作用することを可能としてもよい。所定のバージョンは、ユーザーが規定した設計設定、構造特性及びプロジェクト特性の固有のセットを提供するユーザーが規定したプロジェクトの状態情報を含んでもよい。この入力情報の異なるセットを有する異なるバージョンは、ソーラーコレクタ設備の代替レイアウトに対応していてもよく、各バージョンに対する代替レイアウトは、データの固有のセット間の差分から生じる。データの固有のセットはまた、作業エリア状態情報、アパーチャ状態情報、幾何的オブジェクト情報を含んでもよい。
ある実施形態では、所与の設置プロジェクトの異なるバージョンは、特性を含む設置現場及び/又は構造情報を共有してもよい。このようなバージョンは、可能性のある異なる作業エリア、アパーチャ及びレイアウトを規定してもよい。別の実施形態では、複数のバージョンは、構造情報の全てを共有しなくてもよく、したがって、異なるバージョンが、異なる構造、分類、又は構造特性を有していてもよい。複数のバージョンは、特に、幾何的オブジェクト、オブジェクト分類及び構造特性、プロジェクト特性を含む様々な種類の入力プロジェクト状態情報を共有してもよい。複数のバージョンは、別々のデータセット間の一貫性を保つことにより、データを共有してもよい。これは、ポインタによって、メモリにおける同じ場所を参照するといったように、共有されたプロジェクト状態情報の同じコピーを複数のバージョンが参照することによって達成してもよい。設計設定、構造特性、プロジェクト特性等の入力データの種類それぞれは、1以上の個別のデータが共有され及び/又は1以上のデータが共有されないといったように、分岐されてもよい。
関連するバージョンは、図10A及び図10Bで説明したような階層構造の1つ以上の階層において、情報を共有してもよい。例えば、関連するバージョンは、設置現場、及び構造物と構造物の分離を含む設置現場の物理的特徴の共通の内容を共有してもよい。複数のバージョンは、階層構造におけるいかなる点で、互いに分岐してもよい。ツリー状の階層構造の場合には、分岐点の上方の要素は、複数のバージョン間で共有されてもよく、分岐点の上方のデータに対する変更は、両方のバージョンについて適用可能である。これに替えて、分岐点の下方のデータの2つ以上のコピーを維持してもよく、コピーはそれぞれのバージョンに対して維持され、1バージョンにおける分岐点下方のデータに対する変更は、(存在する場合には)別のバージョンにおける対応するデータに影響を与えない。
ある実施形態では、複数のバージョン間における分岐点は、作業エリアの階層であってもよい。例えば、図13には、1305に3つのバージョンが示されている。図示された例では、3つのバージョン1305は、設置現場に依存する関係となっており、それに従って、これらのバージョンは、設計規則1004、構造1002の一部又は全て、及びこれらの分類及び特性等を含む符号化された情報の複数のセットを共有してもよい。このような状況において、幾何的オブジェクトの別の構造種類への再分類、構造特性における変更等の設置現場1001又は構造1002に対する1つの変更を行うと、その変更が、3つのバージョン1305の全ての本質的部分に反映されてもよい。別の例では、バージョン1305のそれぞれは、別々の独立した作業エリア1005、アパーチャ1010、及ぶ、レイアウトエンジンによって生成された関連したサブ要素(サブアレイ等、図示せず)を含んでもよい。この場合、作業エリア、アパーチャ又はサブ要素に変更が行われると(特定のモジュールを手動で配置、又は、列の配線パターンにおける変更等)、変更が行われたバージョンにのみ、その変更が適用されてもよい。これは、設計者が、構造分類等のプロジェクトの詳細設定は、全てのバージョンにおいて不変としたい場合に有用である。構造特性における1つの変更について、複数のバージョンを、設計者が手動で更新するのではなく、複数のバージョン間で共有された分類を提供するシステムを配置して、全ての関連するバージョンに対して自動的に更新を行うようにしてもよい。
このように、プロジェクトデータ構造は、代替バージョンが、上記したように、独立した(共有されない)プロジェクト状態情報及び共有されたプロジェクト状態情報を含むような、設計の代替バージョンを含む。(共有されない)独立したプロジェクト状態情報は、バージョン毎に異なっている。共有されるプロジェクト状態情報と組み合わせる場合に、状態情報は、異なるバージョン間で異なる設置設計を規定してもよい。
ある実施形態では、階層構造におけるより上位の階層又は下位の階層において、複数バージョンの分岐を行ってもよい。例えば、複数のバージョンは、階層構造における最も上位の階層において分岐してもよく、この場合、複数のバージョンは、構造分類を含む共通の構造を共有しない。これに替えて、複数のバージョンは、下位層において分岐してもよく、例えば、特定のサブアレイに対する列の階層において分岐する場合には、1つのバージョンが、南北方向に複数のモジュールが列になっているとすると、別のバージョンでは、主に東西方向に複数のモジュールがグループ化される。このような場合、2つのバージョンは、分岐点より上に位置する要素(全体的なアパーチャ設計設定等)を共有し、1バージョンにおけるアパーチャ設定の変更は、別のバージョンのそれにも影響を与える。
図14に示すように、幾つかの実施形態では、異なるバージョンを表示、生成、修正及び操作するためのインターフェースを提供してもよい。具体的には、1つ以上のバージョンのリスト1400が提供されてもよい。リスト1400は、所定のバージョンに固有の階層構造の1以上の階層を反映させてもよく、この例では、"バージョン1"に対して示されている。インターフェースは、バージョンを表示するべく、又はユーザーインターフェースにおける別のオペレーションのために、有効にする(又は選択する)、ツールボックス制御1450のようなメカニズムを提供してもよい。1405で示されるバージョン1のように、階層のレベルが表示される場合には、バージョン1 1405の第1アパーチャ1410のように、ユーザーがサブ要素を選択可能な制御を提供してもよく、視覚的表示において選択要素をハイライトする、特性ボックス(図示せず)を表示する、概要情報を表示する等、サブ要素に対する動作を起動してもよい。リスト1400は、様々なバージョンの分岐点を反映又は表示してもよい。
1つのバージョンがアクティブ化されると、そのバージョンのコンテンツが、視覚的表示に表示されてもよい。例えば、あるバージョンがアクティブ化されると、そのバージョンに対応するアパーチャ、作業エリア、構造特性、モジュールレイアウト、例外(以下参照)が表示されてもよい。バージョンがアクティブ化されると、レイアウトエンジンが、そのバージョンに対応した(そのバージョンの特性と一致した)レイアウトを再計算してもよい。また、アクティブ化に伴って、バージョンの概要情報のようなバージョンについての情報が、ステータス行又はフィールドに表示されてもよい。設置現場構造が、生成され分類されて、レイアウト、例外等が生成されると、これらの特性及び例外は、現在アクティブ化されているバージョンと関連付けられてもよい。
アクティブ化されたバージョンに変更が行われ、その変更が、別のバージョン共有されている要素に対するものであったとすると、その変更は、別のバージョンにも反映されてもよい。例えば、2つのバージョンが、上記したように構造分類情報を共有しているとすると、設置現場の所定の構造の再分類、又は、その特性の変更は、両方のバージョンに影響する。アクティブ化されていないバージョンに変更が反映された場合には、そのバージョンと関連付けられたレイアウトの再計算を行ってもよい。バージョン間で共有されていない情報については、アクティブ化されていないバージョンに対する変更は、別のバージョンに影響しない。
新しいバージョンを形成するべく、新しいバージョンのツールボックス制御1455のようなメカニズムが提供されてもよい。新しいバージョンは、一番最初から形成されてもよい(そして、設置現場の特性が適用されてもよい)。これは、最初のバージョンが、新たなプロジェクトの第1バージョン(その時点のみ)として、初期設定で生成される場合が考えられる。これに替えて又はこれに加えて、新しいバージョンは、プロジェクト特性及び構造分類(存在する場合)のようなソーラーコレクタ設置プロジェクト条件の一部を、1つ前のバージョンから継承してもよい。例えば、構造の1セットが規定及び分類されていたとすると、新たに形成されるバージョンは、これらの構造及び分類を継承してもよい。
バージョンコピーツールボックス制御1460のようなメカニズムを提供して、バージョンをコピー又は複製してもよい。新しいバージョンは、既に存在するレイアウト又はバージョンからコピーをする(例えば、分岐する又は複製することによって)ことによって生成されてもよい。現在アクティブ化されているバージョンを使用して、新しいバージョンをそこから分岐させてもよい。複製されたバージョンが、元のバージョンと同じ状態情報の少なくとも一部を使用してシステムに投入された場合には、新たにコピーされたバージョンは、例えば、同じ設置現場特性、アパーチャ、アパーチャ特性、例外等、兄弟バージョンの特性の全て又は大部分から開始してもよい。変更が行われた要素が、バージョン間で共有されているか否かに応じて(図13に示すように)、新たにコピーされたバージョに対する後の修正が元のバージョンに反映されてもよいし、されなくてもよい。ある実施形態では、ユーザーは、ユーザーが規定した設計設定の固有のセット、新たな又は複製されたバージョンに対応する、ユーザー規定の設計設定の固有セットに反映されていない構造特性、新たなバージョン又は複製バージョンの前に形成されたあらゆるバージョンに対応する構造特性に変更を行ってもよい。
バージョン消去ツールボックス1465のようなメカニズムを提供して、例えば、表示からバージョンを取り除く、及びバージョンと関連付けられた記憶領域から取り除く等、バージョンを消去してもよい。例えば、バージョン名変更ツールボックス制御1470のような同様なメカニズムを提供して、バージョンの名前を変更してもよい。
バージョン固有の情報を生成する、又は、バージョンを操作するためのメカニズムを提供してもよく、例えば、あるバージョンのパーツ概要を生成する(CSVファイル形式で)パーツ概要ツールボックス制御1475、バージョン情報を、例えば、データベース記録又は記録のセットのような別の形式で保存するためのバージョンエクスポートツールボックス制御1479、バージョンに関するシミュレーションを実行する及び/又はシミュレーションデータを生成するバージョンシミュレートツールボックス制御1485、バージョンシミュレーション情報を、例えばCSVファイル形式等で保存又はエクスポートするバージョンシミュレーションエクスポートツールボックス制御1490を提供してもよい。上記した制御のそれぞれは、現在アクティブ化されているバージョン、選択されたバージョン、又は複数のバージョンのセット、又は全バージョンに適用してもよい。
制御1477を使用して、プロジェクトの様々なバージョンの概要を生成してもよい。このバージョン概要は、各バージョンについて様々な比較情報を含んでもよく、例えば、ソーラーコレクタの数、コスト、重さ等のレイアウト情報、期待される性能、最大出力、キロワット/時間の発電に対するコスト、最小エネルギー生成等のシミュレーションデータ、例外数、種類等のその他の種類の情報が含まれてもよい。そのバージョンにおいて、不適格及び不十分、又は良好でない状態で配置されたモジュールに関する情報を、バージョン概要で示してもよい。バージョン概要情報はまた、予測される性能、シミュレーション情報、電力、電力効率、コスト、材料、物理的大きさ、部品点数、及び例外のような、各バージョンについての情報を生成してもよい。この情報は、作業エリア、アパーチャ、サブアレイ、モジュール、列等の特定のバージョンのサブ要素に対して、生成及び表示されてもよい。図15には、複数のバージョン1510の概要が示されているバージョン概要1500のサンプルが示されている。設計者は、様々なバージョンから選択し、及び/又は複数のバージョンにおける誤り又は不足を特定することを含めて、多くの目的で、バージョン概要情報を使用してもよい。バージョン概要情報は、外部のファイル又は記憶装置にエクスポートされてもよい。ユーザーは、どのバージョン概要情報を表示させるか又はエクスポートするかを選択してもよい。
設置プロジェクトの様々なバージョンが複数のファイル、又は好ましくは、1つのファイルに保存されていてもよい。上記では、1つのバージョンの設置プロジェクトについて説明したが、複数のバージョンを有するプロジェクトを、XML形式で表示してもよく、最上階層である設置現場ノードは、構造及びそれらの分類のリストを含んでもよい。設置現場ノードは、複数のバージョンノードを含んでもよく、バージョンノードは、複数の作業エリア及びアパーチャノードを含んでもよい。アパーチャノードのそれぞれは、サブアレイノード等を含んでもよい。バージョン概要情報、バージョン名等のバージョンと関連付けられたデータは、バージョンと共に格納されていてもよい。具体的には、ソーラーコレクタレイアウト情報、バージョン概要情報、シミュレーションデータ、契約情報、部品表情報、例外情報等のバージョン毎に異なる場合がある設計出力情報を、キャッシュ又は格納してもよく、バージョンと同じ場所に配置してもよい。
ある実施形態では、ツールバーアイコン又はキーボードショートカットのような"取り消し"制御を提供して、設計者が、プロジェクト及び/又はバージョンに対して行った1以上の変更を取り消せるようにしてもよい。ある実施形態では、設計者があるバージョンに対して変更を行う場合、それが、レイアウトの修正であれ、オブジェクトの分類であれ、その変更が実施形態により記録される。そして制御は、その効果を反転させることにより、ユーザーが変更を"取り消し"することを可能にする。ある実施形態では、変更を、プロジェクト又はバージョンの状態のスナップショットを撮ることによって記録してもよい。実施形態は、そのスナップショットに戻ることにより、変更を取り消してもよい。これに替えて、実施形態は、変更(又はその反転)によって実体化される状態の遷移を記録してもよい。この状態遷移を逆転させることによって、"取り消し"が実行されてもよい。このように、スナップショット又は遷移のスタックを使用することにより、様々なレベルの取り消しを維持することができる。同様に、"取り消し"アクションが、スナップショット又は遷移を反転させる("やり直し)アクションを起こし、"取り消し"の反転を、やり直しのスタックに押し込むことにより、やり直し機能を実装してもよい。
[8.実施例]
図16A〜図16Eには、本明細書で説明したシステム及び方法の一部の実施形態に係るレイアウトソフトウェアからのスクリーンショットの例が示されている。図16Aに示すように、ユーザーインターフェース1600には、設置現場の可視的表示1601が示されており、屋根外縁1602で揃えられている2つの傾斜を有する屋根面に対応する幾何的オブジェクトが配置され、幾何的オブジェクトは、複数の立体障害物(通気孔1603)及び線形障害物(パイプ1604)を含む。ユーザーインターフェース1600は、ツールバー1605及び特性パレット1606を含む。インターフェースは、バージョン表示(図示せず)、バージョン概要(1620)、例外リスト(図示せず)、ユーザー入力及びシステム出力のためのフィールド1630を有してもよく、これらを同時に表示してもよい。
図16Bに示されるように、ツールバー1605の形式の制御によって、ユーザーが構造としてオブジェクトを分類する機能(ここでは、屋根制御1610、立体障害物制御1612、及び線形障害物制御1613が示されている)、及び、作業エリアの境界1611を視覚的表示に形成する機能を提供してもよく、作業エリアは、太陽モジュールを配置してもよい範囲を規定している。オブジェクトの分類を解除する1614制御を提供してもよい。実際のレイアウトを生成する1616制御と共に、レイアウトアパーチャ1615を生成する制御を提供してもよい。例外リスト、特性パレット、バージョン概要、バージョンリスト等のどのインターフェース要素を表示させるか選択するのに表示制御1625が提供されてもよい。レイアウトは、実質的に、作業エリアの境界とアパーチャの境界との交差点に限定され、アパーチャと関連付けられた設計設定のセットに少なくとも一部したがって、レイアウトが生成される。図に示すように、有用な(特に限定しない)テキストが、ポップアップ、ロールオーバー等の形態の制御で提供されてもよい。図16Cに示すように、同様な機能を達成する制御を含むメニューが、提供されてもよい。図16Dに示すように、特性パレットは、ユーザーが、特定の構造に関する特性を見る及び/又は調整することを可能にする。
図16Eは、PVモジュールのレイアウトを視覚的表示で生成した結果であり、2つの屋根オブジェクト1602、大部分がそれぞれの屋根表面と同じ場所に存在している2つの作業エリアの境界、及び3つのアパーチャ境界(そのうち2つは、矩形状のアパーチャ1650であり、1つの屋根及び1つの作業エリアの一部のみにわたって延在し、残りの1つは、不規則な形状をしたアパーチャ1650Aであり、2つの屋及び作業エリアの一部にわたって延在している)が含まれている。図示するように、アパーチャは、アパーチャ内に配置された複数のモジュールのセットを有し、これらモジュールのレイアウトは、アパーチャ内に含まれる対応する屋根、作業エリア及び障害物に関するレイアウト規則に従っている。
[9.結び]
上記の説明における分類及び規則は、添付の特許請求の範囲によって規定される発明を実施する方法の一部を単に示したものに過ぎないことは、当業者にとって明らかである。設置現場に関するレイアウト要求に基づいて、PVモジュールを幾何的オブジェクト内及び周辺にレイアウトするその他の方法を、同様な結果、表、スクリプト、データ構造等を達成するのに使用してもよい。規則は、上述したように、明示的であってもよいし、及び/又は宣言文を含んでもよく、又は、LISPのような規則中心の言語で使用されているようなものであってもよい。これに替えて、1以上の"規則"は、データ構造、命令ステートメント、プログラムフロー、プログラム構築、配置及び配置アルゴリズムにおいて非示的に表現されたものであってもよい。本明細書で使用されている規則は、ツールがPVモジュールレイアウトを生成するのに使用する任意のオブジェクトに関連付けられた情報による一般的な方法の一例を示したに過ぎない。レイアウト制限のような特定の規則は、特定のオブジェクト又は構造、及び/又は特定の種類又は構造の分類と明示的に関連付けられていてもよく、このような規則は、レイアウトエンジンの一部として規定されていてもよいし、非明示的にオブジェクト又は分類と関連付けられていてもよい。
本明細書に記載されるシステム、方法及び技術は、コンピュータハードウェア、ファームウェア、ソフトウェア又はこれらの組合せに実装されてもよい。これらの技術を実体化するシステムは、適切な入力及び出力コンポーネント、コンピュータプロッセサ、及び、機械可読記憶要素に実体化されたコンピュータプログラム製品、又は、プログラム可能プロセッサによる実行のための媒体を含んでもよい。これらの技術を実装するプロセスは、入力データに対する操作及び適切な出力を生成することによって所望の機能を実行するプログラムの命令を実行するプログラム可能プロセッサによって実行されてもよい。技術は、プログラム可能システムから命令及びデータを受信し、データ及び命令をデータ記憶システムへと送信するべく接続された少なくとも1つのプログラム可能プロセッサ、少なくとも1つの入力コンポーネント、少なくとも1つの出力コンポーネントを含む。コンピュータプログラムはそれぞれ、高級手続き型プログラミング言語又は高級オブジェクト指向プログラミング言語に実装されていてもよく、又は、必要に応じて、アセンブリ言語又は機械言語に実装されてもよい。いずれの場合においても、言語は、コンパイルされても、インタープリタ型言語であってもよい。好適なプロセッサとしては、例えば、汎用マイクロプロセッサ及び特殊用途マイクロプロセッサの両方を含む。多くの場合、プロセッサは、命令及びデータを、リードオンリーメモリ及び/又はランダムアクセスメモリから受信する。コンピュータプログラム命令及びデータを好適に実体化して実装するのに好適な記憶要素は、あらゆる形式の不揮発性メモリを含む。不揮発性メモリの例としては、消去可能プログラム可能リードオンリーメモリ(EPROM)、電気的消去可能ROM(EPROM)、電気的消去プログラム可能ROM(EEPROM)、フラッシュメモリ要素のような半導体メモリ要素、内蔵ハードディスク及びリームバルディスクのような磁気ディスク、コンパクトディスクリードオンリーメモリ(CD−ROMディスク)が含まれる。上記のいずれの要素も、特別に設計されたASIC(特定用途向け集積回路)に組み込まれてもよいし、ASICによって補ってもよい。様々なデータ構造のそれぞれの表示、及び上記した方法の段階は、好適に、レンダリングされてもよく、例えば、スクリーン、モニター又はプリンタといったデバイスに、表示される、又は印刷されてもよい。
本明細書の開示は、特定の実施形態及び適用例を記載しているが、本明細書に記載されている特徴及び効果の全てを提供しないような実施形態及び適用例を含む当業者にとって明らかなその他の実施形態及び適用例も、本開示の範囲内に含まれる。また、選択肢及び代替構成のリスト及び詳細の全ては、例示するものとして解釈されるべきであり、限定するものとして解釈されるべきでない。また、リストは、説明を補助する目的で提供されており、可能性のある代替物の全てを列挙することを試みたものではない。本発明の範囲は、特許請求の範囲を参照することによってのみ規定されることを意図している。