もしあなたが Migrate To Utility Network ツールを使って電気データをユーティリティネットワークに移行した場合、おそらく「このユーティリティネットワークを電気配電ネットワークのように動作させるためにはどのような構成を行う必要があるのか？」と自問していることでしょう。
これらのネットワークは、変電所にある中電圧遮断器からネットワーク内の低電圧顧客まで電気が通る経路をモデル化しています。これらのデータセットの分析ワークフローは、遮断器や変圧器の負荷を調べることから、保護装置がシステム内の潜在的な故障に対応できるよう適切なサイズであることを確認することまで多岐にわたります。
この記事では、Migrationツールセットを使用して作成されたモデルをどのように拡張し、これらの基本的なワークフローのいくつかをサポートできるかをご紹介します。
注意：ネットワークの構成変更を行う前に、すべてのトポロジーエラーが解決されていることを確認してください。エラーが含まれるネットワーク領域ではトレースができません。ネットワークトポロジーを有効にしたりユーティリティネットワークを展開した後でトポロジーエラーを修正すると、「Apply Error Resolutions」などのツールでエラーを自動的に修正する機能が制限されます。
接続トレース
ユーティリティネットワークで最も基本的なトレースは接続トレースです。接続トレースを実行するには、マップ上のネットワークフィーチャーに開始点を追加し、接続トレースを実行します。このタイプのトレースは、指定された場所から設定された構成に基づいて通過可能なすべてのフィーチャーを返します。追加設定なしの接続トレースは、以下に示すようにおそらくデータセット全体を返します。
これは切断されたフィーチャーを特定する便利なテストですが、より現実的なトレースではデバイスの状態（開／閉）、電気位相、およびフィーチャーがサービス中か提案中かを考慮します。これらの条件は手動でバリアとしてトレースに追加してシミュレートできますが、推奨される方法は条件バリアとして定義することです。
Migrate To Utility Network を使ってネットワークを作成すると、すべてのフィーチャーにenabledフィールドがあります。ジオメトリックネットワークからデータを移行した場合、このフィールドにはバリアとして機能すべきかどうかを示す値が入っています。以下の例ではジオメトリックネットワークからのデータでトレースを実行し、無効化されたフィーチャー（開いたデバイス）をバリアとして扱っています。
初期トレースとは異なり、このトレースは開始点に関連付けられたフィーチャーと電気的につながっているすべてのフィーチャーを返します。トレース中にこれら条件バリアを評価することで、開始位置から回路の範囲を特定できます。
enabledフィールドを条件バリアとして使うことは完全に許容されますが、enabledフィールドの管理に慣れていない場合やスイッチ可能なデバイス状態管理に別のフィールドを使いたい場合もあります。この点については次節で説明します。
デバイス状態
トレースや分析でフィーチャーから属性を参照するには、ユーティリティネットワークが参照できるようにネットワーク属性を作成します。ここでは、トレース管理に使えるDevice Status ネットワーク属性作成例をご紹介します。
最初のステップは使用したいデータ内のフィールドを特定することです。この例ではdeviceクラス内のNormalOperatingStatusフィールドを使用します。これは短整数型でドメインが割り当てられており、デバイスが開（1）か閉（0）かを示します。
使用するフィールド・データ型・ドメインが特定できたので、次にネットワーク属性を作成します。まず、このフィールドと同じデータ型でユーティリティネットワークにネットワーク属性を追加します。この属性はほぼすべてのトレースで使うためインライン保存しパフォーマンス向上させます。
オンラインヘルプ「network attributes」をご覧いただくと、それらの使用方法やユーティリティネットワーク挙動への影響について詳しく知ることができます。
ネットワーク属性がユーティリティネットワークに追加されたら、次はどのフィールドと関連付けるか選択します。すべてのクラスと関連付ける必要はありませんが、一つのクラスにつき一つだけ関連付け可能です。複数ステータスフィールドがあっても一つだけ選択できます。
このフィールドとネットワーク属性が関連付けられたら、それを使ってトレース用条件バリア定義が可能になります。
ユーザーがネットワーク属性と関連付けられたフィールドを書き換えると、そのフィーチャーは新しい値で更新するため検証すべきダーティエリア（未検証領域）を生成します。以下例では閉じたヒューズ（1）でトレースし、その後ヒューズ状態を開きへ変更し編集検証後、新たに開いたヒューズ（2）でトレース停止しています。
この方法は単一ステータスフィールドの場合によく機能しますが、それぞれ位相ごとに異なるステータスフィールド管理の場合はどうでしょう？次節で説明します。
複数ステータスフィールド
前節では単一フィールドでデバイス開閉状態モデル化しました。しかし各位相ごと別々ステータス管理可能な場合はいくつか解決策検討が必要です。
電気モデルでは一般的に3つ別々フィールドでデバイス開閉状態管理します。それぞれA, B, Cという異なる電気位相対応し、このモデルは各位相ごとの状態モデル化可能です。
Migrate To Utility Network ツール使用時、デバイスは連動操作（gang operated）として扱われます。つまりデバイス全体として開または閉のみで混合状態不可です。混合状態モデル化必要なら別々デバイスとしてモデル化するか Electric Utility Network Foundation にデータ移行する必要があります。
Migrate To Utility Network ツール利用時これら対応方法はいくつかあります。一番簡単なのはenabledフィールド継続利用（または単一デバイスステータスフィールド作成）して既存ステータス値からこのフィールド埋める方法です。そのためには以下理解しておく必要があります：
- 各位相ステータス表現にはどんなフィールド使っていますか？
- 開閉それぞれどんな値ですか？
- ネットワーク内で位相表現にはどんなフィールド使っていますか？
- 位相フィールド内どんな値が各ステータスフィールド適用されますか？
これら情報使い、「Select By Attributes」ツールで開閉すべき機器識別できます。
以下例をご覧ください。
- 各位相ステータス表現にはどんなフィールド使っていますか？
- StatusValueOpen0Closed1 PhasingCodePhaseValueA4B2C1AB6AC5BC3ABC7 この情報から3つクエリを書けます：QueryExpression開くべき機器 (Enabled=False)ENABLED=1 AND(((POSA=0 AND PHASINGCODE=4)OR (POSB=0 AND PHASINGCODE=2)OR (POSC=0 AND PHASINGCODE=1))OR(((POSA=0 OR POSB=0) AND PHASINGCODE=6)OR ((POSA=0 OR POSC=0) AND PHASINGCODE=5)OR ((POSB=0 OR POSC=0) AND PHASINGCODE=3))OR((POSA=0 OR POSB=0 OR POSC=0) AND PHASINGCODE=7))閉じるべき機器 (Enabled=True)ENABLED=0 AND(((POSA=1 AND PHASINGCODE=4)OR (POSB=1 AND PHASINGCODE=2)OR (POSC=1 AND PHASINGCODE=1))OR(((POSA=1 OR POSB=1) AND PHASINGCODE=6)OR ((POSA=1 OR POSC=1) AND PHASINGCODE=5)OR ((POSB=1 OR POSC=1) AND PHASINGCODE=3))OR((POSA=1 OR POSB=1 OR POSC=1) AND PHASINGCODE=7))混合状態機器識別クエリ(PHASINGCODE=6 AND ((POSA=0 AND POSB=1) OR (POSA=1 AND POSB=0)))OR (PHASINGCODE=5 AND ((POSA=0 AND POSC=1) OR (POSA=1 AND POSC=0)))OR (PHASINGCODE=3 AND ((POSB=0 AND POSC=1) OR (POSB=1 AND POSC=0)))OR (PHASINGCODE=7 AND ((POSA=0 AND POSB=0 AND POSC=1) OR (POSA=0 AND POSB=1 AND POSC=0) OR (POSA=0 AND POSB=1 AND POSC=1) OR (POSA=1 AND POSB=0 AND POSC=0) OR (POSA=1 AND POSB=0 AND POSC=1))) この技術適用例をご覧ください。まず混合状態機器識別クエリ実行し該当機器あれば今後混合状態対応方針検討してください。一つステータス欄利用し複数欄管理も可ですが、それ以外ならElectric Utility Network Foundationなど他手段検討してください。その後開くべき機器(Enabled=False)全選択してください。
- ネットワーク内で位相表現にはどんなフィールド使っていますか？
- 位相フィールド内どんな値が各ステータスフィールド適用されますか？
次にこれら機器のEnabled フィールド無効／開放へ設定してください。
注意：大規模データセットの場合編集適用前にネットワークトポロジー無効化やデバイス層上属性ルール無効化検討してください。
編集適用すると検証すべきダーティエリア発生します。編集検証前にこの手順繰り返し有効／閉鎖すべき機器識別してください。この理由はEnabled フィールドはネットワーク属性なので変更検証時「Validate Network Topology」ツール利用必須だからです。一度全ダーティエリア検証完了またはネットワークトポロジー再有効化すると、新値反映したトレース実行可能になります。
ここまで電気ネットワーク内デバイス状態モデル化技術説明しましたので、次にユーティリティネットワーク内回路モデル化方法とサブネットワーク呼称理由について見てみましょう。
Electrical Phasing
活線相の管理は、多くの電気顧客にとってトレースおよび分析の重要な要件です。システム内のすべての線路とデバイスの相順を追跡する場合は、トレースおよび分析時に使用できるように、ネットワークに相情報を含めるために次の手順に従う必要があります。
この構成を実行するには、次の情報を特定する必要があります：
- どのクラスとフィールドが相順を含んでいますか？
- 相順を整数値で表現していますか？
- 相順を表現するためにどのドメインを使用していますか？
この情報を使って、ネットワーク内で相順を追跡するために使用されるネットワーク属性を作成し割り当てることができます。最初に必要なのは、システム内のすべての相の組み合わせを表す符号付き値ドメインです。ユーティリティネットワークはビット単位演算を使って相順を計算および伝播するため、このフィールドは相管理に使用する場合は整数である必要があります。品質保証や分析目的ではなく報告目的だけなら、非整数値で表現しても構いません。基本記事と高度な記事の両方では、ビット単位計算用に設計された符号付き値ドメインと整数を使用して相順を表現します。ユーティリティネットワークが属性を伝播する方法については、サブネットワーク管理における属性伝播と属性置換の記事をご覧ください。
次のステップは、デバイス、ジャンクション、およびラインクラスそれぞれが、このドメインを使用して相順を追跡する単一フィールドを持っていることを確認することです。これが完了したら、このフィールドを使用するようにユーティリティネットワークを構成する準備が整います。
まず、Add Network Attributeツールを使ってネットワークにネットワーク属性を追加します。多くのユーティリティネットワーク管理ツールと同様に、このツールを実行する前にネットワークトポロジーを無効化する必要があります。属性をインラインとしてマークするときは、上記で特定したデータ型とドメインを選択してください。
ネットワーク属性をユーティリティネットワークに追加したら、このネットワーク属性に対応するクラスとフィールドをユーティリティネットワークに指定する必要があります。これには、ネットワーク内で相順を管理する各クラスに対してSet Network Attributeツールを使用します。通常、これにはElectric Device、Electric Junction、およびElectric Lineクラスが含まれます。
これが完了すると、ネットワークトレース実行時にこのフィールドを使用できるようになります。この属性の最も簡単な使い方は、トレース中にフィルターまたはバリアとして機能させることです。以下はA相があるすべてのフィーチャーを返す例です。
注意：対応するクラスのネットワーク属性のフィールドレベルで相順フィールドを割り当てると、手動で数値入力する代わりにドロップダウンが表示されます。
これは便利な報告メカニズムですが、サブネットワークが活線状態判定時に相順も考慮させたい場合は追加設定が必要です。その内容は高度な構成の記事で説明しています。
サブネットワークの作成
ほとんどの電力配電回路は、ステーション内の回路遮断器またはリクロージャから始まります。この回路遮断器より下流はすべて同じ回路の一部です。ユーティリティネットワーク用語では、この回路は分析目的で重要な明確なサブセットであるためサブネットワークと呼ばれます。サブネットワークのソース／シンクとして機能するデバイスはサブネットワークコントローラーと呼ばれます。ほとんどの電気ネットワークの場合、回路遮断器（またはリクロージャ）がサブネットワークコントローラーであり、多くの場合回路には単一のサブネットワークコントローラーがあります。より高いレベルでは配電ドメインネットワークはソースベースです。つまり回路遮断器がサブネットワークのフロー源であり、その下流すべてのフィーチャーより上流にあります。
接続トレースを実行し、Disabled／Open状態のフィーチャーや回路遮断器でバリア設定すると回路範囲が判定できます。以下は回路遮断器起点でこの設定によるトレース結果です：
ここまで実行したトレースはすべて接続性トレースでした。それは上流・下流・隔離トレースにはサブネットワーク定義が必要だからです。ユーティリティネットワークでサブネットワークコントローラー作成には2つ方法があります。1つ目はModify Subnetwork Controllerペインからフィーチャー選択して手動でサブネットワーク作成する方法です。
元の例に戻ります。回路遮断器が回路制御装置だと分かっているので、「Is Controller」オプションをMigrate To Utility Networkツールでそのマッピングにチェックしておくべきでした。これによって生成される資産タイプがサブネットワークコントローラーとして機能します。それがされていない場合は、「Set a subnetwork controller」オンラインヘルプページの指示通り手動設定が必要です。Set a subnetwork controllerオンラインヘルプページをご参照ください。
回路遮断器がサブネットワークコントローラーとして許可されたら、Modify Subnetwork Controllerツールで回路遮断器をサブネットワークコントローラー化し、その作成したダーティエリア（変更領域）を検証します。その後同じ条件バリア設定でサブネットワークトレース実行すると回路範囲が得られます。
注意：Enabled／Device状態用条件バリア設定なしでトレースすると正しい結果になりません。その理由と修正方法についてはSubnetwork Definitionセクションで説明します。
その回路内で上流・下流トレースも実行可能であり、条件バリア適用すれば成功します。
手動によるサブネットワーク作成方法をご理解いただいたので、次は多数または何千もの回路／サブネットワークがある多くの電気網向け重要ステップとして、一括してサブネットワークコントローラー群をユーティリティネットワークへインポートする方法をご紹介します。
サブネットワークのインポート
2つ目の方法はシステム内すべてのサブネットワーク情報記述CSVファイルからインポートすることです。この両方とも有効ですが、多くの電気顧客にはCSVファイル作成による全サブネットコントローラー定義が比較的容易です。このプロセスについて詳しくはImport a subnetwork controllerオンラインヘルプページをご覧ください。この例では以下CSVファイルを作成しました。
CSVファイル入力後、Import Subnetwork Controllersツールでファイルインポートし対応フィーチャー群へサブネットコントローラー権限付与します。
インポート後、それぞれコントローラー上でダーティエリア検証しないとソースとして認識されません。この処理後、上流・下流・隔離などサブネットコントローラー依存トレース実行可能になります。
前述したように、サブネットトレース成功には開閉スイッチ停止用条件バリア手動定義も必須です。この次節ではSet Subnetwork Definitionツール利用による全サブネッ トレース既定動作化方法をご紹介します。
サブネットトレース構成
ここまで各トレースごと条件バリア指定必須でしたが、自動適用させたい場合Set Subnetwork Definitionツール利用し、これら条件バリア既定化できます。またこのツール編集中に調整推奨他パラメータ重要性も解説します。Set Subnetwork Definitionツールでは対象となるネットワーク・ドメイン・ティア選択後、そのティア現在設定済みサブネッ ト定義内容自動表示されます。
最初に条件バリア追加します。この操作はツール内Subnetwork Trace ConfigurationセクションCondition Barriersパラメータへ入力します。このセクション変更内容は該当ティア解析時ユーティリティ ネット既定トレース構成へ反映されます。
Migrate To Utility Networkツール既定では無効化されたフィーチャー用単一条件バリア追加されています。
前例ではOpenデバイスもバリア扱い追加したいので別条件バリア追加しました。他にも障壁として使いたい属性あればここで設定可能です。
このセクション検討推奨オプションとしてコンテナ・コンテンツ・構造物含めるかどうかがあります。それらモデル化するとサブネッ トレース時迅速に支援・被支援フィーチャー特定可能になります。
さらに各サブネッ ト集約統計計算用要約定義も可能です。この要約属性指定すると集約結果計算し報告用にサブネッ トラインフィーチャーへ格納できます。一例として以下図示した回路全導体長合計計算などがあります。
集約計算には時間かかるためユーザー利益との時間配分考慮してください。この設定調整後「実行」クリック可能ですが他セクション調整も検討ください。
有効なフィーチャーおよびオブジェクト
Valid Features and Objects
サブネットワーク定義のもう一つの重要なセクションは、有効なフィーチャとオブジェクトのセクションです。これは、このティアのサブネットワークに参加できるフィーチャを決定します。モデルに新しい資産タイプを追加する際は、それらを考慮するためにサブネットワーク定義を更新することが重要です。そうしないと、これらの新しい資産タイプを含むフィーチャを持つサブネットワークを更新するときにエラーが発生します。
また、Aggregated Lines for SubnetLine Feature Class パラメーターの更新も検討すべきです。これは、サブネットワークラインクラスを作成するときに考慮するジオメトリを決定します。デフォルトでは、ユーティリティネットワークビルダーは資産タイプを含めないため、サブネットワークを更新してもサブネットワークラインは生成されません。このパラメーターには、中電圧および高電圧の線を表す資産タイプのみを選択してください。このパラメーターにすべての資産タイプを選択すると、サブネットワークラインレイヤーの描画時間に大きな悪影響がありますので避けてください。
注意：サブネットワークラインに含まれないフィーチャもネットワークの集計統計には含まれるため、導体長さを計算したい場合はトレース構成で集計関数を使用することを検討してください。これにより、中電圧および低電圧導体の長さを別々に計算するためのフィルターを定義できるという追加の利点があります。
サブネットワークポリシーの更新
サブネットワーク定義の最後の主要なセクションは、サブネットワークポリシーの更新です。これはユーティリティネットワーク内でサブネットワーク情報がどのように更新されるかを制御します。これらの設定変更は、多くのお客様にとって簡単な決定ではなく、利便性とパフォーマンスのトレードオフが伴います。ここではこれらの決定ポイントについて簡単に概要を説明し、利用可能な詳細な議論への参照も提供します。
最初で最も簡単なポイントは、構造体／ドメインネットワークコンテナを更新するかどうかです。サブネットワークトレース構成に構造体／コンテナが含まれている場合、それらを更新するかどうかのオプションが表示されます。これは、サブネットワークに属するフィーチャが含まれるかサポートしている場合に、構造体およびコンテナ上のサブネットワーク名や対応するフィールドが更新されるかどうかを決定します。これにより、トレースを実行せずに属性による選択ツールでサポートしているフィーチャを特定できます。この機能は報告目的には便利ですが、多数（数十万）の追加フィーチャが更新対象となるため、update subnetwork の実行時間が長くなることも意味します。
次に議論すべきオプションは、そのティアが IsDirty フィールドを管理するかどうかです。こちらで 状態管理について詳しく解説しています（Esri Community サイト）。このフィールドは、ユーティリティネットワーク内で検証された編集が特定のサブネットワークに影響したかどうかを示すために使用されます。このオプションはパフォーマンスへの影響があるため、ユーティリティネットワークビルダーでは false に設定されています。
このプロパティが有効になっている場合、編集を検証するたびにユーティリティネットワークは影響を受けたサブネットワークを特定するために1回以上のトレースを実行しなければなりません。ほとんどの電気回路は数千フィーチャしか含まないため、このコストは品質保証への利点と比較して通常は比較的小さいです。しかし、もしあなたのサブネットワークが数万または数十万ものフィーチャを含む場合、このプロパティは無効のままにしておくことを検討してください。
このプロパティが有効だと、変更されたサブネットワークだけに品質保証作業を集中でき、どの回路がクリーンでOMSなど外部システムへ抽出準備ができているか簡単に特定できます。
最もパフォーマンスが良い設定は、このオプションを無効にしたままにすることです。一方で品質保証や統合には状態管理（state management）を有効化する設定が最も有益です。
最後に検討すべきオプションは、デフォルトおよび名前付きバージョンで使用するイベントモードです。これは update subnetwork のパフォーマンスや特定のワークフロー中にサブネットワークフィールドが入力されるかどうかに影響します。こちらで イベントモードについて詳しく解説しています（Esri Community サイト）。以下はその議論の非常に簡略化したバージョンです。
イベントなしでサブネットワークが更新されると処理速度が速くなります。その理由はいくつかありますが、一つには属性ルールやエディタートラッキングがトリガーされないことがあります。この動作の最大の欠点は、名前付きバージョンで update subnetwork を実行した際に、すべてのフィーチャで所属するサブネットワーク名が正しく更新される保証がないことです。
イベントありでサブネットワークが更新されると、最初の update subnetwork 操作にはより長い時間がかかります。また、大量のフィーチャを属性ルール付きで更新している場合、その後の更新も時間がかかることがあります。しかしイベントありで更新すると、バージョン内で update subnetwork を実行した際、そのサブネットワーク名フィーチャが正しくすべての所属フィーチャに入力されていることが保証されます。
注意：ArcGIS Enterprise 11.4 および ArcGIS Pro 3.4 では、新しい Triggering Fields 属性ルール機能によって属性ルール起動時のパフォーマンスコストが軽減できます。
最もパフォーマンス重視の場合はイベントなしモードで更新し続ける設定です。一方品質保証には名前付きバージョンではイベントモード有効化し、すべての属性ルールで適切な triggering fields を設定しておく構成が最も有用です。
結論
この記事をご覧いただいたことで、電気ネットワーク分析用トレースおよびネットワーク属性設定方法の基本をご理解いただけました。また上流・下流・隔離トレース可能なサブネットワーク作成方法や、それら活用によるサブネットワーク定義調整方法も学びました。さらに高度な設定について学ぶ準備ができたら、「electrical networks advanced configuration」記事をご覧ください。
ユーティリティネットワークによる電気ネットワーク管理についてさらに知りたい場合は、ぜひ Learn ArcGIS Utility Network for Electric Utilities シリーズをご覧ください。この学習シリーズにはユーティリティネットワークで電力業界ニーズへ対応するチュートリアルや記事が含まれています。
Migration toolset と Migrate to Utility Network ツールについてはこちらの記事からダウンロードおよび詳細をご確認ください：Get started with the Migration toolset 記事。また、ご質問やコメントはいつでも Esri Community site に投稿してください！
