Quanto è precisa la mappa della rete? Dipende da che GPS l’ha fatta

Il pozzetto che il progetto colloca a quel punto, la squadra lo trova lì — o otto metri più in là, sotto l’asfalto rifatto l’anno scorso? E chi ha preso quella coordinata, con quale apparato, con quale errore dichiarato quel giorno? Sono domande che nella maggior parte delle reti non hanno una risposta scritta, perché la posizione di un elemento di rete non è un dato: è la somma di chi lo ha rilevato, con quale tecnica, e quanto tempo fa.

La raccomandazione, con la sigla giusta

La Raccomandazione ITU-T L.94 (01/2015), Use of global navigation satellite systems to create a referenced network map, approvata il 13 gennaio 2015 dallo Study Group 15, fissa le linee guida per creare, gestire e mantenere la mappa di una rete di telecomunicazioni con il posizionamento satellitare. Lo Scope, verbatim: «The purpose of this Recommendation is to provide general implementation guidelines regarding the creation, operation, and maintenance of the telecommunication network map by using global navigation satellite system (GNSS) and geo-referenced systems.» Dal 15 febbraio 2016 la sigla è cambiata: la scheda registra che «Former ITU-T L.94 renumbered as ITU-T L.262 on 2016-02-15 without further modification and without being republished» — stesso testo, sigla nuova, mai ripubblicata sotto il nuovo numero. Il PDF che si scarica oggi porta ancora, in filigrana, l’intestazione L.94.

Che cosa deve comparire sulla mappa

Il § 6.1 elenca, come contenuto informativo tipico, una serie di voci; fra queste, verbatim: «the cable routing and the type of infrastructure», «the length of each section», «the owner of each section», «the status of infrastructure use, for example empty or occupied duct», «the dimensions of the duct, cable, optical closure and optical cabinet». Il § 6.2 fissa gli elementi minimi da rappresentare: «central offices, poles, manholes, optical closures, optical cabinets, ducts and tunnels» — gli stessi manufatti di cui abbiamo scritto a proposito delle ispezioni delle camerette. Prese una per una sembrano ovvie. Prese insieme, sono l’elenco di ciò che raramente sta in un solo posto: la proprietà di un tratto condiviso è spesso un dato contrattuale, non tecnico, e vive in un archivio diverso da quello dell’as-built.

GNSS o differenziale: la differenza si sente in metri

Il punto debole di ogni mappa referenziata è la parola più usata e meno definita: GPS. La norma distingue. Il GNSS semplice, § 9: «a GNSS has a positioning accuracy of 5 to 10 metres, because there must be a relative line of sight between the GNSS antenna and at least four satellites» — e in area urbana, fra edifici e sovrappassi, il margine peggiora ancora. Il DGNSS, definito al § 3.2.1, corregge la posizione confrontandola con una stazione di riferimento nota: una tecnologia che fornisce una precisione migliore del GNSS tradizionale, «from 5-10 metres down to a few metres […] to about 10 cm in case of the best implementations». Il § 9 lo scrive come raccomandazione esplicita: «In order to have reliable positioning both in urban and in non-urban areas, with an error from 1 to 10 cm, it is recommended to use differential GNSS.» Fra un GNSS semplice e un DGNSS ci sono anche otto metri di differenza — la distanza fra trovare il pozzetto e scavare dove non c’è. Quale dei due sia stato usato per una data coordinata, quasi mai lo dice la mappa stessa.

Due viste, un solo dato

Il § 7 impone due rappresentazioni della stessa rete, non una: «Network maps should be visualized both in geographical information system (GIS) format for geographical view, and in a computer aided design (CAD) system, for schematic view.» La vista geografica dice dove; quella schematica dice come si connette. Le reti che ne hanno solo una — di solito il CAD, perché è quello del progetto — arrivano sul terreno senza la mappa che serve.

Chi porta il dato dal campo, e come

Il dispositivo di rilievo, § 8, non è un telefono qualunque: «should be a mobile handheld device, compliant with [ITU-T L.69]», un’altra raccomandazione sui requisiti del palmare da campo. Il § 11 descrive la procedura quando la mappa non esiste ancora: prima «The survey process», dove i dati raccolti sul campo «are recorded in field and loaded in real time to the database»; poi «The back office process», dove un operatore «should access the district database, validate collecting data and transfer data on the final project». Per l’interrato serve un terzo passaggio: «georadar with GNSS (or differential global navigation satellite system (DGNSS)) should be used», perché sotto il livello del suolo il ricevitore da solo non basta — lo stesso vuoto che lasciano i cavidotti mai rilevati dopo la posa. I tre flussi devono convergere nello stesso sistema di coordinate, «such as the international standard world geodetic system – 1984 (WGS-84)» — altrimenti il rilievo del georadar e quello del tecnico con il palmare raccontano due mappe leggermente diverse.

