Auteur : Katrien Verbeek
L'ArcGIS Utility Network (UN) est-il un standard adapté à la gestion moderne des réseaux ? Dans ce blog, nous examinons si le Utility Network peut répondre à la complexité actuelle du paysage énergétique.
Le UN est considéré comme le standard moderne pour la gestion des réseaux de services publics. La gestion d'un réseau électrique, gazier, télécom ou d'eau (usée) est complexe et requiert un haut degré de scalabilité, de tracing et de qualité des données. Plus la zone de desserte est grande, ou plus les types de services publics gérés sont nombreux, plus la migration vers le UN devient intéressante.
Le UN est entièrement service-based au sein d'ArcGIS Enterprise (petite remarque : il est désormais possible, par exemple à des fins de POC ou d'étude, de faire tourner un UN uniquement sur une geodatabase (gdb) en mode offline). Les REST feature services géreront toutes les actions qu'un utilisateur effectue sur le réseau : CRUD, tracing, validation, etc.
Un certain nombre d'exigences architecturales doivent être respectées :
Le service UN lui-même doit être publié en tant que branch versioned feature service. Celui-ci expose l'UN via REST à différents clients tels qu'ArcGIS Pro ou des web apps.
Figure 1 : Composants logiciels d'un Utility Network
Les utility network rules mentionnées ci-dessus définissent, via une whitelisting, quels assets au sein du réseau peuvent être connectés ou associés entre eux. Celles-ci sont définies au niveau des asset groups et asset types. Le paragraphe sur les Associations approfondira ce point.
Il existe également des attribute rules, réparties en trois types :
Validation Rules. Celles-ci sont appliquées à un stade ultérieur du processus afin de ne pas gêner l'utilisateur lors de la saisie. L'exécution des rules implique en effet un certain impact sur les performances. Elles peuvent par exemple être utilisées pour vérifier l'absence d'erreurs de dessin, comme un luminaire trop éloigné d'un poteau.
Domain et structure réseau
Un utility network contient toujours un ou plusieurs domain networks, généralement un par discipline. Ceux-ci comprennent les assets qui transportent effectivement la discipline ou sur lesquels celle-ci est manipulée, comme un câble électrique, un luminaire ou un robinet de gaz. Ces éléments sont souvent accrochés à ou contenus dans un support physique. C'est le structure network de poteaux, de gaines et de bâtiments.
Lorsqu'une organisation gère plusieurs disciplines, la question doit être posée de créer un structure network par domain network, ou de regrouper tous les structure assets dans un seul structure network commun à tous les domaines. Cette dernière option correspond généralement mieux à la pratique et est aussi techniquement la plus allégée, car elle évite de créer des données redondantes. Cependant, elle pose de (petits) défis en matière de visualisation cartographique, car la demande est généralement de pouvoir visualiser par utility, idéalement avec la possibilité de basculer au sein de la même carte. L'objectif est alors de ne pas afficher les structure assets dans lesquels ou auxquels aucun asset de le utility concernée ne se trouve. La flexibilité et l'extensibilité du utility datamodel révèlent ici l'une de ses forces.
Figure 2 : Base du modèle de données Utility Network
Outre la connectivité géométrique physique, il est également possible de construire une connectivité via des associations. Plusieurs types peuvent être distingués :
Les attachment et containment associations sont également consultables de manière intuitive, ce qui constitue aussi un grand atout. L'attribute pane lors d'une sélection montre quelles features sont contenues dans la feature sélectionnée, et à quelle containment cette feature sélectionnée appartient à son tour.
Figure 3 : Exemple d'associations visibles via l'associations view & l'attributes pane
Une autre condition importante pour pouvoir établir des associations entre deux features dans le réseau est que l'association entre ces deux asset types soit autorisée via les Utility Network Rules.
Figure 4 : Relations de containment via le Network Properties pane de la couche Utility Network
Cela implique également que, pour modifier ces association rules (principalement les supprimer), il faut vérifier si celles-ci étaient déjà utilisées ou non dans le réseau, ce qui est logique. Mais un piège (ou plutôt un bug) ici est que si l'on utilise des preset templates dans lesquels l'association à supprimer est intégrée, celle-ci devient corrompue. Dans ArcGIS Pro 3.5.6 avec UN v.7, il n'est pas possible de consulter ou de modifier (via l'interface client) les associations dans les templates. L'espoir est que cela sera encore résolu.
Lorsque des actions CRUD sont effectuées sur le réseau, cela a une influence sur la connectivité et la topologie. Celles-ci donnent lieu à l'introduction de dirty areas. Celles-ci peuvent grosso modo être divisées en dirty area ordinaire ou en erreur. Dirty signifie alors que le réseau a été touché à cet endroit et doit simplement être revalidé, tandis qu'une error area signifie que des erreurs ont effectivement été commises contre les network rules ou les attribute rules, et que celles-ci doivent être résolues avant que le réseau puisse être revalidé.
Le Utility Network a, au fil des années, évolué en un système GIS à part entière pour gérer les assets faisant partie d'un réseau de services publics. Il reste bien sûr encore des améliorations possibles, mais la technologie est, avec la v.7, suffisamment mature pour être implémentée. La version 7 est compatible avec ArcGIS Pro à partir de la version 3.3 et avec ArcGIS Enterprise à partir de la version 11.3. Ce blog a toutefois été rédigé à partir de l'expérience avec ArcGIS Pro 3.5 et Enterprise 11.5.