ユーティリティネットワークが初めてリリースされたとき、Esriのエコシステムと用語に新しい概念であるSubnetworkが導入されました。この抽象化は、ユーザーが業界特有の用語である「回路」や「圧力ゾーン」を使わずに、ネットワークをネットワークゾーンに分割して管理するさまざまな方法を説明するために作成されました。
では、なぜ「subnetwork」という用語を使うのでしょうか？
ユーティリティのリソースの一連の接続性を管理するために使用されるすべてのデータはユーティリティネットワーク（例：ネットワーク）に格納されます。したがって、このネットワークがより小さくトポロジー的に連続した領域（回路、圧力ゾーンなど）に細分化されると、それぞれのゾーンは正確にサブネットワークとして記述できます。この抽象化により、各サブネットワークを独自のGISオブジェクトとして管理し、可視化、分析、さらにはレポート作成にも利用できるフレームワークが作られました。このフレームワークの重要な要素は、各サブネットワークのメタデータを追跡し、ユーザーがシステムの変化を時間経過で理解できるようにする機能です。
このメタデータは編集者追跡フィールドなどの基本情報を提供するほか、顧客数や保護装置数などユーザー定義の値を組み込むことも可能です。メタデータはまた、GIS担当者が最もよく尋ねられる重要な質問、「このデータは正しいか？」に答える手助けもします。
これは意外と難しい質問です。なぜなら「正しい」の意味は人によって異なるからです。しかし、この元の質問をより具体的な質問に分解すると答えやすくなります：
- サブネットワークは最後にいつ更新されましたか？
- サブネットワークは最後にいつ他のシステムへ抽出されましたか？
- このサブネットワークは最新ですか？
- サブネットワーク内のフィーチャは最後の更新以降変更されていますか？
- このサブネットワークには修正が必要な既知のエラーがありますか？
最初の2つの質問は、サブネットワーク上で管理されているいくつかの日付フィールド（Last Update SubnetworkおよびLast Ack Export Subnetworkフィールド）によって簡単に答えられます。残り3つの質問はすべて、サブネットワークのStatusフィールド（以前のモデルでは「Is Dirty」フィールドと呼ばれていました）を見ることで答えられます。このフィールドにはClean、Dirty、およびInvalidというステータス値が含まれています。これらの値は次の意味を持ちます：
- Clean – 既知のエラーがなく分析に使用できるサブネットワーク。
- Dirty – 変更されており更新が必要なサブネットワーク。
- Invalid – 解決すべき既知のエラーが1つ以上あるサブネットワーク。
基礎が整ったので、この記事の残りではシステムがStatusフィールドをどのように管理し、それぞれ異なるステータス値をどのように解釈するかに焦点を当てます。
サブネットワークをDirtyとしてマークする方法
ユーティリティネットワークでサブネットワークのステータスを管理する鍵は、編集によってどのサブネットワークが影響を受けたかをシステムが判断し、それをDirtyとしてマークできることです。これを実現する方法はいくつもありますが、現在ソフトウェアはvalidate network topology操作を使って影響を受けたサブネットワークを検出しDirtyとしてマークしています。編集ごとにどのサブネットワークが影響を受けたか判定するにはトレースが必要であり、この解析を毎回行うと編集処理に大きな負荷がかかります。さらに、ネットワークに影響するすべての編集作業フローは検証されなければならないため、この仕組みにより編集中でもサブネットワーク状態とデータとの同期ズレが起こらないよう保証しています。
ではシステムはどのようにして変更されたサブネットワークを特定しているのでしょうか？
システムは検証済みフィーチャすべてについてサブネットワークコントローラートレースを実行し、編集によって影響を受けたサブネットワークを発見します。この動作は検証された編集内容がpartitioned型ユーティリティネットワークなのかそれともhierarchical型ユーティリティネットワークなのかによって若干異なります。これら用語の意味と重要性について以下で説明します。
partitioned型サブネットワークでは各フィーチャは最大1つだけサブネットワークに属します。つまりシステムは各階層（tier）ごとに編集されたフィーチャがその階層内どのサブネットワークに属するか調べます。一度特定されたフィーチャは後続階層で解析対象から除外され、すべて特定されれば全階層解析前でも処理完了となります。以下はpartitioned型ネットワークのおおまかな例です：
hierarchical型の場合、各フィーチャはいくつもの階層（tier）内複数サブネットワークに属し得ます。そのためシステムは編集されたすべてのフィーチャについて全階層解析しなければなりません。以下はhierarchical型簡易例です：
異なるトポロジータイプについて概要説明したので、それぞれについていくつか編集シナリオを見てシステム挙動について注目します。
Partitioned型の場合
partitioned型ではトポロジー検証時に編集によって影響した各サブネットワーク特定が必要です。そのためまずサブネットワークを持つすべて階層（tier）を特定し、それぞれについて編集されたフィーチャが属するサブネットワーク有無調査します。この処理を繰り返し行いすべて編集フィーチャについて所属元ソース特定または全階層解析完了まで続けます。以下はいくつか具体例です。
最初の例ではユーティリティネットワーク上で単一編集（紫色ハッシュポリゴン）が行われました。validate network topology実行時、この編集について最初に解析した配電階層で単一ソースが見つかったため送電階層解析は省略されました。これはすでにすべて編集内容カバーするコントローラー発見済みだからです。
2番目例では複数箇所で複数編集された場合です。この場合複数階層で編集発生しているためすべてソース発見まで複数回トレース実行しています。
3番目例ではどのサブネットにも接続していないフィーチャへの編集です。この場合影響なし確認するため全階層トレースしています。
ご覧いただいた通りvalidate network topology操作はpartitioned型で単一階層内限定編集や小規模サブネット変更時には変更箇所特定高速化できます。一方階層数増加や大規模サブネットになるほどトレース回数増え処理時間長くなります。
Hierarchical型の場合
hierarchical型では各フィーチャが複数階層所属可能なのでvalidate network topology時にはすべて階層考慮して影響受けたサブネット特定します。
以下は単一システムサブネット内に2つ小規模サブネット含む簡易hierarchical型例です：
最初例では小規模サブネット所属フィーチャ編集しました。まず該当小規模サブネット特定します。しかしhierarchical型なので残り全階層も解析し別階層内第2サブネットもDirtyマークしました。
2番目例では大規模のみ所属フィーチャ編集しました。この場合下位小規模群には影響ないためDirtyマークされません。この論理はsource-basedでもsink-basedでも同様で最高位階層のみ常に最外殻コンテナ（最終ソースまたは最終シンク）だからです。
3番目例ではどこにも属さないフィーチャ編集しました。この場合Dirtyマークなしですが該当なし確認するため全階層トレースしています。
システム系統網（system subnetworks）は非常に大きいためvalidate network topology処理負荷増加要因になります。また多く機能含むためDirtyマーク頻度高く、多くの場合1日に何度も更新必要になります。そのためhierarchical型最高位階層ではStatus管理せず夜間一括更新設定も一般的です。この設定によって更新頻度減少だけでなくvalidate network topology性能向上も期待できます。本記事次節ではStatus管理設定確認方法について説明します。
設定方法について
Statusフィールド管理はユーティリティネットワーク内で標準動作ですが、一部ユーザーや業界ではsubnetwork status管理不要な場合があります。そのため Set Subnetwork Definition tool のUpdate Subnetwork Policyセクションには対応tierで‘Manage IsDirty’設定オプションがあります。
この動作（状態管理の無効化）を選択しないユーザーは、通常、次の2つの理由のいずれかによります：
- 編集ワークフローの結果、サブネットワークが常にダーティになる場合、または...
- パフォーマンスへの影響
この設定はネットワーク内の各階層ごとに個別に構成されることを覚えておいてください。そのため、一部の階層（配電、圧力ゾーンなど）ではこの設定を有効にしたままにし、他の大きな階層（送電、システムなど）では無効にすることも可能です。
現在のネットワーク構成に関係なく、この設定は後でいつでも変更できます。モデルでこの設定が有効になっている場合、ステータスフィールドの管理が不要だと感じたらこのオプションを無効にできます。逆に、ステータスフィールドを管理していないモデルでも、後でワークフローでステータスフィールドを活用したいと判断した場合は、有効にできます。
整合性を検証
ここまでの議論では、ダーティ領域が検証される際にどのように、いつ、どのサブネットワークがダーティとしてマークされるかについて説明しました。ここで疑問となるのは、未検証の編集を含むサブネットワークをシステムがどのように認識または対応するかという点です。これが解析中に整合性を検証するという考え方が重要になる理由です。
ユーティリティネットワークでトレースを実行するときのデフォルト動作は、トレース結果の整合性を検証することです。実際には、システムがトレース結果に関連付けられたダーティ領域があるかどうかをチェックします。関連するダーティ領域がなければ、その結果は整合的と見なされます。
しかし、トレース結果に関連付けられたダーティ領域がある場合、トレースは失敗し、一つ以上のダーティ領域がトレース中に発見されたことを知らせるエラーが表示されます。もしダーティ領域を無視してトレース結果を見たい場合（誤った結果になる可能性があります）、整合性を検証するオプションのチェックを外すことができます。
これはサブネットワークのステータスにどのように適用されるのでしょうか？更新サブネットワーク中にダーティ領域が見つかると、そのサブネットワークはダーティとしてマークされます。しかしクリーンなサブネットワークは、一貫している場合もあれば、一貫していない場合もあります。それは最後に更新されて以来未検証の編集があるかどうかによります。データベース内に未検証のダーティ領域がある場合、編集が検証されるまでシステムはどのサブネットワーク（もしあれば）をダーティとしてマークすべきかわかりません。すべてのダーティ領域が検証されると、それに対応するサブネットワークがダーティとしてマークされ、すべてのトレースは整合的になります。
これがサブネットワーク管理に与える影響は何でしょうか？それはサブネットワークのステータスだけでは一貫性があるかどうかわからないということです。しかし、一貫していないサブネットワークを解析またはエクスポートしようとすると、そのサブネットワークがクリーンであってもエラーになるため、トレース時には確実にエラー通知を受け取れます。
結論
この記事を読み終えたことで、サブネットワーク管理に関連する利点やワークフロー、およびステータスフィールドがそれらのワークフローをどのように導くかについて理解が深まったことでしょう。また、このフィールドをシステムがどのように管理し、なぜ特定の業界ではユーティリティネットワーク内の一部階層のみでステータスフィールドを管理する選択をする場合があるかについても理解できたはずです。
