Introduzione
La rete elettrica della città di Bienne, come ogni rete, richiede una gestione attenta dei suoi componenti. Questo presuppone l’intervento di numerosi attori specializzati in campi diversi. Per poter svolgere i loro compiti quotidiani in modo efficiente, i collaboratori di Energie Service Bienne devono disporre di una documentazione completa, precisa e aggiornata.
Il piano dell’opera, con il suo alto livello di dettaglio, è il principale strumento di lavoro per definire la posizione degli oggetti. Tuttavia, i collaboratori devono anche avere a disposizione una rappresentazione schematica che rispecchi la logica della rete. Tale schema dovrebbe mostrare l’interconnessione tra i componenti e fornire una prospettiva su cui siano indicati i cavi non sovrapposti e rappresentati da un unico tracciato di percorso. Inoltre, lo schema deve consentire di intervenire in modo rapido ed efficiente in caso di guasto o quando si tratta di pianificare la sostituzione di alcuni cavi o addirittura di dimensionare una nuova sezione della rete.
Problematica da risolvere
Bisogna sostituire la rappresentazione schematica attuale della bassa tensione della rete elettrica. La densità di informazioni è troppo grande, soprattutto nel centro urbano. È quindi necessario trovare un’alternativa a questa rappresentazione visiva, riducendo al minimo i tempi di gestione imputabili al prodotto futuro.
Obiettivi
- Fornire uno strumento di visualizzazione con un accesso semplice ed efficiente ai dati
- Generare una rappresentazione schematica che consenta una rapida comprensione della logica e dei collegamenti della rete elettrica
- Utilizzare il database a grafo Neo4j
- Integrare le capacità di simulazione della libreria JavaScript D3 per evitare sovrapposizioni di cavi
Realizzazione
Studio dei database a grafi
L’utilizzo di Neo4j offre vari vantaggi. Grazie alla gestione dei nodi e delle interconnessioni, questo database a grafo permette l’integrazione ottimale delle topologie lineari delle nostre reti sotterranee. La modellazione fisica delle relazioni permette di ignorare i meccanismi di articolazione durante interrogazioni complesse.
In aggiunta, la fase di modellazione è flessibile e semplificata dalla sua somiglianza con il mondo reale e il linguaggio utilizzato. Lo schema del database può essere facilmente adattato anche dopo l’implementazione della struttura e l’inserimento dei dati.
Transfer di dati dal RDBMS al GDBMS
L’importazione dei dati in Neo4j avviene di norma attraverso un file CSV. Questo è il modo più semplice per ottenere rapidamente un database operativo. Per ridurre a un minimo la procedura di consolidamento dei dati è stato necessario effettuare due operazioni direttamente nel database relazionale. La prima operazione consisteva nell’approntare una funzione che recupera tutti gli attributi necessari in modo interattivo, mentre la seconda ha riguardato l’allestimento di due prospettive che utilizzano questa funzione e i cui risultati forniscono le risorse per l’elaborazione in FME. Nell’area di lavoro di FME in entrata si trovano le due prospettive e la tabella che modella le relazioni esplicite della rete di cavi di alimentazione. L’idea è quella di creare due canali di elaborazione: il primo scrive i dati delle diverse fonti nel formato CSV, mentre il secondo prepara i metadati e integra anche la sintassi corrispondente ai comandi di importazione.
Modellizzazione dei dati in Neo4j
Nel mondo dei database relazionali non è consuetudine creare giunzioni multiple tra due tabelle o su entità a diversi livelli. Questa consuetudine è invece data nel mondo dei database a grafo. Dopo l’importazione dei nodi e la modellazione delle relazioni iniziali, al modello sono stati aggiunti altri legami complementari per facilitare l’interrogazione e la messa a disposizione dei dati.
Da questo punto in poi, lo sviluppo del modello in Neo4j è stato effettuato in parallelo con l’implementazione e la configurazione dell’interfaccia di visualizzazione.
Questi passi hanno rappresentato due grandi sfide: da una parte, si sono dovuti scegliere gli attributi che sarebbero stati utilizzati per informare la funzione di ricerca. D’altra è stato necessario definire l’interrogazione che avrebbe consentito di formattare il risultato e renderlo direttamente utilizzabile dalla libreria di visualizzazione.
Scelta della libreria di visualizzazione
Sebbene Neo4j integri uno strumento di visualizzazione che può essere usato in un browser web, il suo uso è limitato alle persone che hanno le conoscenze adeguate per gestire l’interfaccia e generare una query con il linguaggio Cypher (SQL del GDBMS). Fortunatamente, esistono alternative efficaci per l’implementazione in un’azienda e soprattutto con applicazioni più accessibili ai diversi gruppi di utenti.
Per questo progetto ho scelto un’architettura applicativa che utilizza la libreria JavaScript D3. Questo integra il modulo d3-force che offre una grande flessibilità in termini di configurazioni sia visive che comportamentali.
Attuazione della visualizzazione e integrazione delle funzioni di libreria «D3»
Dopo l’implementazione dell’architettura dell’applicazione, da parte del cliente si sono resi necessari vari adattamenti sia del codice JavaScript che del server nell’API. Queste modifiche hanno permesso di recuperare il set di dati precedentemente formattato in JSON per generare i nodi e le relazioni con la libreria D3.
Lo scopo del modulo d3-force è quello di generare una simulazione con i nodi e le loro relazioni integrando parametri comportamentali come l’attrazione, la repulsione, la velocità o la gestione delle collisioni. L’adeguamento di questi parametri ha poi permesso di influenzare il comportamento dei nodi e quindi di “districare” gli elementi della rete inizialmente sovrapposti.
Visualizzazione generata
La visualizzazione permette all’utente di effettuare una ricerca singola o multipla dell’infrastruttura, integra la gestione della posizione del nodo e offre un pulsante per l’esportazione dei dati in formato JSON. La simulazione fornisce un primo rendering essenziale con il supporto della mappa posta in background e assiste successivamente l’utente nella scelta del posizionamento degli oggetti.
Il prodotto attuale non comprende tutti i punti della rete. I collegamenti tra i manicotti e le connessioni degli edifici e quelli dei cavi collegati direttamente agli alimentatori nelle infrastrutture non sono ancora stati integrati. Questi nodi e queste relazioni devono essere aggiunti all’ambiente visivo e costituiranno la prossima fase di sviluppo.
Ecco uno spaccato dell’attuale interfaccia web:
Prospettive e conclusione
Il database a grafo integra perfettamente le topologie lineari dei nostri consueti RDBMS e il suo utilizzo apre le porte a nuove applicazioni aziendali. D’altra parte, l’interfaccia web sviluppata permette di soddisfare le esigenze inerenti alla generazione di un nuovo piano schematico. Tuttavia, ulteriori test hanno dimostrato che la tecnologia SVG utilizzata per generare il rendering degli elementi raggiunge i suoi limiti in termini di prestazioni quando si tratta di simulare e rappresentare un gran numero di nodi. Attualmente si sta esplorando una nuova pista. Si tratta di una libreria che include le funzionalità già presenti in d3-force. In questo caso la visualizzazione è basata sulla tecnologia WebGL. Quest’approccio consente di sfruttare l’accelerazione hardware del processore grafico a livello di terminale e quindi di aumentare notevolmente le capacità di calcolo durante l’esecuzione della simulazione.
Patrick Vogt
Tecnico in geomatica con brevetto federale
Funzione presso la ESB: responsabile documentazione delle reti
Energie Service Biel/Bienne
Rue de Gottstatt 4
Casella postale
2501 Bienne
Telefono 032 321 12 61
patrick.vogt@esb.ch