Introduction
Le réseau électrique de la ville de Bienne, comme tout réseau, demande une gestion pointue de ses composants. Cette dernière nécessite l’intervention de nombreux acteurs spécialisés dans différents domaines. Pour effectuer leurs tâches quotidiennes de manière efficace, les collaborateurs chez Energie Service Bienne doivent avoir la possibilité de s’appuyer sur une documentation actuelle, complète et précise.
Le plan d’ouvrage, avec son niveau de détail élevé, constitue le principal outil de travail pour définir l’emplacement des objets. Cependant, les collaborateurs ont également besoin d’une représentation schématique qui exprime la logique du réseau. Celle-ci doit permettre de visualiser les relations entre les composants et offrir une vue où les câbles ne sont pas superposés et représentés par une ligne de tracé unique. De plus, elle doit permettre d’effectuer une intervention rapide et efficace en cas de panne, de planifier le remplacement de certains câbles ou encore de dimensionner une nouvelle section du réseau.
Problématique à résoudre
La représentation schématique actuelle de la basse tension du réseau électrique doit être remplacée. La densité d’informations y est trop élevée, spécialement dans le centre urbain. Il faut donc trouver une alternative à cette représentation visuelle tout en minimisant le temps de gestion qui devra être alloué au futur produit.
Objectifs
- Fournir un outil de visualisation avec un accès simple et efficace aux données
- Générer une représentation schématique permettant une compréhension rapide de la logique et connectique du réseau électrique
- Utiliser la base de données graphe Neo4j
- Intégrer les capacités de simulation de la librairie JavaScript D3 afin d’éviter les superpositions de câbles
Réalisation
Étude des bases de données graphes
L’utilisation de Neo4j offre différents avantages. Cette BD orientée graphe permet l’intégration optimale des topologies linéaires de nos réseaux souterrains grâce à sa gestion des nœuds et relations. La modélisation physique des relationspermet de faire abstraction des mécanismes de jointures lors des requêtes complexes.
De plus, l’étape de modélisation est flexible et simplifiée par son apparentement au monde réel ainsi qu’au langage utilisé. Même après l’implémentation de la structure et l’injection des données, il est facilement possible de faire évoluer le schéma de la base de données.
Transfert des données du SGBD-R vers le SGBD-G
L’import des données dans Neo4j se fait en principe par le biais d’un fichier CSV. C’est la manière la plus simple d’obtenir rapidement une BD opérationnelle. Dans le but de minimiser la procédure de consolidation des données, deux opérations ont dû être réalisées directement dans la base de données relationnelle. Tout d’abord une fonction récupérant tous les attributs nécessaires de manière itérative, puis deux vues utilisant cette fonction et dont les résultats fournissent les ressources pour le traitement dans FME. Dans l’espace de travail FME, on retrouve en entrée les deux vues ainsi que la table modélisant les relations explicites du réseau de câbles électriques. L’idée ici est de créer deux canaux de traitement. Le premier écrit les données des différentes sources au format CSV. Le second prépare les métadonnées et intègre également la syntaxe correspondant aux commandes d’import.
Modélisation des données dans Neo4j
Créer des jointures multiples entre deux tables ou sur des entités de différents niveaux n’est pas monnaie courante dans le monde des bases de données relationnelles. Il en est autrement dans celui des BD graphes. Après l’import des nœuds et la modélisation des relations initiales, d’autres liaisons complémentaires ont été ajoutées au modèle en vue de faciliter l’interrogation et la mise à disposition des données.
À partir de ce stade, le développement du modèle dans Neo4j a été réalisé parallèlement à la mise en place et à la configuration de l’interface de visualisation. Ces étapes ont constitué deux défis majeurs. D’une part il a fallu choisir les attributs qui seraient utilisés pour renseigner la fonction de recherche. D’autre part il a fallu définir la requête qui permettrait de formater le résultat et de le rendre directement exploitable par la librairie de visualisation.
Choix de la librairie de visualisation
Bien que Neo4j intègre un outil de visualisation exploitable dans un navigateur web, son utilisation est limitée aux personnes ayant des connaissances pour piloter l’interface et générer des requêtes avec le langage Cypher (SQL des SGBD-G). Heureusement il existe des alternatives efficaces pour un déploiement en entreprise et surtout avec des applications plus accessibles aux différents groupes d’utilisateurs.
Dans le cadre de ce projet, mon choix s’est orienté vers une architecture applicative qui sollicite la librairie JavaScript D3. Celle-ci intègre le module d3-force qui offre une grande flexibilité au niveau des configurations, tant visuelles que comportementales.
Mise en place de la visualisation et intégration des fonctions de la librairie « D3 »
Après le déploiement de l’architecture applicative, différentes adaptations ont été nécessaires côté client au niveau du code JavaScript et également côté serveur au niveau de l’API. Ces modifications ont notamment permis de récupérer le jeu de données formaté précédemment en JSON afin de générer les nœuds et relations avec la librairie D3.
Le module d3-force a pour but de générer une simulation avec les nœuds et leurs relations en y intégrant des paramètres comportementaux tels que l’attraction, la répulsion, la vélocité ou encore la gestion des collisions. L’ajustement de ces paramètres a ensuite permis d’influencer le comportement des nœuds et ainsi de « démêler » les éléments du réseau initialement superposés.
Visualisation produite
La visualisation permettant à l’utilisateur d’effectuer une recherche d’infrastructure, unique ou multiple, intègre une gestion de la position des nœuds et offre un bouton pour l’export des données au format JSON. La simulation fournit un premier rendu épuré avec l’appui de la carte placée en arrière-plan. Elle accompagne ensuite l’utilisateur dans le choix du placement des objets.
Le produit actuel ne comprend pas tous les points du réseau. Les liaisons entre manchons et raccordements de bâtiments ainsi que celles des câbles connectés directement aux départs dans les infrastructures ne sont pas encore intégrées. Ces nœuds et relations doivent être ajoutés à l’environnement visuel et constitueront la prochaine étape de développement.
Voici un aperçu de l’interface web actuelle:
Perspectives et conclusion
La base de données graphe intègre parfaitement les topologies linéaires de nos SGBD-R habituels et son utilisation ouvre la porte à de nouvelles applications métier. D’autre part, l’interface web développée permet de couvrir les besoins inhérents à la génération d’un nouveau plan schématique. Cependant, des tests complémentaires ont démontré que la technologie SVG utilisée pour générer le rendu des éléments atteint ses limites en termes de performances lorsqu’il s’agit de simuler et de représenter un grand nombre de nœuds. Une nouvelle piste est actuellement explorée. Il s’agit d’une librairie reprenant les fonctionnalités déjà présentes dans d3-force. Mais cette fois, la visualisation s’appuie sur la technologie WebGL. Celle-ci permet d’exploiter l’accélération matérielle du processeur graphique au niveau du terminal et donc d’augmenter considérablement les capacités de calcul lors de l’exécution de la simulation.
Patrick Vogt
Technicien en géomatique avec brevet fédéral
Fonction chez ESB : Responsable documentation réseaux
Energie Service Biel/Bienne
Rue de Gottstatt 4
Case postale
2501 Biel/Bienne
Téléphone 032 321 12 61
patrick.vogt@esb.ch