L’etichetta, il database, e lo stato che cambia

Il § 12 chiude il cerchio fra oggetto fisico e record digitale: nel database locale «it should be possible to associate in-field information directly to the network element, recorded with an ID tag applied to it, as described in [ITU-T L.64]» — l’etichetta fisica che lega il pozzetto sul terreno alla sua riga nel database, lo stesso principio dietro l’identificazione di un cavo per vibrazione. Nel database remoto si sceglie l’area e si filtra per strato: «you could see only the telecommunication copper network or only empty ducts.» Ma la posizione non basta: il § 10 chiede che la mappa mostri anche lo stato dell’elemento, «such as new, old or to be changed», e che «The status of the network elements should be upgraded when finishing a construction or repairing work». Il tempo di aggiornamento, aggiunge la norma, «should depend on the network element type» — senza fissarne uno. È la voce più facile da promettere in gara e più difficile da controllare in accettazione: una mappa aggiornata a marzo, dopo un intervento di giugno, non è sbagliata sulla carta. È solo vecchia.

Vedi il servizio · Parlane con un tecnico

L’appendice italiana

Un’appendice, dichiarata «Italian experience regarding geo-referencing system», descrive una piattaforma con rilievo da terminale mobile GNSS e sincronizzazione automatica: «Using the GNSS-enabled mobile terminal, it is possible to collect data of an asset and capture its GNSS position. Once the operation is completed, the device automatically sends the data to the cloud.»

Quello che non sappiamo

La conformità alle raccomandazioni ITU-T è volontaria: «Compliance with this Recommendation is voluntary.» L’appendice sull’esperienza italiana lo dichiara in apertura: «This appendix does not form an integral part of this Recommendation»; materiale illustrativo di una piattaforma non identificata per nome nel testo pubblico, non un requisito. Non sappiamo se quella piattaforma sia ancora in commercio dieci anni dopo, né se descriva una pratica oggi diffusa fra gli operatori italiani: la citiamo come precedente storico, non come prescrizione attuale. E non abbiamo trovato — non lo affermiamo né lo escludiamo, perché non verificato su fonte primaria italiana — un obbligo italiano che imponga il DGNSS per questo rilievo: chi lo vuole scritto e verificabile deve metterlo lui, nel capitolato, magari agganciandolo ai layer già previsti dal catasto SINFI.

I due assi, applicati

Primo asse: il metodo di rilievo — GNSS o differenziale, con quale margine dichiarato —, il sistema di coordinate, gli elementi minimi da rappresentare e il tempo massimo per aggiornare lo stato dopo un intervento diventano righe del capitolato, non una voce generica rilievo GPS. In accettazione si verifica che la precisione dichiarata sia quella richiesta, non quella di fabbrica del ricevitore usato quel giorno.

Secondo asse: il rilievo GNSS, il report georadar, il progetto CAD, il catasto GIS e l’etichetta fisica sul manufatto smettono di essere cinque archivi separati e diventano, con CSIDIA, l’altra società del gruppo, una mappa unica della rete su cui un’AI fa la diagnosi e la squadra chiude il guasto: perché la diagnosi utile — un pozzetto spostato, una tratta interrata diversa dal progetto, un tratto mai rilevato — nasce dal confronto fra misure successive riferite allo stesso identificativo, quello che il § 12 chiama ID tag. Nel perimetro del cliente: on-premise su macchine autonome senza integrazione profonda, oppure cloud dedicato con data center in Italia, sempre con gestione condivisa.

Dal sopralluogo, senza costi, esce l’elenco dei punti della vostra rete con rilievo GNSS — pozzetti, chiusini, muffole, cabinet — e per ciascuno: con quale tecnica è stato preso, quando, e con quale precisione dichiarata. Comprese le coordinate che, controllate, semplicemente non ci sono. Il punto sulla mappa che la squadra segue domani mattina: chi lo ha misurato, e con quale margine di errore?