ソーラーコレクタ自動設置設計
実施形態は、設置現場の表示を生成及び編集し、様々なデータオブジェクトを生成し、オブジェクトを、付随する特性及びレイアウト制限を伴う予め規定された"構造"の様々な種類として分類するシステム及び方法を含んでもよい。分類の一部として、又は分類に追加して、ある実施形態は、これらのオブジェクトに固有の特性又は付随する特性を生成、関連付け及び編集するシステム及び方法を含んでもよい。設計エンジンは、上記の構造に設計規則を適用して、１以上のソーラーコレクタ設置設計の代替案を生成してもよく、物理レイアウトのスクリーン表示及び／又は紙表示、又は、１以上の設計代替案の配置を生成することを含む。
【発明の詳細な説明】
【背景技術】
【０００１】
近年、太陽光発電は、非常に重要なエネルギー資源となりつつある。太陽光エネルギーは、様々な方法で収集及び利用することができ、太陽電池（ＰＶ）モジュール及び太陽熱による熱及び電力の収集及び変換のような、ソーラーコレクタ（太陽光熱の収集器）の利用が含まれる。これらのプロジェクトは、一家族の屋根に設置されるような家庭向けの利用から、百万個を超えるＰＶモジュールを設置する大規模なものまで、その大きさは様々である。
【０００２】
太陽光発電設備のコスト、寿命、エネルギー生成及び経済的価値は、多くの複雑に相関するパラメータに依存し、これらに限定されないが、パラメータとしては、例えば、１）ロケーション、２）気候、３）天窓のような、レイアウトと干渉する物理的な障害物、４）敷地の境界線による妨げ、又は、電線の敷設権のような非物理的な場所の構造、５）システムが影になってしまう原因となる物理的障害物、６）重量制限及び防火規定を定める地域の建築基準法、７）風速耐性設計のような環境的条件、８）地面、屋根、又は駐車場の上部の骨組み等の設置表面、９）地方及び国の法律、１０）電力の電気接続条件、１１）顧客の設置現場における既存の電力設備、及び、１２）顧客の電力又はエネルギーコストが挙げられる。これらの条件に適合する効率的なシステムを設計及び分析する仕事は、複雑で時間が掛かり、また、誤りも多く、太陽エネルギープロジェクト開発において、一番コストの掛かる仕事となる場合がある。
【発明の概要】
【０００３】
物理的設置現場におけるソーラーコレクタ設置の設計を自動化するためのコンピュータベースのユーザーインターフェースを開示する。ユーザーインターフェースは、物理的設置現場の少なくとも一部の表示を含んでもよい。表示は、１以上の幾何的オブジェクトを含んでもよく、１以上の幾何的オブジェクトは、物理的設置現場における物理的又は非物理的構造、又はその他の構造に対応していてもよい。ユーザーインターフェースはまた、幾何的オブジェクトを、特定の構造分類のインスタンスとして分類するよう動作する制御を含んでもよい。構造分類は、予め存在する複数の構造分類から選択されてもよく、特定の構造分類は、詳細事項、物理的又は非物理的構造の特徴の全て又は一部と関連付けられていてもよい。特徴は、ソーラーコレクタ設置設計と関係したものであってもよい。ユーザーインターフェースはまた、物理的現場における設置のためのソーラーコレクタ設置設計を少なくとも１つ自動的に生成するよう動作する制御を提供してもよい。１以上の幾何的オブジェクト、構造分類及び現場と関連付けられた物理的構造の特徴の詳細事項に、実質的に又は完全に従って、設計が生成されてもよい。
【０００４】
また、物理的現場に設置するためのソーラーモジュール設置レイアウトを生成するシステムが、開示される。システムは、ソーラーモジュール設置レイアウトを生成するための特性と幾何的オブジェクトとを関連付けることができる分類コンポーネントを含んでもよい。幾何的オブジェクトは、コンピュータストレージに記憶されていてもよい。複数の幾何的オブジェクトのうちの少なくとも１つが、物理的設置現場における物理的構造又は非物理的構造に対応していてもよい。カテゴリ化コンポーネント又は分類コンポーネントは、複数の幾何的オブジェクトのそれぞれの内側にソーラーモジュールをレイアウトするために、１以上のオブジェクトを作業エリアと関連付けてもよい。コンポーネントはまた、（先に規定したオブジェクトに加えて）１以上の幾何的オブジェクトを、１以上の幾何的オブジェクトの第２グループ内のソーラーモジュールレイアウト禁止領域と関連付けてもよい。システムはまた、レイアウトコンポーネントを含んでもよい。レイアウトコンポーネントは、タイリングを使用してもよく、ソーラーモジュールを少なくとも１つの作業エリアにタイル状に配置することにより、ソーラーモジュールの設置レイアウトを生成してもよい。その後に、コンポーネントは、オブジェクトに関連付けられたソーラーモジュールのレイアウトの禁止に従って、レイアウトから１以上のタイリングされたソーラーモジュールを取り除いてもよい。
【図面の簡単な説明】
【０００５】
【図１】屋根、換気扇及び配線管を含むソーラーコレクタ設備の設置現場の例を示した、概略的な等角図である。
【図２】図１の設置する設置現場を表した、屋根、換気扇及び配線管の構造に対応する幾何的オブジェクトを含む視覚的表示が表示されているユーザーインターフェースを概略的に描いた図である。
【図３】図２のユーザーインターフェースが描かれており、視覚的表示における第１の幾何的オブジェクトが、"屋根"として分類され、構造特性の第１セット及び対応するレイアウト制限に関連付けられる様子を示した図である。
【図４】図３のユーザーインターフェースが描かれており、視覚的表示における第２の幾何的オブジェクトが、"障害物"として分類され、構造特性の第２セット及び対応するレイアウト制限に関連付けられる様子を示した図である。
【図５Ａ】図４のユーザーインターフェースが描かれており、ＰＶモジュールの種類、方向及び開始点を含むレイアウト生成の設計設定のセットの一例を入力する様子を示した図である。
【図５Ｂ】図５Ａのユーザーインターフェースが描かれており、入力（例えば、構造的特性、プロジェクト特性及び設計設定）及びレイアウト規則（例えば、レイアウト制限、環境因子、その地域の建築基準等）に従って、レイアウトエンジンにより、ＰＶモジュールのレイアウトが生成された様子が示されている。
【図６Ａ】ソフトウェアの実施形態を使用して、図５Ｂに示されたような、ＰＶモジュールレイアウトを生成するプロセスを示したフローチャートである。
【図６Ｂ】図５Ａのユーザーインターフェースが描かれており、図６Ａの第１パスのプロセスの一実施形態に従った、ＰＶモジュールレイアウトが屋根の上にタイル状に配置された様子を示した図である。
【図７Ａ】図５Ａのユーザーインターフェースが描かれており、ユーザーが、設置現場内に、１つ以上の近接するサブエリア及び"作業エリア"を形成したところであり、設置現場におけるモジュールの設置場所に対する所有者による設定が幾何的表示に示されている様子を描いた図である。これは、例えば、設置現場が、建物及び未開発の土地の両方を含み、所有者が、モジュールを建物上にのみ配置することに興味がある場合などが想定される。
【図７Ｂ】図７Ａのユーザーインターフェースが描かれており、作業エリア特性、構造特性、レイアウト制限、設計設定及びその他のレイアウト規則に従って、ＰＶモジュールレイアウトが生成された様子を示した図である。
【図８Ａ】図５Ａのユーザーインターフェースが描かれており、ユーザーが生成した２つのアパーチャ、及びその設計設定が規定された様子を示した図である。
【図８Ｂ】図８Ａのユーザーインターフェースが描かれており、各アパーチャに対するアパーチャ設計設定、及び、プロジェクト特性、構造特性、レイアウト制限及びその他のレイアウト規則に従って、ＰＶモジュールレイアウトが生成された様子を示した図である。
【図９Ａ】それぞれが異なるアパーチャ設計設定を有するユーザーが規定した複数のアパーチャに従って、レイアウトエンジンにより形成されてもよいＰＶモジュールレイアウトの形成プロセスを示したフローチャートである。
【図９Ｂ】それぞれが異なるアパーチャ設計設定を有するユーザーが規定した複数のアパーチャに従って、レイアウトエンジンにより形成されてもよいＰＶモジュールレイアウトの形成プロセスを示したフローチャートである。
【図１０Ａ】本明細書の教示に従って、ソフトウェアアプリケーションで配置された設置現場構造及びソーラーコレクタを表すデータの階層構造の一部を概略的に示した図である。
【図１０Ｂ】本明細書の教示に従って、ソフトウェアアプリケーションで配置された現場構造及びソーラーコレクタを表すデータの階層構造の一部を概略的に示した図である。
【図１１】警告、エラー及び契約例外事項を含む例外事項のリスト、及び設計者が例外事項を表現する様々なメカニズムを含むユーザーインターフェースを概略的に示した図である。
【図１２】ユーザー入力及び生成されたレイアウトが認証され、例外事項が生成されてもよいプロセスを示したフローチャートである。
【図１３】図１０Ａのプロジェクト要素の階層を表した図であり、代替構造の特性、設計設定、プロジェクト特性等のユーザーの選択に応答して、ソフトウェアによって形成された、レイアウトの複数のバージョンを部分的に表示するよう拡張された様子を示した図である。
【図１４】プロジェクト設計のバージョンリスト及びバージョンに応じた動作を制御することを含むユーザーインターフェースを概略的に描いた図である。
【図１５】バージョンの要約の一部を概略的に示した図である。
【図１６Ａ】ユーザーが幾何的オブジェクトを分類し、構造特性、プロジェクト特性、レイアウト規則及び設計設定に従って生成されたＰＶモジュールレイアウトが表示された別の例示的ユーザーインターフェースのスクリーンショットが示されている図である。
【図１６Ｂ】ＰＶモジュールのレイアウト及び分類に関連した機能に対するツールバー制御を提供する例示的ユーザーインターフェースを描いたスクリーンショットである。
【図１６Ｃ】ＰＶモジュールのレイアウト及び分類に関連した機能に対するメニュー制御を提供する例示的ユーザーインターフェースを描いたスクリーンショットである。
【図１６Ｄ】構造特性、設計設定及びその他のユーザー入力へのアクセス及び修正のためのパレット制御を提供する例示的ユーザーインターフェースを描いたスクリーンショットである。
【図１６Ｅ】図１０Ａのユーザーインターフェースが描かれており、ユーザー入力（例えば、構造的特性、プロジェクト特性及び設計設定）及びレイアウト規則（例えば、レイアウト制限、環境因子、その地域の建築基準等）に従って、ＰＶモジュールのレイアウトが生成されたユーザーインターフェースを描いたスクリーンショットである。
【発明を実施するための形態】
【０００６】
コンピュータ支援設計（ＣＡＤ）は、何十年にもわたって、商業利用されている。ＣＡＤシステムは、設計情報の形成、編集、表示及び検索を自動化する効率的な方法を提供する。ＣＡＤシステムの能力は、知識集約型のプログラミング技術の利用により向上し、エンジニアリング及び／又は設計規則を形式化及び符号化して、設計プロセスの一部を自動化する、又は、潜在的な設計エラーを検出するべく実行することができる。知識集約型のシステムの一般的な例としては、多くの商用ワードプロセッサに適用されている文法チェック機能が挙げられ、英文法の多くの規則が符号化されて、自動的にテキスト文書に適用されて、潜在的な誤りをハイライトし、正しいアクションを提案する。
【０００７】
本明細書に記載するシステム及び方法は、その土地の状態、工法規則及び建築基準法等の多数の設計制限に従った太陽エネルギーシステム設計の自動レイアウト、評価及び最適化に対する、知識集約型のＣＡＤ技術の適用に関する。好ましい実施形態は、ＡｕｔｏＣＡＤ（登録商標）のような、既存のＣＡＤシステムに対するソフトウェアのカスタマイズを統合したセットとして実装される。または、本明細書に記載されるシステム及び方法は、全く新しいスタンドアローンのソフトウェアプログラムとして実装されてもよい。
【０００８】
本明細書に記載される本発明の好ましい一実施形態では、所定の作業場所における設置に適したソーラーコレクタのレイアウトを設計する方法及びシステムを提供する。実施形態は、様々なデータオブジェクトを生成及び編集し、このようなオブジェクトを、付随する特性及びレイアウト制限を伴う予め規定された"構造"の様々なタイプで分類する。構造の種類又はカテゴリは、（１）壁、屋根及び換気扇等の設置現場の物理的構造、（２）敷地境界、区画の境界、電線の敷設権、洪水が起きる土地、環境を配慮したエリア、特定の地震帯、公共設備の地役権等の設置現場の無形資産又は非物理的構造、並びに（３）太陽エネルギーシステム構成要素及び配置、を含んでもよい。分類の一部として、又は分類に加えて、実施形態は、固有特性又は付随する特性をオブジェクトに対して、生成する、割り当てる又は編集するシステム及び方法を含んでもよい。固有の構造的特性としては、高さ、重さ、コスト等のオブジェクトそのものに固有の特性が含まれる。付随する特性は、どのようのオブジェクトが、その他のオブジェクトとインタラクション（対話）するかの規定を含む。外因性特性の例としては、オブジェクトと別の隣接するオブジェクトとの間の最小距離（セットバック）を確立するセットバック規定が含まれる。
【０００９】
例えば、特定の法域では、敷地境界から３０フィート以内に、構造物を設置することが許可されていない場合がある。一実施形態に係るシステムを使用することにより、ユーザーは、最初に、次のようにして、"敷地境界"構造分類を生成してもよい。ユーザーは、（１）"敷地境界"と名付けた新たな種類の構造分類を形成する、（２）敷地境界の構造分類の視覚的表示として、黒色の点線を設定する、（３）"セットバック"と称される特性を規定し、"敷地境界"構造分類に割り当てる、（４）この構造分類に、例えば、３０フィートといった初期値を割り当てる、（５）特定の設計における利用、又は、あらゆるプロジェクト設計における一般利用に対する構造分類データベース内に、この構造分類規定を格納する。
【００１０】
次に、設計者は、予め規定された構造分類の"敷地境界"を、以下のように使用してもよい。設計者は、（１）設置現場の表示を、実施形態として生成する又は取り込む、（２）設置現場表示において、予め規定された分類である"敷地境界"に、１以上の幾何的要素（例えば、線）を割り当てる、（３）必要に応じて、オブジェクトの"セットバック"の値を、例えば、２０フィートに変更する、（４）"敷地境界"と記されたオブジェクトのセットバック規定に準拠した、ソーラーコレクタのレイアウトを含む、太陽光システム設計を生成するように実施形態に命令する。
【００１１】
ソーラーコレクタレイアウトを生成するプロセスの一部として、本発明の好ましい実施形態は、（１）設計規則を生成する、（２）１以上の太陽エネルギーシステム設計の代替案を生成するべく、上記したオブジェクトに、設計規則を適用する、（３）１以上の設計代替案の配置又は物理的レイアウトの画面表示及び／又は紙表示を生成する、（４）部品点数、最大能力、コスト及びエネルギー生成のような１以上の設計の１以上のバージョンの概要を生成する、（５）ユーザーに柔軟性を提供する、並びに、顧客、設計、法的及び製造者の要求に対処することを確かにするメカニズムとして、ユーザー順守又は修正マニュアルに対する修正、又は設計規則の無効化等のソフトウェア符号化された設計ルールに対する例外を追跡する、及び（６）設計者が、設計代替案及び設計修正案の相対的な利点をリアルタイムで評価する、及び設計最適化を助けることを可能とする、可視化された情報を生成すること、を行うための方法及びシステムを提供する。
【００１２】
好ましい一実施形態に係る方法の動作は、（１）設置現場を表す情報を、知識集約型太陽ＣＡＤシステムに取り込む、又は、ＣＡＤシステムを使用して、設置現場を表す幾何的表現を生成する、（２）分類又はカテゴリ化によって、設置現場を表す関係する幾何的要素のそれぞれを、所定のデータオブジェクト種の１以上のインスタンスとして関連付け、それぞれの特性を調整する、（３）例えば、プロジェクトレイアウトを目的とする設置現場のエリアのような"作業エリア"を指定する、（４）ソーラーコレクタの種類及び設置サイズのような設計設定を選択する、（５）設置現場のデータ表示及びそれに付随する特性に従って、自動的に設計を生成する、（６）１以上の測定基準に従って設計を評価する、（７）設計代替案の生成及び比較を行う、（８）設計修正及び設計代替案の選択による、設計の最適化を行う、及び（９）設計上の例外規定のような、設計例外事項のリストの生成、を含む。
【００１３】
関連付けは、設置現場表示における特定の幾何オブジェクトを分類することによって行われてもよく、例えば、構造物の種類のインスタンスを、"屋根"又は"換気扇"といったように分類してもよい。このような分類は、幾何的オブジェクトを、特定の特性及び、太陽エネルギーシステムの自動設計を実行するのに使用されるレイアウト制限と関連付けるべく行われる。設置現場の特性、レイアウト制限、設計設定、モジュール特性及び制限、性能目標等に関連する更なる設計規則及び特性を、規定してもよい。この符号化された情報の全てが、ツールによって使用され、設計者による設定、プロジェクト制限、工学的慣例、建築基準法等に従った太陽モジュール設置に対する設計が、自動的に生成される。そして、配線図、部品表、説明、規約、概要、監査報告、その他の提出物、又は以下に示す表１に従った出力のような関連情報が生成される。
【００１４】
上記したように、ツールは、レイアウト生成に関して１以上の特定の境界を規定できる能力を設計者に提供することにより、レイアウト生成の制御を提供してもよい。ユーザーは、（例えば、分類されたオブジェクトの特性のような、その他の特性及び規則に整合して）ソーラーコレクタの設置が許される場所の境界に対応する作業領域を１以上規定してもよい。ユーザーは、例えば、ソーラーコレクタモジュールのレイアウトを設置現場の一部、例えば、屋根の南側に面した部分に制限するといったように、作業エリアを使用してもよい。ユーザーはまた、１以上のレイアウトアパーチャ（ａｐｅｒｔｕｒｅ）を規定してもよく、レイアウトアパーチャのそれぞれは、ユーザーが規定した異なる設計設定のセットに準拠すべきレイアウトにおける境界に対応していてもよい。異なる設計設定を有するアパーチャを使用することにより、ユーザーが、例えば、一種類のモジュールを屋根の一領域に配置し、別の種類のモジュールを屋根の別の領域に配置するといったことが可能となる。
【００１５】
ある実施形態では、設計者が、上述したように、構造の分類、レイアウトの生成、そして、レイアウトの修正といったプロセスを経るに従って、設計プロセスに関するメタデータが生成されてもよい。このメタデータは、多くの形式をとってもよく、また、設計者が行った及び行うべき動作についての情報を含んでもよく、監督者、共同設計者及びダウンストリームのユーザー、及び設計の受取人にとって有用な設計情報を含んでもよい。
【００１６】
ある実施形態では、このメタデータの一部又は全てが、設計者に、ソフトウェアにおける符号化された規則に対する例外といった形式で表示されるユーザーインターフェースが提供されてもよい。規則は、顧客の要求、国の法律及び規整、工学的制約、ソーラーコレクタ製造ガイドライン等から生成されていてもよい。例外としては、プロジェクト作業エリアのロケーションのような特性情報が提供できない場合が含まれる。設計者は、この例外の情報を、様々な方法でやり取りしてもよく、例えば、規則を適用することで、例外リストから項目を取り除く、又は、規定の適用を無効化するといった方法でやり取りしてもよい。メタデータの一部又は全てを、共通のストレージ又は参照によって、設計と関連付けてもよい。その後、ダウンストリームユーザー及び自動化システムを含む設計の処理者が、情報にアクセスしてもよい。情報は、また、要約、エクスポート、暗号化、されてもよく、また、システムによって演算されてもよい。例外のリストは、ユーザーにとっての"ＴｏＤｏ（やるべきことの）リスト"として機能してもよく（ユーザーインターフェースにおいても同様に称されていてもよい）、ソフトウェア規則が対処されるシーケンスと同時に、確かにソフトウェア規則が対処されることを確かにする、ユーザーに柔軟性を与える。例外、及び、それらがどのように扱われたかの情報は、後の再検討のために、履歴として維持することができ、契約書が、通常でない又は非標準選択肢を反映したものであることを確かめる一助となる。
【００１７】
ある実施形態では、特定の設置現場に対して、ソーラーコレクタレイアウト設計の複数のバージョンを見る、生成する及び操作するためのシステム及びユーザーインターフェースを提供してもよい。複数のバージョンの使用により、例えば、設計者が、入力（例えば、設計設定及び／又は特徴、又はプロジェクト特性）を素早く且つ容易に変更することができ、同じプロジェクトに対する代替設計選択肢（例えば、様々な種類のＰＶモジュールを使用することによるコストへの影響）に対応する生成された出力（例えば、代替レイアウト案、コスト、性能データ）を見ることができる。複数のバージョンを提供することにより、設計者は、ユーザー入力における変更に基づいて異なるレイアウトを迅速にモデル化でき、またその結果を評価することが可能となる。ある実施形態では、設計者は、一のバージョンから別のバージョンへと迅速に移動することができ、また、別の実施系形態では、設計者が、１つのアクションで複数のバージョンに影響を与えることを可能としてもよい。複数のバージョンは、複数の要素、特性又は設計規則の1以上のセットを共有してもよく、このようにすることにより、一のバージョンに適用された変化を、関連する複数のバージョンに適用可能としてもよい。例えば、新たに発見された現場の構造を追加するといったような、設置現場に一般的な変更を行う場合、複数のバージョンについても同様な変更を反映させてもよい。複数のバージョンは、例えば、１つのファイル又は複合ファイルに情報を位置させることによって、情報を共有してもよい。
【００１８】
［１．序論］
本明細書に記載する原理は、一般的な太陽エネルギー収集設備に適用可能である。パネル、吸収体及び反射体といった様々な種類の太陽エネルギー収集器、及び、太陽電池（ＰＶ）モジュール、太陽熱吸収装置、集光型太陽熱発電（ＣＳＰ）等のその他のエネルギー変換技術が、使用されてもよい。ソーラーコレクタは、そのまま取り付けられてもよいし、又は、様々な種類の搭載システムに配置されてもよい。搭載システムとしては、タイル状システム、固定システム及び追跡システムが含まれる。システムは、公共の電力設備にオングリッド接続されるように設計される、及び／又はオフグリッドシステムに接続させるように設計されていてもよい。ソーラーコレクタ及び搭載システムは、地面、屋根の上、壁、駐車場の建物等に、様々な形態で取り付けられてもよい。説明を容易にするため、本明細書では、大部分をＰＶモジュールの設置に関連して説明している。しかしながら、実施形態は、上述したように、ソーラーコレクタ全般に適用可能である。
【００１９】
ＰＶ設備の設計タスクには、一般的に、簡単ではない共依存の複数のプロセスが含まれる。このようなプロセスとしては、例えば、（１）入手可能性、コスト、効率、電力条件等に基いて、特定のＰＶモジュールを選択する、（２）設置現場におけるＰＶモジュールの配置（レイアウト）を生成する、（３）設置したＰＶモジュールに対する配線図（ルーティング図）を生成する、（４）複雑なプロジェクト固有の入力に基いて、電力生成、電力変換効率等のプロジェクトの生産能力を見積もる、（５）プロジェクトの部品表（ＢＯＭ）、契約書等のダウンストリームにおける書類を作成する、等が含まれる。無論、上記の全てが、地方の規制、国の法律等に沿って実行されなければならない。大規模太陽光プロジェクトにおいて実行される典型的な段階のシーケンスが、表２に示されている。
【００２０】
設備のサイズが大きくなればなるほど、例えば、モジュールの数が増えれば増えるほど、上記のプロセスを実行する難しさが増加する。例えば、所定の行に１つのモジュールを追加するといったような、表向きは些細な変更であっても、配線接続形態及び／又はその他のモジュールの配置に対して大きな影響を与える場合があり、したがって、生成されるシステム設計及びシステムの出力（出力電力等）に対しても大きな影響がある。このような複雑性が存在することから、モジュールの再配置、追加又は除去を含むレイアウトの最適化又は修正は、難しく、特に、大規模なプロジェクトでは、試行錯誤のプロセスと似通ったものになってしまう。一般的に、１０〜２０週かけてプロジェクト設計が終了する、又は、何ヶ月かを経て契約を締結する時には、レイアウトに元々使用することを考えていた構成要素が、市場ではすでに手に入らなくなってしまい、大幅な設計変更が必要になってしまうかもしれない。
【００２１】
設置現場の設計過程における、退屈な及び複雑な作業は、自動化ツールを使用することにより、削減することができる。具体的には、ソフトウェア又はその他のコンピュータに実装されるツールが本明細書に記載され、これらは、工学的慣例、設計者の好み及び設置現場の状態に対応する符号化された情報に基づいて、設置現場の設計を自動的に生成する。このようなツールの一部は、例えば、ＡｕｔｏＣＡＤ．ＤＷＧファイルのような、設置現場のＣＡＤ表示を、開始点として使用する。このファイルは、設置現場のベクトル又はビットマップ表示を含んでもよく、典型的には、線、ポリライン、曲線、正方形、矩形、スプライン、記号、多角形、その他の二次元又は三次元の形、面、立体、画像データ等の幾何的オブジェクトの集合によって、表示が行われる。この表示では、一般的に、幾何的オブジェクトには意味情報がほとんど又は全く添付されておらず、この表現における情報は、設置現場の物理的特徴に対応する形状及び大きさに限定されてもよい。例えば、換気扇を有する屋根の２Ｄ平面図表示は、大きな矩形（屋根）を形成する４つの線のセットと、小さな正方形（換気扇）を形成する４つの線のセットとによって構成されており、小さな正方形が、大きな矩形に内包された表示となっている。ＣＡＤの従来のツール、及びある実施形態では、ユーザーが、このような、幾何的オブジジェクトの初期表示を生成することができる機能を提供してもよい。これに替えて、ユーザーは、コンピュータファイルのような格納場所から、幾何的オブジジェクトの初期表示を取り込んでもよい。
【００２２】
ある実施形態では、表示で使用されるオブジェクトを分類する（例えば、カテゴリ化又はタグ付け）メカニズムが提供されてもよく、オブジェクトを、構造種類のような、モジュールレイアウト生成に関係する意味情報と関連付けてもよい。例えば、上記の線のセットを、ユーザーは、事前に存在する構造物の種類である"屋根"のインスタンスとして、分類してもよい。システムは、オブジェクトを、屋根とモジュールレイアウトとの間の関係に対応する意味情報のセットと関連付けるのに、この分類を利用してもよい。この情報は、屋根に固有の物理的特性、例えば、"ピッチ＝１７度"及び"高さ＝３０．０フィート"、及び／又は、屋根に付帯する特性（例えば、"エッジセットバック＝１．０フット"）と、関連付けられていてもよい。このような特性は、多くの場合、ユーザーによって編集可能であり、同じ汎用型の異なるインスタンスによって変化してもよく、また、司法域（例えば、都市計画法など）によって変化してもよい。構造分類のリストの例が、表３に示されており、また、構造特性のリストの例が、表４に示されている。
【００２３】
同様に、ユーザーが、設置現場の表示における別のオブジェクト（又は複数のオブジェクトのセット）を、構造種類"換気扇"のインスタンスとして分類してもよい。その後で、システムは、オブジェクトを、"高さ＝３フィート"といったように、換気扇に対応する構造特性と関連付ける。ある実施形態では、事実上、無限数のオブジェクトを、様々な特性を有する構造の様々な種類で分類してもよい。これら様々な構造の幾つかについて、構造特性を、カテゴリ的に予め定めてもよく（特定の分類又は種類のインスタンスそれぞれに対して、適用可能であって且つ不変である）、その他の構造特性は、単なる初期値、インスタンス固有の値であってもよい。ユーザーは、高さのような数多くの構造特性を、必要に応じて及び／又は適宜調整してもよく、全体的な構造種類に対応する構造特性のような、その他の構造特性については、ユーザーが編集できる、又はできないようにしてもよい。このように、分類されたオブジェクトは、その他の分類されたオブジェクトと共通の及び／又は固有の構造特性を有してもよい。
【００２４】
特定のオブジェクトに関連付けられた意味情報は、特定の構造分類の全てのインスタンスに対して通常は不変である、一般化された設計規則に対応していてもよい。例えば、屋根として分類されるオブジェクトは、システムよって、例えば、"コレクタレイアウト可能＝ｙｅｓ"といったように、適切な構造レイアウト制限と関連付けられてもよく、どのようにモジュールを屋根の上又は周辺に配置するかに関するその他の設計規則と関連付けられてもよい。以下に説明するように、ある実施形態では、設計規則は、少なくともソフトウェアの最初の使用の際に、無効化されてもよいが、規則の必要条件からの変更を追跡するために、例外事項のリストはそのまま維持される。
【００２５】
このようにして、ユーザーがアクションを分類することにより、オブジェクトの元の単純な幾何的表示に、例えば、より高い階層の追加の構造的情報を割り当てて、自動化設計システムに使用させてもよい。加えて、システムは、オブジェクトが、構造のインスタンスとして自動的に分類され、構造特性及び設計特性に値が割り当てられるようなメカニズムを提供してもよい。形状再設定アルゴリズム、学習アルゴリズム、又はその他のエキスパートシステムを使用して、オブジェクトの分類及び値の割り当てを実行してもよい。また、幾何的オブジェクトを、前処理段階で補正、例えば修正して、分類、構造割り当て又はレイアウト処理におけるより良い状態又は位置にオブジェクトを配置してもよい。エンジンは、例えば、試作分類といった設計者からの入力を、オブジェクト修正の基本として使用してもよい。例えば、設計者が、４つの線を"屋根"として分類することを試みているが、４つの線が完全に閉じた形を形成しない場合には、ソフトウェア修正エンジンが、線の終点が共有されるように、適切にオブジェクトを修正することを試みてもよい。
【００２６】
ある実施形態では、分類されたオブジェクト、その分類、例えば、構造特性のセットのような符号化された情報、及び以下に記載するようなその他の情報を使用するレイアウトエンジンソフトウェアモジュールのような、レイアウト構成要素を提供して、モジュール設置設計を生成してもよい。例えば、"屋根"として分類されたオブジェクトが、"レイアウト可能＝ｙｅｓ"というレイアウト規則と関連付けられていてもよく、それにより、レイアウトエンジンは、"屋根"として印を付けられ分類されたオブジェクト間の境界領域に、ソーラーコレクタを設置することを考えてもよい。同様に、換気扇が、分類又は特定のインスタンスとして、レイアウト規則"レイアウト可能＝ｎｏ"と関連付けられていてもよく、したがって、レイアウトエンジンは、"換気扇"と印が付けられているオブジェクトに対応する領域には、モジュールを配置できないと知ることができる。屋根のように、そこにモジュールの配置が許されるオブジェクトには、明示的に"作業エリア"と称して、モジュールが配置されてもよい場所（その他のレイアウト規則と矛盾せずに）であることを示してもよく、この場合、ユーザーが個別に、作業エリアを定義する必要はない。
【００２７】
レイアウトプロセスに対するより大きな制御を有効にするメカニズムを、ユーザーに提供してもよい。ユーザーは、例えば、明示的に、１以上のユーザー生成作業領域を定義することによって、モジュール配置が許可される境界の範囲を狭めてもよい。ユーザー生成作業領域は、ユーザーによって生成された幾何的オブジェクトであってもよく、例えば、"レイアウト可能＝ｙｅｓ"を含むレイアウト規則の特定のセットと関連付けられていてもよい。レイアウトエンジンソフトウェアモジュールは、明示的な、例えばユーザーが生成した作業エリア、明示的な作業エリアの一方、又は両方内に含まれるロケーションにのみ、ソーラーコレクタを配置することを考えるように設定されてもよい。これは、例えば、設計者が、屋根の一部に制限して、ソーラーコレクタを配置することを望んでいる場合に有用であり、屋根の所望の部分にのみ作業エリアを作成すればよい。
【００２８】
ユーザーはまた、モジュールの種類又はソーラーコレクタレイアウトの方位のような様々な設計設定を設定可能であってもよく、さらに、表示の異なるエリアに、異なる選択を行うことが可能であってもよい。表５には、設計設定のサンプルのリストが示されている。例えば、ユーザーは、設計設定の特定のセットが適用される境界を、例えば、１以上のアパーチャを規定することにより、規定できるようにしてもよい。アパーチャ（ａｐｅｒｔｕｒｅ）は、ユーザーが生成した幾何的オブジェクトによって表される境界又は外枠である。システムは、例えば、"ＰＶモジュール＝ＳＤ３０５"及び／又は"傾き＝４５度"といった設計設定を含む設計設定のセットと、アパーチャとを関連付けてもよい。レイアウトエンジンは、割り当てられたアパーチャの設計設定、関連する構造特性、レイアウト規則、及びその他の適用可能な特性及び設計規則に従った所定のアパーチャの境界内に、例えば、ＰＶモジュールであるソーラーコレクタを配置するように設定されていてもよい。幾つかのケースでは、ユーザーは、１以上のアパーチャを規定してもよく、レイアウトエンジンは、設置現場の様々な領域において、レイアウトの設計設定の異なるセットを使用してもよい。設計者が、１種類のモジュール、例えば、ＳＤ３０５ｓを、屋根のあるエリアにおいて、南北の方向に向けて配置することを望んでおり、また、別のモジュール、例えば、ＳＰ２２５ｓを、屋根の別のエリアにおいて、東西に向けて配置することを望んでいる場合には、別々のアパーチャを使用することが有用である。別の例として、作業エリアの異なる領域におけるモジュールの行間を、異なる間隔に設定する目的で、複数のアパーチャを不均一にレイアウトしてもよい。また、ある実施形態では、作業領域内（例えば、作業領域内のみ）のソーラーコレクタの設置が許可された領域内にソーラーコレクタのレイアウトが生成されてもよく、また、ソーラーコレクタの配置に関するアパーチャの設計設定、オブジェクト及び構造の特性、及びレイアウト規則又はこれに関連付けられた制限に従ったレイアウトアパーチャ内に、ソーラーコレクタのレイアウトが生成されてもよい。
【００２９】
ある例では、ユーザーによって規定されたアパーチャ同士が重なってしまう、又は、相関してしまう場合が発生する。このような場合は、アパーチャの競合を解消する規則が利用されてもよい。例えば、競合解消ルールでは、アパーチャ２よりも、アパーチャ１を優先させるよう規定してもよい。レイアウトエンジンは、アパーチャ２に従って設置されるモジュールよりも、アパーチャ１に従って設置されるモジュールを優先させる。これは、設計者が規定したアパーチャの境界が重なっている場合、又は、設計者が、例えば、ＰＶモジュールであるソーラーコレクタを、凹形状の屋根の両側（すなわち、逆Ｖ字型又はＶ字型の屋根の対向する壁）に配置したいと望んでいる場合には、有用である。コレクタ及びその搭載構造は、高さがあるため、２つの屋根部分の交差点（すなわち、Ｖ字の底部）に、モジュール配置する際には、競合が発生すると考えられる。屋根部分の１つが、他方よりも太陽光を受ける場合には、設計者は、アパーチャを、太陽光が照射される部分及び陰になる部分に設定したいと考える。ユーザーは、競合が発生した場合には、２つのアパーチャに対して優先順位を付けることが可能であってもよく、レイアウトエンジンは、陰になるアパーチャの設計設定よりも、太陽光があたるアパーチャ分の設計設定を優先させて、それに従ってモジュールを配置する。このようにすることにより、この設置におけるモジュール平均の電力生成を、全体として増加させることが可能になる。例えば、ユーザーがアパーチャを規定するシーケンスに従って、初期設定の優先順位をアパーチャに割り当ててもよく、又は明示的に優先順位を設定してもよい。
【００３０】
レイアウトを含む設計の結果は、表示され、保存され、印刷され、送信され、又は利用されてもよい。部品表、レンダリング、財務分析、契約、契約条件、エネルギー予測、コスト分析、部品リスト、シミュレーション等の、レイアウトに関する追加情報が、符号化された情報及び生成されたレイアウトに基づいて生成されてもよい。
【００３１】
以下の動作を実行するソフトウェア制御は、ＣＡＤソフトウェアの一部として含まれていてもよい。これに替えて又はこれに追加して、専用のエンジン、ライブラリ又はプラグインを、スタートアップで又はオンディマンドで、ＣＡＤソフトウェアにロードしてもよい。これに替えて、専用の又は新しいソフトウェアプログラムを、本発明の実施形態の実装専用に書いてもよい。ＣＡＤソフトウェア環境においてオブジェクトの生成、選択及び操作に対する多くのメカニズムが、当技術分野では知られており、このようなメカニズムとしては、例えば、クリック選択、ドラッグ選択、シート選択、アイコン上でのクリック及び右クリック、ツールバー、ポップアップ、オブジェクト等が含まれる。Ｊｏｅ Ｓｕｔｐｈｉｎ著、「ＡｕｔｏＣＡＤ ２００６ ＶＢＡ：Ａ Ｐｒｏｇｒａｍｍｅｒ'ｓ Ｒｅｆｅｒｅｎｃｅ」、１０１プロダクション（２００５）、ＩＳＢＮ９７８１５９０５９５７９４では、このような方法を数多く開示しており、その内容は、参照により、本明細書に組み込まれる。
【００３２】
［２．システム動作及びユーザーインターフェース］
図１は、ソーラーコレクタレイアウトが設計される設置現場を、概略的に示した図である。簡略化のため、本明細書で説明される実施形態は、ソーラーコレクタの例として、太陽電池（ＰＶ）モジュールを使用している。ＰＶモジュールは、建物１００の屋根１０１の上に配置される。屋根１０１は、換気扇１０２、配線管１０３、通路、配管１０５、大型冷暖房空調設備（ＨＶＡＣ）１０４、天窓、エレベータ機械、階段等の一連の物理的構造物を有すると考えられる。これらを、幾何学的に、屋根１０１の上に投影させる（上部から下部を見る鳥瞰図として）と、構造物は、屋根に対して、立体的／二次元的（例えば、換気扇１０２）に、又は線形的／一次元的（例えば、配線管１０３）に表されてもよい。所定の構造は、例えば、換気扇は矩形の伏図といったように、屋根の上に規則的な伏図として表されてもよく、これに替えて、構造を不規則な伏図で表してもよい。屋根の構造としては、無形のもの、例えば、風の強い又は上昇気流が存在するエリア１０６を含んでもよい。屋根１０１及び屋根に設けられている構造のそれぞれは、ソーラーコレクタ設置設計に関連する特徴のセットを有してもよい。例えば、ＰＶモジュールは、通常、換気扇の上、又は、換気扇１０２から所定のセットバック内には配置されず、セットバックは、規則、顧客の規定事項又は設計選択肢によって規定されていてもよい。同様に、ＰＶモジュールは、通常、風速が大きいエリア１０６内、又は、屋根１０１の角又は縁から特定の距離の範囲内には配置されない。
【００３３】
屋根の構造物はまた、屋根１０１上に配置されるＰＶモジュールの相対的な性能を決定してもよい。例えば、屋根１０１が、多くの場合、南側（１０５で示されている）からの太陽光に最も晒されると仮定すると、（大型冷暖房空調設備（ＨＶＡＣ）１０４によって、少なくとも部分的に太陽光が邪魔される）位置Ｂに配置されるＰＶモジュールよりも、位置Ａに配置されるＰＶモジュールの方が、平均してより多くの電力を生成すると考えられる。
【００３４】
図２は、コンピュータ支援設計（ＣＡＤ）システム２００のユーザーインターフェースの一例で表示された、図１の設置現場を示した図である。ＣＡＤシステム２００は、設置現場の２Ｄ又は３Ｄの視覚的表示を含んでもよい。典型的な表示では、設置現場の構造物についての３次元情報を含む。簡便のため、実施形態は、２次元の平面図２０４を参照して説明される。視覚的表示は、線、線分、ポリライン、円弧、曲線、縁、正方形、矩形、多角形等の幾何的実体により構成されてもよい。これらの幾何的実体は、境界で囲まれたエリアを規定するよう閉じていてもよいし、開いていてもよいし、自交していてもよいし、平面的であっても非平面的であってもよいし、孔、複雑な表面及び幾何学的トポグラフィーを含んでもよい。これらの幾何的オブジェクトは、物理的な設置現場の、物理的構造又は非物理的構造に対応していてもよい。例えば、表示２０４には２つの多角形が示しされており、それぞれ、図１の換気扇構造１０２に対応する参照番号２０２で示された有界エリアを規定している。線分及び曲線２０３のセットは、図１の配線管１０３の構造に対応している。視覚的表示は、最初に、ＡｕｔｏＣＡＤ．ＤＷＧといった特定のファイル形式を使用して、ＣＡＤソフトウェアに読み込まれてもよい。これに替えて、視覚的表示を、標準的なＣＡＤ描画ツールを使用して、ＣＡＤソフトウェアによって生成してもよい。ＣＡＤソフトウェアにおける視覚的表示２０４は、設置現場の一部のみを表示してもよいし、設置現場を超えた領域まで表示してもよい。
【００３５】
この時点では、ＣＡＤソフトウェアにおける設置現場の表示には、非常に少ない意味情報しか添付されていなくてもよい。例えば、純粋な形状以外、有界エリア２０２を形成している４つの線分は、意味情報と関連付けられていなくてもよい、又は、対応する換気扇構造１０２に関する意味のみを有していてもよい。ＰＶモジュール設計に関する換気扇構造の特徴、例えば、典型的なセットバック、又は一日又は一年のうちの様々な時間に形成される影（例えば、形成されると予測される影）といった特性は、この表示に組み込まれていなくてもよい。同様に、屋根の外形に対応する線２０１は、ＣＡＤソフトウェアにおいて、設置現場の屋根１０１と、意味的に関連付けられていなくてもよい。むしろ、ＣＡＤソフトウェアの観点からすると、視覚的表示は、単純に、大きさの情報のみを有する幾何的オブジェクトの集合であり、互いに、外部の設置現場、又はソーラーコレクタ設置設計と関連する意味情報が取り除かれたものであると考えられる。これに替えて、視覚的表示は、例えば、ＧＰＳデータのような意味情報が、オブジェクトに付加されていてもよい。このデータは、プロセスにおける後の段階で使用されてもよい。
【００３６】
図３は、視覚的表示及び視覚的表示内の幾何的オブジェクトに、意味情報が付与されるプロセスを示した図である。実施形態の分類要素は、"データ処理能力のない"幾何的オブジェクト、例えば、大きさの情報しか有していないオブジェクトを、自動的に又はユーザーによって、構造の特定の種類のインスタンスとして分類することにより、この分類を実行する。構造の種類のインスタンスとしての分類の一部として、オブジェクトは、追加の構造特性のセットと関連付けられてもよく、このセットには、ソーラーコレクタ設置設計に関連する高さ、セットバック等の構造特性が含まれていてもよい。システムは、分類及び特性を使用して、オブジェクトを、分類されたオブジェクトとその他のオブジェクトとの間のインタラクションの可能性、及び生成されたソーラーコレクタ設計に対する影響に対応するレイアウト規則と関連付けてもよい。これらの構造的特性は、レイアウトエンジンがレイアウト規則をオブジェクトに適用するといったように、ソフトウェアによって認識され、利用され及び操作されてもよい。
【００３７】
例えば、ポリライン２０１は、例えば、"屋根"のような、構造の１種類と関連付けられてもよい。この分類は、屋根の上へのＰＶモジュールの設置に関するレイアウト規則に関係していてもよい。レイアウトエンジンによってこのような規則が呼び出されると、特定の屋根の構造的特性（例えば、地面からの垂直方向の高さ及び屋根のピッチ）に作用してもよい。オブジェクトに関連付けられた特性は、その他のオブジェクト特性との対応又は相関関係によって決定されてもよい。例えば、屋根に対する換気扇の高さ（これは、換気扇による影の屋根に対する影響を計算する時に有用な情報である）は、換気扇の絶対的な最大高度、及び換気扇が位置する点における屋根の絶対的な高さ（これは、屋根の特性である高さ及びピッチから自明的に決定することができる）を示す構造特性から、決定することができる。このようにして、オブジェクト分類及び構造の特性を含む符号化された情報は、設置現場の物理的構造の特徴の完全な又は部分的な仕様を形成して（又は関連付けられて）いてもよく、仕様は、ＰＶモジュールのレイアウト設計と関係している。具体的には、ソーラーコレクタレイアウト設計と関連する物理的構造の特徴は、その物理的構造内又は周辺にソーラーコレクタを自動的に配置するための、情報のセットの少なくとも一部を含む又は構成する。予め規定される構造分類及びクラスは、物理的特徴及び非物理的特徴を含んでもよく、例えば、敷地境界、不動産区画境界、建築規制指定、電線の敷設権、洪水が起きる土地、環境を配慮したエリア、又は特定の地震帯のような特徴を含んでもよい。
【００３８】
特に、幾何的オブジェクトの中には、ＰＶモジュール設置の許可を提供する構造種類のインスタンスとして分類されるものが存在してもよく、例えば、屋根として分類される幾何的オブジェクトは、屋根の表面にＰＶモジュールを配置することを許可するレイアウト規則と関連付けられていてもよい。このように、"屋根"としてオブジェクトを分類することは、間接的に、そのオブジェクトを作業エリアとして扱うことにつながる場合がある。同様に、オブジェクトの中には、ＰＶモジュールの配置を通常は許可しない又は禁止する構造として分類されるもの存在し、例えば、池又は空調ユニットとして分類された幾何的オブジェクトは、障害物又は障害物の予め規定された境界内、例えば、距離内に、ＰＶモジュールを配置することを通常は許可しないレイアウト規則と関連付けられていてもよい。ＰＶモジュールの配置に対するその他のレイアウト規則を規定してもよく、建築規制及び建築法、風条件、温度条件、及びモジュール配置に対する電力及び熱生成制限の適用を実体化する制限を、所与の構造に対して及びその付近に対して規定してもよい。
【００３９】
構造の所定の種類と関連付けられる構造特性の形式及び内容は、対応するオブジェクトの形成の前に形成されてもよいし、前もって存在するものであってもよい。物理的構造の分類、及びそれに対応する符号化された情報は、予め規定しておいてもよい。例えば、屋根又はその他の表面に対応する特性及び初期値のセット、及び、それらに適用される設計規則は、データベース及び／又は分類規定の一部に格納されていてもよい。（表３〜４参照。）特定のオブジェクトが屋根として分類されると、分類規定がインスタンス化されて、そのオブジェクトと関連付けられてもよい。無論、ソフトウェアは、更なる構造の種類を、設計者が規定することができ、分類に使用することができるようなメカニズムを提供してもよい。所定の種類のオブジェクトに対して、特性及びレイアウト制限の初期値を含む初期値又は予め存在する符号化情報が、設計者又は管理者によって修正されてもよい。符号化された情報の修正は、レイアウト生成の前に行ってもよいし、及び／又は、レイアウト生成の後に行ってもよい。レイアウトが生成された後に行われる構造特性のような特定の符号化された情報の修正は、データの新たなセットに基づくレイアウトの自動再生成をトリガしてもよい。
【００４０】
オブジェクトが分類され、修正される、又は、特性と関連付けられるメカニズム又はユーザーインターフェースの制御は、様々であってよい。例えば、図３に示すように、ユーザーは、屋根１０１に対応するポリライン２０１を選択してもよい。そして、ユーザーは、"屋根"又は"分類・・・"と記載されたツールバー又はアイコンをクリックする、又は同様のコマンドをメニューから選択してもよい。ユーザーは、また、ポリライン２０１上でポインタツールを使用して右クリックし、ポリライン２０１を選択すると同時に、屋根と分類することを可能とするコンテキストメニュー３１０を開いてもよい。選択及び分類の間に、この選択又は分類を示すように、オブジェクトの表示が変更されてもよい。例えば、色を変更してもよく、線の太さ又はスタイルを、変更してもよい（本例では、ポリライン２０１は点線で示されている）。ユーザーインターフェースにおけるオブジェクトに対するアクションの実行に関する制御には多くの種類が存在することは、当分野では周知である。複数のオブジェクトを、同じ種類の構造、例えば、"屋根"のインスタンスとして分類してもよく、この場合には、システムは、複数の屋根を含む設置現場に対するレイアウトを生成する。特徴の異なる種類又はサブ種類を、様々に表現してもよく、例えば、ユーザーインターフェースにおいて、別々の描画層に配置してもよいし、及び／又は、異なる色又は線の太さで表してもよい。また、オブジェクトの分類を解除する制御を提供してもよい。
【００４１】
無効な又は不完全な設置現場の幾何的形状を自動的に修正するメカニズムを採用してもよい。例えば、一実施形態において、設計規則が、"屋根"は、閉じた多角形で表示されるべきであると規定しているとする。設置現場表示における屋根に対応する幾何的情報が、４つの線分で構成されており、共通の終点が近接してはいるが、一致していない（すなわち、閉じた形状をしていない）と仮定する。この幾何的表示では、線分の終点を一致させない限り、処理エラーとなる又は不正確な結果を生成すると考えられる。一実施形態において、分類している間に、前処理幾何的要素に対して、メカニズムが提供され、例えば、終点が一致していない線分を、終点が共有される線分へと互いに近づけるように、特定の角度内に収めるような変換が行われる。非意味的幾何的データの修正のための幾何的アルゴリズムが存在する。
【００４２】
ソフトウェアはまた、ユーザーが、所与のオブジェクトと関連付けられた編集可能な特性のような、符号化された情報の一部又は全てを見る及び／又は修正することが可能となる制御を提供してもよい。例えば、ユーザーインターフェースは、そのオブジェクトと関連付けられた構造特性の一部又は全ての表現を表示するための特性ロールアップ、ツールバー又はパレット３１１を含んでもよい。屋根に対する構造特性の一部、例えば、垂直方向高さ３１２は、ユーザーが調整可能であってもよい。屋根の、例えば、平方メートル単位の生成された面積、といった、ＰＶモジュールの設置に使用されるその他の構造特性を、ソフトウェアによって計算してもよく、例えば、レイアウト制限、構造特性等とのインタラクションによって決定される。所与のオブジェクトに適用可能なレイアウト規則の表示のようなその他の情報、例えば、特定のオブジェクトが、ＰＶモジュールの設置に好適であるといった表示は、ユーザーに表示又は可視化されなくてもよい。ユーザーインターフェースにおいて、オブジェクトの特性を修正するための制御には様々な種類が存在する。
【００４３】
ある実施形態では、構造分類の階層構造を含んでもよい。例えば、構造は、設置可能表面、立体障害物、線形障害物３つのカテゴリに分けられてもよい。各カテゴリは、構造の複数の種類を含んでもよい。例えば、設置可能表面としては、屋根、野原、壁等を含んでもよい。立体障害物としては、換気扇、柱、冷暖房空調設備（ＨＶＡＣ）、くぼみ、木、屋根の昇降口、アンテナ、衛星アンテナ、階段、排水管、塔屋、屋根の窓、天窓、梁、観察点、通気孔、バルブ等を含めてもよい。線形状の障害物としては、通路、機器、延長ジョイント、壁、配線管、パイプ等が含まれる。構造物の種類それぞれは、サブ種類を含んでもよく、例えば、アンテナ障害物は、サブ種類として、アウトラインアンテナ、ポイントアンテナ等を含んでもよく、配線管は、サブ種類として、電気配線、水配管、支持配線、垂直配線、導水管等を含んでもよい。障害物は、その固有の幾何的形状（例えば、階段）に応じて、立体又は線形のいずれかに分類されてもよい。
【００４４】
図４は、第２障害物が分類されて、意味的情報と関連付けられるプロセスを示した図である。ここでは、屋根の上に設けられている換気扇に対応する複数の線のセット又はポリライン２０２は、立体障害物として分類されている。すなわち、コンテキストメニュー３１０及び特性パレット３１１を使用して、"ＨＶＡＣユニット"のサブ種類"換気扇"と分類される。ここで、点線は、ユーザーが、この特定のオブジェクトを選択したことを表す視覚的手掛かりとして使用されている。特性パレット３１１は、同様な構造特性のサンプルを示しており、また、換気扇についての現在の値、例えば、高さ、セットバック、サブ種類等も示している。パレット３１１は、図４において、オブジェクト２０２が構造カテゴリ（又は分類）の立体障害物３１５、種類ＨＶＡＣ３１７、及びサブ種類換気扇３１９に分類されたことを示している。このようにして、物理的設置現場に対応する複数のオブジェクトが分類されてもよい。ある配置では、上述したようなユーザーが手動でオブジェクトを分類することを必要とするのではなく、システムが、例えば、設置現場の表示の帰納的分析、又は利用可能なメタデータに基づいて、最初に自動的にオブジェクトを分類するのを試みてもよく、例えば、予め生成されたＣＡＤ図面の層において"天窓"と名付けられたオブジェクトを、自動的に"天窓"として分類してもよい。システムはその後で、ユーザーによる修正及び認証を許可又は要求してもよい。システムは、ＧＰＳデータのような幾何的オブジェクトに関する情報を使用して、自動的にオブジェクトを分類してもよい。
【００４５】
全ての特性を、表示における特定の構造又は幾何的オブジェクトと関連付ける必要はない。例えば、ソフトウェアは、設置現場ロケーション（郵便番号）、設置現場の方位（北向きの矢印）、縮尺、測定の単位、国、顧客情報（顧客の名前、住所等）といった、プロジェクト全体の特性情報を利用及び設定可能としてもよい。プロジェクト特性情報は、連絡先、法的資格、財務状況、電気利用情報、電気料金、及びエネルギー消費量の情報を含む顧客特性情報を含み、予め設定されていてもよい。その他のプロジェクトの特性情報として、土壌の種類、気候条件、設計温度、設計地震負荷、動作特徴、負荷限界、電気配線条件等が含まれてもよい。この情報は、設計者によって手動で入力されてもよいし、顧客のアカウント情報を保持するのに使用される顧客関係管理（ＣＲＭ）システムのような外部のデータソースとつながるリンクを通じて、この情報がアクセスされてもよい。表６には、プロジェクトの特性情報のリストの例が示されている。例えば、全体のレイアウト規則といったプロジェクト設計の規則は、特定の構造物とは独立して作用してもよく、例えば、公共電力設備にＰＶシステムを接続する際の規制である電力接続規則等が挙げられる。予め規定されるプロジェクト設計規則は、電気設備基準、敷地セットバック必要条件、安全要求事項、配線必要条件、設計規則又は成功事例、ヒューズ設定条件等の使用を規定してもよい。公共電気グリッド、私有電気グリッド又はその他の規格に接続されるレイアウトを生成する際に、このような規制的規則を採用してもよい。
【００４６】
モジュールの種類は、例えば、モジュール特性、モジュール間の間隔、電圧、配線条件、重さ等の特定のモジュール固有の情報と関連付けられていることから、設計で使用されるモジュールの種類は、レイアウトエンジンがどのように動作するかについても影響を与える。モジュール固有の情報の一部は、モジュールの種類、搭載システム、インバータタの種類等の特定の種類と関連付けられていてもよい。様々なモジュール設計規則を、モジュール毎に、モジュールの列毎に、及び／又はモジュール‐サブアレイベースで、適用してもよい。例えば、特定のモジュールは、最小のモジュール間距離及び動作温度、又は特定の配線構造を要求してもよく、例えば、１列（ストリング）あたりのモジュールの数が、温度の関数であってもよい。表７には、モジュール特性のリストの例が示されている。
【００４７】
図５Ａに示すように、使用されるモジュール５０２の種類及び／又は搭載システムの種類、モジュールの行及び列を配置する方位５０３、タイル状に配置する開始点５０４（又は原点）、インバータの種類（選択肢が損愛する場合）等を含む設計設定情報を、規定してもよい。また、動作全体特性、設計設定、及び／又はモジュール特性の１以上を、ユーザーが修正可能であってもよい。例えば、真北の方角に対するモジュールの方位（角度）は、５０３に示すように、適当な制御部に、数字で入力してもよい。これに替えて、方位を、屋根の外縁のような既存の線を選択し、モジュールの方位が、選択された線と同じであることを示すことによって設定してもよい。レイアウトの開始点を、例えば、適当な制御部に、座標を入力５０４することによって設定してもよく、及び／又は、５０６に示すように、マウス又はタッチスクリーンのようなポインティングデバイスを使用して、可視的表示における１点を選択することにより設定してもよい。コンテキストメニュー５２０のような制御部が、ソーラーコレクタ設置レイアウトエンジンを起動するべく、提供されてもよい。
【００４８】
図５Ｂに示すように、レイアウトエンジンは、関係する符号化された情報に基づいて及び従って、ソーラーコレクタの設計を生成するように起動されてもよく、符号化された情報としては、構造分類、構造特性、作業エリア、設計設定、全体特性、モジュール特性、レイアウト規則、設計規則等が含まれる。ＰＶモジュールの場合、レイアウトには、視覚表示に示される複数のＰＶモジュールの物理的配置が含まれてもよく、付随する配線システム、搭載システム、ハードウェア、設置の適切なオペレーションのための電子部品等の配置も含まれてもよい。ある場合には、ＰＶモジュールは、全オブジェクトに対する規則及び制限の全て（実質的に全て）に従ってＰＶモジュールが配置されてもよい。このようなＰＶモジュールレイアウトを生成するのに、数多くの方法及びシステムを使用してもよい。特に、システムのレイアウトエンジン構成要素は、タイリングアルゴリズムを使用して、レイアウトを生成してもよい。
【００４９】
図６Ａのフローチャートに示されるように、ある１つのアルゴリズムの下、あらゆる幾何的オブジェクトを含む設置現場の視覚表示は、まず、設置現場における物理的構造についての（特に、大きさについての）データを収集することによって、最初に規定され（６０５）てもよい。これは、ＧＰＳベースの測量機器を使用して設置現場で行ってもよく、又はこれに替えて、ＣＡＤソフトウェアを使用して、代表的な幾何的オブジェクトを生成してもよい。この段階は、段階６１０と交互に行ってもよい。段階６１０において、視覚表示におけるオブジェクトは、構造で分類されて、構造特性に適切な値が設定される。これは、ユーザーが手動で行ってもよいし、自動化された構造認識を使用してシステムが自動で行ってもよい。ユーザーは、１以上のオブジェクトを、ＰＶモジュールの設置が許される又は望まれる領域、例えば、野原や屋根のような領域を提供する構造として分類する。段階６１２において、ユーザーは、１以上の作業エリア、例えば、ＰＶモジュールレイアウトが望まれると推測される領域を、所有者の指示に基づいて、規定してもよい。作業エリアを明示的に規定してもよく、それについては以下に説明する。６１５において、設計設定、プロジェクト特性、及びその他の符号化された情報を、設定又は修正してもよい。
【００５０】
６２０において、まず、複数のＰＶモジュールを、１以上の作業エリアにわたって、障害物又はその他の干渉する構造（例えば換気扇）を考慮することなく、タイル状に配置してもよい。作業エリアとしては、配置が許可されると分かっているオブジェクト、例えば、屋根表面が挙げられる。これは、明示的な作業エリアにわたって、例えば、ＰＶモジュールを支持する構造として分類されているオブジェクトにわたって、複数のＰＶモジュールを配置することにより、操作可能としてもよい。タイル状に配置するタイリングは、関連するモジュール設計規則及び特性に従う規定された空間に、グリッド又はアレイを形成することにより行ってもよい。タイリングは、行間隔、隣接する行間のオフセット量、曲線の道又は土地の境界線のような不規則な外縁等を含むように、パラメータ的に変化してもよい。また、タイリングは、個々のモジュール（個別に様々に指定された長さ又は幅を有する）に対応するように行われてもよく、また、任意の配置（例えば、モジュールが、同一の搭載構造又は追跡メカニズムと接続されている場合）における複数モジュールの集合体を表していてもよい。加えて、タイリングの周期的な中断を設けて、側道、設置義務である消防車が侵入可能な道路、又はその他の種類の設計規則を規定するようにしてもよい。ある実施形態では、レイアウトされるモジュールオブジェクトに対応する幾何的オブジェクトを、図６Ｂに示すように、実際に生成して、可視的表示内に配置してもよい。これに替えて又はこれに加えて、レイアウトは、モジュールが表現されているデータ構造において、論理的であってもよい。いずれの場合にせよ、幾何的オブジェクトは、関係するモジュール種類のインスタンスとして分類され、特定の構造特性及びレイアウト制限と関連付けられる。
【００５１】
図６Ａに戻り、６２５では、システムが、タイル状に配置された複数モジュールについて、２回目のパスを実行し、特性に適用される１以上の設計規則に反して配置されているモジュールに、不適格であるとの印を付してもよい。例えば、図６Ｂに示すように、屋根２０１の表面全体が、モジュールでタイル状に覆われたとする。２回目のパスでは、モジュールそれぞれを考慮して、規則に違反して配置されている（すなわち、表示及びオブジェクトの規則に従っていない）モジュールに印を付ける。これは、例えば、配置されたモジュールそれぞれを検証するようにループ化し、モジュールそれぞれに対して、全ての設計規則を検証するようループ化し、規則との不一致を探すべく関係するものを適用することによって、動作させることができる。したがって、換気扇２０２の物理的伏図内、又は、換気扇２０２からのセットバックの伏図内に位置するモジュールには、不適格であると印を付けてもよい。同様に、風速の大きいゾーン内の特定の距離の範囲内に位置するモジュール、例えば、図１の１０６にも、不適格であると印を付けてもよい。不適格であるとされたモジュールは、グレー表示をして、自動的に取り除き、別の階層に移動させてもよいし、データ構造における"適格"なモジュールに対する変更を行ってもよい。不適格であるとの印付けは、ソフトウェアデータ構造における特性又はフィールド内に"不適格？"と明示的に行ってもよいし、プロセス実行において非明示的に行ってもよい。ユーザーは、不適格とされたモジュールに対してアクセス可能であってもよいし、アクセス不可能としてもよい。不適格とするにも様々なレベルが存在してもよく、あるモデルでは、設計者が取り消しを無効にすることができないように、厳密に不適格としてもよいし、別のモデルでは、設計者が配置を元の場所に戻すことを許容する程度に、緩く不適格又は好ましくないとしてもよい。様々なレベルの適法性を、別々の色、層等を使用して維持してもよい。このようなレイアウトプロセスで得られる結果は、設置現場に対する設計規則及び特性に一致したＰＶモジュールレイアウトとなる。図５Ｂに示すように、網掛け線で示されている５３０に配置されているモジュールは、規則に従って配置されている。参照番号５３３で示されているエリアにはモジュールが存在していないが、これは、これに関連付けられたエリアが、障害物の物理的境界の内側に存在しているからである。システムは、１以上の不適格となるモジュールを選択し、それらを通常の配置に戻す能力を有してもよい。ある場合には、構造特性に対して適用される規則の少なくとも１つに違反して実行されてもよい。灰色で網かけされた５３５に配置されたモジュールは、選択的であるセットバック必要条件を満たしていないことから、緩く不適格であると言える。以下に説明するように、設計者は、このように緩く不適格であるとされたモジュールをオンとする、又は、元に戻してもよい。
【００５２】
例えば、モジュールが、換気扇に近接し過ぎて配置されるといったように、あるモジュール配置は、その他のモジュールとの関係に関わらず不適格となる。しかしながら、不適格であるとする設定は、その他のモジュールに対してのみ明確であってもよく、再帰的に特定されるものであってもよい。例えば、グリッド接続されるＰＶの設置は、予め決められた数のモジュールを、電気的に直列に配線接続する必要がある。例えば、ＳｕｎＰｏｗｅｒ３０５モジュールが、北カリフォルニアで使用され、６００ＶのＤＣインバータと接続される場合、各列（ストリング）に、１２個のモジュールを接続しなければならない。
【００５３】
このように、厳密に不適格であるモジュールを取り除いた後、システムは、残ったモジュールに対して更なる"パス"を実行して、例えば、モジュール間接続規則のような設計規則を満たさない更なるモジュールが存在するかのチェックを、再帰的に又は回帰的に実行してもよい。このようなモジュールは、図５Ｂでは、グレー表示されている。
【００５４】
図６Ａに戻り、６３０では、レイアウトが自動的に生成された後で、ユーザーには、少なくとも１つのオブジェクト又はプロジェクト全般を修正するオプションが示される。ユーザーが配置を修正することを可能とするユーザーインターフェースの制御部分は、様々であってもよい。不適格なモジュールは、表示の別の階層に配置されてもよく、及び／又は、図５Ｂに示すように、異なる色又はスタイルで示されてもよい。ユーザーは、不適格であるとされたモジュールの層を適格であると変更してもよいし、その反対の変更を行ってもよい。ユーザーは、右クリックをする又はモジュールを選択して、そのモジュールのステータスを変更してもよい。また、適格に配置されたモジュールの消去を可能としてもよく、完全な消去、又は、モジュールを"消去済み"階層に移動させることを含んでもよい。消去されたモジュールは、必要に応じて、復元されてもよい。アクションの取り消し、又は、例えば、モジュールのインスタンス化し直しのような、取り消したアクションのやり直しを可能とする制御を提供してもよい。取り消し及びやり直しについては、以下にさらに説明する。
【００５５】
制御は、規則又は分類を変更する能力、及び自動レイアウトをやり直す能力を含むように、提供されていてもよい。システムの修正コンポーネントは、一度は配置されたが後に取り除かれた（規則を満たさなかったため）タイルの置き換えを可能とするユーザーインターフェース、又はその他のメカニズムを提供してもよい。また、配置されたモジュールを、レイアウトから取り除くメカニズムを提供してもよい。
【００５６】
６３５に示すように、レイアウトをユーザーが変更を行うと、変更されたレイアウトは、関係する設計規則及び特性に対して矛盾した状態となる、又は、不一致が存在する場合がある。例えば、ユーザによって特定のポイントにモジュールを手動で追加すると、セットバックに関する設計規則を破ってしまうことが考えられる。このように、追加、置き換え又は削除といった、レイアウトの修正は、レイアウトの再計算、レイアウトに対するルーティング／配線構造の再計算等を必要とする場合がある。レイアウトの修正、又はレイアウト規則の不一致は、以下に詳細に説明する、例外事項のリストに明記されてもよい。
【００５７】
６４０において、生成されたレイアウトに対して更なるアクションをユーザーが実行可能なように、ユーザーインターフェースの制御を提供してもよい。例えば、レイアウトを保存、印刷及び／又は送信してもよい。また、レイアウト情報を、オブジェクトの規則及び分類と共に、更なる構成要素を生成するのに使用してもよい。例えば、ユーザーが選択したモデルのソーラーコレクタの効率、及び、屋根の面積が受ける光の量に関するエネルギー予測シミュレーション規則、緯度及び高さといった可視化表示における構造物に関するエンコードされた情報を使用して、電力出力のような特定のモジュールレイアウト性能を、シミュレーションしてもよい。シミュレーション結果は、表示されてもよいし、設計者が利用可能なようにしてもよい。別の例では、モジュール及び関連する部品（配線及び電気インバータ等）の数及びコストを集計して、部品表、コスト計算、請求書等を作成するのに使用してもよい。ある実施形態では、典型的なレイアウト設計プロセスに関連して記載される、複数の種類の書類又は提出物が、ダウンストリームの出力として、自動的に生成されてもよい。
【００５８】
［３．ユーザー規定作業エリア］
上記で説明したシステムは、構造分類によって規定される明示的な作業エリアを使用して、屋根のような許可された表面又はオブジェクト上に、ソーラーコレクタ、特にＰＶモジュールを配置するレイアウトを適用する。更に又はこれに替えて、システムは、ユーザーに、モジュールの配置が許可されている領域として作業エリアを規定する及び利用することに対する明示的な管理権を与えることにより、よりきめの細かい制御を可能とするユーザーインターフェースを提供してもよい。
【００５９】
具体的には、図７Ａに示されるように、システムは、例えば、明示的な作業エリアのような、モジュールレイアウトを制限する又は拡張するための、１以上のユーザー生成境界を、ユーザーが規定できるようにしてもよい。作業エリアは、物理的な設置現場のロケーションに対応するモジュール設置可能な領域の境界、範囲又はセットを表していてもよい。作業エリアは、物理的設置現場に対応するオブジェクトのセット又は１つのオブジェクトと、同一の広がりを持っていてもよい。これに替えて、７０１のように、レイアウトが許可されるオブジェクトの部分のみをカバーするように、作業エリアが設定されてもよい。作業エリアは、複数のオブジェクトにまたがって設定されてもよく、複数の作業エリアが規定されてもよい。ポインティングデバイス（例えば、マウス、タッチパッド、ジョイスティック又はタッチスクリーン）、又はキーボードショートカットを使用して、"作業エリア"アイコンを選択し、四角形、ポリライン又はその他のオブジェクトを描くことによって、明示的な作業エリア７０１を形成してもよい。ユーザーは、四角形をドラッグする及び"作業エリア"ツールバーアイコンをクリックすることを含む、又は、コンテキストメニューを使用することを含む、幾何的オブジェクトを規定するあらゆる方法によって、作業エリアを規定してもよい。例示した実施形態では、オブジェクトは、ユーザーによって、明示的な作業エリアとして印を付され（又は、関連付けされ）てもよい。必ずしもそうする必要はないが、ユーザーが生成した作業エリアは、例えば、建物の表面、野原といったオブジェクト、又は視覚的表示全体と同一の広がりを有していてもよい。ユーザーが生成した作業エリアは、明示的な作業エリアに加えて又は替えて、使用されてもよい。
【００６０】
ある場合では、レイアウトエンジンは、屋根又は野原といった非明示的な作業エリアと、明示的な作業エリアとの交差点にのみ、ＰＶモジュールを配置するように設定されていてもよい。別のケースでは、明示的作業エリアは、その他の設置可能オブジェクト又は非明示的な作業エリアを考慮することなく（又は、この考慮に加えて）、設置可能エリアを規定してもよい。オブジェクトに対する初期設置規則を無効にするのに、明示的作業エリアを使用してもよい。これにより、設計者は、モジュールを屋根の一部にのみ配置するか否かといった、モジュールの配置場所に対する制御権を持つことができる。例えば、図７Ａに示すように、設計者が、屋根２０１の西側の部分にのみオブジェクトを配置したいと考えている場合には、設計者は、作業エリア７０１を形成することができる。ある場合には、生成されるレイアウトにおいて、モジュールが、屋根２０１と作業エリア７０１との交差部分にのみ配置される。すなわち、モジュールは、ロケーションＡ（配線管２０３に対する規則のようなその他の規則に一致する）に配置されるが、ロケーションＢには配置されない。このようなレイアウトの一例が、図７Ｂに示されている。
【００６１】
レイアウトエンジンによって明示的作業エリアを実装する１つのアルゴリズムは次のようであってもよい。図６Ａの６２０に示すように、設置可能オブジェクト（屋根又は野原のような）及び明示的作業エリアの両方が含まれるロケーションにのみ、モジュールをタイル状に配置する。そして、方法は、上記のように進められてもよい。これに替えて、６２５において、モジュールを、許可される全ての面上にタイル状に配置した後、明示的な作業エリアの境界の外側になってしまったモジュールに印を付ける及び／又は取り除いてもよい。
【００６２】
ユーザーは、作業エリアの境界を移動させる又は調整することによって、作業エリアを修正することができる。作業エリアの修正に伴って、前に生成されたレイアウトの自動再計算又は再生成が実行されてもよいし、実行されなくてもよい。
【００６３】
［４．アパーチャ］
作業エリアに加えて、又はこれに替えて、システムは、ユーザーが、例えば、レイアウトアパーチャのような、設計設定の１以上のローカライズされたセットを適用するために、１以上の境界を規定可能としてもよい。複数のアパーチャを使用することにより、設計者は、所望のレイアウトに対して、異種の領域を形成することができ、レイアウトプロセスに対して、制御の別の階層を提供するのに使用することができる。上述のレイアウトエンジンでは、モジュールをレイアウトするのに、設計設定の１つのセット（例えば、モジュール種類、方位、開始点等）を使用していた。これに替えて、ユーザーインターフェースは、ユーザーが、１以上のアパーチャを規定可能とし、アパーチャのそれぞれが、１つの境界を含むようにしてもよい。複数のアパーチャを、設計設定の異なる種類の独立したセットと関連付けてもよい。異なるアパーチャは、異なる範囲を有していてもよく、１つのアパーチャの境界内におけるＰＶモジュールのレイアウトは、（例外もあるが）典型的には、少なくとも一部、アパーチャと関連付けられたユーザーが規定する設計設定によって決定されてもよい。
【００６４】
図８Ａに示すように、ユーザーは、第１アパーチャ８０１を規定してもよい。アパーチャの境界８０１は、屋根２０１のような１つのオブジェクトと、及び／又は、明示的又は非明示的作業エリアと同一の外延を有してもよい。または、図８Ａに示すように、アパーチャ境界８０１は、屋根２０１のような設置可能オブジェクトの一部分のみをカバーしてもよい。アパーチャ境界８０１はまた、モジュールが設置されてもよい１以上の作業エリア及び／又はオブジェクトを範囲に含んでもよい。第１アパーチャ８０１は、７０２から７０５に示すように、そのアパーチャに関連付けられた設計設定のセットを有してもよい。アパーチャの設計設定としては、ＰＶモジュールの種類又はモデル、真北の方向に対するモジュールの方位、行間の距離、傾斜角度、搭載方法、ストリング出力電圧、行間オフセット、アパーチャの大きさ及び形状、タイル開始点及びその他の特性を含んでもよい（更なる例については、表５を参照）。ある実施形態では、ユーザーは、設計設定の一部又は全てを変更してもよいし、初期設定のまま続けてもよい。同様に、作業エリア及び／又は屋根２０１のような設置可能オブジェクトの全体又は一部を含むように、第２アパーチャ８０２を生成してもよい。第２アパーチャ８０２は、関連付けられた設計設定の異なるセットを有してもよい。アパーチャは、ユーザーによって形成されてもよいし、自動的に規定されても、予め規定されてもよい。例えば、特定の作業エリア全体、又は、作業現場の表示全体を含むように、一般的な初期アパーチャを、初期値として最初に規定してもよい。これに替えて、ソフトウェアは、ユーザーに、レイアウトエンジンを動作させる前に少なくとも１つのアパーチャを規定するように要求してもよい。例えば、幾何的オブジェクトを選択して、ツールボックスアイコンをクリックする、又は、８０５に示すようにコンテキストメニューを使用することにより、アパーチャを生成してもよい。アパーチャの規則を調整するのに複数の制御方法が適用されていてもよく、例えば、ユーザーは、アパーチャにおけるモジュールレイアウトの方位を示すために、線形参照オブジェクトを選択することができる。
【００６５】
ある場合には、アパーチャと作業エリアとが交差する又は重なる部分に配置されたモジュールの配置は、アパーチャの設計設定に依存する。例えば、図８Ａに示すように、屋根２０１と同一の広がりを有している作業エリアが（明示的に又は非明示的に）形成されたと仮定する。レイアウトエンジンが起動されると、モジュールは、第１アパーチャ８０１の設計設定に従って、ロケーションＡに配置されてもよいし、第２アパーチャ８０２と関連付けられた設計設定に従って、ロケーションＢに配置されてもよいが、ロケーションＣは、アパーチャ内に位置していないことから、ロケーションＣにはモジュールは配置されない。ある場合には、ロケーションＤのように、アパーチャは重なってもよく、この場合は、ロケーションＤには、アパーチャの設計設定の２つ以上のセットが適用されることを意味する。このような場合、システムは、アパーチャ競合解消規則を利用してもよく、これについては、図９を参照して以下に詳細に説明する。また、ロケーションＥは、作業エリア内でないことから、ロケーションＥには、モジュールは配置されない。図８Ｂには、上記の説明に従ってレイアウトされた例が示されており、第１アパーチャ８０１を優先させて、領域Ｄにおける競合が解消されたレイアウトが示されている。アパーチャの競合解消規則については、以下に詳細に説明する。
【００６６】
アパーチャを使用することにより、例えば、図８Ａ及び図８Ｂに示すように、ユーザーは、屋根のような、１つの作業領域又はオブジェクトの第１部分に対して設計設定及び特性の１セットを規定することができ、同じ作業エリア又はオブジェクトの第２の部分に対して、設計設定及び特性の第２セットを規定することが可能となることから、有用である。例えば、ソーラーコレクタが、同じ屋根上の２つの部分に配置され、１つの部分は平らであるが、もう１つの部分は傾斜している場合に、設計者は、それぞれに対して２つの異なる垂直方向に対する搭載角度、南向きに対する方位、ＰＶモジュールのモデル、及び／又は、２種類の屋根に適した搭載システムを選択してもよい。同様に、屋根の一方の面が、他方の面と比べて強い風を受ける場合には、ユーザーは、風が強い方の面に対して第１アパーチャを形成し、風に強いモジュール及び搭載システムを含む設計設定を使用してもよく、風が強くない方の屋根の面に対して第２アパーチャを形成して、風に対してさほど耐性を有さないモジュール及び搭載システムを適用してもよい。アパーチャは、ユーザーによって、（ユーザーが規定した作業エリアとして）移動及び調整可能であってもよく、これにより、設計者が、レイアウトの代替案を素早く可視化することができるようになる。
【００６７】
アパーチャによって、モジュール配置に対する設計設定の異なるセットを提供できるようになることから、隣接する又は重なるアパーチャでは、配置における不一致が生じる場合がある。アパーチャの重複の程度が大きい場合も存在する。アパーチャにおける不一致を解決する規則を使用して、モジュール配置における矛盾点を解消してもよい。不一致解決規則の単純な形の一例は、アパーチャを生成順番でランク付けすることであり、最初に形成されたアパーチャ又は最後に形成されたアパーチャが、一番優先されるようにする。または、辞書式順序を利用してもよい。ユーザーには、明示的にアパーチャの優先順位を変更可能な制御が提供される。優先順位変更の方法の一つは、優先順位を規定しているユーザー編集可能な設計設定とアパーチャそれぞれとの関連付けを行うことであり、例えば、"優先順位＝２"とする。初期設定のアパーチャが存在する場合には、それに対して、最も低い優先順位を割り当ててもよい。
【００６８】
アパーチャ不一致解決規則に従って、様々な方法で、モジュールレイアウトを生成することができる。例えば、アパーチャに対して上述のような優先順位が付与され、配置における不一致が生じた場合には、最も高い優先順位のアパーチャにおける配置が優先される。
【００６９】
例えば、各アパーチャ境界内に少なくとも一部位置しているオブジェクト及び構造物に、上述のような方法を適用することで、優先順位を考慮することなく、規定された全てのアパーチャに対して、独立した部分的なレイアウトが生成されてもよい。この計算は、並列に実行されてもよい。アパーチャに重複が生じない場合には、２つの部分的なレイアウトを結合させたものを、最終的なレイアウトとして、出力デバイスに、保存、格納又はレンダリングしてもよい。重複が存在する場合には、不一致解決規則に基づいて、配置されたモジュール間の不一致を解消してもよい。不一致が発生しているモジュールのある場合には、低い優先順位のアパーチャからのモジュールを取り除き、低い優先順位のアパーチャに対応する部分的な設置レイアウトを修正又は調整してもよい。図９Ａには、レイアウトの一方法が示されている。９００でプロセスが開始し、まず初めに９０１において、設置現場データ（例えば、境界及び構造の物理的大きさのデータ）が入力し、次に、９０２では、オブジェクトを分類し、作業エリア及びアパーチャを生成する。９０４では、アパーチャそれぞれ内に、モジュールのレイアウトを生成し、９０６では、各アパーチャ内に配置されたモジュールを分析して、別のモジュール及び／又は別のアパーチャと、配置に関する不一致が生じていないかを確認する。９０８では、アパーチャの優先順位規則を使用して不一致を解消し、９１０において、前述のようにユーザーがモジュール配置を修正可能とする。このプロセスは、９１２で終了するが、上記の段階に対して、数多くの中間に位置する追加のプロセス、及び同様な段階の繰り返しを行ってもよいことは、明らかである。
【００７０】
これを達成する別の方法は、優先順位の高いものから低いものへと各アパーチャの解析を行い、優先順位の高いアパーチャの一部に既に配置されているモジュールと配置における不一致が生じない限りにおいて、そのアパーチャ内に可能なモジュールの配置を（上記のように）行う。典型的なＰＶモジュールの配置は、そのアパーチャ内で交差する（又はアパーチャ内に収容される）構造物に適用されるアパーチャの設計設定、構造特性、モジュール特性及びプロジェクト特性に応じて、所定のアパーチャの境界内で実行される。この方法では、連続した設置レイアウトのセットが生成され、連続したレイアウトのそれぞれは、現在の及び優先順位の高いアパーチャ全ての設計設定と一致している。連続した設置レイアウトは、デバイス又は媒体にレンダリング又は格納されてもよい。
【００７１】
図９Ｂには、分類されたオブジェクト、作業エリア及び競合しているアパーチャに従って、モジュールをレイアウトするプロセスの別の例が示されている。プロセスは９３０で開始し、初めに、９３１において、ユーザーは、オブジェクトを分類し、１以上の作業エリア及び／又はアパーチャを生成する（若しくは、初期設定の又は明示的な作業エリア及びアパーチャを使用してもよい）。ある実施形態では、アパーチャは、後に行う不一致解決における優先順位を決定づけてもよい、生成の相対的な順番と関連付けられていてもよい。
【００７２】
９３２において、モジュールは、上記の相対的優先順位付け規則に従って決定されてもよい１番目の"第１"アパーチャにおける規則に従って、モジュールを配置する。明示的か非明示的かに関わらず、第１アパーチャ及び作業エリアの境界内にのみ、モジュールが配置されてもよい。明示的な作業エリアが規定されている場合には、アパーチャ、配置可能な面、及び明示的作業エリアの交差点にのみ、モジュールが配置されてもよい。明示的な作業エリアが規定されていない又は使用されない場合には、アパーチャと、屋根のような配置可能オブジェクトによって規定される作業エリアとの交差部分に、モジュールが配置されてもよい。９３３において、例えば、換気扇に対するセットバック必要条件を満たしていないといった、１以上の設計規則に合致しないモジュールには、不適格との印が付与された後、消去される又は有効化されているレイアウトからは取り除かれる。
【００７３】
９３４において、２番目に高い優先順位が付与されたアパーチャ（が存在する場合には）に対して、段階９３２及び段階９３３が繰り返される。しかしながら、通常必要とされる作業エリアの交差点に加えて、第１アパーチャにすでに配置されているモジュールと競合が生じない場合には、第２アパーチャ内にもモジュールを配置してもよい。これは、上記の配置段階（９３２）と同様に行うことができ、例えば、第１アパーチャと一致しない条件のモジュールは、決して配置しないようにする。これに替えて、第１アパーチャにおけるモジュール又は設計設定を考慮することなく、第２アパーチャにモジュールを配置してもよく、その後で、第１アパーチャに配置されたモジュール（又は、それらに付与されている設計設定）と一致しないモジュールが発見された場合には、（段階９３３と同様な段階の間に）そのようなモジュールを取り除く。
【００７４】
９３５において、３番目に高い優先順位が付与されているアパーチャ（存在する場合）に対して、段階９３２及び段階９３３を繰り返す。第１アパーチャ又は第２アパーチャに配置されたモジュール及び設計設定と不一致が生じない場合にのみ、第３アパーチャの規則に従って、モジュールが第３アパーチャ内に配置される。必要であれば、９３６に示すように、残りの全てのアパーチャに対して、このプロセスを繰り返してもよい。９３７において、又はこれよりも前の段階において、ユーザーは、モジュールの配置を修正可能であってもよく、修正に伴って、上記の段階に基づいて、レイアウトの一部又は全ての再生成が実行されてもよい。上記したように、追加の段階を間に挟んで実行してもよいし、９３８においてプロセスが終了する前に、上記の段階を要求に応じて繰り返してもよい。最終的なレイアウトを、コンピュータデバイスに表示してもよいし、レンダリング又は格納してもよい。
【００７５】
［５．プロジェクト階層化及び格納］
プロジェクトの設置現場、構造及びその分類、及びソーラーコレクタのレイアウトを含む、太陽光設備プロジェクト設計は、プロジェクト状態情報によって特徴づけられてもよい。プロジェクト状態情報は、一般的に、特定のソーラーコレクタ設計設定を更に必要とせずに、再生成をするのに使用可能な情報を含む。例えば、プロジェクト状態情報の典型的な使用により、不揮発性メモリに設計を保存することができるようになる。特定の設計に対して、"保存"機能又は制御を起動すると、プロジェクト状態情報がハードディスクに書き込まれるようにしてもよい。そして、ソフトウェアプログラムが停止（動作しているメモリの全てを消去する）してた後、再開する。ユーザーは、"開く"機能又は制御を選択して、ソフトウェアに、保存したプロジェクト状態情報を指し示す。ソフトウェアは、示されたプロジェクト状態情報を読み込み操作を行って、太陽光設備設置プロジェクトを再生成してもよい。
【００７６】
ある場合には、特定の設計が表示されている時のソフトウェアの動作メモリの全コンテンツを、"プロジェクト状態情報"として認識させることができ、これによって特定の設計を十分に特定することができる。プロジェクト状態情報を使用する１つの利点としては、動作メモリ（又はその他のデータ）のサブセットのみを使用する点であり、プロジェクト状態情報のサイズ及び複雑性の両方を低減することができる。例えば、所与の設計が、全てがモジュール種類Ｔ１０であり、１０００×１０００のサブアレイに配置される百万個のコレクタを含むレイアウトを含むとする。このような設計を保存する一つの方法は、関係する特性情報（例えば、"モジュール種類＝Ｔ１０"、ロケーション、方位等）のコピーをそれぞれが有する"コレクタ"データ構造を百万個割り当てて格納することである。これに替えて、システムは、単純に"１０００×１０００のＴ１０モジュールのサブアレイ、方位０度"の状態情報を格納してもよい。このように、プロジェクト状態情報をコンパクトな表示形態にすると、保存する際に便利であり、また修正も容易になる。例えば、設計者が、全てのモジュールについてＴ１０から別の種類への変更を考えているとすると、最初の例の場合では、１００万個のデータ構造を全てスキャンし、それに対して変更を実行しなければならない。一方で、２番目の例の場合には、状態情報に１つの変更を行うだけで、修正を実行することができる。
【００７７】
ある実施形態では、所定の設計に対するプロジェクト状態情報は、設計を再生成するのに使用されるデータのような、設計入力の全てを含む。例えば、プロジェクト状態情報は、幾何的オブジェクト、これら幾何的オブジェクトの構造物としての分類、分類されたオブジェクトそれぞれに対する構造特性、設計設定、作業エリア規定、アパーチャ規定及び付随する設計設定、プロジェクト特性等を含む設置現場の表示のような入力情報を含んでもよい。プロジェクト状態情報はまた、生成されたレイアウト情報に対するユーザー修正のような、その他の種類の入力を含んでもよい。例えば、ユーザーが特定のモジュールのステータスを"不適格"から"適格"へと変更した場合などの、ユーザーが生成されたレイアウトに対してモジュールを手動で追加した場合、そのモジュールの状態は、プロジェクト状態情報に反映させてもよい。
【００７８】
プロジェクト状態情報はまた、生成されたレイアウト、生成されたレイアウトの性能及びコスト特徴等の出力情報を含んでもよい。例えば、特定の設計についての部品表は、設計入力、例えば、設計設定の関数であるから、設計の出力であるといえる。例えば、出力情報をキャッシュしておくことにより、必要となる計算量を低減することができると考えられる。
【００７９】
プロジェクト状態情報の効率的な管理は、難しい場合がある。特に、ある実施形態では、プロジェクト状態情報は、"不一致"情報のために提供されてもよく、例えば、ユーザーが、ＰｏｗｅｒＧｕａｒｄモジュールを、Ｔ１０と指定されたアパーチャ境界内に配置する場合などが挙げられる。システムが、ユーザーによる両方のアクションを有効にする場合には、プロジェクト状態情報を表現する効率的で強力な表示があれば便利である。
【００８０】
そこで、ある実施形態では、プロジェクト状態情報を、データ構造で表現される階層構造要素の配置として認識してもよい。ある条件下では、階層構造は、サブ要素が、固有の親オブジェクトに割り当てられるツリー状構造に似たものであってもよい。別の場には、階層構造は、特定のオブジェクトが１以上の親オブジェクトを有するような階層構造の、一般的なグラフのインスタンスであってもよい。
【００８１】
図１０Ａ及び図１０Ｂは、ソーラーコレクタレイアウト設計ツールによって使用されてもよい、プロジェクト状態情報階層構造を示している。具体的には、図１０Ａに示すように、プロジェクト１０００全体は、設置現場表現１００１を含み、設置現場表現１００１は、１以上の構造１００２を含んでもよい。構造１００２はそれぞれ、構造特性を含んでもよい。
【００８２】
設置現場表示は、複数の作業エリア１００５を含んでもよく、図１０Ａに示されるように、２つの作業エリアを含んでもよい。各作業エリア１００５は、１以上のアパーチャ１０１０を含んでもよく、例えば、第１作業エリア１００５は、１０１０において２つのアパーチャを含んでもよい。これは、設置現場表示において、アパーチャ１０１０が、所定の作業エリア１００５の境界内に収まっている場合である。複数の作業エリアと重複している１つのアパーチャである場合には、アパーチャオブジェクト１０１０は、複数の作業エリア間で共有されていてもよいし、複製されていてもよい。これに替えて、作業エリア１００５に対する子供のオブジェクトとして、（アパーチャ全体ではなく）作業エリアアパーチャの交差点を使用するように、階層構造を調整してもよい。
【００８３】
ある実施形態では、上記したように、ソーラーコレクタが、アパーチャ１０１０と作業エリア１００５との交差部分に配置される。各アパーチャ、又は、作業エリアとアパーチャの交差部は、アパーチャ１０１０内に、コレクタの１以上のサブアレイ１０１５を含んでもよい。所定のアパーチャ１０１０におけるサブアレイ１０１５の数及び構成は、アパーチャの境界内及び周辺に位置する障害物構造を含む、複数の変数の関数であってもよい。例えば、アパーチャを二等分するような線形障害物（例えば、壁のような）によって、アパーチャ１０１０内におけるコレクタのレイアウトが、壁の両側にそれぞれ配置される２つのサブアレイ１０１５に分割される。ある実施形態では、サブアレイ１０１５は、四角形の形状であってもよいし、別の実施形態では、形状に関係なく、アパーチャ１０１０内の隣接するコレクタのグループからサブアレイ１０１５を形成してもよい。別の実施形態では、サブアレイ１０１５を形成するのに、配線条件又は出力条件等のその他の規則１００４を使用してもよい。
【００８４】
所定のサブアレイ１０１５をさらに、コレクタ１０２５の列１０２０へと分割してもよい。ある条件下では、ＰＶモジュールで考えられるように及び上述したように、選択されたモデルに応じて、必要とされる出力電圧を生成するために、所定の数のコレクタを、例えば直列でといったように特定の態様で、互いに配線する必要がある。したがって、例えば、所定のサブアレイの要求される出力電圧が、最大出力にして１５０Ｖである場合、サブアレイを形成するのに使用された特定のモジュールの最大出力がそれぞれ、１５Ｖであるとすると、設置するためには、モジュールを１０個一列（ストリング）にしてグループ化する必要がある。各列におけるコレクタが直列に配線されて、サブアレイの各列は、サブアレイの別の列と並列に接続されてもよい。所定のサブアレイ１０１０は、複数の列（ストリング）１０２０から構成される。これら列１０２０のそれぞれは、複数のコレクタ１０２５から構成されている。
【００８５】
図１０Ｂに示すように、所与のソーラーコレクタは、要素の階層構造を有してもよい。例えば、ＰＶモジュールは、複数のセル列１０３０で構成されていてもよく、セル列のそれぞれは、一連のセル１０３５（図１０Ａに示すサブアレイ１０１５が、複数モジュール１０２５の列１０２０によって構成されているのと同様に）を含む。例えば、１５Ｖのモジュールは、３つのセル列が並列に配線されたものであってもよく、セル列のそれぞれは、１．５Ｖのセルが１０個直列に接続された構成を含む。
【００８６】
階層構造の各層における要素それぞれは、特性のセットと関連付けられていてもよい。例えば、所与の列の特性として、モジュールの数、列の位置等が含まれてもよい。特定の作業エリア、アパーチャ、プロジェクト及び構造と関連付けられてもよい特性の幾つかは、上記で例示した。１つの要素の特性は、完全に表示されてもよいし、特性の別のセットを参照して表示されてもよい。例えば、特性の初期値は、階層構造で表されているデータ構造の親の要素から引き継いだものであってもよく、これらの初期値は、所与の子供に格納されている特性の値を優先させ、無効化されてもよい。
【００８７】
特性と同様に、レイアウトエンジンによって採用される構造レイアウト規則のような設計規則は、階層構造における各要素と関連付けられていてもよい。図１０Ａの１００４に示すように、構造の特定のインスタンスに固有でない設計規則は、プロジェクト又は設置現場に広く関連付けられていてもよい。設計規則も、特定のレイアウト又は設計エンジンから受け継がれたものであってもよく、プロジェクト状態情報階層構造に表示されなくてもよい。また、設計設定も、階層構造における各要素と関連付けられていてもよい。プロジェクト設計設定も、プロジェクト要素と関連付けられていてもよい。階層データ構造は、特性、設計設定及び規則の分類における柔軟性を提供する。例えば、ユーザーによって配置された又は修正されたコレクタは、付随する特性を有する構造１００２として分類されてもよく、階層構造の別のレベル（１０２５に示されているように）又は両方に維持されてもよい。
【００８８】
ある実施形態では、例えば、プロジェクトを保存及び検索するのに使用するべく、プロジェクト状態情報を表示するためにソフトウェアによって使用されるデータ構造は、要素、特性及びそれに関連付けられた設計規則の集合間の階層的関係として表現されていてもよい。例えば、プロジェクト状態情報は、ＸＭＬ型の形式で表示されてもよく、最上階層の設置現場のノードは、構造及びその分類のリストを含んでもよい。設置現場ノードは、また、複数の作業エリアノードを含んでもよく、作業エリアノードは、複数のアパーチャノードを含んでもよい。アパーチャノードのそれぞれは、サブアレイノード等を含んでもよい。レイアウトを再生成するのに十分な情報を、データ構造内に含むという意味では、プロジェクト階層データ構造は、設計プロジェクトの状態を表しているとも言える。
【００８９】
［６．プロジェクト例外］
ある実施形態では、上述したように、設計者が、構造の分類、レイアウトの生成、及びレイアウトの修正といったプロセスを進めると、設計プロセスに関するメタデータが生成されてもよい。メタデータは、例えば、構造特性、設計設定、バージョン情報のような、プロジェクト状態情報に適用される規則から決定されてもよい。このメタデータは、多くの形式であってもよく、設計者が行った動作、及び設計者が行うべき動作に関する情報、管理者、共同設計者、ダウンストリームのユーザー及び設計を受け取る者にとって有用な設計情報を含んでもよい。システムは、メタデータ及びその他のデータを使用して、"例外"のリストを生成してもよく、リストは、例外的条件をメタデータにエンコードしたものであって、例えば、プロジェクト状態情報そのもの、設計出力に反映されたプロジェクト情報、又はその他の条件によって規則が破られる場合を示している。例外的条件及び対応する例外は、ユーザーによる不作為、規制の違反、ソーラーコレクタ製造業者の仕様に対する違反、顧客の要求に対する違反、設計原理に対する違反、物理空間制限に対する違反、会社の設計規則に対する違反等と関連していてもよい。
【００９０】
リストにより、設計者は、適正なアクションを最終的に実行すると同時に、設計欠陥のような例外的条件を見過ごすことなく、設置設計を生成する場合に、より柔軟に一連のアクションを実行することができる。例外リストを使用することにより、特に、特定の順番でワークフローを実行することを強要されず、設計者が選択した順番でアクションを実行することが可能になる。例外リストは、別のアクションを実行する前に、特にユーザーに例外事項（又は例外条件）を対処することを要求することなく、ユーザーに提示されてもよい。例外リストは、特定の例外に対処すべきか否かを設計者が決定する機能を提供してもよい。例外リストはまた、疑いのあるモジュール配置等の、設計についての重要な情報を示す単純なインターフェースを提供してもよい。ユーザーは、例外を効率的に（少なくとも一時的に）無視して、"やるべきことのリスト"の一部としてユーザーがスケジュールした時点に扱われるようにしてもよい。ユーザーは、例えば、ユーザーインターフェースにおいて、例外又は例外リストを、動作を邪魔しないものとして、所定の例外を無視するオプションを提供してもよい。また、ユーザーには、失われている情報を提供する、又は生成されたレイアウト又はユーザーが修正したレイアウトから不適格なモジュールを取り除くことによって、例外条件に対するソフトウェアの例外事項に従うオプションが与えられてもよい。メタデータ及び例外は、契約の例外事項のような、ダウンストリームにおける書類を生成及び維持するのに有用である。
【００９１】
ある実施形態では、例外事項を含むメタデータの一部又は全てが、共有ストレージ又は上記のデータ構造階層構造への参照によって、設計と関連付けられていてもよい。その後、自動化システムを含むダウンストリームのユーザー及び設計の処理者は、メタデータを使用してもよい。メタデータは、集約、エクスポート、暗号化、されてもよく、また、システムによって演算されてもよい。生成されたメタデータ及び例外は、特に、契約における例外事項に関する情報、設計者に対する注意、及び設置現場表示又はレイアウトにおけるエラーを含んでもよい。
【００９２】
図１１に示すように、ユーザーインターフェース１１００は、設計に関するメタデータの一部又は全てが、例外のリスト１１０５の形で設計者に表示されるようにしてもよい。表示には、レイアウト、リスト又は設計例外、及び例外事項を操作することが可能な制御が含まれてもよい。例外は、設計者の一部に対してアクションが必要であることを示してもよい。ある例外事項の場合には、例外が生成されてはいるが、設計者は、要求された情報を提供しなかったことに対する設計プロセスにおける障害を受けるとことが無いようにすることもできる。例えば、ある実施形態では、郵便番号で近似することができる設置現場のロケーションは、レイアウトに影響を与える設置現場特性である。これは、異なる郵便番号が、異なる規制制度を暗に意味しており、例えば、屋根に載せる負荷、セットバック等に関して異なる規制が課されることが考えられる。したがって、設計規則は、郵便番号の提供を要求してもよい。このような場合に、設計者が、設置場所に対する郵便番号を指定し忘れると、この情報の不足が、設計に関するメタデータとして通知されて、郵便番号例外１１１０が生成されてもよい。郵便番号例外１１１０が未決の間であっても、設計者は、初期設定値の郵便番号又はシステムによって提供された規則制度を使用して、オブジェクトの分類、及びレイアウト又はダウンストリームにおける書類作成を進めることができる。
【００９３】
これに替えて、システムは、例外が存在ししている間は、ユーザーは、それと無関係のアクションを実行可能なようにしてもよく、レイアウト生成、シミュレーション又はダウンストリームの書類作成のような特定の動作を許可する前に、設計者に例外の対処をするように要求してもよい。例えば、設計者は、郵便番号を入力する前にオブジェクトの分類を継続することは許されるが、レイアウトを生成することは許されない。別の例としては、その他のメタデータが、設計継続が許されないような致命的な状態を示してもよい。例えば、設計者が換気扇の上にモジュールを配置した場合には、システムは、エラー例外１１１５を生成してもよい。設計者は、最終的な設計が生成される前に、この例外１１１５に対処する。ユーザーが例外に対処していない場合（すなわち、無視している場合）には、その例外は、管理者がレビューするために、例外リスト１１０５に残される。ユーザーによるある種の対処、例えば、要求されたもの又は変更に一致させることは、例外リストの項目から除外されてもよい。例えば、無効化、又は、要求された情報又は変更に一致させることを明示的に拒否するような、ユーザーによるその他の対処の場合には、例外の修正及び例外の保守が必要となり、ユーザーは、例外履歴における入力を無効化する。これは、修正、管理者のレビュー、契約書作成等で将来の有用となる。その他の種類の例外については、以下に記載する。
【００９４】
設計者は、設計者に対応を要求する例外事項について、様々な態様で対処してもよい。例えば、設計者は、設置現場の郵便番号を入力することにより、郵便番号例外１１１０に対処することを選択してもよい。この例外に対しては複数の方法で対処が可能であり、例えば、上記したようなプロジェクト特性を入力するメカニズムを使用して対処可能である。これに替えて、例外１１１０そのものを、これを対処するメカニズムと関連付けてもよい。例えば、郵便番号例外１１１０が、郵便番号を入力するフィールドを含み、プロジェクトと関連付けられていてもよい。ユーザーが例外に対処すると、システムは、情報を再計算又は再生成する。例えば、ユーザーが値を郵便番号例外に入力すると、システムは、その郵便番号を有効化して、例えば、新たなロケーション情報でレイアウトを再生成してもよい。例外に応答して、ユーザーは、例外的条件又は規則違反を是正するのに十分なコンプライアンス情報を提供してもよく、そのような情報としては、プロジェクト特性、顧客特性、設計設定、作業エリア境界及びアパーチャ境界が含まれてもよい。ある実施形態では、コンプライアンス情報を認識して、プロジェクト状態情報又はその他の設計情報を修正するべく情報を使用してもよい。コンプライアンス情報を受信した後、システムは、対応する例外を除去してもよい。
【００９５】
システムはまた、ダウンストリームのユーザー及びプロセスに有用な設計に関する情報又はメタデータを反映する例外を含んでもよい。例えば、設計者が、（オンサイトの検査官によって規定された）"不適格な風の領域"として分類された構造と重複した構造に、モジュールを配置すると、除外例外１１２０が生成される。上記したように、この除外例外が設計者に示されて、設計者は、規則に従うように、例えば、例外を除去又は改善するように（例えば、対象となっている特定のモジュールを取り除くことにより）、制御を操作してもよい。これに替えて又はこれに加えて、除外例外を含む例外の一部は、設計と共に維持される又は設計と関連付けられてもよく、それにより、設計を使用する次のプロセスを実行可能としてもよい。例えば、別のソフトウェアプログラムが、除外例外情報を使用して、設計者と顧客との間で交わされる契約書の条項の一部として記載されてもよい、契約上の例外のリストを生成してもよい。例えば、水漏れがある屋根の領域にモジュールが配置されたことに対応する例外１１２０は、水漏れのある屋根の領域に配置されたモジュールに対する設計者の品質保証を制限する契約上の特別な条項を生成するために、ダウンストリームのプロセスで使用されてもよい。
【００９６】
また、例外の中には、設計者以外の人物又は権限を持つものが、レビュー及び追加の許可を必ず行うように設計されていてもよい。例えば、最大設計重量の９５％の重量負荷がある屋根と関連する例外１１２５は、設計者の管理者による承認を必要としてもよい。設計者が、少なくとも特定の指定されたアクションに関して実行を続ける前に、管理者又は別のユーザーによる例外の承認を要求してもよい。これに替えて、システムは、このような承認を必ず伴う例外の全てついてのリストを生成してもよく、このリストは、設計のダウンストリームプロセスの一部として使用されて、ユーザーが、例外が存在したとしても少なくとも一部のタスクを進められるようにする。後で行う、例外事項の修正、無効化、又は無効化の許可（例えば、管理者による）に伴って、ユーザーが間で行った仕事が無駄にならないように、関連するソーラーコレクタのレイアウトの再生成を行ってもよい。
【００９７】
ある実施形態では、上記の例外及び対処の組み合わせの一部又は全てを実装してもよい。例えば、例外に応じて、システムが設計者に対して利用可能とする適格な対処には、"例外無視"、"自動レイアウト修正"、"例外無効化"、"コレクタ消去"、"レイアウト再生成"、"値入力及び再計算"、"管理者へのフラグ"、"例外に従う"等の変形例が含まれてもよい。例えば、ユーザーは、ソフトウェア制御によって、例外的条件を取り除くことに合わせたプロジェクト状態情報又は設計の修正によって、システムが自動的に例外的条件の修正を試みる段階を実行する命令を発行してもよい。
【００９８】
ある実施形態では、ユーザーの認証を含む例外への対応の一部として行われた動作を含む、ユーザーの対処を記録してもよい。対処の記録は、例外と関連付けられて、所定のプロジェクトと共に格納され、ダウンストリームのユーザー等にエクスポートされてもよい。別の実施形態では、ユーザーの入力又は推進事項のあるなしに関わらず、例外事項の存在を再評価してもよく、例外的条件がもはや存在しない場合には、システムは、その例外事項を除去してもよい。
【００９９】
図１２には、例外を実装するプロセスが示されている。１２０５−１２１０において、システムは、入力認証ループに入ってもよい。１２０５において、設計者は、設置現場情報を入力し、オブジェクトを構造として分類し、構造特性、及びその他の設計特性及び設定を入力してもよい。１２１０において、システムは、幾何的オブジェクト、及び、プロジェクト状態情報におけるその他の入力情報に規則を適用することにより、設計者の入力を分析及び認証してもよい。認証エンジンは、プロジェクトの種類に固有の認証ルールを使用してもよく、又は一般化されてもよい。認証規則は、プロジェクト階層構造と共に格納されてもよいし、プロジェクトの外部に配置されていてもよい。認証エンジンによって、不一致が通知されると、この不一致が例外リストに掲載されて、例えば、１２１２において、コンピュータメモリのデータ構造に配置されてもよい。上記したように、例外事項は、ユーザーに表示されてもよい。ユーザーは、例外リストに配置された例外事項に対処するかを選択する、又は、ユーザーは更なる特性、分類及びその他の情報を入力してもよい。
【０１００】
入力認証ループ１２０５‐１２１０は、ユーザーが１２１５においてレイアウトを生成させるまで、継続させてもよい。このように構成した場合、システムは、レイアウト認証修正ループ１２１５‐１２２０‐１２２５‐１２３０に入ってもよい。１２２０に示すように、生成されたレイアウトが分析されて、設計設定、構造及びプロジェクト特性、レイアウト規則、所望の出力、及びその他の符号化された情報の基準と合致しているかの認証が行われてもよい。生成されたレイアウトから生じた変更又は逸脱が、例外として再び表示され、１２２２において例外リストに配置されてもよい。１２２５において、ユーザーには、上記したように、レイアウトを修正する機能が表示される。修正する機能には、特性又は設定の変更、例外への対処（これは、特性又はレイアウトにおける変更を伴う）、モジュールの追加又は削除等が含まれる。
【０１０１】
１２３０に示すように、ユーザーのアクションが、認証エンジンによって認証されてもよい。１２３２では、ユーザーのアクションによって生じた例外が、例外リストに再び追加されてもよい。ある場合には、ユーザーによる変更が、レイアウトの再生成をトリガすることがある。例えば、ユーザーが、セットバック特性を大きくすると、大きくなったセットバックに合うように、レイアウトが再生成されてもよい。例外の種類に応じて、１２２５‐１２３０のループ（ユーザー入力が認証されてレイアウトの再生成無しに例外事項が生成される）、又は、１２１５‐１２２０‐１２２５‐１２３０ループ（ユーザー入力によって、レイアウトの再生成が発生する）を、必要に応じて又は設計者の要求に応じて、繰り返してもよい。
【０１０２】
１２３５において、例外及び例外に対処するためにとられた動作を含むプロセスを通じて生成されたメタデータの一部又は全ては、存在する場合には、格納されてもよいし、ダウンストリームユーザー対して利用可能としてもよい。例えば、契約書の条項のリストを、契約の除外例外の全てから生成してもよく、承認が必要な例外事項の全てのリストが生成されて、適切な認証実体に転送されてもよい。ユーザーインターフェースは、ソーラーコレクタ設置設計による設計規則の違反に関連した例外的条件に対応する契約例外事項のリストを提供してもよく、契約例外又は条件は、契約書に組み込むべき条項を特定するのに十分な情報を提供する。通常は、メタデータ、例外、又はユーザーのアクションが、プロジェクト状態情報の一部として含まれる。
【０１０３】
［７．プロジェクトのバージョン］
ある実施形態では、特定の設置現場に対するソーラーコレクタレイアウト設計の複数のバージョンを閲覧、生成及び操作するためのシステム及びユーザーインターフェースを提供する。複数のバージョンが扱えるようになると、例えば、設計者は、別のモジュール、別の構造分類、別の作業エリア及び／又はアパーチャ境界、別の入力又は設計設定のその他の種類を選択した場合のレイアウト及びその他の出力を素早く容易に見ることができるようになる。複数のバージョンにより、設計者が、様々な入力変更による出力の変化をインタラクティブに見ることができるようになる。ある実施形態では、設計者が、１つのバージョンから別のバージョンへの移動を迅速にできるようにし、別の実施形態では、設計者が、１つのアクションで複数のバージョンに作用することを可能としてもよい。所定のバージョンは、ユーザーが規定した設計設定、構造特性及びプロジェクト特性の固有のセットを提供するユーザーが規定したプロジェクトの状態情報を含んでもよい。この入力情報の異なるセットを有する異なるバージョンは、ソーラーコレクタ設備の代替レイアウトに対応していてもよく、各バージョンに対する代替レイアウトは、データの固有のセット間の差分から生じる。データの固有のセットはまた、作業エリア状態情報、アパーチャ状態情報、幾何的オブジェクト情報を含んでもよい。
【０１０４】
ある実施形態では、所与の設置プロジェクトの異なるバージョンは、特性を含む設置現場及び／又は構造情報を共有してもよい。このようなバージョンは、可能性のある異なる作業エリア、アパーチャ及びレイアウトを規定してもよい。別の実施形態では、複数のバージョンは、構造情報の全てを共有しなくてもよく、したがって、異なるバージョンが、異なる構造、分類、又は構造特性を有していてもよい。複数のバージョンは、特に、幾何的オブジェクト、オブジェクト分類及び構造特性、プロジェクト特性を含む様々な種類の入力プロジェクト状態情報を共有してもよい。複数のバージョンは、別々のデータセット間の一貫性を保つことにより、データを共有してもよい。これは、ポインタによって、メモリにおける同じ場所を参照するといったように、共有されたプロジェクト状態情報の同じコピーを複数のバージョンが参照することによって達成してもよい。設計設定、構造特性、プロジェクト特性等の入力データの種類それぞれは、１以上の個別のデータが共有され及び／又は１以上のデータが共有されないといったように、分岐されてもよい。
【０１０５】
関連するバージョンは、図１０Ａ及び図１０Ｂで説明したような階層構造の１つ以上の階層において、情報を共有してもよい。例えば、関連するバージョンは、設置現場、及び構造物と構造物の分離を含む設置現場の物理的特徴の共通の内容を共有してもよい。複数のバージョンは、階層構造におけるいかなる点で、互いに分岐してもよい。ツリー状の階層構造の場合には、分岐点の上方の要素は、複数のバージョン間で共有されてもよく、分岐点の上方のデータに対する変更は、両方のバージョンについて適用可能である。これに替えて、分岐点の下方のデータの２つ以上のコピーを維持してもよく、コピーはそれぞれのバージョンに対して維持され、１バージョンにおける分岐点下方のデータに対する変更は、（存在する場合には）別のバージョンにおける対応するデータに影響を与えない。
【０１０６】
ある実施形態では、複数のバージョン間における分岐点は、作業エリアの階層であってもよい。例えば、図１３には、１３０５に３つのバージョンが示されている。図示された例では、３つのバージョン１３０５は、設置現場に依存する関係となっており、それに従って、これらのバージョンは、設計規則１００４、構造１００２の一部又は全て、及びこれらの分類及び特性等を含む符号化された情報の複数のセットを共有してもよい。このような状況において、幾何的オブジェクトの別の構造種類への再分類、構造特性における変更等の設置現場１００１又は構造１００２に対する１つの変更を行うと、その変更が、３つのバージョン１３０５の全ての本質的部分に反映されてもよい。別の例では、バージョン１３０５のそれぞれは、別々の独立した作業エリア１００５、アパーチャ１０１０、及ぶ、レイアウトエンジンによって生成された関連したサブ要素（サブアレイ等、図示せず）を含んでもよい。この場合、作業エリア、アパーチャ又はサブ要素に変更が行われると（特定のモジュールを手動で配置、又は、列の配線パターンにおける変更等）、変更が行われたバージョンにのみ、その変更が適用されてもよい。これは、設計者が、構造分類等のプロジェクトの詳細設定は、全てのバージョンにおいて不変としたい場合に有用である。構造特性における１つの変更について、複数のバージョンを、設計者が手動で更新するのではなく、複数のバージョン間で共有された分類を提供するシステムを配置して、全ての関連するバージョンに対して自動的に更新を行うようにしてもよい。
【０１０７】
このように、プロジェクトデータ構造は、代替バージョンが、上記したように、独立した（共有されない）プロジェクト状態情報及び共有されたプロジェクト状態情報を含むような、設計の代替バージョンを含む。（共有されない）独立したプロジェクト状態情報は、バージョン毎に異なっている。共有されるプロジェクト状態情報と組み合わせる場合に、状態情報は、異なるバージョン間で異なる設置設計を規定してもよい。
【０１０８】
ある実施形態では、階層構造におけるより上位の階層又は下位の階層において、複数バージョンの分岐を行ってもよい。例えば、複数のバージョンは、階層構造における最も上位の階層において分岐してもよく、この場合、複数のバージョンは、構造分類を含む共通の構造を共有しない。これに替えて、複数のバージョンは、下位層において分岐してもよく、例えば、特定のサブアレイに対する列の階層において分岐する場合には、１つのバージョンが、南北方向に複数のモジュールが列になっているとすると、別のバージョンでは、主に東西方向に複数のモジュールがグループ化される。このような場合、２つのバージョンは、分岐点より上に位置する要素（全体的なアパーチャ設計設定等）を共有し、１バージョンにおけるアパーチャ設定の変更は、別のバージョンのそれにも影響を与える。
【０１０９】
図１４に示すように、幾つかの実施形態では、異なるバージョンを表示、生成、修正及び操作するためのインターフェースを提供してもよい。具体的には、１つ以上のバージョンのリスト１４００が提供されてもよい。リスト１４００は、所定のバージョンに固有の階層構造の１以上の階層を反映させてもよく、この例では、"バージョン１"に対して示されている。インターフェースは、バージョンを表示するべく、又はユーザーインターフェースにおける別のオペレーションのために、有効にする（又は選択する）、ツールボックス制御１４５０のようなメカニズムを提供してもよい。１４０５で示されるバージョン１のように、階層のレベルが表示される場合には、バージョン１ １４０５の第１アパーチャ１４１０のように、ユーザーがサブ要素を選択可能な制御を提供してもよく、視覚的表示において選択要素をハイライトする、特性ボックス（図示せず）を表示する、概要情報を表示する等、サブ要素に対する動作を起動してもよい。リスト１４００は、様々なバージョンの分岐点を反映又は表示してもよい。
【０１１０】
１つのバージョンがアクティブ化されると、そのバージョンのコンテンツが、視覚的表示に表示されてもよい。例えば、あるバージョンがアクティブ化されると、そのバージョンに対応するアパーチャ、作業エリア、構造特性、モジュールレイアウト、例外（以下参照）が表示されてもよい。バージョンがアクティブ化されると、レイアウトエンジンが、そのバージョンに対応した（そのバージョンの特性と一致した）レイアウトを再計算してもよい。また、アクティブ化に伴って、バージョンの概要情報のようなバージョンについての情報が、ステータス行又はフィールドに表示されてもよい。設置現場構造が、生成され分類されて、レイアウト、例外等が生成されると、これらの特性及び例外は、現在アクティブ化されているバージョンと関連付けられてもよい。
【０１１１】
アクティブ化されたバージョンに変更が行われ、その変更が、別のバージョン共有されている要素に対するものであったとすると、その変更は、別のバージョンにも反映されてもよい。例えば、２つのバージョンが、上記したように構造分類情報を共有しているとすると、設置現場の所定の構造の再分類、又は、その特性の変更は、両方のバージョンに影響する。アクティブ化されていないバージョンに変更が反映された場合には、そのバージョンと関連付けられたレイアウトの再計算を行ってもよい。バージョン間で共有されていない情報については、アクティブ化されていないバージョンに対する変更は、別のバージョンに影響しない。
【０１１２】
新しいバージョンを形成するべく、新しいバージョンのツールボックス制御１４５５のようなメカニズムが提供されてもよい。新しいバージョンは、一番最初から形成されてもよい（そして、設置現場の特性が適用されてもよい）。これは、最初のバージョンが、新たなプロジェクトの第１バージョン（その時点のみ）として、初期設定で生成される場合が考えられる。これに替えて又はこれに加えて、新しいバージョンは、プロジェクト特性及び構造分類（存在する場合）のようなソーラーコレクタ設置プロジェクト条件の一部を、１つ前のバージョンから継承してもよい。例えば、構造の１セットが規定及び分類されていたとすると、新たに形成されるバージョンは、これらの構造及び分類を継承してもよい。
【０１１３】
バージョンコピーツールボックス制御１４６０のようなメカニズムを提供して、バージョンをコピー又は複製してもよい。新しいバージョンは、既に存在するレイアウト又はバージョンからコピーをする（例えば、分岐する又は複製することによって）ことによって生成されてもよい。現在アクティブ化されているバージョンを使用して、新しいバージョンをそこから分岐させてもよい。複製されたバージョンが、元のバージョンと同じ状態情報の少なくとも一部を使用してシステムに投入された場合には、新たにコピーされたバージョンは、例えば、同じ設置現場特性、アパーチャ、アパーチャ特性、例外等、兄弟バージョンの特性の全て又は大部分から開始してもよい。変更が行われた要素が、バージョン間で共有されているか否かに応じて（図１３に示すように）、新たにコピーされたバージョに対する後の修正が元のバージョンに反映されてもよいし、されなくてもよい。ある実施形態では、ユーザーは、ユーザーが規定した設計設定の固有のセット、新たな又は複製されたバージョンに対応する、ユーザー規定の設計設定の固有セットに反映されていない構造特性、新たなバージョン又は複製バージョンの前に形成されたあらゆるバージョンに対応する構造特性に変更を行ってもよい。
【０１１４】
バージョン消去ツールボックス１４６５のようなメカニズムを提供して、例えば、表示からバージョンを取り除く、及びバージョンと関連付けられた記憶領域から取り除く等、バージョンを消去してもよい。例えば、バージョン名変更ツールボックス制御１４７０のような同様なメカニズムを提供して、バージョンの名前を変更してもよい。
【０１１５】
バージョン固有の情報を生成する、又は、バージョンを操作するためのメカニズムを提供してもよく、例えば、あるバージョンのパーツ概要を生成する（ＣＳＶファイル形式で）パーツ概要ツールボックス制御１４７５、バージョン情報を、例えば、データベース記録又は記録のセットのような別の形式で保存するためのバージョンエクスポートツールボックス制御１４７９、バージョンに関するシミュレーションを実行する及び／又はシミュレーションデータを生成するバージョンシミュレートツールボックス制御１４８５、バージョンシミュレーション情報を、例えばＣＳＶファイル形式等で保存又はエクスポートするバージョンシミュレーションエクスポートツールボックス制御１４９０を提供してもよい。上記した制御のそれぞれは、現在アクティブ化されているバージョン、選択されたバージョン、又は複数のバージョンのセット、又は全バージョンに適用してもよい。
【０１１６】
制御１４７７を使用して、プロジェクトの様々なバージョンの概要を生成してもよい。このバージョン概要は、各バージョンについて様々な比較情報を含んでもよく、例えば、ソーラーコレクタの数、コスト、重さ等のレイアウト情報、期待される性能、最大出力、キロワット／時間の発電に対するコスト、最小エネルギー生成等のシミュレーションデータ、例外数、種類等のその他の種類の情報が含まれてもよい。そのバージョンにおいて、不適格及び不十分、又は良好でない状態で配置されたモジュールに関する情報を、バージョン概要で示してもよい。バージョン概要情報はまた、予測される性能、シミュレーション情報、電力、電力効率、コスト、材料、物理的大きさ、部品点数、及び例外のような、各バージョンについての情報を生成してもよい。この情報は、作業エリア、アパーチャ、サブアレイ、モジュール、列等の特定のバージョンのサブ要素に対して、生成及び表示されてもよい。図１５には、複数のバージョン１５１０の概要が示されているバージョン概要１５００のサンプルが示されている。設計者は、様々なバージョンから選択し、及び／又は複数のバージョンにおける誤り又は不足を特定することを含めて、多くの目的で、バージョン概要情報を使用してもよい。バージョン概要情報は、外部のファイル又は記憶装置にエクスポートされてもよい。ユーザーは、どのバージョン概要情報を表示させるか又はエクスポートするかを選択してもよい。
【０１１７】
設置プロジェクトの様々なバージョンが複数のファイル、又は好ましくは、１つのファイルに保存されていてもよい。上記では、１つのバージョンの設置プロジェクトについて説明したが、複数のバージョンを有するプロジェクトを、ＸＭＬ形式で表示してもよく、最上階層である設置現場ノードは、構造及びそれらの分類のリストを含んでもよい。設置現場ノードは、複数のバージョンノードを含んでもよく、バージョンノードは、複数の作業エリア及びアパーチャノードを含んでもよい。アパーチャノードのそれぞれは、サブアレイノード等を含んでもよい。バージョン概要情報、バージョン名等のバージョンと関連付けられたデータは、バージョンと共に格納されていてもよい。具体的には、ソーラーコレクタレイアウト情報、バージョン概要情報、シミュレーションデータ、契約情報、部品表情報、例外情報等のバージョン毎に異なる場合がある設計出力情報を、キャッシュ又は格納してもよく、バージョンと同じ場所に配置してもよい。
【０１１８】
ある実施形態では、ツールバーアイコン又はキーボードショートカットのような"取り消し"制御を提供して、設計者が、プロジェクト及び／又はバージョンに対して行った１以上の変更を取り消せるようにしてもよい。ある実施形態では、設計者があるバージョンに対して変更を行う場合、それが、レイアウトの修正であれ、オブジェクトの分類であれ、その変更が実施形態により記録される。そして制御は、その効果を反転させることにより、ユーザーが変更を"取り消し"することを可能にする。ある実施形態では、変更を、プロジェクト又はバージョンの状態のスナップショットを撮ることによって記録してもよい。実施形態は、そのスナップショットに戻ることにより、変更を取り消してもよい。これに替えて、実施形態は、変更（又はその反転）によって実体化される状態の遷移を記録してもよい。この状態遷移を逆転させることによって、"取り消し"が実行されてもよい。このように、スナップショット又は遷移のスタックを使用することにより、様々なレベルの取り消しを維持することができる。同様に、"取り消し"アクションが、スナップショット又は遷移を反転させる（"やり直し）アクションを起こし、"取り消し"の反転を、やり直しのスタックに押し込むことにより、やり直し機能を実装してもよい。
【０１１９】
［８．実施例］
図１６Ａ〜図１６Ｅには、本明細書で説明したシステム及び方法の一部の実施形態に係るレイアウトソフトウェアからのスクリーンショットの例が示されている。図１６Ａに示すように、ユーザーインターフェース１６００には、設置現場の可視的表示１６０１が示されており、屋根外縁１６０２で揃えられている２つの傾斜を有する屋根面に対応する幾何的オブジェクトが配置され、幾何的オブジェクトは、複数の立体障害物（通気孔１６０３）及び線形障害物（パイプ１６０４）を含む。ユーザーインターフェース１６００は、ツールバー１６０５及び特性パレット１６０６を含む。インターフェースは、バージョン表示（図示せず）、バージョン概要（１６２０）、例外リスト（図示せず）、ユーザー入力及びシステム出力のためのフィールド１６３０を有してもよく、これらを同時に表示してもよい。
【０１２０】
図１６Ｂに示されるように、ツールバー１６０５の形式の制御によって、ユーザーが構造としてオブジェクトを分類する機能（ここでは、屋根制御１６１０、立体障害物制御１６１２、及び線形障害物制御１６１３が示されている）、及び、作業エリアの境界１６１１を視覚的表示に形成する機能を提供してもよく、作業エリアは、太陽モジュールを配置してもよい範囲を規定している。オブジェクトの分類を解除する１６１４制御を提供してもよい。実際のレイアウトを生成する１６１６制御と共に、レイアウトアパーチャ１６１５を生成する制御を提供してもよい。例外リスト、特性パレット、バージョン概要、バージョンリスト等のどのインターフェース要素を表示させるか選択するのに表示制御１６２５が提供されてもよい。レイアウトは、実質的に、作業エリアの境界とアパーチャの境界との交差点に限定され、アパーチャと関連付けられた設計設定のセットに少なくとも一部したがって、レイアウトが生成される。図に示すように、有用な（特に限定しない）テキストが、ポップアップ、ロールオーバー等の形態の制御で提供されてもよい。図１６Ｃに示すように、同様な機能を達成する制御を含むメニューが、提供されてもよい。図１６Ｄに示すように、特性パレットは、ユーザーが、特定の構造に関する特性を見る及び／又は調整することを可能にする。
【０１２１】
図１６Ｅは、ＰＶモジュールのレイアウトを視覚的表示で生成した結果であり、２つの屋根オブジェクト１６０２、大部分がそれぞれの屋根表面と同じ場所に存在している２つの作業エリアの境界、及び３つのアパーチャ境界（そのうち２つは、矩形状のアパーチャ１６５０であり、１つの屋根及び１つの作業エリアの一部のみにわたって延在し、残りの１つは、不規則な形状をしたアパーチャ１６５０Ａであり、２つの屋及び作業エリアの一部にわたって延在している）が含まれている。図示するように、アパーチャは、アパーチャ内に配置された複数のモジュールのセットを有し、これらモジュールのレイアウトは、アパーチャ内に含まれる対応する屋根、作業エリア及び障害物に関するレイアウト規則に従っている。
【０１２２】
［９．結び］
上記の説明における分類及び規則は、添付の特許請求の範囲によって規定される発明を実施する方法の一部を単に示したものに過ぎないことは、当業者にとって明らかである。設置現場に関するレイアウト要求に基づいて、ＰＶモジュールを幾何的オブジェクト内及び周辺にレイアウトするその他の方法を、同様な結果、表、スクリプト、データ構造等を達成するのに使用してもよい。規則は、上述したように、明示的であってもよいし、及び／又は宣言文を含んでもよく、又は、ＬＩＳＰのような規則中心の言語で使用されているようなものであってもよい。これに替えて、１以上の"規則"は、データ構造、命令ステートメント、プログラムフロー、プログラム構築、配置及び配置アルゴリズムにおいて非示的に表現されたものであってもよい。本明細書で使用されている規則は、ツールがＰＶモジュールレイアウトを生成するのに使用する任意のオブジェクトに関連付けられた情報による一般的な方法の一例を示したに過ぎない。レイアウト制限のような特定の規則は、特定のオブジェクト又は構造、及び／又は特定の種類又は構造の分類と明示的に関連付けられていてもよく、このような規則は、レイアウトエンジンの一部として規定されていてもよいし、非明示的にオブジェクト又は分類と関連付けられていてもよい。
【０１２３】
本明細書に記載されるシステム、方法及び技術は、コンピュータハードウェア、ファームウェア、ソフトウェア又はこれらの組合せに実装されてもよい。これらの技術を実体化するシステムは、適切な入力及び出力コンポーネント、コンピュータプロッセサ、及び、機械可読記憶要素に実体化されたコンピュータプログラム製品、又は、プログラム可能プロセッサによる実行のための媒体を含んでもよい。これらの技術を実装するプロセスは、入力データに対する操作及び適切な出力を生成することによって所望の機能を実行するプログラムの命令を実行するプログラム可能プロセッサによって実行されてもよい。技術は、プログラム可能システムから命令及びデータを受信し、データ及び命令をデータ記憶システムへと送信するべく接続された少なくとも１つのプログラム可能プロセッサ、少なくとも１つの入力コンポーネント、少なくとも１つの出力コンポーネントを含む。コンピュータプログラムはそれぞれ、高級手続き型プログラミング言語又は高級オブジェクト指向プログラミング言語に実装されていてもよく、又は、必要に応じて、アセンブリ言語又は機械言語に実装されてもよい。いずれの場合においても、言語は、コンパイルされても、インタープリタ型言語であってもよい。好適なプロセッサとしては、例えば、汎用マイクロプロセッサ及び特殊用途マイクロプロセッサの両方を含む。多くの場合、プロセッサは、命令及びデータを、リードオンリーメモリ及び／又はランダムアクセスメモリから受信する。コンピュータプログラム命令及びデータを好適に実体化して実装するのに好適な記憶要素は、あらゆる形式の不揮発性メモリを含む。不揮発性メモリの例としては、消去可能プログラム可能リードオンリーメモリ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ要素のような半導体メモリ要素、内蔵ハードディスク及びリームバルディスクのような磁気ディスク、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭディスク）が含まれる。上記のいずれの要素も、特別に設計されたＡＳＩＣ（特定用途向け集積回路）に組み込まれてもよいし、ＡＳＩＣによって補ってもよい。様々なデータ構造のそれぞれの表示、及び上記した方法の段階は、好適に、レンダリングされてもよく、例えば、スクリーン、モニター又はプリンタといったデバイスに、表示される、又は印刷されてもよい。
【０１２４】
本明細書の開示は、特定の実施形態及び適用例を記載しているが、本明細書に記載されている特徴及び効果の全てを提供しないような実施形態及び適用例を含む当業者にとって明らかなその他の実施形態及び適用例も、本開示の範囲内に含まれる。また、選択肢及び代替構成のリスト及び詳細の全ては、例示するものとして解釈されるべきであり、限定するものとして解釈されるべきでない。また、リストは、説明を補助する目的で提供されており、可能性のある代替物の全てを列挙することを試みたものではない。本発明の範囲は、特許請求の範囲を参照することによってのみ規定されることを意図している。
【０１２５】
プロジェクト設計に依存する情報出力のサンプル
【表１】
【０１２６】
太陽光プロジェクト設計の段階のサンプル
【表２】
【０１２７】
構造分類のサンプル
【表３】
【０１２８】
構造特性のサンプル
【表４】
【０１２９】
設計設定のサンプル
【表５】
【０１３０】
プロジェクト設計特性のサンプル
【表６】
【０１３１】
モジュール特性のサンプル
【表７】
【背景技術】
【０００１】
近年、太陽光発電は、非常に重要なエネルギー資源となりつつある。太陽光エネルギーは、様々な方法で収集及び利用することができ、太陽電池（ＰＶ）モジュール及び太陽熱による熱及び電力の収集及び変換のような、ソーラーコレクタ（太陽光熱の収集器）の利用が含まれる。これらのプロジェクトは、一家族の屋根に設置されるような家庭向けの利用から、百万個を超えるＰＶモジュールを設置する大規模なものまで、その大きさは様々である。
【０００２】
太陽光発電設備のコスト、寿命、エネルギー生成及び経済的価値は、多くの複雑に相関するパラメータに依存し、これらに限定されないが、パラメータとしては、例えば、１）ロケーション、２）気候、３）天窓のような、レイアウトと干渉する物理的な障害物、４）敷地の境界線による妨げ、又は、電線の敷設権のような非物理的な場所の構造、５）システムが影になってしまう原因となる物理的障害物、６）重量制限及び防火規定を定める地域の建築基準法、７）風速耐性設計のような環境的条件、８）地面、屋根、又は駐車場の上部の骨組み等の設置表面、９）地方及び国の法律、１０）電力の電気接続条件、１１）顧客の設置現場における既存の電力設備、及び、１２）顧客の電力又はエネルギーコストが挙げられる。これらの条件に適合する効率的なシステムを設計及び分析する仕事は、複雑で時間が掛かり、また、誤りも多く、太陽エネルギープロジェクト開発において、一番コストの掛かる仕事となる場合がある。
【発明の概要】
【０００３】
物理的設置現場におけるソーラーコレクタ設置の設計を自動化するためのコンピュータベースのユーザーインターフェースを開示する。ユーザーインターフェースは、物理的設置現場の少なくとも一部の表示を含んでもよい。表示は、１以上の幾何的オブジェクトを含んでもよく、１以上の幾何的オブジェクトは、物理的設置現場における物理的又は非物理的構造、又はその他の構造に対応していてもよい。ユーザーインターフェースはまた、幾何的オブジェクトを、特定の構造分類のインスタンスとして分類するよう動作する制御を含んでもよい。構造分類は、予め存在する複数の構造分類から選択されてもよく、特定の構造分類は、詳細事項、物理的又は非物理的構造の特徴の全て又は一部と関連付けられていてもよい。特徴は、ソーラーコレクタ設置設計と関係したものであってもよい。ユーザーインターフェースはまた、物理的現場における設置のためのソーラーコレクタ設置設計を少なくとも１つ自動的に生成するよう動作する制御を提供してもよい。１以上の幾何的オブジェクト、構造分類及び現場と関連付けられた物理的構造の特徴の詳細事項に、実質的に又は完全に従って、設計が生成されてもよい。
【０００４】
また、物理的現場に設置するためのソーラーモジュール設置レイアウトを生成するシステムが、開示される。システムは、ソーラーモジュール設置レイアウトを生成するための特性と幾何的オブジェクトとを関連付けることができる分類コンポーネントを含んでもよい。幾何的オブジェクトは、コンピュータストレージに記憶されていてもよい。複数の幾何的オブジェクトのうちの少なくとも１つが、物理的設置現場における物理的構造又は非物理的構造に対応していてもよい。カテゴリ化コンポーネント又は分類コンポーネントは、複数の幾何的オブジェクトのそれぞれの内側にソーラーモジュールをレイアウトするために、１以上のオブジェクトを作業エリアと関連付けてもよい。コンポーネントはまた、（先に規定したオブジェクトに加えて）１以上の幾何的オブジェクトを、１以上の幾何的オブジェクトの第２グループ内のソーラーモジュールレイアウト禁止領域と関連付けてもよい。システムはまた、レイアウトコンポーネントを含んでもよい。レイアウトコンポーネントは、タイリングを使用してもよく、ソーラーモジュールを少なくとも１つの作業エリアにタイル状に配置することにより、ソーラーモジュールの設置レイアウトを生成してもよい。その後に、コンポーネントは、オブジェクトに関連付けられたソーラーモジュールのレイアウトの禁止に従って、レイアウトから１以上のタイリングされたソーラーモジュールを取り除いてもよい。
【図面の簡単な説明】
【０００５】
【図１】屋根、換気扇及び配線管を含むソーラーコレクタ設備の設置現場の例を示した、概略的な等角図である。
【図２】図１の設置する設置現場を表した、屋根、換気扇及び配線管の構造に対応する幾何的オブジェクトを含む視覚的表示が表示されているユーザーインターフェースを概略的に描いた図である。
【図３】図２のユーザーインターフェースが描かれており、視覚的表示における第１の幾何的オブジェクトが、"屋根"として分類され、構造特性の第１セット及び対応するレイアウト制限に関連付けられる様子を示した図である。
【図４】図３のユーザーインターフェースが描かれており、視覚的表示における第２の幾何的オブジェクトが、"障害物"として分類され、構造特性の第２セット及び対応するレイアウト制限に関連付けられる様子を示した図である。
【図５Ａ】図４のユーザーインターフェースが描かれており、ＰＶモジュールの種類、方向及び開始点を含むレイアウト生成の設計設定のセットの一例を入力する様子を示した図である。
【図５Ｂ】図５Ａのユーザーインターフェースが描かれており、入力（例えば、構造的特性、プロジェクト特性及び設計設定）及びレイアウト規則（例えば、レイアウト制限、環境因子、その地域の建築基準等）に従って、レイアウトエンジンにより、ＰＶモジュールのレイアウトが生成された様子が示されている。
【図６Ａ】ソフトウェアの実施形態を使用して、図５Ｂに示されたような、ＰＶモジュールレイアウトを生成するプロセスを示したフローチャートである。
【図６Ｂ】図５Ａのユーザーインターフェースが描かれており、図６Ａの第１パスのプロセスの一実施形態に従った、ＰＶモジュールレイアウトが屋根の上にタイル状に配置された様子を示した図である。
【図７Ａ】図５Ａのユーザーインターフェースが描かれており、ユーザーが、設置現場内に、１つ以上の近接するサブエリア及び"作業エリア"を形成したところであり、設置現場におけるモジュールの設置場所に対する所有者による設定が幾何的表示に示されている様子を描いた図である。これは、例えば、設置現場が、建物及び未開発の土地の両方を含み、所有者が、モジュールを建物上にのみ配置することに興味がある場合などが想定される。
【図７Ｂ】図７Ａのユーザーインターフェースが描かれており、作業エリア特性、構造特性、レイアウト制限、設計設定及びその他のレイアウト規則に従って、ＰＶモジュールレイアウトが生成された様子を示した図である。
【図８Ａ】図５Ａのユーザーインターフェースが描かれており、ユーザーが生成した２つのアパーチャ、及びその設計設定が規定された様子を示した図である。
【図８Ｂ】図８Ａのユーザーインターフェースが描かれており、各アパーチャに対するアパーチャ設計設定、及び、プロジェクト特性、構造特性、レイアウト制限及びその他のレイアウト規則に従って、ＰＶモジュールレイアウトが生成された様子を示した図である。
【図９Ａ】それぞれが異なるアパーチャ設計設定を有するユーザーが規定した複数のアパーチャに従って、レイアウトエンジンにより形成されてもよいＰＶモジュールレイアウトの形成プロセスを示したフローチャートである。
【図９Ｂ】それぞれが異なるアパーチャ設計設定を有するユーザーが規定した複数のアパーチャに従って、レイアウトエンジンにより形成されてもよいＰＶモジュールレイアウトの形成プロセスを示したフローチャートである。
【図１０Ａ】本明細書の教示に従って、ソフトウェアアプリケーションで配置された設置現場構造及びソーラーコレクタを表すデータの階層構造の一部を概略的に示した図である。
【図１０Ｂ】本明細書の教示に従って、ソフトウェアアプリケーションで配置された現場構造及びソーラーコレクタを表すデータの階層構造の一部を概略的に示した図である。
【図１１】警告、エラー及び契約例外事項を含む例外事項のリスト、及び設計者が例外事項を表現する様々なメカニズムを含むユーザーインターフェースを概略的に示した図である。
【図１２】ユーザー入力及び生成されたレイアウトが認証され、例外事項が生成されてもよいプロセスを示したフローチャートである。
【図１３】図１０Ａのプロジェクト要素の階層を表した図であり、代替構造の特性、設計設定、プロジェクト特性等のユーザーの選択に応答して、ソフトウェアによって形成された、レイアウトの複数のバージョンを部分的に表示するよう拡張された様子を示した図である。
【図１４】プロジェクト設計のバージョンリスト及びバージョンに応じた動作を制御することを含むユーザーインターフェースを概略的に描いた図である。
【図１５】バージョンの要約の一部を概略的に示した図である。
【図１６Ａ】ユーザーが幾何的オブジェクトを分類し、構造特性、プロジェクト特性、レイアウト規則及び設計設定に従って生成されたＰＶモジュールレイアウトが表示された別の例示的ユーザーインターフェースのスクリーンショットが示されている図である。
【図１６Ｂ】ＰＶモジュールのレイアウト及び分類に関連した機能に対するツールバー制御を提供する例示的ユーザーインターフェースを描いたスクリーンショットである。
【図１６Ｃ】ＰＶモジュールのレイアウト及び分類に関連した機能に対するメニュー制御を提供する例示的ユーザーインターフェースを描いたスクリーンショットである。
【図１６Ｄ】構造特性、設計設定及びその他のユーザー入力へのアクセス及び修正のためのパレット制御を提供する例示的ユーザーインターフェースを描いたスクリーンショットである。
【図１６Ｅ】図１０Ａのユーザーインターフェースが描かれており、ユーザー入力（例えば、構造的特性、プロジェクト特性及び設計設定）及びレイアウト規則（例えば、レイアウト制限、環境因子、その地域の建築基準等）に従って、ＰＶモジュールのレイアウトが生成されたユーザーインターフェースを描いたスクリーンショットである。
【発明を実施するための形態】
【０００６】
コンピュータ支援設計（ＣＡＤ）は、何十年にもわたって、商業利用されている。ＣＡＤシステムは、設計情報の形成、編集、表示及び検索を自動化する効率的な方法を提供する。ＣＡＤシステムの能力は、知識集約型のプログラミング技術の利用により向上し、エンジニアリング及び／又は設計規則を形式化及び符号化して、設計プロセスの一部を自動化する、又は、潜在的な設計エラーを検出するべく実行することができる。知識集約型のシステムの一般的な例としては、多くの商用ワードプロセッサに適用されている文法チェック機能が挙げられ、英文法の多くの規則が符号化されて、自動的にテキスト文書に適用されて、潜在的な誤りをハイライトし、正しいアクションを提案する。
【０００７】
本明細書に記載するシステム及び方法は、その土地の状態、工法規則及び建築基準法等の多数の設計制限に従った太陽エネルギーシステム設計の自動レイアウト、評価及び最適化に対する、知識集約型のＣＡＤ技術の適用に関する。好ましい実施形態は、ＡｕｔｏＣＡＤ（登録商標）のような、既存のＣＡＤシステムに対するソフトウェアのカスタマイズを統合したセットとして実装される。または、本明細書に記載されるシステム及び方法は、全く新しいスタンドアローンのソフトウェアプログラムとして実装されてもよい。
【０００８】
本明細書に記載される本発明の好ましい一実施形態では、所定の作業場所における設置に適したソーラーコレクタのレイアウトを設計する方法及びシステムを提供する。実施形態は、様々なデータオブジェクトを生成及び編集し、このようなオブジェクトを、付随する特性及びレイアウト制限を伴う予め規定された"構造"の様々なタイプで分類する。構造の種類又はカテゴリは、（１）壁、屋根及び換気扇等の設置現場の物理的構造、（２）敷地境界、区画の境界、電線の敷設権、洪水が起きる土地、環境を配慮したエリア、特定の地震帯、公共設備の地役権等の設置現場の無形資産又は非物理的構造、並びに（３）太陽エネルギーシステム構成要素及び配置、を含んでもよい。分類の一部として、又は分類に加えて、実施形態は、固有特性又は付随する特性をオブジェクトに対して、生成する、割り当てる又は編集するシステム及び方法を含んでもよい。固有の構造的特性としては、高さ、重さ、コスト等のオブジェクトそのものに固有の特性が含まれる。付随する特性は、どのようのオブジェクトが、その他のオブジェクトとインタラクション（対話）するかの規定を含む。外因性特性の例としては、オブジェクトと別の隣接するオブジェクトとの間の最小距離（セットバック）を確立するセットバック規定が含まれる。
【０００９】
例えば、特定の法域では、敷地境界から３０フィート以内に、構造物を設置することが許可されていない場合がある。一実施形態に係るシステムを使用することにより、ユーザーは、最初に、次のようにして、"敷地境界"構造分類を生成してもよい。ユーザーは、（１）"敷地境界"と名付けた新たな種類の構造分類を形成する、（２）敷地境界の構造分類の視覚的表示として、黒色の点線を設定する、（３）"セットバック"と称される特性を規定し、"敷地境界"構造分類に割り当てる、（４）この構造分類に、例えば、３０フィートといった初期値を割り当てる、（５）特定の設計における利用、又は、あらゆるプロジェクト設計における一般利用に対する構造分類データベース内に、この構造分類規定を格納する。
【００１０】
次に、設計者は、予め規定された構造分類の"敷地境界"を、以下のように使用してもよい。設計者は、（１）設置現場の表示を、実施形態として生成する又は取り込む、（２）設置現場表示において、予め規定された分類である"敷地境界"に、１以上の幾何的要素（例えば、線）を割り当てる、（３）必要に応じて、オブジェクトの"セットバック"の値を、例えば、２０フィートに変更する、（４）"敷地境界"と記されたオブジェクトのセットバック規定に準拠した、ソーラーコレクタのレイアウトを含む、太陽光システム設計を生成するように実施形態に命令する。
【００１１】
ソーラーコレクタレイアウトを生成するプロセスの一部として、本発明の好ましい実施形態は、（１）設計規則を生成する、（２）１以上の太陽エネルギーシステム設計の代替案を生成するべく、上記したオブジェクトに、設計規則を適用する、（３）１以上の設計代替案の配置又は物理的レイアウトの画面表示及び／又は紙表示を生成する、（４）部品点数、最大能力、コスト及びエネルギー生成のような１以上の設計の１以上のバージョンの概要を生成する、（５）ユーザーに柔軟性を提供する、並びに、顧客、設計、法的及び製造者の要求に対処することを確かにするメカニズムとして、ユーザー順守又は修正マニュアルに対する修正、又は設計規則の無効化等のソフトウェア符号化された設計ルールに対する例外を追跡する、及び（６）設計者が、設計代替案及び設計修正案の相対的な利点をリアルタイムで評価する、及び設計最適化を助けることを可能とする、可視化された情報を生成すること、を行うための方法及びシステムを提供する。
【００１２】
好ましい一実施形態に係る方法の動作は、（１）設置現場を表す情報を、知識集約型太陽ＣＡＤシステムに取り込む、又は、ＣＡＤシステムを使用して、設置現場を表す幾何的表現を生成する、（２）分類又はカテゴリ化によって、設置現場を表す関係する幾何的要素のそれぞれを、所定のデータオブジェクト種の１以上のインスタンスとして関連付け、それぞれの特性を調整する、（３）例えば、プロジェクトレイアウトを目的とする設置現場のエリアのような"作業エリア"を指定する、（４）ソーラーコレクタの種類及び設置サイズのような設計設定を選択する、（５）設置現場のデータ表示及びそれに付随する特性に従って、自動的に設計を生成する、（６）１以上の測定基準に従って設計を評価する、（７）設計代替案の生成及び比較を行う、（８）設計修正及び設計代替案の選択による、設計の最適化を行う、及び（９）設計上の例外規定のような、設計例外事項のリストの生成、を含む。
【００１３】
関連付けは、設置現場表示における特定の幾何オブジェクトを分類することによって行われてもよく、例えば、構造物の種類のインスタンスを、"屋根"又は"換気扇"といったように分類してもよい。このような分類は、幾何的オブジェクトを、特定の特性及び、太陽エネルギーシステムの自動設計を実行するのに使用されるレイアウト制限と関連付けるべく行われる。設置現場の特性、レイアウト制限、設計設定、モジュール特性及び制限、性能目標等に関連する更なる設計規則及び特性を、規定してもよい。この符号化された情報の全てが、ツールによって使用され、設計者による設定、プロジェクト制限、工学的慣例、建築基準法等に従った太陽モジュール設置に対する設計が、自動的に生成される。そして、配線図、部品表、説明、規約、概要、監査報告、その他の提出物、又は以下に示す表１に従った出力のような関連情報が生成される。
【００１４】
上記したように、ツールは、レイアウト生成に関して１以上の特定の境界を規定できる能力を設計者に提供することにより、レイアウト生成の制御を提供してもよい。ユーザーは、（例えば、分類されたオブジェクトの特性のような、その他の特性及び規則に整合して）ソーラーコレクタの設置が許される場所の境界に対応する作業領域を１以上規定してもよい。ユーザーは、例えば、ソーラーコレクタモジュールのレイアウトを設置現場の一部、例えば、屋根の南側に面した部分に制限するといったように、作業エリアを使用してもよい。ユーザーはまた、１以上のレイアウトアパーチャ（ａｐｅｒｔｕｒｅ）を規定してもよく、レイアウトアパーチャのそれぞれは、ユーザーが規定した異なる設計設定のセットに準拠すべきレイアウトにおける境界に対応していてもよい。異なる設計設定を有するアパーチャを使用することにより、ユーザーが、例えば、一種類のモジュールを屋根の一領域に配置し、別の種類のモジュールを屋根の別の領域に配置するといったことが可能となる。
【００１５】
ある実施形態では、設計者が、上述したように、構造の分類、レイアウトの生成、そして、レイアウトの修正といったプロセスを経るに従って、設計プロセスに関するメタデータが生成されてもよい。このメタデータは、多くの形式をとってもよく、また、設計者が行った及び行うべき動作についての情報を含んでもよく、監督者、共同設計者及びダウンストリームのユーザー、及び設計の受取人にとって有用な設計情報を含んでもよい。
【００１６】
ある実施形態では、このメタデータの一部又は全てが、設計者に、ソフトウェアにおける符号化された規則に対する例外といった形式で表示されるユーザーインターフェースが提供されてもよい。規則は、顧客の要求、国の法律及び規整、工学的制約、ソーラーコレクタ製造ガイドライン等から生成されていてもよい。例外としては、プロジェクト作業エリアのロケーションのような特性情報が提供できない場合が含まれる。設計者は、この例外の情報を、様々な方法でやり取りしてもよく、例えば、規則を適用することで、例外リストから項目を取り除く、又は、規定の適用を無効化するといった方法でやり取りしてもよい。メタデータの一部又は全てを、共通のストレージ又は参照によって、設計と関連付けてもよい。その後、ダウンストリームユーザー及び自動化システムを含む設計の処理者が、情報にアクセスしてもよい。情報は、また、要約、エクスポート、暗号化、されてもよく、また、システムによって演算されてもよい。例外のリストは、ユーザーにとっての"ＴｏＤｏ（やるべきことの）リスト"として機能してもよく（ユーザーインターフェースにおいても同様に称されていてもよい）、ソフトウェア規則が対処されるシーケンスと同時に、確かにソフトウェア規則が対処されることを確かにする、ユーザーに柔軟性を与える。例外、及び、それらがどのように扱われたかの情報は、後の再検討のために、履歴として維持することができ、契約書が、通常でない又は非標準選択肢を反映したものであることを確かめる一助となる。
【００１７】
ある実施形態では、特定の設置現場に対して、ソーラーコレクタレイアウト設計の複数のバージョンを見る、生成する及び操作するためのシステム及びユーザーインターフェースを提供してもよい。複数のバージョンの使用により、例えば、設計者が、入力（例えば、設計設定及び／又は特徴、又はプロジェクト特性）を素早く且つ容易に変更することができ、同じプロジェクトに対する代替設計選択肢（例えば、様々な種類のＰＶモジュールを使用することによるコストへの影響）に対応する生成された出力（例えば、代替レイアウト案、コスト、性能データ）を見ることができる。複数のバージョンを提供することにより、設計者は、ユーザー入力における変更に基づいて異なるレイアウトを迅速にモデル化でき、またその結果を評価することが可能となる。ある実施形態では、設計者は、一のバージョンから別のバージョンへと迅速に移動することができ、また、別の実施系形態では、設計者が、１つのアクションで複数のバージョンに影響を与えることを可能としてもよい。複数のバージョンは、複数の要素、特性又は設計規則の1以上のセットを共有してもよく、このようにすることにより、一のバージョンに適用された変化を、関連する複数のバージョンに適用可能としてもよい。例えば、新たに発見された現場の構造を追加するといったような、設置現場に一般的な変更を行う場合、複数のバージョンについても同様な変更を反映させてもよい。複数のバージョンは、例えば、１つのファイル又は複合ファイルに情報を位置させることによって、情報を共有してもよい。
【００１８】
［１．序論］
本明細書に記載する原理は、一般的な太陽エネルギー収集設備に適用可能である。パネル、吸収体及び反射体といった様々な種類の太陽エネルギー収集器、及び、太陽電池（ＰＶ）モジュール、太陽熱吸収装置、集光型太陽熱発電（ＣＳＰ）等のその他のエネルギー変換技術が、使用されてもよい。ソーラーコレクタは、そのまま取り付けられてもよいし、又は、様々な種類の搭載システムに配置されてもよい。搭載システムとしては、タイル状システム、固定システム及び追跡システムが含まれる。システムは、公共の電力設備にオングリッド接続されるように設計される、及び／又はオフグリッドシステムに接続させるように設計されていてもよい。ソーラーコレクタ及び搭載システムは、地面、屋根の上、壁、駐車場の建物等に、様々な形態で取り付けられてもよい。説明を容易にするため、本明細書では、大部分をＰＶモジュールの設置に関連して説明している。しかしながら、実施形態は、上述したように、ソーラーコレクタ全般に適用可能である。
【００１９】
ＰＶ設備の設計タスクには、一般的に、簡単ではない共依存の複数のプロセスが含まれる。このようなプロセスとしては、例えば、（１）入手可能性、コスト、効率、電力条件等に基いて、特定のＰＶモジュールを選択する、（２）設置現場におけるＰＶモジュールの配置（レイアウト）を生成する、（３）設置したＰＶモジュールに対する配線図（ルーティング図）を生成する、（４）複雑なプロジェクト固有の入力に基いて、電力生成、電力変換効率等のプロジェクトの生産能力を見積もる、（５）プロジェクトの部品表（ＢＯＭ）、契約書等のダウンストリームにおける書類を作成する、等が含まれる。無論、上記の全てが、地方の規制、国の法律等に沿って実行されなければならない。大規模太陽光プロジェクトにおいて実行される典型的な段階のシーケンスが、表２に示されている。
【００２０】
設備のサイズが大きくなればなるほど、例えば、モジュールの数が増えれば増えるほど、上記のプロセスを実行する難しさが増加する。例えば、所定の行に１つのモジュールを追加するといったような、表向きは些細な変更であっても、配線接続形態及び／又はその他のモジュールの配置に対して大きな影響を与える場合があり、したがって、生成されるシステム設計及びシステムの出力（出力電力等）に対しても大きな影響がある。このような複雑性が存在することから、モジュールの再配置、追加又は除去を含むレイアウトの最適化又は修正は、難しく、特に、大規模なプロジェクトでは、試行錯誤のプロセスと似通ったものになってしまう。一般的に、１０〜２０週かけてプロジェクト設計が終了する、又は、何ヶ月かを経て契約を締結する時には、レイアウトに元々使用することを考えていた構成要素が、市場ではすでに手に入らなくなってしまい、大幅な設計変更が必要になってしまうかもしれない。
【００２１】
設置現場の設計過程における、退屈な及び複雑な作業は、自動化ツールを使用することにより、削減することができる。具体的には、ソフトウェア又はその他のコンピュータに実装されるツールが本明細書に記載され、これらは、工学的慣例、設計者の好み及び設置現場の状態に対応する符号化された情報に基づいて、設置現場の設計を自動的に生成する。このようなツールの一部は、例えば、ＡｕｔｏＣＡＤ．ＤＷＧファイルのような、設置現場のＣＡＤ表示を、開始点として使用する。このファイルは、設置現場のベクトル又はビットマップ表示を含んでもよく、典型的には、線、ポリライン、曲線、正方形、矩形、スプライン、記号、多角形、その他の二次元又は三次元の形、面、立体、画像データ等の幾何的オブジェクトの集合によって、表示が行われる。この表示では、一般的に、幾何的オブジェクトには意味情報がほとんど又は全く添付されておらず、この表現における情報は、設置現場の物理的特徴に対応する形状及び大きさに限定されてもよい。例えば、換気扇を有する屋根の２Ｄ平面図表示は、大きな矩形（屋根）を形成する４つの線のセットと、小さな正方形（換気扇）を形成する４つの線のセットとによって構成されており、小さな正方形が、大きな矩形に内包された表示となっている。ＣＡＤの従来のツール、及びある実施形態では、ユーザーが、このような、幾何的オブジジェクトの初期表示を生成することができる機能を提供してもよい。これに替えて、ユーザーは、コンピュータファイルのような格納場所から、幾何的オブジジェクトの初期表示を取り込んでもよい。
【００２２】
ある実施形態では、表示で使用されるオブジェクトを分類する（例えば、カテゴリ化又はタグ付け）メカニズムが提供されてもよく、オブジェクトを、構造種類のような、モジュールレイアウト生成に関係する意味情報と関連付けてもよい。例えば、上記の線のセットを、ユーザーは、事前に存在する構造物の種類である"屋根"のインスタンスとして、分類してもよい。システムは、オブジェクトを、屋根とモジュールレイアウトとの間の関係に対応する意味情報のセットと関連付けるのに、この分類を利用してもよい。この情報は、屋根に固有の物理的特性、例えば、"ピッチ＝１７度"及び"高さ＝３０．０フィート"、及び／又は、屋根に付帯する特性（例えば、"エッジセットバック＝１．０フット"）と、関連付けられていてもよい。このような特性は、多くの場合、ユーザーによって編集可能であり、同じ汎用型の異なるインスタンスによって変化してもよく、また、司法域（例えば、都市計画法など）によって変化してもよい。構造分類のリストの例が、表３に示されており、また、構造特性のリストの例が、表４に示されている。
【００２３】
同様に、ユーザーが、設置現場の表示における別のオブジェクト（又は複数のオブジェクトのセット）を、構造種類"換気扇"のインスタンスとして分類してもよい。その後で、システムは、オブジェクトを、"高さ＝３フィート"といったように、換気扇に対応する構造特性と関連付ける。ある実施形態では、事実上、無限数のオブジェクトを、様々な特性を有する構造の様々な種類で分類してもよい。これら様々な構造の幾つかについて、構造特性を、カテゴリ的に予め定めてもよく（特定の分類又は種類のインスタンスそれぞれに対して、適用可能であって且つ不変である）、その他の構造特性は、単なる初期値、インスタンス固有の値であってもよい。ユーザーは、高さのような数多くの構造特性を、必要に応じて及び／又は適宜調整してもよく、全体的な構造種類に対応する構造特性のような、その他の構造特性については、ユーザーが編集できる、又はできないようにしてもよい。このように、分類されたオブジェクトは、その他の分類されたオブジェクトと共通の及び／又は固有の構造特性を有してもよい。
【００２４】
特定のオブジェクトに関連付けられた意味情報は、特定の構造分類の全てのインスタンスに対して通常は不変である、一般化された設計規則に対応していてもよい。例えば、屋根として分類されるオブジェクトは、システムよって、例えば、"コレクタレイアウト可能＝ｙｅｓ"といったように、適切な構造レイアウト制限と関連付けられてもよく、どのようにモジュールを屋根の上又は周辺に配置するかに関するその他の設計規則と関連付けられてもよい。以下に説明するように、ある実施形態では、設計規則は、少なくともソフトウェアの最初の使用の際に、無効化されてもよいが、規則の必要条件からの変更を追跡するために、例外事項のリストはそのまま維持される。
【００２５】
このようにして、ユーザーがアクションを分類することにより、オブジェクトの元の単純な幾何的表示に、例えば、より高い階層の追加の構造的情報を割り当てて、自動化設計システムに使用させてもよい。加えて、システムは、オブジェクトが、構造のインスタンスとして自動的に分類され、構造特性及び設計特性に値が割り当てられるようなメカニズムを提供してもよい。形状再設定アルゴリズム、学習アルゴリズム、又はその他のエキスパートシステムを使用して、オブジェクトの分類及び値の割り当てを実行してもよい。また、幾何的オブジェクトを、前処理段階で補正、例えば修正して、分類、構造割り当て又はレイアウト処理におけるより良い状態又は位置にオブジェクトを配置してもよい。エンジンは、例えば、試作分類といった設計者からの入力を、オブジェクト修正の基本として使用してもよい。例えば、設計者が、４つの線を"屋根"として分類することを試みているが、４つの線が完全に閉じた形を形成しない場合には、ソフトウェア修正エンジンが、線の終点が共有されるように、適切にオブジェクトを修正することを試みてもよい。
【００２６】
ある実施形態では、分類されたオブジェクト、その分類、例えば、構造特性のセットのような符号化された情報、及び以下に記載するようなその他の情報を使用するレイアウトエンジンソフトウェアモジュールのような、レイアウト構成要素を提供して、モジュール設置設計を生成してもよい。例えば、"屋根"として分類されたオブジェクトが、"レイアウト可能＝ｙｅｓ"というレイアウト規則と関連付けられていてもよく、それにより、レイアウトエンジンは、"屋根"として印を付けられ分類されたオブジェクト間の境界領域に、ソーラーコレクタを設置することを考えてもよい。同様に、換気扇が、分類又は特定のインスタンスとして、レイアウト規則"レイアウト可能＝ｎｏ"と関連付けられていてもよく、したがって、レイアウトエンジンは、"換気扇"と印が付けられているオブジェクトに対応する領域には、モジュールを配置できないと知ることができる。屋根のように、そこにモジュールの配置が許されるオブジェクトには、明示的に"作業エリア"と称して、モジュールが配置されてもよい場所（その他のレイアウト規則と矛盾せずに）であることを示してもよく、この場合、ユーザーが個別に、作業エリアを定義する必要はない。
【００２７】
レイアウトプロセスに対するより大きな制御を有効にするメカニズムを、ユーザーに提供してもよい。ユーザーは、例えば、明示的に、１以上のユーザー生成作業領域を定義することによって、モジュール配置が許可される境界の範囲を狭めてもよい。ユーザー生成作業領域は、ユーザーによって生成された幾何的オブジェクトであってもよく、例えば、"レイアウト可能＝ｙｅｓ"を含むレイアウト規則の特定のセットと関連付けられていてもよい。レイアウトエンジンソフトウェアモジュールは、明示的な、例えばユーザーが生成した作業エリア、明示的な作業エリアの一方、又は両方内に含まれるロケーションにのみ、ソーラーコレクタを配置することを考えるように設定されてもよい。これは、例えば、設計者が、屋根の一部に制限して、ソーラーコレクタを配置することを望んでいる場合に有用であり、屋根の所望の部分にのみ作業エリアを作成すればよい。
【００２８】
ユーザーはまた、モジュールの種類又はソーラーコレクタレイアウトの方位のような様々な設計設定を設定可能であってもよく、さらに、表示の異なるエリアに、異なる選択を行うことが可能であってもよい。表５には、設計設定のサンプルのリストが示されている。例えば、ユーザーは、設計設定の特定のセットが適用される境界を、例えば、１以上のアパーチャを規定することにより、規定できるようにしてもよい。アパーチャ（ａｐｅｒｔｕｒｅ）は、ユーザーが生成した幾何的オブジェクトによって表される境界又は外枠である。システムは、例えば、"ＰＶモジュール＝ＳＤ３０５"及び／又は"傾き＝４５度"といった設計設定を含む設計設定のセットと、アパーチャとを関連付けてもよい。レイアウトエンジンは、割り当てられたアパーチャの設計設定、関連する構造特性、レイアウト規則、及びその他の適用可能な特性及び設計規則に従った所定のアパーチャの境界内に、例えば、ＰＶモジュールであるソーラーコレクタを配置するように設定されていてもよい。幾つかのケースでは、ユーザーは、１以上のアパーチャを規定してもよく、レイアウトエンジンは、設置現場の様々な領域において、レイアウトの設計設定の異なるセットを使用してもよい。設計者が、１種類のモジュール、例えば、ＳＤ３０５ｓを、屋根のあるエリアにおいて、南北の方向に向けて配置することを望んでおり、また、別のモジュール、例えば、ＳＰ２２５ｓを、屋根の別のエリアにおいて、東西に向けて配置することを望んでいる場合には、別々のアパーチャを使用することが有用である。別の例として、作業エリアの異なる領域におけるモジュールの行間を、異なる間隔に設定する目的で、複数のアパーチャを不均一にレイアウトしてもよい。また、ある実施形態では、作業領域内（例えば、作業領域内のみ）のソーラーコレクタの設置が許可された領域内にソーラーコレクタのレイアウトが生成されてもよく、また、ソーラーコレクタの配置に関するアパーチャの設計設定、オブジェクト及び構造の特性、及びレイアウト規則又はこれに関連付けられた制限に従ったレイアウトアパーチャ内に、ソーラーコレクタのレイアウトが生成されてもよい。
【００２９】
ある例では、ユーザーによって規定されたアパーチャ同士が重なってしまう、又は、相関してしまう場合が発生する。このような場合は、アパーチャの競合を解消する規則が利用されてもよい。例えば、競合解消ルールでは、アパーチャ２よりも、アパーチャ１を優先させるよう規定してもよい。レイアウトエンジンは、アパーチャ２に従って設置されるモジュールよりも、アパーチャ１に従って設置されるモジュールを優先させる。これは、設計者が規定したアパーチャの境界が重なっている場合、又は、設計者が、例えば、ＰＶモジュールであるソーラーコレクタを、凹形状の屋根の両側（すなわち、逆Ｖ字型又はＶ字型の屋根の対向する壁）に配置したいと望んでいる場合には、有用である。コレクタ及びその搭載構造は、高さがあるため、２つの屋根部分の交差点（すなわち、Ｖ字の底部）に、モジュール配置する際には、競合が発生すると考えられる。屋根部分の１つが、他方よりも太陽光を受ける場合には、設計者は、アパーチャを、太陽光が照射される部分及び陰になる部分に設定したいと考える。ユーザーは、競合が発生した場合には、２つのアパーチャに対して優先順位を付けることが可能であってもよく、レイアウトエンジンは、陰になるアパーチャの設計設定よりも、太陽光があたるアパーチャ分の設計設定を優先させて、それに従ってモジュールを配置する。このようにすることにより、この設置におけるモジュール平均の電力生成を、全体として増加させることが可能になる。例えば、ユーザーがアパーチャを規定するシーケンスに従って、初期設定の優先順位をアパーチャに割り当ててもよく、又は明示的に優先順位を設定してもよい。
【００３０】
レイアウトを含む設計の結果は、表示され、保存され、印刷され、送信され、又は利用されてもよい。部品表、レンダリング、財務分析、契約、契約条件、エネルギー予測、コスト分析、部品リスト、シミュレーション等の、レイアウトに関する追加情報が、符号化された情報及び生成されたレイアウトに基づいて生成されてもよい。
【００３１】
以下の動作を実行するソフトウェア制御は、ＣＡＤソフトウェアの一部として含まれていてもよい。これに替えて又はこれに追加して、専用のエンジン、ライブラリ又はプラグインを、スタートアップで又はオンディマンドで、ＣＡＤソフトウェアにロードしてもよい。これに替えて、専用の又は新しいソフトウェアプログラムを、本発明の実施形態の実装専用に書いてもよい。ＣＡＤソフトウェア環境においてオブジェクトの生成、選択及び操作に対する多くのメカニズムが、当技術分野では知られており、このようなメカニズムとしては、例えば、クリック選択、ドラッグ選択、シート選択、アイコン上でのクリック及び右クリック、ツールバー、ポップアップ、オブジェクト等が含まれる。Ｊｏｅ Ｓｕｔｐｈｉｎ著、「ＡｕｔｏＣＡＤ ２００６ ＶＢＡ：Ａ Ｐｒｏｇｒａｍｍｅｒ'ｓ Ｒｅｆｅｒｅｎｃｅ」、１０１プロダクション（２００５）、ＩＳＢＮ９７８１５９０５９５７９４では、このような方法を数多く開示しており、その内容は、参照により、本明細書に組み込まれる。
【００３２】
［２．システム動作及びユーザーインターフェース］
図１は、ソーラーコレクタレイアウトが設計される設置現場を、概略的に示した図である。簡略化のため、本明細書で説明される実施形態は、ソーラーコレクタの例として、太陽電池（ＰＶ）モジュールを使用している。ＰＶモジュールは、建物１００の屋根１０１の上に配置される。屋根１０１は、換気扇１０２、配線管１０３、通路、配管１０５、大型冷暖房空調設備（ＨＶＡＣ）１０４、天窓、エレベータ機械、階段等の一連の物理的構造物を有すると考えられる。これらを、幾何学的に、屋根１０１の上に投影させる（上部から下部を見る鳥瞰図として）と、構造物は、屋根に対して、立体的／二次元的（例えば、換気扇１０２）に、又は線形的／一次元的（例えば、配線管１０３）に表されてもよい。所定の構造は、例えば、換気扇は矩形の伏図といったように、屋根の上に規則的な伏図として表されてもよく、これに替えて、構造を不規則な伏図で表してもよい。屋根の構造としては、無形のもの、例えば、風の強い又は上昇気流が存在するエリア１０６を含んでもよい。屋根１０１及び屋根に設けられている構造のそれぞれは、ソーラーコレクタ設置設計に関連する特徴のセットを有してもよい。例えば、ＰＶモジュールは、通常、換気扇の上、又は、換気扇１０２から所定のセットバック内には配置されず、セットバックは、規則、顧客の規定事項又は設計選択肢によって規定されていてもよい。同様に、ＰＶモジュールは、通常、風速が大きいエリア１０６内、又は、屋根１０１の角又は縁から特定の距離の範囲内には配置されない。
【００３３】
屋根の構造物はまた、屋根１０１上に配置されるＰＶモジュールの相対的な性能を決定してもよい。例えば、屋根１０１が、多くの場合、南側（１０５で示されている）からの太陽光に最も晒されると仮定すると、（大型冷暖房空調設備（ＨＶＡＣ）１０４によって、少なくとも部分的に太陽光が邪魔される）位置Ｂに配置されるＰＶモジュールよりも、位置Ａに配置されるＰＶモジュールの方が、平均してより多くの電力を生成すると考えられる。
【００３４】
図２は、コンピュータ支援設計（ＣＡＤ）システム２００のユーザーインターフェースの一例で表示された、図１の設置現場を示した図である。ＣＡＤシステム２００は、設置現場の２Ｄ又は３Ｄの視覚的表示を含んでもよい。典型的な表示では、設置現場の構造物についての３次元情報を含む。簡便のため、実施形態は、２次元の平面図２０４を参照して説明される。視覚的表示は、線、線分、ポリライン、円弧、曲線、縁、正方形、矩形、多角形等の幾何的実体により構成されてもよい。これらの幾何的実体は、境界で囲まれたエリアを規定するよう閉じていてもよいし、開いていてもよいし、自交していてもよいし、平面的であっても非平面的であってもよいし、孔、複雑な表面及び幾何学的トポグラフィーを含んでもよい。これらの幾何的オブジェクトは、物理的な設置現場の、物理的構造又は非物理的構造に対応していてもよい。例えば、表示２０４には２つの多角形が示しされており、それぞれ、図１の換気扇構造１０２に対応する参照番号２０２で示された有界エリアを規定している。線分及び曲線２０３のセットは、図１の配線管１０３の構造に対応している。視覚的表示は、最初に、ＡｕｔｏＣＡＤ．ＤＷＧといった特定のファイル形式を使用して、ＣＡＤソフトウェアに読み込まれてもよい。これに替えて、視覚的表示を、標準的なＣＡＤ描画ツールを使用して、ＣＡＤソフトウェアによって生成してもよい。ＣＡＤソフトウェアにおける視覚的表示２０４は、設置現場の一部のみを表示してもよいし、設置現場を超えた領域まで表示してもよい。
【００３５】
この時点では、ＣＡＤソフトウェアにおける設置現場の表示には、非常に少ない意味情報しか添付されていなくてもよい。例えば、純粋な形状以外、有界エリア２０２を形成している４つの線分は、意味情報と関連付けられていなくてもよい、又は、対応する換気扇構造１０２に関する意味のみを有していてもよい。ＰＶモジュール設計に関する換気扇構造の特徴、例えば、典型的なセットバック、又は一日又は一年のうちの様々な時間に形成される影（例えば、形成されると予測される影）といった特性は、この表示に組み込まれていなくてもよい。同様に、屋根の外形に対応する線２０１は、ＣＡＤソフトウェアにおいて、設置現場の屋根１０１と、意味的に関連付けられていなくてもよい。むしろ、ＣＡＤソフトウェアの観点からすると、視覚的表示は、単純に、大きさの情報のみを有する幾何的オブジェクトの集合であり、互いに、外部の設置現場、又はソーラーコレクタ設置設計と関連する意味情報が取り除かれたものであると考えられる。これに替えて、視覚的表示は、例えば、ＧＰＳデータのような意味情報が、オブジェクトに付加されていてもよい。このデータは、プロセスにおける後の段階で使用されてもよい。
【００３６】
図３は、視覚的表示及び視覚的表示内の幾何的オブジェクトに、意味情報が付与されるプロセスを示した図である。実施形態の分類要素は、"データ処理能力のない"幾何的オブジェクト、例えば、大きさの情報しか有していないオブジェクトを、自動的に又はユーザーによって、構造の特定の種類のインスタンスとして分類することにより、この分類を実行する。構造の種類のインスタンスとしての分類の一部として、オブジェクトは、追加の構造特性のセットと関連付けられてもよく、このセットには、ソーラーコレクタ設置設計に関連する高さ、セットバック等の構造特性が含まれていてもよい。システムは、分類及び特性を使用して、オブジェクトを、分類されたオブジェクトとその他のオブジェクトとの間のインタラクションの可能性、及び生成されたソーラーコレクタ設計に対する影響に対応するレイアウト規則と関連付けてもよい。これらの構造的特性は、レイアウトエンジンがレイアウト規則をオブジェクトに適用するといったように、ソフトウェアによって認識され、利用され及び操作されてもよい。
【００３７】
例えば、ポリライン２０１は、例えば、"屋根"のような、構造の１種類と関連付けられてもよい。この分類は、屋根の上へのＰＶモジュールの設置に関するレイアウト規則に関係していてもよい。レイアウトエンジンによってこのような規則が呼び出されると、特定の屋根の構造的特性（例えば、地面からの垂直方向の高さ及び屋根のピッチ）に作用してもよい。オブジェクトに関連付けられた特性は、その他のオブジェクト特性との対応又は相関関係によって決定されてもよい。例えば、屋根に対する換気扇の高さ（これは、換気扇による影の屋根に対する影響を計算する時に有用な情報である）は、換気扇の絶対的な最大高度、及び換気扇が位置する点における屋根の絶対的な高さ（これは、屋根の特性である高さ及びピッチから自明的に決定することができる）を示す構造特性から、決定することができる。このようにして、オブジェクト分類及び構造の特性を含む符号化された情報は、設置現場の物理的構造の特徴の完全な又は部分的な仕様を形成して（又は関連付けられて）いてもよく、仕様は、ＰＶモジュールのレイアウト設計と関係している。具体的には、ソーラーコレクタレイアウト設計と関連する物理的構造の特徴は、その物理的構造内又は周辺にソーラーコレクタを自動的に配置するための、情報のセットの少なくとも一部を含む又は構成する。予め規定される構造分類及びクラスは、物理的特徴及び非物理的特徴を含んでもよく、例えば、敷地境界、不動産区画境界、建築規制指定、電線の敷設権、洪水が起きる土地、環境を配慮したエリア、又は特定の地震帯のような特徴を含んでもよい。
【００３８】
特に、幾何的オブジェクトの中には、ＰＶモジュール設置の許可を提供する構造種類のインスタンスとして分類されるものが存在してもよく、例えば、屋根として分類される幾何的オブジェクトは、屋根の表面にＰＶモジュールを配置することを許可するレイアウト規則と関連付けられていてもよい。このように、"屋根"としてオブジェクトを分類することは、間接的に、そのオブジェクトを作業エリアとして扱うことにつながる場合がある。同様に、オブジェクトの中には、ＰＶモジュールの配置を通常は許可しない又は禁止する構造として分類されるもの存在し、例えば、池又は空調ユニットとして分類された幾何的オブジェクトは、障害物又は障害物の予め規定された境界内、例えば、距離内に、ＰＶモジュールを配置することを通常は許可しないレイアウト規則と関連付けられていてもよい。ＰＶモジュールの配置に対するその他のレイアウト規則を規定してもよく、建築規制及び建築法、風条件、温度条件、及びモジュール配置に対する電力及び熱生成制限の適用を実体化する制限を、所与の構造に対して及びその付近に対して規定してもよい。
【００３９】
構造の所定の種類と関連付けられる構造特性の形式及び内容は、対応するオブジェクトの形成の前に形成されてもよいし、前もって存在するものであってもよい。物理的構造の分類、及びそれに対応する符号化された情報は、予め規定しておいてもよい。例えば、屋根又はその他の表面に対応する特性及び初期値のセット、及び、それらに適用される設計規則は、データベース及び／又は分類規定の一部に格納されていてもよい。（表３〜４参照。）特定のオブジェクトが屋根として分類されると、分類規定がインスタンス化されて、そのオブジェクトと関連付けられてもよい。無論、ソフトウェアは、更なる構造の種類を、設計者が規定することができ、分類に使用することができるようなメカニズムを提供してもよい。所定の種類のオブジェクトに対して、特性及びレイアウト制限の初期値を含む初期値又は予め存在する符号化情報が、設計者又は管理者によって修正されてもよい。符号化された情報の修正は、レイアウト生成の前に行ってもよいし、及び／又は、レイアウト生成の後に行ってもよい。レイアウトが生成された後に行われる構造特性のような特定の符号化された情報の修正は、データの新たなセットに基づくレイアウトの自動再生成をトリガしてもよい。
【００４０】
オブジェクトが分類され、修正される、又は、特性と関連付けられるメカニズム又はユーザーインターフェースの制御は、様々であってよい。例えば、図３に示すように、ユーザーは、屋根１０１に対応するポリライン２０１を選択してもよい。そして、ユーザーは、"屋根"又は"分類・・・"と記載されたツールバー又はアイコンをクリックする、又は同様のコマンドをメニューから選択してもよい。ユーザーは、また、ポリライン２０１上でポインタツールを使用して右クリックし、ポリライン２０１を選択すると同時に、屋根と分類することを可能とするコンテキストメニュー３１０を開いてもよい。選択及び分類の間に、この選択又は分類を示すように、オブジェクトの表示が変更されてもよい。例えば、色を変更してもよく、線の太さ又はスタイルを、変更してもよい（本例では、ポリライン２０１は点線で示されている）。ユーザーインターフェースにおけるオブジェクトに対するアクションの実行に関する制御には多くの種類が存在することは、当分野では周知である。複数のオブジェクトを、同じ種類の構造、例えば、"屋根"のインスタンスとして分類してもよく、この場合には、システムは、複数の屋根を含む設置現場に対するレイアウトを生成する。特徴の異なる種類又はサブ種類を、様々に表現してもよく、例えば、ユーザーインターフェースにおいて、別々の描画層に配置してもよいし、及び／又は、異なる色又は線の太さで表してもよい。また、オブジェクトの分類を解除する制御を提供してもよい。
【００４１】
無効な又は不完全な設置現場の幾何的形状を自動的に修正するメカニズムを採用してもよい。例えば、一実施形態において、設計規則が、"屋根"は、閉じた多角形で表示されるべきであると規定しているとする。設置現場表示における屋根に対応する幾何的情報が、４つの線分で構成されており、共通の終点が近接してはいるが、一致していない（すなわち、閉じた形状をしていない）と仮定する。この幾何的表示では、線分の終点を一致させない限り、処理エラーとなる又は不正確な結果を生成すると考えられる。一実施形態において、分類している間に、前処理幾何的要素に対して、メカニズムが提供され、例えば、終点が一致していない線分を、終点が共有される線分へと互いに近づけるように、特定の角度内に収めるような変換が行われる。非意味的幾何的データの修正のための幾何的アルゴリズムが存在する。
【００４２】
ソフトウェアはまた、ユーザーが、所与のオブジェクトと関連付けられた編集可能な特性のような、符号化された情報の一部又は全てを見る及び／又は修正することが可能となる制御を提供してもよい。例えば、ユーザーインターフェースは、そのオブジェクトと関連付けられた構造特性の一部又は全ての表現を表示するための特性ロールアップ、ツールバー又はパレット３１１を含んでもよい。屋根に対する構造特性の一部、例えば、垂直方向高さ３１２は、ユーザーが調整可能であってもよい。屋根の、例えば、平方メートル単位の生成された面積、といった、ＰＶモジュールの設置に使用されるその他の構造特性を、ソフトウェアによって計算してもよく、例えば、レイアウト制限、構造特性等とのインタラクションによって決定される。所与のオブジェクトに適用可能なレイアウト規則の表示のようなその他の情報、例えば、特定のオブジェクトが、ＰＶモジュールの設置に好適であるといった表示は、ユーザーに表示又は可視化されなくてもよい。ユーザーインターフェースにおいて、オブジェクトの特性を修正するための制御には様々な種類が存在する。
【００４３】
ある実施形態では、構造分類の階層構造を含んでもよい。例えば、構造は、設置可能表面、立体障害物、線形障害物３つのカテゴリに分けられてもよい。各カテゴリは、構造の複数の種類を含んでもよい。例えば、設置可能表面としては、屋根、野原、壁等を含んでもよい。立体障害物としては、換気扇、柱、冷暖房空調設備（ＨＶＡＣ）、くぼみ、木、屋根の昇降口、アンテナ、衛星アンテナ、階段、排水管、塔屋、屋根の窓、天窓、梁、観察点、通気孔、バルブ等を含めてもよい。線形状の障害物としては、通路、機器、延長ジョイント、壁、配線管、パイプ等が含まれる。構造物の種類それぞれは、サブ種類を含んでもよく、例えば、アンテナ障害物は、サブ種類として、アウトラインアンテナ、ポイントアンテナ等を含んでもよく、配線管は、サブ種類として、電気配線、水配管、支持配線、垂直配線、導水管等を含んでもよい。障害物は、その固有の幾何的形状（例えば、階段）に応じて、立体又は線形のいずれかに分類されてもよい。
【００４４】
図４は、第２障害物が分類されて、意味的情報と関連付けられるプロセスを示した図である。ここでは、屋根の上に設けられている換気扇に対応する複数の線のセット又はポリライン２０２は、立体障害物として分類されている。すなわち、コンテキストメニュー３１０及び特性パレット３１１を使用して、"ＨＶＡＣユニット"のサブ種類"換気扇"と分類される。ここで、点線は、ユーザーが、この特定のオブジェクトを選択したことを表す視覚的手掛かりとして使用されている。特性パレット３１１は、同様な構造特性のサンプルを示しており、また、換気扇についての現在の値、例えば、高さ、セットバック、サブ種類等も示している。パレット３１１は、図４において、オブジェクト２０２が構造カテゴリ（又は分類）の立体障害物３１５、種類ＨＶＡＣ３１７、及びサブ種類換気扇３１９に分類されたことを示している。このようにして、物理的設置現場に対応する複数のオブジェクトが分類されてもよい。ある配置では、上述したようなユーザーが手動でオブジェクトを分類することを必要とするのではなく、システムが、例えば、設置現場の表示の帰納的分析、又は利用可能なメタデータに基づいて、最初に自動的にオブジェクトを分類するのを試みてもよく、例えば、予め生成されたＣＡＤ図面の層において"天窓"と名付けられたオブジェクトを、自動的に"天窓"として分類してもよい。システムはその後で、ユーザーによる修正及び認証を許可又は要求してもよい。システムは、ＧＰＳデータのような幾何的オブジェクトに関する情報を使用して、自動的にオブジェクトを分類してもよい。
【００４５】
全ての特性を、表示における特定の構造又は幾何的オブジェクトと関連付ける必要はない。例えば、ソフトウェアは、設置現場ロケーション（郵便番号）、設置現場の方位（北向きの矢印）、縮尺、測定の単位、国、顧客情報（顧客の名前、住所等）といった、プロジェクト全体の特性情報を利用及び設定可能としてもよい。プロジェクト特性情報は、連絡先、法的資格、財務状況、電気利用情報、電気料金、及びエネルギー消費量の情報を含む顧客特性情報を含み、予め設定されていてもよい。その他のプロジェクトの特性情報として、土壌の種類、気候条件、設計温度、設計地震負荷、動作特徴、負荷限界、電気配線条件等が含まれてもよい。この情報は、設計者によって手動で入力されてもよいし、顧客のアカウント情報を保持するのに使用される顧客関係管理（ＣＲＭ）システムのような外部のデータソースとつながるリンクを通じて、この情報がアクセスされてもよい。表６には、プロジェクトの特性情報のリストの例が示されている。例えば、全体のレイアウト規則といったプロジェクト設計の規則は、特定の構造物とは独立して作用してもよく、例えば、公共電力設備にＰＶシステムを接続する際の規制である電力接続規則等が挙げられる。予め規定されるプロジェクト設計規則は、電気設備基準、敷地セットバック必要条件、安全要求事項、配線必要条件、設計規則又は成功事例、ヒューズ設定条件等の使用を規定してもよい。公共電気グリッド、私有電気グリッド又はその他の規格に接続されるレイアウトを生成する際に、このような規制的規則を採用してもよい。
【００４６】
モジュールの種類は、例えば、モジュール特性、モジュール間の間隔、電圧、配線条件、重さ等の特定のモジュール固有の情報と関連付けられていることから、設計で使用されるモジュールの種類は、レイアウトエンジンがどのように動作するかについても影響を与える。モジュール固有の情報の一部は、モジュールの種類、搭載システム、インバータタの種類等の特定の種類と関連付けられていてもよい。様々なモジュール設計規則を、モジュール毎に、モジュールの列毎に、及び／又はモジュール‐サブアレイベースで、適用してもよい。例えば、特定のモジュールは、最小のモジュール間距離及び動作温度、又は特定の配線構造を要求してもよく、例えば、１列（ストリング）あたりのモジュールの数が、温度の関数であってもよい。表７には、モジュール特性のリストの例が示されている。
【００４７】
図５Ａに示すように、使用されるモジュール５０２の種類及び／又は搭載システムの種類、モジュールの行及び列を配置する方位５０３、タイル状に配置する開始点５０４（又は原点）、インバータの種類（選択肢が損愛する場合）等を含む設計設定情報を、規定してもよい。また、動作全体特性、設計設定、及び／又はモジュール特性の１以上を、ユーザーが修正可能であってもよい。例えば、真北の方角に対するモジュールの方位（角度）は、５０３に示すように、適当な制御部に、数字で入力してもよい。これに替えて、方位を、屋根の外縁のような既存の線を選択し、モジュールの方位が、選択された線と同じであることを示すことによって設定してもよい。レイアウトの開始点を、例えば、適当な制御部に、座標を入力５０４することによって設定してもよく、及び／又は、５０６に示すように、マウス又はタッチスクリーンのようなポインティングデバイスを使用して、可視的表示における１点を選択することにより設定してもよい。コンテキストメニュー５２０のような制御部が、ソーラーコレクタ設置レイアウトエンジンを起動するべく、提供されてもよい。
【００４８】
図５Ｂに示すように、レイアウトエンジンは、関係する符号化された情報に基づいて及び従って、ソーラーコレクタの設計を生成するように起動されてもよく、符号化された情報としては、構造分類、構造特性、作業エリア、設計設定、全体特性、モジュール特性、レイアウト規則、設計規則等が含まれる。ＰＶモジュールの場合、レイアウトには、視覚表示に示される複数のＰＶモジュールの物理的配置が含まれてもよく、付随する配線システム、搭載システム、ハードウェア、設置の適切なオペレーションのための電子部品等の配置も含まれてもよい。ある場合には、ＰＶモジュールは、全オブジェクトに対する規則及び制限の全て（実質的に全て）に従ってＰＶモジュールが配置されてもよい。このようなＰＶモジュールレイアウトを生成するのに、数多くの方法及びシステムを使用してもよい。特に、システムのレイアウトエンジン構成要素は、タイリングアルゴリズムを使用して、レイアウトを生成してもよい。
【００４９】
図６Ａのフローチャートに示されるように、ある１つのアルゴリズムの下、あらゆる幾何的オブジェクトを含む設置現場の視覚表示は、まず、設置現場における物理的構造についての（特に、大きさについての）データを収集することによって、最初に規定され（６０５）てもよい。これは、ＧＰＳベースの測量機器を使用して設置現場で行ってもよく、又はこれに替えて、ＣＡＤソフトウェアを使用して、代表的な幾何的オブジェクトを生成してもよい。この段階は、段階６１０と交互に行ってもよい。段階６１０において、視覚表示におけるオブジェクトは、構造で分類されて、構造特性に適切な値が設定される。これは、ユーザーが手動で行ってもよいし、自動化された構造認識を使用してシステムが自動で行ってもよい。ユーザーは、１以上のオブジェクトを、ＰＶモジュールの設置が許される又は望まれる領域、例えば、野原や屋根のような領域を提供する構造として分類する。段階６１２において、ユーザーは、１以上の作業エリア、例えば、ＰＶモジュールレイアウトが望まれると推測される領域を、所有者の指示に基づいて、規定してもよい。作業エリアを明示的に規定してもよく、それについては以下に説明する。６１５において、設計設定、プロジェクト特性、及びその他の符号化された情報を、設定又は修正してもよい。
【００５０】
６２０において、まず、複数のＰＶモジュールを、１以上の作業エリアにわたって、障害物又はその他の干渉する構造（例えば換気扇）を考慮することなく、タイル状に配置してもよい。作業エリアとしては、配置が許可されると分かっているオブジェクト、例えば、屋根表面が挙げられる。これは、明示的な作業エリアにわたって、例えば、ＰＶモジュールを支持する構造として分類されているオブジェクトにわたって、複数のＰＶモジュールを配置することにより、操作可能としてもよい。タイル状に配置するタイリングは、関連するモジュール設計規則及び特性に従う規定された空間に、グリッド又はアレイを形成することにより行ってもよい。タイリングは、行間隔、隣接する行間のオフセット量、曲線の道又は土地の境界線のような不規則な外縁等を含むように、パラメータ的に変化してもよい。また、タイリングは、個々のモジュール（個別に様々に指定された長さ又は幅を有する）に対応するように行われてもよく、また、任意の配置（例えば、モジュールが、同一の搭載構造又は追跡メカニズムと接続されている場合）における複数モジュールの集合体を表していてもよい。加えて、タイリングの周期的な中断を設けて、側道、設置義務である消防車が侵入可能な道路、又はその他の種類の設計規則を規定するようにしてもよい。ある実施形態では、レイアウトされるモジュールオブジェクトに対応する幾何的オブジェクトを、図６Ｂに示すように、実際に生成して、可視的表示内に配置してもよい。これに替えて又はこれに加えて、レイアウトは、モジュールが表現されているデータ構造において、論理的であってもよい。いずれの場合にせよ、幾何的オブジェクトは、関係するモジュール種類のインスタンスとして分類され、特定の構造特性及びレイアウト制限と関連付けられる。
【００５１】
図６Ａに戻り、６２５では、システムが、タイル状に配置された複数モジュールについて、２回目のパスを実行し、特性に適用される１以上の設計規則に反して配置されているモジュールに、不適格であるとの印を付してもよい。例えば、図６Ｂに示すように、屋根２０１の表面全体が、モジュールでタイル状に覆われたとする。２回目のパスでは、モジュールそれぞれを考慮して、規則に違反して配置されている（すなわち、表示及びオブジェクトの規則に従っていない）モジュールに印を付ける。これは、例えば、配置されたモジュールそれぞれを検証するようにループ化し、モジュールそれぞれに対して、全ての設計規則を検証するようループ化し、規則との不一致を探すべく関係するものを適用することによって、動作させることができる。したがって、換気扇２０２の物理的伏図内、又は、換気扇２０２からのセットバックの伏図内に位置するモジュールには、不適格であると印を付けてもよい。同様に、風速の大きいゾーン内の特定の距離の範囲内に位置するモジュール、例えば、図１の１０６にも、不適格であると印を付けてもよい。不適格であるとされたモジュールは、グレー表示をして、自動的に取り除き、別の階層に移動させてもよいし、データ構造における"適格"なモジュールに対する変更を行ってもよい。不適格であるとの印付けは、ソフトウェアデータ構造における特性又はフィールド内に"不適格？"と明示的に行ってもよいし、プロセス実行において非明示的に行ってもよい。ユーザーは、不適格とされたモジュールに対してアクセス可能であってもよいし、アクセス不可能としてもよい。不適格とするにも様々なレベルが存在してもよく、あるモデルでは、設計者が取り消しを無効にすることができないように、厳密に不適格としてもよいし、別のモデルでは、設計者が配置を元の場所に戻すことを許容する程度に、緩く不適格又は好ましくないとしてもよい。様々なレベルの適法性を、別々の色、層等を使用して維持してもよい。このようなレイアウトプロセスで得られる結果は、設置現場に対する設計規則及び特性に一致したＰＶモジュールレイアウトとなる。図５Ｂに示すように、網掛け線で示されている５３０に配置されているモジュールは、規則に従って配置されている。参照番号５３３で示されているエリアにはモジュールが存在していないが、これは、これに関連付けられたエリアが、障害物の物理的境界の内側に存在しているからである。システムは、１以上の不適格となるモジュールを選択し、それらを通常の配置に戻す能力を有してもよい。ある場合には、構造特性に対して適用される規則の少なくとも１つに違反して実行されてもよい。灰色で網かけされた５３５に配置されたモジュールは、選択的であるセットバック必要条件を満たしていないことから、緩く不適格であると言える。以下に説明するように、設計者は、このように緩く不適格であるとされたモジュールをオンとする、又は、元に戻してもよい。
【００５２】
例えば、モジュールが、換気扇に近接し過ぎて配置されるといったように、あるモジュール配置は、その他のモジュールとの関係に関わらず不適格となる。しかしながら、不適格であるとする設定は、その他のモジュールに対してのみ明確であってもよく、再帰的に特定されるものであってもよい。例えば、グリッド接続されるＰＶの設置は、予め決められた数のモジュールを、電気的に直列に配線接続する必要がある。例えば、ＳｕｎＰｏｗｅｒ３０５モジュールが、北カリフォルニアで使用され、６００ＶのＤＣインバータと接続される場合、各列（ストリング）に、１２個のモジュールを接続しなければならない。
【００５３】
このように、厳密に不適格であるモジュールを取り除いた後、システムは、残ったモジュールに対して更なる"パス"を実行して、例えば、モジュール間接続規則のような設計規則を満たさない更なるモジュールが存在するかのチェックを、再帰的に又は回帰的に実行してもよい。このようなモジュールは、図５Ｂでは、グレー表示されている。
【００５４】
図６Ａに戻り、６３０では、レイアウトが自動的に生成された後で、ユーザーには、少なくとも１つのオブジェクト又はプロジェクト全般を修正するオプションが示される。ユーザーが配置を修正することを可能とするユーザーインターフェースの制御部分は、様々であってもよい。不適格なモジュールは、表示の別の階層に配置されてもよく、及び／又は、図５Ｂに示すように、異なる色又はスタイルで示されてもよい。ユーザーは、不適格であるとされたモジュールの層を適格であると変更してもよいし、その反対の変更を行ってもよい。ユーザーは、右クリックをする又はモジュールを選択して、そのモジュールのステータスを変更してもよい。また、適格に配置されたモジュールの消去を可能としてもよく、完全な消去、又は、モジュールを"消去済み"階層に移動させることを含んでもよい。消去されたモジュールは、必要に応じて、復元されてもよい。アクションの取り消し、又は、例えば、モジュールのインスタンス化し直しのような、取り消したアクションのやり直しを可能とする制御を提供してもよい。取り消し及びやり直しについては、以下にさらに説明する。
【００５５】
制御は、規則又は分類を変更する能力、及び自動レイアウトをやり直す能力を含むように、提供されていてもよい。システムの修正コンポーネントは、一度は配置されたが後に取り除かれた（規則を満たさなかったため）タイルの置き換えを可能とするユーザーインターフェース、又はその他のメカニズムを提供してもよい。また、配置されたモジュールを、レイアウトから取り除くメカニズムを提供してもよい。
【００５６】
６３５に示すように、レイアウトをユーザーが変更を行うと、変更されたレイアウトは、関係する設計規則及び特性に対して矛盾した状態となる、又は、不一致が存在する場合がある。例えば、ユーザによって特定のポイントにモジュールを手動で追加すると、セットバックに関する設計規則を破ってしまうことが考えられる。このように、追加、置き換え又は削除といった、レイアウトの修正は、レイアウトの再計算、レイアウトに対するルーティング／配線構造の再計算等を必要とする場合がある。レイアウトの修正、又はレイアウト規則の不一致は、以下に詳細に説明する、例外事項のリストに明記されてもよい。
【００５７】
６４０において、生成されたレイアウトに対して更なるアクションをユーザーが実行可能なように、ユーザーインターフェースの制御を提供してもよい。例えば、レイアウトを保存、印刷及び／又は送信してもよい。また、レイアウト情報を、オブジェクトの規則及び分類と共に、更なる構成要素を生成するのに使用してもよい。例えば、ユーザーが選択したモデルのソーラーコレクタの効率、及び、屋根の面積が受ける光の量に関するエネルギー予測シミュレーション規則、緯度及び高さといった可視化表示における構造物に関するエンコードされた情報を使用して、電力出力のような特定のモジュールレイアウト性能を、シミュレーションしてもよい。シミュレーション結果は、表示されてもよいし、設計者が利用可能なようにしてもよい。別の例では、モジュール及び関連する部品（配線及び電気インバータ等）の数及びコストを集計して、部品表、コスト計算、請求書等を作成するのに使用してもよい。ある実施形態では、典型的なレイアウト設計プロセスに関連して記載される、複数の種類の書類又は提出物が、ダウンストリームの出力として、自動的に生成されてもよい。
【００５８】
［３．ユーザー規定作業エリア］
上記で説明したシステムは、構造分類によって規定される明示的な作業エリアを使用して、屋根のような許可された表面又はオブジェクト上に、ソーラーコレクタ、特にＰＶモジュールを配置するレイアウトを適用する。更に又はこれに替えて、システムは、ユーザーに、モジュールの配置が許可されている領域として作業エリアを規定する及び利用することに対する明示的な管理権を与えることにより、よりきめの細かい制御を可能とするユーザーインターフェースを提供してもよい。
【００５９】
具体的には、図７Ａに示されるように、システムは、例えば、明示的な作業エリアのような、モジュールレイアウトを制限する又は拡張するための、１以上のユーザー生成境界を、ユーザーが規定できるようにしてもよい。作業エリアは、物理的な設置現場のロケーションに対応するモジュール設置可能な領域の境界、範囲又はセットを表していてもよい。作業エリアは、物理的設置現場に対応するオブジェクトのセット又は１つのオブジェクトと、同一の広がりを持っていてもよい。これに替えて、７０１のように、レイアウトが許可されるオブジェクトの部分のみをカバーするように、作業エリアが設定されてもよい。作業エリアは、複数のオブジェクトにまたがって設定されてもよく、複数の作業エリアが規定されてもよい。ポインティングデバイス（例えば、マウス、タッチパッド、ジョイスティック又はタッチスクリーン）、又はキーボードショートカットを使用して、"作業エリア"アイコンを選択し、四角形、ポリライン又はその他のオブジェクトを描くことによって、明示的な作業エリア７０１を形成してもよい。ユーザーは、四角形をドラッグする及び"作業エリア"ツールバーアイコンをクリックすることを含む、又は、コンテキストメニューを使用することを含む、幾何的オブジェクトを規定するあらゆる方法によって、作業エリアを規定してもよい。例示した実施形態では、オブジェクトは、ユーザーによって、明示的な作業エリアとして印を付され（又は、関連付けされ）てもよい。必ずしもそうする必要はないが、ユーザーが生成した作業エリアは、例えば、建物の表面、野原といったオブジェクト、又は視覚的表示全体と同一の広がりを有していてもよい。ユーザーが生成した作業エリアは、明示的な作業エリアに加えて又は替えて、使用されてもよい。
【００６０】
ある場合では、レイアウトエンジンは、屋根又は野原といった非明示的な作業エリアと、明示的な作業エリアとの交差点にのみ、ＰＶモジュールを配置するように設定されていてもよい。別のケースでは、明示的作業エリアは、その他の設置可能オブジェクト又は非明示的な作業エリアを考慮することなく（又は、この考慮に加えて）、設置可能エリアを規定してもよい。オブジェクトに対する初期設置規則を無効にするのに、明示的作業エリアを使用してもよい。これにより、設計者は、モジュールを屋根の一部にのみ配置するか否かといった、モジュールの配置場所に対する制御権を持つことができる。例えば、図７Ａに示すように、設計者が、屋根２０１の西側の部分にのみオブジェクトを配置したいと考えている場合には、設計者は、作業エリア７０１を形成することができる。ある場合には、生成されるレイアウトにおいて、モジュールが、屋根２０１と作業エリア７０１との交差部分にのみ配置される。すなわち、モジュールは、ロケーションＡ（配線管２０３に対する規則のようなその他の規則に一致する）に配置されるが、ロケーションＢには配置されない。このようなレイアウトの一例が、図７Ｂに示されている。
【００６１】
レイアウトエンジンによって明示的作業エリアを実装する１つのアルゴリズムは次のようであってもよい。図６Ａの６２０に示すように、設置可能オブジェクト（屋根又は野原のような）及び明示的作業エリアの両方が含まれるロケーションにのみ、モジュールをタイル状に配置する。そして、方法は、上記のように進められてもよい。これに替えて、６２５において、モジュールを、許可される全ての面上にタイル状に配置した後、明示的な作業エリアの境界の外側になってしまったモジュールに印を付ける及び／又は取り除いてもよい。
【００６２】
ユーザーは、作業エリアの境界を移動させる又は調整することによって、作業エリアを修正することができる。作業エリアの修正に伴って、前に生成されたレイアウトの自動再計算又は再生成が実行されてもよいし、実行されなくてもよい。
【００６３】
［４．アパーチャ］
作業エリアに加えて、又はこれに替えて、システムは、ユーザーが、例えば、レイアウトアパーチャのような、設計設定の１以上のローカライズされたセットを適用するために、１以上の境界を規定可能としてもよい。複数のアパーチャを使用することにより、設計者は、所望のレイアウトに対して、異種の領域を形成することができ、レイアウトプロセスに対して、制御の別の階層を提供するのに使用することができる。上述のレイアウトエンジンでは、モジュールをレイアウトするのに、設計設定の１つのセット（例えば、モジュール種類、方位、開始点等）を使用していた。これに替えて、ユーザーインターフェースは、ユーザーが、１以上のアパーチャを規定可能とし、アパーチャのそれぞれが、１つの境界を含むようにしてもよい。複数のアパーチャを、設計設定の異なる種類の独立したセットと関連付けてもよい。異なるアパーチャは、異なる範囲を有していてもよく、１つのアパーチャの境界内におけるＰＶモジュールのレイアウトは、（例外もあるが）典型的には、少なくとも一部、アパーチャと関連付けられたユーザーが規定する設計設定によって決定されてもよい。
【００６４】
図８Ａに示すように、ユーザーは、第１アパーチャ８０１を規定してもよい。アパーチャの境界８０１は、屋根２０１のような１つのオブジェクトと、及び／又は、明示的又は非明示的作業エリアと同一の外延を有してもよい。または、図８Ａに示すように、アパーチャ境界８０１は、屋根２０１のような設置可能オブジェクトの一部分のみをカバーしてもよい。アパーチャ境界８０１はまた、モジュールが設置されてもよい１以上の作業エリア及び／又はオブジェクトを範囲に含んでもよい。第１アパーチャ８０１は、７０２から７０５に示すように、そのアパーチャに関連付けられた設計設定のセットを有してもよい。アパーチャの設計設定としては、ＰＶモジュールの種類又はモデル、真北の方向に対するモジュールの方位、行間の距離、傾斜角度、搭載方法、ストリング出力電圧、行間オフセット、アパーチャの大きさ及び形状、タイル開始点及びその他の特性を含んでもよい（更なる例については、表５を参照）。ある実施形態では、ユーザーは、設計設定の一部又は全てを変更してもよいし、初期設定のまま続けてもよい。同様に、作業エリア及び／又は屋根２０１のような設置可能オブジェクトの全体又は一部を含むように、第２アパーチャ８０２を生成してもよい。第２アパーチャ８０２は、関連付けられた設計設定の異なるセットを有してもよい。アパーチャは、ユーザーによって形成されてもよいし、自動的に規定されても、予め規定されてもよい。例えば、特定の作業エリア全体、又は、作業現場の表示全体を含むように、一般的な初期アパーチャを、初期値として最初に規定してもよい。これに替えて、ソフトウェアは、ユーザーに、レイアウトエンジンを動作させる前に少なくとも１つのアパーチャを規定するように要求してもよい。例えば、幾何的オブジェクトを選択して、ツールボックスアイコンをクリックする、又は、８０５に示すようにコンテキストメニューを使用することにより、アパーチャを生成してもよい。アパーチャの規則を調整するのに複数の制御方法が適用されていてもよく、例えば、ユーザーは、アパーチャにおけるモジュールレイアウトの方位を示すために、線形参照オブジェクトを選択することができる。
【００６５】
ある場合には、アパーチャと作業エリアとが交差する又は重なる部分に配置されたモジュールの配置は、アパーチャの設計設定に依存する。例えば、図８Ａに示すように、屋根２０１と同一の広がりを有している作業エリアが（明示的に又は非明示的に）形成されたと仮定する。レイアウトエンジンが起動されると、モジュールは、第１アパーチャ８０１の設計設定に従って、ロケーションＡに配置されてもよいし、第２アパーチャ８０２と関連付けられた設計設定に従って、ロケーションＢに配置されてもよいが、ロケーションＣは、アパーチャ内に位置していないことから、ロケーションＣにはモジュールは配置されない。ある場合には、ロケーションＤのように、アパーチャは重なってもよく、この場合は、ロケーションＤには、アパーチャの設計設定の２つ以上のセットが適用されることを意味する。このような場合、システムは、アパーチャ競合解消規則を利用してもよく、これについては、図９を参照して以下に詳細に説明する。また、ロケーションＥは、作業エリア内でないことから、ロケーションＥには、モジュールは配置されない。図８Ｂには、上記の説明に従ってレイアウトされた例が示されており、第１アパーチャ８０１を優先させて、領域Ｄにおける競合が解消されたレイアウトが示されている。アパーチャの競合解消規則については、以下に詳細に説明する。
【００６６】
アパーチャを使用することにより、例えば、図８Ａ及び図８Ｂに示すように、ユーザーは、屋根のような、１つの作業領域又はオブジェクトの第１部分に対して設計設定及び特性の１セットを規定することができ、同じ作業エリア又はオブジェクトの第２の部分に対して、設計設定及び特性の第２セットを規定することが可能となることから、有用である。例えば、ソーラーコレクタが、同じ屋根上の２つの部分に配置され、１つの部分は平らであるが、もう１つの部分は傾斜している場合に、設計者は、それぞれに対して２つの異なる垂直方向に対する搭載角度、南向きに対する方位、ＰＶモジュールのモデル、及び／又は、２種類の屋根に適した搭載システムを選択してもよい。同様に、屋根の一方の面が、他方の面と比べて強い風を受ける場合には、ユーザーは、風が強い方の面に対して第１アパーチャを形成し、風に強いモジュール及び搭載システムを含む設計設定を使用してもよく、風が強くない方の屋根の面に対して第２アパーチャを形成して、風に対してさほど耐性を有さないモジュール及び搭載システムを適用してもよい。アパーチャは、ユーザーによって、（ユーザーが規定した作業エリアとして）移動及び調整可能であってもよく、これにより、設計者が、レイアウトの代替案を素早く可視化することができるようになる。
【００６７】
アパーチャによって、モジュール配置に対する設計設定の異なるセットを提供できるようになることから、隣接する又は重なるアパーチャでは、配置における不一致が生じる場合がある。アパーチャの重複の程度が大きい場合も存在する。アパーチャにおける不一致を解決する規則を使用して、モジュール配置における矛盾点を解消してもよい。不一致解決規則の単純な形の一例は、アパーチャを生成順番でランク付けすることであり、最初に形成されたアパーチャ又は最後に形成されたアパーチャが、一番優先されるようにする。または、辞書式順序を利用してもよい。ユーザーには、明示的にアパーチャの優先順位を変更可能な制御が提供される。優先順位変更の方法の一つは、優先順位を規定しているユーザー編集可能な設計設定とアパーチャそれぞれとの関連付けを行うことであり、例えば、"優先順位＝２"とする。初期設定のアパーチャが存在する場合には、それに対して、最も低い優先順位を割り当ててもよい。
【００６８】
アパーチャ不一致解決規則に従って、様々な方法で、モジュールレイアウトを生成することができる。例えば、アパーチャに対して上述のような優先順位が付与され、配置における不一致が生じた場合には、最も高い優先順位のアパーチャにおける配置が優先される。
【００６９】
例えば、各アパーチャ境界内に少なくとも一部位置しているオブジェクト及び構造物に、上述のような方法を適用することで、優先順位を考慮することなく、規定された全てのアパーチャに対して、独立した部分的なレイアウトが生成されてもよい。この計算は、並列に実行されてもよい。アパーチャに重複が生じない場合には、２つの部分的なレイアウトを結合させたものを、最終的なレイアウトとして、出力デバイスに、保存、格納又はレンダリングしてもよい。重複が存在する場合には、不一致解決規則に基づいて、配置されたモジュール間の不一致を解消してもよい。不一致が発生しているモジュールのある場合には、低い優先順位のアパーチャからのモジュールを取り除き、低い優先順位のアパーチャに対応する部分的な設置レイアウトを修正又は調整してもよい。図９Ａには、レイアウトの一方法が示されている。９００でプロセスが開始し、まず初めに９０１において、設置現場データ（例えば、境界及び構造の物理的大きさのデータ）が入力し、次に、９０２では、オブジェクトを分類し、作業エリア及びアパーチャを生成する。９０４では、アパーチャそれぞれ内に、モジュールのレイアウトを生成し、９０６では、各アパーチャ内に配置されたモジュールを分析して、別のモジュール及び／又は別のアパーチャと、配置に関する不一致が生じていないかを確認する。９０８では、アパーチャの優先順位規則を使用して不一致を解消し、９１０において、前述のようにユーザーがモジュール配置を修正可能とする。このプロセスは、９１２で終了するが、上記の段階に対して、数多くの中間に位置する追加のプロセス、及び同様な段階の繰り返しを行ってもよいことは、明らかである。
【００７０】
これを達成する別の方法は、優先順位の高いものから低いものへと各アパーチャの解析を行い、優先順位の高いアパーチャの一部に既に配置されているモジュールと配置における不一致が生じない限りにおいて、そのアパーチャ内に可能なモジュールの配置を（上記のように）行う。典型的なＰＶモジュールの配置は、そのアパーチャ内で交差する（又はアパーチャ内に収容される）構造物に適用されるアパーチャの設計設定、構造特性、モジュール特性及びプロジェクト特性に応じて、所定のアパーチャの境界内で実行される。この方法では、連続した設置レイアウトのセットが生成され、連続したレイアウトのそれぞれは、現在の及び優先順位の高いアパーチャ全ての設計設定と一致している。連続した設置レイアウトは、デバイス又は媒体にレンダリング又は格納されてもよい。
【００７１】
図９Ｂには、分類されたオブジェクト、作業エリア及び競合しているアパーチャに従って、モジュールをレイアウトするプロセスの別の例が示されている。プロセスは９３０で開始し、初めに、９３１において、ユーザーは、オブジェクトを分類し、１以上の作業エリア及び／又はアパーチャを生成する（若しくは、初期設定の又は明示的な作業エリア及びアパーチャを使用してもよい）。ある実施形態では、アパーチャは、後に行う不一致解決における優先順位を決定づけてもよい、生成の相対的な順番と関連付けられていてもよい。
【００７２】
９３２において、モジュールは、上記の相対的優先順位付け規則に従って決定されてもよい１番目の"第１"アパーチャにおける規則に従って、モジュールを配置する。明示的か非明示的かに関わらず、第１アパーチャ及び作業エリアの境界内にのみ、モジュールが配置されてもよい。明示的な作業エリアが規定されている場合には、アパーチャ、配置可能な面、及び明示的作業エリアの交差点にのみ、モジュールが配置されてもよい。明示的な作業エリアが規定されていない又は使用されない場合には、アパーチャと、屋根のような配置可能オブジェクトによって規定される作業エリアとの交差部分に、モジュールが配置されてもよい。９３３において、例えば、換気扇に対するセットバック必要条件を満たしていないといった、１以上の設計規則に合致しないモジュールには、不適格との印が付与された後、消去される又は有効化されているレイアウトからは取り除かれる。
【００７３】
９３４において、２番目に高い優先順位が付与されたアパーチャ（が存在する場合には）に対して、段階９３２及び段階９３３が繰り返される。しかしながら、通常必要とされる作業エリアの交差点に加えて、第１アパーチャにすでに配置されているモジュールと競合が生じない場合には、第２アパーチャ内にもモジュールを配置してもよい。これは、上記の配置段階（９３２）と同様に行うことができ、例えば、第１アパーチャと一致しない条件のモジュールは、決して配置しないようにする。これに替えて、第１アパーチャにおけるモジュール又は設計設定を考慮することなく、第２アパーチャにモジュールを配置してもよく、その後で、第１アパーチャに配置されたモジュール（又は、それらに付与されている設計設定）と一致しないモジュールが発見された場合には、（段階９３３と同様な段階の間に）そのようなモジュールを取り除く。
【００７４】
９３５において、３番目に高い優先順位が付与されているアパーチャ（存在する場合）に対して、段階９３２及び段階９３３を繰り返す。第１アパーチャ又は第２アパーチャに配置されたモジュール及び設計設定と不一致が生じない場合にのみ、第３アパーチャの規則に従って、モジュールが第３アパーチャ内に配置される。必要であれば、９３６に示すように、残りの全てのアパーチャに対して、このプロセスを繰り返してもよい。９３７において、又はこれよりも前の段階において、ユーザーは、モジュールの配置を修正可能であってもよく、修正に伴って、上記の段階に基づいて、レイアウトの一部又は全ての再生成が実行されてもよい。上記したように、追加の段階を間に挟んで実行してもよいし、９３８においてプロセスが終了する前に、上記の段階を要求に応じて繰り返してもよい。最終的なレイアウトを、コンピュータデバイスに表示してもよいし、レンダリング又は格納してもよい。
【００７５】
［５．プロジェクト階層化及び格納］
プロジェクトの設置現場、構造及びその分類、及びソーラーコレクタのレイアウトを含む、太陽光設備プロジェクト設計は、プロジェクト状態情報によって特徴づけられてもよい。プロジェクト状態情報は、一般的に、特定のソーラーコレクタ設計設定を更に必要とせずに、再生成をするのに使用可能な情報を含む。例えば、プロジェクト状態情報の典型的な使用により、不揮発性メモリに設計を保存することができるようになる。特定の設計に対して、"保存"機能又は制御を起動すると、プロジェクト状態情報がハードディスクに書き込まれるようにしてもよい。そして、ソフトウェアプログラムが停止（動作しているメモリの全てを消去する）してた後、再開する。ユーザーは、"開く"機能又は制御を選択して、ソフトウェアに、保存したプロジェクト状態情報を指し示す。ソフトウェアは、示されたプロジェクト状態情報を読み込み操作を行って、太陽光設備設置プロジェクトを再生成してもよい。
【００７６】
ある場合には、特定の設計が表示されている時のソフトウェアの動作メモリの全コンテンツを、"プロジェクト状態情報"として認識させることができ、これによって特定の設計を十分に特定することができる。プロジェクト状態情報を使用する１つの利点としては、動作メモリ（又はその他のデータ）のサブセットのみを使用する点であり、プロジェクト状態情報のサイズ及び複雑性の両方を低減することができる。例えば、所与の設計が、全てがモジュール種類Ｔ１０であり、１０００×１０００のサブアレイに配置される百万個のコレクタを含むレイアウトを含むとする。このような設計を保存する一つの方法は、関係する特性情報（例えば、"モジュール種類＝Ｔ１０"、ロケーション、方位等）のコピーをそれぞれが有する"コレクタ"データ構造を百万個割り当てて格納することである。これに替えて、システムは、単純に"１０００×１０００のＴ１０モジュールのサブアレイ、方位０度"の状態情報を格納してもよい。このように、プロジェクト状態情報をコンパクトな表示形態にすると、保存する際に便利であり、また修正も容易になる。例えば、設計者が、全てのモジュールについてＴ１０から別の種類への変更を考えているとすると、最初の例の場合では、１００万個のデータ構造を全てスキャンし、それに対して変更を実行しなければならない。一方で、２番目の例の場合には、状態情報に１つの変更を行うだけで、修正を実行することができる。
【００７７】
ある実施形態では、所定の設計に対するプロジェクト状態情報は、設計を再生成するのに使用されるデータのような、設計入力の全てを含む。例えば、プロジェクト状態情報は、幾何的オブジェクト、これら幾何的オブジェクトの構造物としての分類、分類されたオブジェクトそれぞれに対する構造特性、設計設定、作業エリア規定、アパーチャ規定及び付随する設計設定、プロジェクト特性等を含む設置現場の表示のような入力情報を含んでもよい。プロジェクト状態情報はまた、生成されたレイアウト情報に対するユーザー修正のような、その他の種類の入力を含んでもよい。例えば、ユーザーが特定のモジュールのステータスを"不適格"から"適格"へと変更した場合などの、ユーザーが生成されたレイアウトに対してモジュールを手動で追加した場合、そのモジュールの状態は、プロジェクト状態情報に反映させてもよい。
【００７８】
プロジェクト状態情報はまた、生成されたレイアウト、生成されたレイアウトの性能及びコスト特徴等の出力情報を含んでもよい。例えば、特定の設計についての部品表は、設計入力、例えば、設計設定の関数であるから、設計の出力であるといえる。例えば、出力情報をキャッシュしておくことにより、必要となる計算量を低減することができると考えられる。
【００７９】
プロジェクト状態情報の効率的な管理は、難しい場合がある。特に、ある実施形態では、プロジェクト状態情報は、"不一致"情報のために提供されてもよく、例えば、ユーザーが、ＰｏｗｅｒＧｕａｒｄモジュールを、Ｔ１０と指定されたアパーチャ境界内に配置する場合などが挙げられる。システムが、ユーザーによる両方のアクションを有効にする場合には、プロジェクト状態情報を表現する効率的で強力な表示があれば便利である。
【００８０】
そこで、ある実施形態では、プロジェクト状態情報を、データ構造で表現される階層構造要素の配置として認識してもよい。ある条件下では、階層構造は、サブ要素が、固有の親オブジェクトに割り当てられるツリー状構造に似たものであってもよい。別の場には、階層構造は、特定のオブジェクトが１以上の親オブジェクトを有するような階層構造の、一般的なグラフのインスタンスであってもよい。
【００８１】
図１０Ａ及び図１０Ｂは、ソーラーコレクタレイアウト設計ツールによって使用されてもよい、プロジェクト状態情報階層構造を示している。具体的には、図１０Ａに示すように、プロジェクト１０００全体は、設置現場表現１００１を含み、設置現場表現１００１は、１以上の構造１００２を含んでもよい。構造１００２はそれぞれ、構造特性を含んでもよい。
【００８２】
設置現場表示は、複数の作業エリア１００５を含んでもよく、図１０Ａに示されるように、２つの作業エリアを含んでもよい。各作業エリア１００５は、１以上のアパーチャ１０１０を含んでもよく、例えば、第１作業エリア１００５は、１０１０において２つのアパーチャを含んでもよい。これは、設置現場表示において、アパーチャ１０１０が、所定の作業エリア１００５の境界内に収まっている場合である。複数の作業エリアと重複している１つのアパーチャである場合には、アパーチャオブジェクト１０１０は、複数の作業エリア間で共有されていてもよいし、複製されていてもよい。これに替えて、作業エリア１００５に対する子供のオブジェクトとして、（アパーチャ全体ではなく）作業エリアアパーチャの交差点を使用するように、階層構造を調整してもよい。
【００８３】
ある実施形態では、上記したように、ソーラーコレクタが、アパーチャ１０１０と作業エリア１００５との交差部分に配置される。各アパーチャ、又は、作業エリアとアパーチャの交差部は、アパーチャ１０１０内に、コレクタの１以上のサブアレイ１０１５を含んでもよい。所定のアパーチャ１０１０におけるサブアレイ１０１５の数及び構成は、アパーチャの境界内及び周辺に位置する障害物構造を含む、複数の変数の関数であってもよい。例えば、アパーチャを二等分するような線形障害物（例えば、壁のような）によって、アパーチャ１０１０内におけるコレクタのレイアウトが、壁の両側にそれぞれ配置される２つのサブアレイ１０１５に分割される。ある実施形態では、サブアレイ１０１５は、四角形の形状であってもよいし、別の実施形態では、形状に関係なく、アパーチャ１０１０内の隣接するコレクタのグループからサブアレイ１０１５を形成してもよい。別の実施形態では、サブアレイ１０１５を形成するのに、配線条件又は出力条件等のその他の規則１００４を使用してもよい。
【００８４】
所定のサブアレイ１０１５をさらに、コレクタ１０２５の列１０２０へと分割してもよい。ある条件下では、ＰＶモジュールで考えられるように及び上述したように、選択されたモデルに応じて、必要とされる出力電圧を生成するために、所定の数のコレクタを、例えば直列でといったように特定の態様で、互いに配線する必要がある。したがって、例えば、所定のサブアレイの要求される出力電圧が、最大出力にして１５０Ｖである場合、サブアレイを形成するのに使用された特定のモジュールの最大出力がそれぞれ、１５Ｖであるとすると、設置するためには、モジュールを１０個一列（ストリング）にしてグループ化する必要がある。各列におけるコレクタが直列に配線されて、サブアレイの各列は、サブアレイの別の列と並列に接続されてもよい。所定のサブアレイ１０１０は、複数の列（ストリング）１０２０から構成される。これら列１０２０のそれぞれは、複数のコレクタ１０２５から構成されている。
【００８５】
図１０Ｂに示すように、所与のソーラーコレクタは、要素の階層構造を有してもよい。例えば、ＰＶモジュールは、複数のセル列１０３０で構成されていてもよく、セル列のそれぞれは、一連のセル１０３５（図１０Ａに示すサブアレイ１０１５が、複数モジュール１０２５の列１０２０によって構成されているのと同様に）を含む。例えば、１５Ｖのモジュールは、３つのセル列が並列に配線されたものであってもよく、セル列のそれぞれは、１．５Ｖのセルが１０個直列に接続された構成を含む。
【００８６】
階層構造の各層における要素それぞれは、特性のセットと関連付けられていてもよい。例えば、所与の列の特性として、モジュールの数、列の位置等が含まれてもよい。特定の作業エリア、アパーチャ、プロジェクト及び構造と関連付けられてもよい特性の幾つかは、上記で例示した。１つの要素の特性は、完全に表示されてもよいし、特性の別のセットを参照して表示されてもよい。例えば、特性の初期値は、階層構造で表されているデータ構造の親の要素から引き継いだものであってもよく、これらの初期値は、所与の子供に格納されている特性の値を優先させ、無効化されてもよい。
【００８７】
特性と同様に、レイアウトエンジンによって採用される構造レイアウト規則のような設計規則は、階層構造における各要素と関連付けられていてもよい。図１０Ａの１００４に示すように、構造の特定のインスタンスに固有でない設計規則は、プロジェクト又は設置現場に広く関連付けられていてもよい。設計規則も、特定のレイアウト又は設計エンジンから受け継がれたものであってもよく、プロジェクト状態情報階層構造に表示されなくてもよい。また、設計設定も、階層構造における各要素と関連付けられていてもよい。プロジェクト設計設定も、プロジェクト要素と関連付けられていてもよい。階層データ構造は、特性、設計設定及び規則の分類における柔軟性を提供する。例えば、ユーザーによって配置された又は修正されたコレクタは、付随する特性を有する構造１００２として分類されてもよく、階層構造の別のレベル（１０２５に示されているように）又は両方に維持されてもよい。
【００８８】
ある実施形態では、例えば、プロジェクトを保存及び検索するのに使用するべく、プロジェクト状態情報を表示するためにソフトウェアによって使用されるデータ構造は、要素、特性及びそれに関連付けられた設計規則の集合間の階層的関係として表現されていてもよい。例えば、プロジェクト状態情報は、ＸＭＬ型の形式で表示されてもよく、最上階層の設置現場のノードは、構造及びその分類のリストを含んでもよい。設置現場ノードは、また、複数の作業エリアノードを含んでもよく、作業エリアノードは、複数のアパーチャノードを含んでもよい。アパーチャノードのそれぞれは、サブアレイノード等を含んでもよい。レイアウトを再生成するのに十分な情報を、データ構造内に含むという意味では、プロジェクト階層データ構造は、設計プロジェクトの状態を表しているとも言える。
【００８９】
［６．プロジェクト例外］
ある実施形態では、上述したように、設計者が、構造の分類、レイアウトの生成、及びレイアウトの修正といったプロセスを進めると、設計プロセスに関するメタデータが生成されてもよい。メタデータは、例えば、構造特性、設計設定、バージョン情報のような、プロジェクト状態情報に適用される規則から決定されてもよい。このメタデータは、多くの形式であってもよく、設計者が行った動作、及び設計者が行うべき動作に関する情報、管理者、共同設計者、ダウンストリームのユーザー及び設計を受け取る者にとって有用な設計情報を含んでもよい。システムは、メタデータ及びその他のデータを使用して、"例外"のリストを生成してもよく、リストは、例外的条件をメタデータにエンコードしたものであって、例えば、プロジェクト状態情報そのもの、設計出力に反映されたプロジェクト情報、又はその他の条件によって規則が破られる場合を示している。例外的条件及び対応する例外は、ユーザーによる不作為、規制の違反、ソーラーコレクタ製造業者の仕様に対する違反、顧客の要求に対する違反、設計原理に対する違反、物理空間制限に対する違反、会社の設計規則に対する違反等と関連していてもよい。
【００９０】
リストにより、設計者は、適正なアクションを最終的に実行すると同時に、設計欠陥のような例外的条件を見過ごすことなく、設置設計を生成する場合に、より柔軟に一連のアクションを実行することができる。例外リストを使用することにより、特に、特定の順番でワークフローを実行することを強要されず、設計者が選択した順番でアクションを実行することが可能になる。例外リストは、別のアクションを実行する前に、特にユーザーに例外事項（又は例外条件）を対処することを要求することなく、ユーザーに提示されてもよい。例外リストは、特定の例外に対処すべきか否かを設計者が決定する機能を提供してもよい。例外リストはまた、疑いのあるモジュール配置等の、設計についての重要な情報を示す単純なインターフェースを提供してもよい。ユーザーは、例外を効率的に（少なくとも一時的に）無視して、"やるべきことのリスト"の一部としてユーザーがスケジュールした時点に扱われるようにしてもよい。ユーザーは、例えば、ユーザーインターフェースにおいて、例外又は例外リストを、動作を邪魔しないものとして、所定の例外を無視するオプションを提供してもよい。また、ユーザーには、失われている情報を提供する、又は生成されたレイアウト又はユーザーが修正したレイアウトから不適格なモジュールを取り除くことによって、例外条件に対するソフトウェアの例外事項に従うオプションが与えられてもよい。メタデータ及び例外は、契約の例外事項のような、ダウンストリームにおける書類を生成及び維持するのに有用である。
【００９１】
ある実施形態では、例外事項を含むメタデータの一部又は全てが、共有ストレージ又は上記のデータ構造階層構造への参照によって、設計と関連付けられていてもよい。その後、自動化システムを含むダウンストリームのユーザー及び設計の処理者は、メタデータを使用してもよい。メタデータは、集約、エクスポート、暗号化、されてもよく、また、システムによって演算されてもよい。生成されたメタデータ及び例外は、特に、契約における例外事項に関する情報、設計者に対する注意、及び設置現場表示又はレイアウトにおけるエラーを含んでもよい。
【００９２】
図１１に示すように、ユーザーインターフェース１１００は、設計に関するメタデータの一部又は全てが、例外のリスト１１０５の形で設計者に表示されるようにしてもよい。表示には、レイアウト、リスト又は設計例外、及び例外事項を操作することが可能な制御が含まれてもよい。例外は、設計者の一部に対してアクションが必要であることを示してもよい。ある例外事項の場合には、例外が生成されてはいるが、設計者は、要求された情報を提供しなかったことに対する設計プロセスにおける障害を受けるとことが無いようにすることもできる。例えば、ある実施形態では、郵便番号で近似することができる設置現場のロケーションは、レイアウトに影響を与える設置現場特性である。これは、異なる郵便番号が、異なる規制制度を暗に意味しており、例えば、屋根に載せる負荷、セットバック等に関して異なる規制が課されることが考えられる。したがって、設計規則は、郵便番号の提供を要求してもよい。このような場合に、設計者が、設置場所に対する郵便番号を指定し忘れると、この情報の不足が、設計に関するメタデータとして通知されて、郵便番号例外１１１０が生成されてもよい。郵便番号例外１１１０が未決の間であっても、設計者は、初期設定値の郵便番号又はシステムによって提供された規則制度を使用して、オブジェクトの分類、及びレイアウト又はダウンストリームにおける書類作成を進めることができる。
【００９３】
これに替えて、システムは、例外が存在ししている間は、ユーザーは、それと無関係のアクションを実行可能なようにしてもよく、レイアウト生成、シミュレーション又はダウンストリームの書類作成のような特定の動作を許可する前に、設計者に例外の対処をするように要求してもよい。例えば、設計者は、郵便番号を入力する前にオブジェクトの分類を継続することは許されるが、レイアウトを生成することは許されない。別の例としては、その他のメタデータが、設計継続が許されないような致命的な状態を示してもよい。例えば、設計者が換気扇の上にモジュールを配置した場合には、システムは、エラー例外１１１５を生成してもよい。設計者は、最終的な設計が生成される前に、この例外１１１５に対処する。ユーザーが例外に対処していない場合（すなわち、無視している場合）には、その例外は、管理者がレビューするために、例外リスト１１０５に残される。ユーザーによるある種の対処、例えば、要求されたもの又は変更に一致させることは、例外リストの項目から除外されてもよい。例えば、無効化、又は、要求された情報又は変更に一致させることを明示的に拒否するような、ユーザーによるその他の対処の場合には、例外の修正及び例外の保守が必要となり、ユーザーは、例外履歴における入力を無効化する。これは、修正、管理者のレビュー、契約書作成等で将来の有用となる。その他の種類の例外については、以下に記載する。
【００９４】
設計者は、設計者に対応を要求する例外事項について、様々な態様で対処してもよい。例えば、設計者は、設置現場の郵便番号を入力することにより、郵便番号例外１１１０に対処することを選択してもよい。この例外に対しては複数の方法で対処が可能であり、例えば、上記したようなプロジェクト特性を入力するメカニズムを使用して対処可能である。これに替えて、例外１１１０そのものを、これを対処するメカニズムと関連付けてもよい。例えば、郵便番号例外１１１０が、郵便番号を入力するフィールドを含み、プロジェクトと関連付けられていてもよい。ユーザーが例外に対処すると、システムは、情報を再計算又は再生成する。例えば、ユーザーが値を郵便番号例外に入力すると、システムは、その郵便番号を有効化して、例えば、新たなロケーション情報でレイアウトを再生成してもよい。例外に応答して、ユーザーは、例外的条件又は規則違反を是正するのに十分なコンプライアンス情報を提供してもよく、そのような情報としては、プロジェクト特性、顧客特性、設計設定、作業エリア境界及びアパーチャ境界が含まれてもよい。ある実施形態では、コンプライアンス情報を認識して、プロジェクト状態情報又はその他の設計情報を修正するべく情報を使用してもよい。コンプライアンス情報を受信した後、システムは、対応する例外を除去してもよい。
【００９５】
システムはまた、ダウンストリームのユーザー及びプロセスに有用な設計に関する情報又はメタデータを反映する例外を含んでもよい。例えば、設計者が、（オンサイトの検査官によって規定された）"不適格な風の領域"として分類された構造と重複した構造に、モジュールを配置すると、除外例外１１２０が生成される。上記したように、この除外例外が設計者に示されて、設計者は、規則に従うように、例えば、例外を除去又は改善するように（例えば、対象となっている特定のモジュールを取り除くことにより）、制御を操作してもよい。これに替えて又はこれに加えて、除外例外を含む例外の一部は、設計と共に維持される又は設計と関連付けられてもよく、それにより、設計を使用する次のプロセスを実行可能としてもよい。例えば、別のソフトウェアプログラムが、除外例外情報を使用して、設計者と顧客との間で交わされる契約書の条項の一部として記載されてもよい、契約上の例外のリストを生成してもよい。例えば、水漏れがある屋根の領域にモジュールが配置されたことに対応する例外１１２０は、水漏れのある屋根の領域に配置されたモジュールに対する設計者の品質保証を制限する契約上の特別な条項を生成するために、ダウンストリームのプロセスで使用されてもよい。
【００９６】
また、例外の中には、設計者以外の人物又は権限を持つものが、レビュー及び追加の許可を必ず行うように設計されていてもよい。例えば、最大設計重量の９５％の重量負荷がある屋根と関連する例外１１２５は、設計者の管理者による承認を必要としてもよい。設計者が、少なくとも特定の指定されたアクションに関して実行を続ける前に、管理者又は別のユーザーによる例外の承認を要求してもよい。これに替えて、システムは、このような承認を必ず伴う例外の全てついてのリストを生成してもよく、このリストは、設計のダウンストリームプロセスの一部として使用されて、ユーザーが、例外が存在したとしても少なくとも一部のタスクを進められるようにする。後で行う、例外事項の修正、無効化、又は無効化の許可（例えば、管理者による）に伴って、ユーザーが間で行った仕事が無駄にならないように、関連するソーラーコレクタのレイアウトの再生成を行ってもよい。
【００９７】
ある実施形態では、上記の例外及び対処の組み合わせの一部又は全てを実装してもよい。例えば、例外に応じて、システムが設計者に対して利用可能とする適格な対処には、"例外無視"、"自動レイアウト修正"、"例外無効化"、"コレクタ消去"、"レイアウト再生成"、"値入力及び再計算"、"管理者へのフラグ"、"例外に従う"等の変形例が含まれてもよい。例えば、ユーザーは、ソフトウェア制御によって、例外的条件を取り除くことに合わせたプロジェクト状態情報又は設計の修正によって、システムが自動的に例外的条件の修正を試みる段階を実行する命令を発行してもよい。
【００９８】
ある実施形態では、ユーザーの認証を含む例外への対応の一部として行われた動作を含む、ユーザーの対処を記録してもよい。対処の記録は、例外と関連付けられて、所定のプロジェクトと共に格納され、ダウンストリームのユーザー等にエクスポートされてもよい。別の実施形態では、ユーザーの入力又は推進事項のあるなしに関わらず、例外事項の存在を再評価してもよく、例外的条件がもはや存在しない場合には、システムは、その例外事項を除去してもよい。
【００９９】
図１２には、例外を実装するプロセスが示されている。１２０５−１２１０において、システムは、入力認証ループに入ってもよい。１２０５において、設計者は、設置現場情報を入力し、オブジェクトを構造として分類し、構造特性、及びその他の設計特性及び設定を入力してもよい。１２１０において、システムは、幾何的オブジェクト、及び、プロジェクト状態情報におけるその他の入力情報に規則を適用することにより、設計者の入力を分析及び認証してもよい。認証エンジンは、プロジェクトの種類に固有の認証ルールを使用してもよく、又は一般化されてもよい。認証規則は、プロジェクト階層構造と共に格納されてもよいし、プロジェクトの外部に配置されていてもよい。認証エンジンによって、不一致が通知されると、この不一致が例外リストに掲載されて、例えば、１２１２において、コンピュータメモリのデータ構造に配置されてもよい。上記したように、例外事項は、ユーザーに表示されてもよい。ユーザーは、例外リストに配置された例外事項に対処するかを選択する、又は、ユーザーは更なる特性、分類及びその他の情報を入力してもよい。
【０１００】
入力認証ループ１２０５‐１２１０は、ユーザーが１２１５においてレイアウトを生成させるまで、継続させてもよい。このように構成した場合、システムは、レイアウト認証修正ループ１２１５‐１２２０‐１２２５‐１２３０に入ってもよい。１２２０に示すように、生成されたレイアウトが分析されて、設計設定、構造及びプロジェクト特性、レイアウト規則、所望の出力、及びその他の符号化された情報の基準と合致しているかの認証が行われてもよい。生成されたレイアウトから生じた変更又は逸脱が、例外として再び表示され、１２２２において例外リストに配置されてもよい。１２２５において、ユーザーには、上記したように、レイアウトを修正する機能が表示される。修正する機能には、特性又は設定の変更、例外への対処（これは、特性又はレイアウトにおける変更を伴う）、モジュールの追加又は削除等が含まれる。
【０１０１】
１２３０に示すように、ユーザーのアクションが、認証エンジンによって認証されてもよい。１２３２では、ユーザーのアクションによって生じた例外が、例外リストに再び追加されてもよい。ある場合には、ユーザーによる変更が、レイアウトの再生成をトリガすることがある。例えば、ユーザーが、セットバック特性を大きくすると、大きくなったセットバックに合うように、レイアウトが再生成されてもよい。例外の種類に応じて、１２２５‐１２３０のループ（ユーザー入力が認証されてレイアウトの再生成無しに例外事項が生成される）、又は、１２１５‐１２２０‐１２２５‐１２３０ループ（ユーザー入力によって、レイアウトの再生成が発生する）を、必要に応じて又は設計者の要求に応じて、繰り返してもよい。
【０１０２】
１２３５において、例外及び例外に対処するためにとられた動作を含むプロセスを通じて生成されたメタデータの一部又は全ては、存在する場合には、格納されてもよいし、ダウンストリームユーザー対して利用可能としてもよい。例えば、契約書の条項のリストを、契約の除外例外の全てから生成してもよく、承認が必要な例外事項の全てのリストが生成されて、適切な認証実体に転送されてもよい。ユーザーインターフェースは、ソーラーコレクタ設置設計による設計規則の違反に関連した例外的条件に対応する契約例外事項のリストを提供してもよく、契約例外又は条件は、契約書に組み込むべき条項を特定するのに十分な情報を提供する。通常は、メタデータ、例外、又はユーザーのアクションが、プロジェクト状態情報の一部として含まれる。
【０１０３】
［７．プロジェクトのバージョン］
ある実施形態では、特定の設置現場に対するソーラーコレクタレイアウト設計の複数のバージョンを閲覧、生成及び操作するためのシステム及びユーザーインターフェースを提供する。複数のバージョンが扱えるようになると、例えば、設計者は、別のモジュール、別の構造分類、別の作業エリア及び／又はアパーチャ境界、別の入力又は設計設定のその他の種類を選択した場合のレイアウト及びその他の出力を素早く容易に見ることができるようになる。複数のバージョンにより、設計者が、様々な入力変更による出力の変化をインタラクティブに見ることができるようになる。ある実施形態では、設計者が、１つのバージョンから別のバージョンへの移動を迅速にできるようにし、別の実施形態では、設計者が、１つのアクションで複数のバージョンに作用することを可能としてもよい。所定のバージョンは、ユーザーが規定した設計設定、構造特性及びプロジェクト特性の固有のセットを提供するユーザーが規定したプロジェクトの状態情報を含んでもよい。この入力情報の異なるセットを有する異なるバージョンは、ソーラーコレクタ設備の代替レイアウトに対応していてもよく、各バージョンに対する代替レイアウトは、データの固有のセット間の差分から生じる。データの固有のセットはまた、作業エリア状態情報、アパーチャ状態情報、幾何的オブジェクト情報を含んでもよい。
【０１０４】
ある実施形態では、所与の設置プロジェクトの異なるバージョンは、特性を含む設置現場及び／又は構造情報を共有してもよい。このようなバージョンは、可能性のある異なる作業エリア、アパーチャ及びレイアウトを規定してもよい。別の実施形態では、複数のバージョンは、構造情報の全てを共有しなくてもよく、したがって、異なるバージョンが、異なる構造、分類、又は構造特性を有していてもよい。複数のバージョンは、特に、幾何的オブジェクト、オブジェクト分類及び構造特性、プロジェクト特性を含む様々な種類の入力プロジェクト状態情報を共有してもよい。複数のバージョンは、別々のデータセット間の一貫性を保つことにより、データを共有してもよい。これは、ポインタによって、メモリにおける同じ場所を参照するといったように、共有されたプロジェクト状態情報の同じコピーを複数のバージョンが参照することによって達成してもよい。設計設定、構造特性、プロジェクト特性等の入力データの種類それぞれは、１以上の個別のデータが共有され及び／又は１以上のデータが共有されないといったように、分岐されてもよい。
【０１０５】
関連するバージョンは、図１０Ａ及び図１０Ｂで説明したような階層構造の１つ以上の階層において、情報を共有してもよい。例えば、関連するバージョンは、設置現場、及び構造物と構造物の分離を含む設置現場の物理的特徴の共通の内容を共有してもよい。複数のバージョンは、階層構造におけるいかなる点で、互いに分岐してもよい。ツリー状の階層構造の場合には、分岐点の上方の要素は、複数のバージョン間で共有されてもよく、分岐点の上方のデータに対する変更は、両方のバージョンについて適用可能である。これに替えて、分岐点の下方のデータの２つ以上のコピーを維持してもよく、コピーはそれぞれのバージョンに対して維持され、１バージョンにおける分岐点下方のデータに対する変更は、（存在する場合には）別のバージョンにおける対応するデータに影響を与えない。
【０１０６】
ある実施形態では、複数のバージョン間における分岐点は、作業エリアの階層であってもよい。例えば、図１３には、１３０５に３つのバージョンが示されている。図示された例では、３つのバージョン１３０５は、設置現場に依存する関係となっており、それに従って、これらのバージョンは、設計規則１００４、構造１００２の一部又は全て、及びこれらの分類及び特性等を含む符号化された情報の複数のセットを共有してもよい。このような状況において、幾何的オブジェクトの別の構造種類への再分類、構造特性における変更等の設置現場１００１又は構造１００２に対する１つの変更を行うと、その変更が、３つのバージョン１３０５の全ての本質的部分に反映されてもよい。別の例では、バージョン１３０５のそれぞれは、別々の独立した作業エリア１００５、アパーチャ１０１０、及ぶ、レイアウトエンジンによって生成された関連したサブ要素（サブアレイ等、図示せず）を含んでもよい。この場合、作業エリア、アパーチャ又はサブ要素に変更が行われると（特定のモジュールを手動で配置、又は、列の配線パターンにおける変更等）、変更が行われたバージョンにのみ、その変更が適用されてもよい。これは、設計者が、構造分類等のプロジェクトの詳細設定は、全てのバージョンにおいて不変としたい場合に有用である。構造特性における１つの変更について、複数のバージョンを、設計者が手動で更新するのではなく、複数のバージョン間で共有された分類を提供するシステムを配置して、全ての関連するバージョンに対して自動的に更新を行うようにしてもよい。
【０１０７】
このように、プロジェクトデータ構造は、代替バージョンが、上記したように、独立した（共有されない）プロジェクト状態情報及び共有されたプロジェクト状態情報を含むような、設計の代替バージョンを含む。（共有されない）独立したプロジェクト状態情報は、バージョン毎に異なっている。共有されるプロジェクト状態情報と組み合わせる場合に、状態情報は、異なるバージョン間で異なる設置設計を規定してもよい。
【０１０８】
ある実施形態では、階層構造におけるより上位の階層又は下位の階層において、複数バージョンの分岐を行ってもよい。例えば、複数のバージョンは、階層構造における最も上位の階層において分岐してもよく、この場合、複数のバージョンは、構造分類を含む共通の構造を共有しない。これに替えて、複数のバージョンは、下位層において分岐してもよく、例えば、特定のサブアレイに対する列の階層において分岐する場合には、１つのバージョンが、南北方向に複数のモジュールが列になっているとすると、別のバージョンでは、主に東西方向に複数のモジュールがグループ化される。このような場合、２つのバージョンは、分岐点より上に位置する要素（全体的なアパーチャ設計設定等）を共有し、１バージョンにおけるアパーチャ設定の変更は、別のバージョンのそれにも影響を与える。
【０１０９】
図１４に示すように、幾つかの実施形態では、異なるバージョンを表示、生成、修正及び操作するためのインターフェースを提供してもよい。具体的には、１つ以上のバージョンのリスト１４００が提供されてもよい。リスト１４００は、所定のバージョンに固有の階層構造の１以上の階層を反映させてもよく、この例では、"バージョン１"に対して示されている。インターフェースは、バージョンを表示するべく、又はユーザーインターフェースにおける別のオペレーションのために、有効にする（又は選択する）、ツールボックス制御１４５０のようなメカニズムを提供してもよい。１４０５で示されるバージョン１のように、階層のレベルが表示される場合には、バージョン１ １４０５の第１アパーチャ１４１０のように、ユーザーがサブ要素を選択可能な制御を提供してもよく、視覚的表示において選択要素をハイライトする、特性ボックス（図示せず）を表示する、概要情報を表示する等、サブ要素に対する動作を起動してもよい。リスト１４００は、様々なバージョンの分岐点を反映又は表示してもよい。
【０１１０】
１つのバージョンがアクティブ化されると、そのバージョンのコンテンツが、視覚的表示に表示されてもよい。例えば、あるバージョンがアクティブ化されると、そのバージョンに対応するアパーチャ、作業エリア、構造特性、モジュールレイアウト、例外（以下参照）が表示されてもよい。バージョンがアクティブ化されると、レイアウトエンジンが、そのバージョンに対応した（そのバージョンの特性と一致した）レイアウトを再計算してもよい。また、アクティブ化に伴って、バージョンの概要情報のようなバージョンについての情報が、ステータス行又はフィールドに表示されてもよい。設置現場構造が、生成され分類されて、レイアウト、例外等が生成されると、これらの特性及び例外は、現在アクティブ化されているバージョンと関連付けられてもよい。
【０１１１】
アクティブ化されたバージョンに変更が行われ、その変更が、別のバージョン共有されている要素に対するものであったとすると、その変更は、別のバージョンにも反映されてもよい。例えば、２つのバージョンが、上記したように構造分類情報を共有しているとすると、設置現場の所定の構造の再分類、又は、その特性の変更は、両方のバージョンに影響する。アクティブ化されていないバージョンに変更が反映された場合には、そのバージョンと関連付けられたレイアウトの再計算を行ってもよい。バージョン間で共有されていない情報については、アクティブ化されていないバージョンに対する変更は、別のバージョンに影響しない。
【０１１２】
新しいバージョンを形成するべく、新しいバージョンのツールボックス制御１４５５のようなメカニズムが提供されてもよい。新しいバージョンは、一番最初から形成されてもよい（そして、設置現場の特性が適用されてもよい）。これは、最初のバージョンが、新たなプロジェクトの第１バージョン（その時点のみ）として、初期設定で生成される場合が考えられる。これに替えて又はこれに加えて、新しいバージョンは、プロジェクト特性及び構造分類（存在する場合）のようなソーラーコレクタ設置プロジェクト条件の一部を、１つ前のバージョンから継承してもよい。例えば、構造の１セットが規定及び分類されていたとすると、新たに形成されるバージョンは、これらの構造及び分類を継承してもよい。
【０１１３】
バージョンコピーツールボックス制御１４６０のようなメカニズムを提供して、バージョンをコピー又は複製してもよい。新しいバージョンは、既に存在するレイアウト又はバージョンからコピーをする（例えば、分岐する又は複製することによって）ことによって生成されてもよい。現在アクティブ化されているバージョンを使用して、新しいバージョンをそこから分岐させてもよい。複製されたバージョンが、元のバージョンと同じ状態情報の少なくとも一部を使用してシステムに投入された場合には、新たにコピーされたバージョンは、例えば、同じ設置現場特性、アパーチャ、アパーチャ特性、例外等、兄弟バージョンの特性の全て又は大部分から開始してもよい。変更が行われた要素が、バージョン間で共有されているか否かに応じて（図１３に示すように）、新たにコピーされたバージョに対する後の修正が元のバージョンに反映されてもよいし、されなくてもよい。ある実施形態では、ユーザーは、ユーザーが規定した設計設定の固有のセット、新たな又は複製されたバージョンに対応する、ユーザー規定の設計設定の固有セットに反映されていない構造特性、新たなバージョン又は複製バージョンの前に形成されたあらゆるバージョンに対応する構造特性に変更を行ってもよい。
【０１１４】
バージョン消去ツールボックス１４６５のようなメカニズムを提供して、例えば、表示からバージョンを取り除く、及びバージョンと関連付けられた記憶領域から取り除く等、バージョンを消去してもよい。例えば、バージョン名変更ツールボックス制御１４７０のような同様なメカニズムを提供して、バージョンの名前を変更してもよい。
【０１１５】
バージョン固有の情報を生成する、又は、バージョンを操作するためのメカニズムを提供してもよく、例えば、あるバージョンのパーツ概要を生成する（ＣＳＶファイル形式で）パーツ概要ツールボックス制御１４７５、バージョン情報を、例えば、データベース記録又は記録のセットのような別の形式で保存するためのバージョンエクスポートツールボックス制御１４７９、バージョンに関するシミュレーションを実行する及び／又はシミュレーションデータを生成するバージョンシミュレートツールボックス制御１４８５、バージョンシミュレーション情報を、例えばＣＳＶファイル形式等で保存又はエクスポートするバージョンシミュレーションエクスポートツールボックス制御１４９０を提供してもよい。上記した制御のそれぞれは、現在アクティブ化されているバージョン、選択されたバージョン、又は複数のバージョンのセット、又は全バージョンに適用してもよい。
【０１１６】
制御１４７７を使用して、プロジェクトの様々なバージョンの概要を生成してもよい。このバージョン概要は、各バージョンについて様々な比較情報を含んでもよく、例えば、ソーラーコレクタの数、コスト、重さ等のレイアウト情報、期待される性能、最大出力、キロワット／時間の発電に対するコスト、最小エネルギー生成等のシミュレーションデータ、例外数、種類等のその他の種類の情報が含まれてもよい。そのバージョンにおいて、不適格及び不十分、又は良好でない状態で配置されたモジュールに関する情報を、バージョン概要で示してもよい。バージョン概要情報はまた、予測される性能、シミュレーション情報、電力、電力効率、コスト、材料、物理的大きさ、部品点数、及び例外のような、各バージョンについての情報を生成してもよい。この情報は、作業エリア、アパーチャ、サブアレイ、モジュール、列等の特定のバージョンのサブ要素に対して、生成及び表示されてもよい。図１５には、複数のバージョン１５１０の概要が示されているバージョン概要１５００のサンプルが示されている。設計者は、様々なバージョンから選択し、及び／又は複数のバージョンにおける誤り又は不足を特定することを含めて、多くの目的で、バージョン概要情報を使用してもよい。バージョン概要情報は、外部のファイル又は記憶装置にエクスポートされてもよい。ユーザーは、どのバージョン概要情報を表示させるか又はエクスポートするかを選択してもよい。
【０１１７】
設置プロジェクトの様々なバージョンが複数のファイル、又は好ましくは、１つのファイルに保存されていてもよい。上記では、１つのバージョンの設置プロジェクトについて説明したが、複数のバージョンを有するプロジェクトを、ＸＭＬ形式で表示してもよく、最上階層である設置現場ノードは、構造及びそれらの分類のリストを含んでもよい。設置現場ノードは、複数のバージョンノードを含んでもよく、バージョンノードは、複数の作業エリア及びアパーチャノードを含んでもよい。アパーチャノードのそれぞれは、サブアレイノード等を含んでもよい。バージョン概要情報、バージョン名等のバージョンと関連付けられたデータは、バージョンと共に格納されていてもよい。具体的には、ソーラーコレクタレイアウト情報、バージョン概要情報、シミュレーションデータ、契約情報、部品表情報、例外情報等のバージョン毎に異なる場合がある設計出力情報を、キャッシュ又は格納してもよく、バージョンと同じ場所に配置してもよい。
【０１１８】
ある実施形態では、ツールバーアイコン又はキーボードショートカットのような"取り消し"制御を提供して、設計者が、プロジェクト及び／又はバージョンに対して行った１以上の変更を取り消せるようにしてもよい。ある実施形態では、設計者があるバージョンに対して変更を行う場合、それが、レイアウトの修正であれ、オブジェクトの分類であれ、その変更が実施形態により記録される。そして制御は、その効果を反転させることにより、ユーザーが変更を"取り消し"することを可能にする。ある実施形態では、変更を、プロジェクト又はバージョンの状態のスナップショットを撮ることによって記録してもよい。実施形態は、そのスナップショットに戻ることにより、変更を取り消してもよい。これに替えて、実施形態は、変更（又はその反転）によって実体化される状態の遷移を記録してもよい。この状態遷移を逆転させることによって、"取り消し"が実行されてもよい。このように、スナップショット又は遷移のスタックを使用することにより、様々なレベルの取り消しを維持することができる。同様に、"取り消し"アクションが、スナップショット又は遷移を反転させる（"やり直し）アクションを起こし、"取り消し"の反転を、やり直しのスタックに押し込むことにより、やり直し機能を実装してもよい。
【０１１９】
［８．実施例］
図１６Ａ〜図１６Ｅには、本明細書で説明したシステム及び方法の一部の実施形態に係るレイアウトソフトウェアからのスクリーンショットの例が示されている。図１６Ａに示すように、ユーザーインターフェース１６００には、設置現場の可視的表示１６０１が示されており、屋根外縁１６０２で揃えられている２つの傾斜を有する屋根面に対応する幾何的オブジェクトが配置され、幾何的オブジェクトは、複数の立体障害物（通気孔１６０３）及び線形障害物（パイプ１６０４）を含む。ユーザーインターフェース１６００は、ツールバー１６０５及び特性パレット１６０６を含む。インターフェースは、バージョン表示（図示せず）、バージョン概要（１６２０）、例外リスト（図示せず）、ユーザー入力及びシステム出力のためのフィールド１６３０を有してもよく、これらを同時に表示してもよい。
【０１２０】
図１６Ｂに示されるように、ツールバー１６０５の形式の制御によって、ユーザーが構造としてオブジェクトを分類する機能（ここでは、屋根制御１６１０、立体障害物制御１６１２、及び線形障害物制御１６１３が示されている）、及び、作業エリアの境界１６１１を視覚的表示に形成する機能を提供してもよく、作業エリアは、太陽モジュールを配置してもよい範囲を規定している。オブジェクトの分類を解除する１６１４制御を提供してもよい。実際のレイアウトを生成する１６１６制御と共に、レイアウトアパーチャ１６１５を生成する制御を提供してもよい。例外リスト、特性パレット、バージョン概要、バージョンリスト等のどのインターフェース要素を表示させるか選択するのに表示制御１６２５が提供されてもよい。レイアウトは、実質的に、作業エリアの境界とアパーチャの境界との交差点に限定され、アパーチャと関連付けられた設計設定のセットに少なくとも一部したがって、レイアウトが生成される。図に示すように、有用な（特に限定しない）テキストが、ポップアップ、ロールオーバー等の形態の制御で提供されてもよい。図１６Ｃに示すように、同様な機能を達成する制御を含むメニューが、提供されてもよい。図１６Ｄに示すように、特性パレットは、ユーザーが、特定の構造に関する特性を見る及び／又は調整することを可能にする。
【０１２１】
図１６Ｅは、ＰＶモジュールのレイアウトを視覚的表示で生成した結果であり、２つの屋根オブジェクト１６０２、大部分がそれぞれの屋根表面と同じ場所に存在している２つの作業エリアの境界、及び３つのアパーチャ境界（そのうち２つは、矩形状のアパーチャ１６５０であり、１つの屋根及び１つの作業エリアの一部のみにわたって延在し、残りの１つは、不規則な形状をしたアパーチャ１６５０Ａであり、２つの屋及び作業エリアの一部にわたって延在している）が含まれている。図示するように、アパーチャは、アパーチャ内に配置された複数のモジュールのセットを有し、これらモジュールのレイアウトは、アパーチャ内に含まれる対応する屋根、作業エリア及び障害物に関するレイアウト規則に従っている。
【０１２２】
［９．結び］
上記の説明における分類及び規則は、添付の特許請求の範囲によって規定される発明を実施する方法の一部を単に示したものに過ぎないことは、当業者にとって明らかである。設置現場に関するレイアウト要求に基づいて、ＰＶモジュールを幾何的オブジェクト内及び周辺にレイアウトするその他の方法を、同様な結果、表、スクリプト、データ構造等を達成するのに使用してもよい。規則は、上述したように、明示的であってもよいし、及び／又は宣言文を含んでもよく、又は、ＬＩＳＰのような規則中心の言語で使用されているようなものであってもよい。これに替えて、１以上の"規則"は、データ構造、命令ステートメント、プログラムフロー、プログラム構築、配置及び配置アルゴリズムにおいて非示的に表現されたものであってもよい。本明細書で使用されている規則は、ツールがＰＶモジュールレイアウトを生成するのに使用する任意のオブジェクトに関連付けられた情報による一般的な方法の一例を示したに過ぎない。レイアウト制限のような特定の規則は、特定のオブジェクト又は構造、及び／又は特定の種類又は構造の分類と明示的に関連付けられていてもよく、このような規則は、レイアウトエンジンの一部として規定されていてもよいし、非明示的にオブジェクト又は分類と関連付けられていてもよい。
【０１２３】
本明細書に記載されるシステム、方法及び技術は、コンピュータハードウェア、ファームウェア、ソフトウェア又はこれらの組合せに実装されてもよい。これらの技術を実体化するシステムは、適切な入力及び出力コンポーネント、コンピュータプロッセサ、及び、機械可読記憶要素に実体化されたコンピュータプログラム製品、又は、プログラム可能プロセッサによる実行のための媒体を含んでもよい。これらの技術を実装するプロセスは、入力データに対する操作及び適切な出力を生成することによって所望の機能を実行するプログラムの命令を実行するプログラム可能プロセッサによって実行されてもよい。技術は、プログラム可能システムから命令及びデータを受信し、データ及び命令をデータ記憶システムへと送信するべく接続された少なくとも１つのプログラム可能プロセッサ、少なくとも１つの入力コンポーネント、少なくとも１つの出力コンポーネントを含む。コンピュータプログラムはそれぞれ、高級手続き型プログラミング言語又は高級オブジェクト指向プログラミング言語に実装されていてもよく、又は、必要に応じて、アセンブリ言語又は機械言語に実装されてもよい。いずれの場合においても、言語は、コンパイルされても、インタープリタ型言語であってもよい。好適なプロセッサとしては、例えば、汎用マイクロプロセッサ及び特殊用途マイクロプロセッサの両方を含む。多くの場合、プロセッサは、命令及びデータを、リードオンリーメモリ及び／又はランダムアクセスメモリから受信する。コンピュータプログラム命令及びデータを好適に実体化して実装するのに好適な記憶要素は、あらゆる形式の不揮発性メモリを含む。不揮発性メモリの例としては、消去可能プログラム可能リードオンリーメモリ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ要素のような半導体メモリ要素、内蔵ハードディスク及びリームバルディスクのような磁気ディスク、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭディスク）が含まれる。上記のいずれの要素も、特別に設計されたＡＳＩＣ（特定用途向け集積回路）に組み込まれてもよいし、ＡＳＩＣによって補ってもよい。様々なデータ構造のそれぞれの表示、及び上記した方法の段階は、好適に、レンダリングされてもよく、例えば、スクリーン、モニター又はプリンタといったデバイスに、表示される、又は印刷されてもよい。
【０１２４】
本明細書の開示は、特定の実施形態及び適用例を記載しているが、本明細書に記載されている特徴及び効果の全てを提供しないような実施形態及び適用例を含む当業者にとって明らかなその他の実施形態及び適用例も、本開示の範囲内に含まれる。また、選択肢及び代替構成のリスト及び詳細の全ては、例示するものとして解釈されるべきであり、限定するものとして解釈されるべきでない。また、リストは、説明を補助する目的で提供されており、可能性のある代替物の全てを列挙することを試みたものではない。本発明の範囲は、特許請求の範囲を参照することによってのみ規定されることを意図している。
【０１２５】
プロジェクト設計に依存する情報出力のサンプル
【表１】
【０１２６】
太陽光プロジェクト設計の段階のサンプル
【表２】
【０１２７】
構造分類のサンプル
【表３】
【０１２８】
構造特性のサンプル
【表４】
【０１２９】
設計設定のサンプル
【表５】
【０１３０】
プロジェクト設計特性のサンプル
【表６】
【０１３１】
モジュール特性のサンプル
【表７】
【特許請求の範囲】
【請求項１】
物理的設置現場におけるソーラーコレクタ設置の設計を自動化するためのコンピュータベースのユーザーインターフェースであって、
前記物理的設置現場における物理的構造に対応する少なくとも１つの幾何的オブジェクトを含む、前記物理的設置現場の少なくとも部分的な表示と、
前記幾何的オブジェクトを、予め存在する複数の構造分類から選択されソーラーコレクタ設置設計に関する前記物理的構造の特徴の詳細事項と関連付けられる第１の構造分類のインスタンスとして分類する制御と、
前記幾何的オブジェクト、前記構造分類及び関連付けられた前記物理的構造の特徴の前記詳細事項に従って、前記物理的設置現場における設置のためのソーラーコレクタ設置設計を自動的に生成する制御とを備えるユーザーインターフェース。
【請求項２】
前記表示は、前記物理的設置現場における第２の物理的構造に対応する第２幾何的オブジェクトを更に含み、
前記ユーザーインターフェースは、
前記第２幾何的オブジェクトを、前記予め存在する複数の構造分類から選択され、ソーラーコレクタレイアウト設計に関する前記第２の物理的構造の特徴の詳細事項と関連付けられる第２の構造分類として分類する制御を更に備え、
前記ソーラーコレクタ設置設計を自動的に生成する制御は更に、前記第１の構造分類及び前記第１の構造分類と関連付けられた前記物理的構造の特徴の前記詳細事項、並びに、前記第２の構造分類及び前記第２の構造分類と関連付けられた物理的構造の特徴の前記詳細事項に従って、前記物理的設置現場における設置のためのソーラーコレクタ設置設計を生成する請求項１に記載のユーザーインターフェース。
【請求項３】
前記ソーラーコレクタ設置設計は、複数のソーラーコレクタのレイアウトを含む請求項１に記載のユーザーインターフェース。
【請求項４】
前記ソーラーコレクタ設置設計は、複数のソーラーコレクタのレイアウト、及び、関連付けられた搭載ハードウェア及び前記設置の適切な動作に必要な電気部品を含む群のうちの少なくとも１つを含む請求項１に記載のユーザーインターフェース。
【請求項５】
ソーラーコレクタレイアウト設計に関する前記物理的構造の特徴の前記詳細事項は、前記物理的構造の特性を含む請求項１に記載のユーザーインターフェース。
【請求項６】
前記予め存在する複数の構造分類のうちの少なくとも１つが、前記物理的設置現場における非有形構造に対応している請求項１に記載のユーザーインターフェース。
【請求項７】
前記予め存在する複数の構造分類のうちの少なくとも１つが、敷地境界、不動産区画境界、建築規制指定、電線の敷設権、洪水が起きる土地、環境を配慮したエリア、又は特定の地震帯である請求項１に記載のユーザーインターフェース。
【請求項８】
前記物理的設置現場における設置のためのソーラーコレクタ設置設計を自動的に生成する制御は更に、
複数の設計設定のセットに従って、前記ソーラーコレクタのレイアウトを生成することを含む請求項１に記載のユーザーインターフェース。
【請求項９】
前記複数の設計設定のセットは、ソーラーコレクタの種類、方位、レイアウト開始点、搭載システム及び間隔からなる群から選択される少なくとも１つの設計設定を含む請求項８に記載のユーザーインターフェース。
【請求項１０】
前記物理的設置現場における設置のためのソーラーコレクタ設置設計を自動的に生成する制御は更に、
いかなる幾何的オブジェクトとも関連付けられていないプロジェクト特性のセットに従って、前記ソーラーコレクタのレイアウトを生成することを含む請求項１に記載のユーザーインターフェース。
【請求項１１】
前記プロジェクト特性のセットは、土壌の種類、気候条件、設計温度、設計地震負荷、動作特徴、負荷限界、電気配線条件及び建築基準法からなる群から選択される少なくとも１つのプロジェクト特性を含む請求項１０に記載のユーザーインターフェース。
【請求項１２】
前記プロジェクト特性のセットは、少なくとも１つの予め規定された顧客特性を含む請求項１０に記載のユーザーインターフェース。
【請求項１３】
前記顧客特性は、連絡先、法的資格、財務状況、電気利用情報、電気料金、及びエネルギー消費量からなる群から選択される請求項１２に記載のユーザーインターフェース。
【請求項１４】
前記物理的設置現場における設置のためのソーラーコレクタ設置設計を自動的に生成する制御は更に、
予め規定されるプロジェクト設計規則のセットに従って、前記ソーラーコレクタのレイアウトを生成することを含む請求項１に記載のユーザーインターフェース。
【請求項１５】
前記予め規定されるプロジェクト設計規則のうちの少なくとも１つは、電気設備基準、敷地セットバック必要条件、安全必要条件、配線必要条件、工学的規則又は成功事例、及びヒューズ必要条件を含む群のうちの少なくとも１つを規定する請求項１２に記載のユーザーインターフェース。
【請求項１６】
前記幾何的オブジェクトは、線、ポリライン、曲線、正方形、矩形、スプライン、記号、多角形、その他の二次元又は三次元の形、面、画像データ、及び立体を含む群のうちの少なくとも１つを含む請求項１に記載のユーザーインターフェース。
【請求項１７】
ソーラーコレクタレイアウト設計に関する前記物理的構造の特徴の前記詳細事項は、前記物理的構造内又は周辺にソーラーコレクタを自動的に配置するための情報のセットを少なくとも部分的に含む請求項１に記載のユーザーインターフェース。
【請求項１８】
ソーラーモジュールのレイアウトを自動的に決定する前に、ソーラーコレクタレイアウト設計に関する前記物理的構造の特徴の前記詳細事項を修正する制御を更に備える請求項１に記載のユーザーインターフェース。
【請求項１９】
前記ソーラーコレクタ設置設計を修正する制御を更に備える請求項１に記載のユーザーインターフェース。
【請求項２０】
前記ソーラーコレクタ設置設計を修正する制御は更に、前記物理的構造の特徴の部分的な詳細事項の少なくとも一部に反して、前記ソーラーコレクタ設置設計を修正することを可能とする請求項１９に記載のユーザーインターフェース。
【請求項２１】
部品表、レンダリング、財務分析、契約、契約条件、エネルギー予測、コスト分析、部品リスト、シミュレーションを含む群のうちの少なくとも１つを、前記ソーラーコレクタ設置設計と一致させて、生成する制御を更に備える請求項１に記載のユーザーインターフェース。
【請求項２２】
前記ソーラーコレクタ設置設計は、太陽電池モジュールを含む請求項１に記載のユーザーインターフェース。
【請求項２３】
物理的設置現場に設置するためのソーラーモジュール設置レイアウトを生成するシステムであって、
ソーラーモジュール設置レイアウトを生成するために、幾何的オブジェクトと特性とを関連付ける分類コンポーネントと、
少なくとも１つの作業エリアに複数のソーラーモジュールをタイリングすることにより、ソーラーモジュール設置レイアウトを生成し、その後に、第２のオブジェクトと関連付けられたソーラーモジュールのレイアウト禁止に従って、前記タイリングされたソーラーモジュールを少なくとも１つ取り除くレイアウトタイリングコンポーネントとを備え、
前記幾何的オブジェクトは、コンピュータストレージに記憶されており、前記幾何的オブジェクトの少なくとも１つは、前記物理的設置現場における１つの物理的構造に対応しており、
前記分類コンポーネントは、第１幾何的オブジェクトを、前記第１幾何的オブジェクト内のソーラーモジュールのレイアウトに対する作業エリアと関連付け、第２幾何的オブジェクトを、前記第２幾何的オブジェクト内のソーラーモジュールのレイアウト禁止と関連付けるシステム。
【請求項２４】
ユーザーが、ソーラーモジュール設置レイアウトを修正することを可能とする修正コンポーネントを更に備え、
ソーラーモジュール設置レイアウトを修正することは、
ソーラーモジュールのレイアウト禁止に従って取り除かれたタイリングされたモジュールを置き換えること、及び、ソーラーモジュールのレイアウト禁止に従って取り除かれなかった配置されているソーラーモジュールを取り除くことのうちの少なくとも１つを含む請求項２３に記載のシステム。
【請求項２５】
前記ソーラーモジュールは、太陽電池モジュールを含む請求項２３に記載のユーザーインターフェース。
【請求項２６】
前記少なくとも１つの作業エリアにソーラーモジュールをタイリングすることは、ソーラーモジュールのグリッドを形成することを含む請求項２３に記載のユーザーインターフェース。
【請求項２７】
前記少なくとも１つの作業エリアにソーラーモジュールをタイリングすることは、開始点に並べられたソーラーモジュールのアレイを形成することを含む請求項２３に記載のユーザーインターフェース。
【請求項２８】
前記少なくとも１つの作業エリアにソーラーモジュールをタイリングすることは、アパーチャの設計設定に従ってソーラーモジュールをタイリングすることを含む請求項２３に記載のユーザーインターフェース。
【請求項１】
物理的設置現場におけるソーラーコレクタ設置の設計を自動化するためのコンピュータベースのユーザーインターフェースであって、
前記物理的設置現場における物理的構造に対応する少なくとも１つの幾何的オブジェクトを含む、前記物理的設置現場の少なくとも部分的な表示と、
前記幾何的オブジェクトを、予め存在する複数の構造分類から選択されソーラーコレクタ設置設計に関する前記物理的構造の特徴の詳細事項と関連付けられる第１の構造分類のインスタンスとして分類する制御と、
前記幾何的オブジェクト、前記構造分類及び関連付けられた前記物理的構造の特徴の前記詳細事項に従って、前記物理的設置現場における設置のためのソーラーコレクタ設置設計を自動的に生成する制御とを備えるユーザーインターフェース。
【請求項２】
前記表示は、前記物理的設置現場における第２の物理的構造に対応する第２幾何的オブジェクトを更に含み、
前記ユーザーインターフェースは、
前記第２幾何的オブジェクトを、前記予め存在する複数の構造分類から選択され、ソーラーコレクタレイアウト設計に関する前記第２の物理的構造の特徴の詳細事項と関連付けられる第２の構造分類として分類する制御を更に備え、
前記ソーラーコレクタ設置設計を自動的に生成する制御は更に、前記第１の構造分類及び前記第１の構造分類と関連付けられた前記物理的構造の特徴の前記詳細事項、並びに、前記第２の構造分類及び前記第２の構造分類と関連付けられた物理的構造の特徴の前記詳細事項に従って、前記物理的設置現場における設置のためのソーラーコレクタ設置設計を生成する請求項１に記載のユーザーインターフェース。
【請求項３】
前記ソーラーコレクタ設置設計は、複数のソーラーコレクタのレイアウトを含む請求項１に記載のユーザーインターフェース。
【請求項４】
前記ソーラーコレクタ設置設計は、複数のソーラーコレクタのレイアウト、及び、関連付けられた搭載ハードウェア及び前記設置の適切な動作に必要な電気部品を含む群のうちの少なくとも１つを含む請求項１に記載のユーザーインターフェース。
【請求項５】
ソーラーコレクタレイアウト設計に関する前記物理的構造の特徴の前記詳細事項は、前記物理的構造の特性を含む請求項１に記載のユーザーインターフェース。
【請求項６】
前記予め存在する複数の構造分類のうちの少なくとも１つが、前記物理的設置現場における非有形構造に対応している請求項１に記載のユーザーインターフェース。
【請求項７】
前記予め存在する複数の構造分類のうちの少なくとも１つが、敷地境界、不動産区画境界、建築規制指定、電線の敷設権、洪水が起きる土地、環境を配慮したエリア、又は特定の地震帯である請求項１に記載のユーザーインターフェース。
【請求項８】
前記物理的設置現場における設置のためのソーラーコレクタ設置設計を自動的に生成する制御は更に、
複数の設計設定のセットに従って、前記ソーラーコレクタのレイアウトを生成することを含む請求項１に記載のユーザーインターフェース。
【請求項９】
前記複数の設計設定のセットは、ソーラーコレクタの種類、方位、レイアウト開始点、搭載システム及び間隔からなる群から選択される少なくとも１つの設計設定を含む請求項８に記載のユーザーインターフェース。
【請求項１０】
前記物理的設置現場における設置のためのソーラーコレクタ設置設計を自動的に生成する制御は更に、
いかなる幾何的オブジェクトとも関連付けられていないプロジェクト特性のセットに従って、前記ソーラーコレクタのレイアウトを生成することを含む請求項１に記載のユーザーインターフェース。
【請求項１１】
前記プロジェクト特性のセットは、土壌の種類、気候条件、設計温度、設計地震負荷、動作特徴、負荷限界、電気配線条件及び建築基準法からなる群から選択される少なくとも１つのプロジェクト特性を含む請求項１０に記載のユーザーインターフェース。
【請求項１２】
前記プロジェクト特性のセットは、少なくとも１つの予め規定された顧客特性を含む請求項１０に記載のユーザーインターフェース。
【請求項１３】
前記顧客特性は、連絡先、法的資格、財務状況、電気利用情報、電気料金、及びエネルギー消費量からなる群から選択される請求項１２に記載のユーザーインターフェース。
【請求項１４】
前記物理的設置現場における設置のためのソーラーコレクタ設置設計を自動的に生成する制御は更に、
予め規定されるプロジェクト設計規則のセットに従って、前記ソーラーコレクタのレイアウトを生成することを含む請求項１に記載のユーザーインターフェース。
【請求項１５】
前記予め規定されるプロジェクト設計規則のうちの少なくとも１つは、電気設備基準、敷地セットバック必要条件、安全必要条件、配線必要条件、工学的規則又は成功事例、及びヒューズ必要条件を含む群のうちの少なくとも１つを規定する請求項１２に記載のユーザーインターフェース。
【請求項１６】
前記幾何的オブジェクトは、線、ポリライン、曲線、正方形、矩形、スプライン、記号、多角形、その他の二次元又は三次元の形、面、画像データ、及び立体を含む群のうちの少なくとも１つを含む請求項１に記載のユーザーインターフェース。
【請求項１７】
ソーラーコレクタレイアウト設計に関する前記物理的構造の特徴の前記詳細事項は、前記物理的構造内又は周辺にソーラーコレクタを自動的に配置するための情報のセットを少なくとも部分的に含む請求項１に記載のユーザーインターフェース。
【請求項１８】
ソーラーモジュールのレイアウトを自動的に決定する前に、ソーラーコレクタレイアウト設計に関する前記物理的構造の特徴の前記詳細事項を修正する制御を更に備える請求項１に記載のユーザーインターフェース。
【請求項１９】
前記ソーラーコレクタ設置設計を修正する制御を更に備える請求項１に記載のユーザーインターフェース。
【請求項２０】
前記ソーラーコレクタ設置設計を修正する制御は更に、前記物理的構造の特徴の部分的な詳細事項の少なくとも一部に反して、前記ソーラーコレクタ設置設計を修正することを可能とする請求項１９に記載のユーザーインターフェース。
【請求項２１】
部品表、レンダリング、財務分析、契約、契約条件、エネルギー予測、コスト分析、部品リスト、シミュレーションを含む群のうちの少なくとも１つを、前記ソーラーコレクタ設置設計と一致させて、生成する制御を更に備える請求項１に記載のユーザーインターフェース。
【請求項２２】
前記ソーラーコレクタ設置設計は、太陽電池モジュールを含む請求項１に記載のユーザーインターフェース。
【請求項２３】
物理的設置現場に設置するためのソーラーモジュール設置レイアウトを生成するシステムであって、
ソーラーモジュール設置レイアウトを生成するために、幾何的オブジェクトと特性とを関連付ける分類コンポーネントと、
少なくとも１つの作業エリアに複数のソーラーモジュールをタイリングすることにより、ソーラーモジュール設置レイアウトを生成し、その後に、第２のオブジェクトと関連付けられたソーラーモジュールのレイアウト禁止に従って、前記タイリングされたソーラーモジュールを少なくとも１つ取り除くレイアウトタイリングコンポーネントとを備え、
前記幾何的オブジェクトは、コンピュータストレージに記憶されており、前記幾何的オブジェクトの少なくとも１つは、前記物理的設置現場における１つの物理的構造に対応しており、
前記分類コンポーネントは、第１幾何的オブジェクトを、前記第１幾何的オブジェクト内のソーラーモジュールのレイアウトに対する作業エリアと関連付け、第２幾何的オブジェクトを、前記第２幾何的オブジェクト内のソーラーモジュールのレイアウト禁止と関連付けるシステム。
【請求項２４】
ユーザーが、ソーラーモジュール設置レイアウトを修正することを可能とする修正コンポーネントを更に備え、
ソーラーモジュール設置レイアウトを修正することは、
ソーラーモジュールのレイアウト禁止に従って取り除かれたタイリングされたモジュールを置き換えること、及び、ソーラーモジュールのレイアウト禁止に従って取り除かれなかった配置されているソーラーモジュールを取り除くことのうちの少なくとも１つを含む請求項２３に記載のシステム。
【請求項２５】
前記ソーラーモジュールは、太陽電池モジュールを含む請求項２３に記載のユーザーインターフェース。
【請求項２６】
前記少なくとも１つの作業エリアにソーラーモジュールをタイリングすることは、ソーラーモジュールのグリッドを形成することを含む請求項２３に記載のユーザーインターフェース。
【請求項２７】
前記少なくとも１つの作業エリアにソーラーモジュールをタイリングすることは、開始点に並べられたソーラーモジュールのアレイを形成することを含む請求項２３に記載のユーザーインターフェース。
【請求項２８】
前記少なくとも１つの作業エリアにソーラーモジュールをタイリングすることは、アパーチャの設計設定に従ってソーラーモジュールをタイリングすることを含む請求項２３に記載のユーザーインターフェース。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６Ａ】
【図１６Ｂ】
【図１６Ｃ】
【図１６Ｄ】
【図１６Ｅ】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６Ａ】
【図１６Ｂ】
【図１６Ｃ】
【図１６Ｄ】
【図１６Ｅ】
【公表番号】特表２０１２−５１８８３８（Ｐ２０１２−５１８８３８Ａ）
【公表日】平成２４年８月１６日（２０１２．８．１６）
【国際特許分類】
【出願番号】特願２０１１−５５１１０１（Ｐ２０１１−５５１１０１）
【出願日】平成２２年２月３日（２０１０．２．３）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０２３０６５
【国際公開番号】ＷＯ２０１０／０９６２６８
【国際公開日】平成２２年８月２６日（２０１０．８．２６）
【出願人】（５０５３７９４６７）サンパワー コーポレイション (41)
【Ｆターム（参考）】
【公表日】平成２４年８月１６日（２０１２．８．１６）
【国際特許分類】
【出願日】平成２２年２月３日（２０１０．２．３）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０２３０６５
【国際公開番号】ＷＯ２０１０／０９６２６８
【国際公開日】平成２２年８月２６日（２０１０．８．２６）
【出願人】（５０５３７９４６７）サンパワー コーポレイション (41)
【Ｆターム（参考）】
[ Back to top ]