XML o JSON: in che formato arrivano i dati alla vostra supervisione di sito?

Il capitolato è firmato, la supervisione funziona, gli allarmi arrivano in sala. Poi un apparato va sostituito e quello nuovo espone i dati in un altro formato — restando conforme alla stessa serie di norme del vecchio. Da quel momento la domanda non è tecnica. È chi paga il pezzo in mezzo.

Il 10 aprile 2025 la parte più a monte ha cambiato lingua

ETSI ES 202 336-1 V1.3.1, Generic Interface, è stata pubblicata il 10 aprile 2025. È la parte che tutte le altre richiamano in via normativa: non descrive un apparato, descrive come parla alla supervisione. Sul Work Programme è il work item RES/EE-02105, stato Publication al 10-04-2025, non armonizzata, sostenuto fra gli altri da Orange e Telecom Italia. L’edizione precedente era del luglio 2011. La gemella ITU è la Raccomandazione ITU-T L.1395 (07/25), in vigore dal 29 luglio 2025.

Il registro delle modifiche sta in una riga: «Added parameter definition and parameter accuracy. Delete references to XMLand give possibility to use different communication protocol» — il refuso è dell’originale. La scheda del work item dice perché: «protocols instead of outdated ones (e.g. xml -> RESTful HTTP-based/YAML/JSON payload (or NetConf/YANG) etc.)». Il metodo è in due stadi: «protocol-independent information modelling», poi «protocol-specific data modelling e.g. in YAML/JSON». Che cosa un apparato deve dire non cambia. Cambia la lingua in cui lo dice.

L’obbligo riguarda solo le interfacce nuove

Ecco perché da dentro un impianto in esercizio non si vede niente. Nel corpo normativo la prescrizione sul protocollo è una sola, e stretta: il TCP/IP «shall be used for new interfaces with REST mechanism to exchange formatted data at application layers through HTTP services and HTTP parameters» — per le interfacce nuove. Quello che gira già nessuno obbliga a toccarlo.

Per l’esistente la via d’uscita è indicata con un shall: «To keep the existing supervised power and cooling equipment without changing their output interfaces (i.e. old CU), adding a DGU that converts old CU protocols towards Ethernet XML.» — tenere gli apparati già supervisionati senza cambiarne le interfacce, aggiungendo un’unità che converte. Un traduttore in mezzo, da comprare, configurare, collaudare e mantenere. Il documento dice che si può fare, non a chi tocca pagarlo.

Il vecchio formato non è stato tolto dal testo

La clausola 10, che definisce la struttura dei dati e detta «some rules which shall be respected», è ancora scritta in XML: i tipi delle tabelle sono xs:string, xs:integer, xs:complexType, cioè quelli dell’XML Schema, e gli eventi funzionano così: «When an event happens on a site, a part of the full xml file, with the relevant information, is sent to the NMS, with an HTTP POST over TCP/IP.» L’annesso E si intitola ancora Overview of the XML format.

E c’è il dettaglio che conta di più: nella V1.3.1 nessun annesso è normativo. Sono informativi sia l’annesso A, sul meccanismo REST su HTTP, sia l’annesso G sull’API comune — «A secured RESTful HyperText Transfer Protocol (HTTP)-based communication is recommended». Il formato nuovo è raccomandato, non imposto; il vecchio è ancora nel corpo. Un fornitore può stare da una parte o dall’altra e dirsi conforme.

Due generazioni di formato sullo stesso sito

A diciassette mesi, il quadro si verifica aprendo i PDF uno per uno.

Le parti da 2 a 10 — dalla corrente continua all’inverter, passando per UPS e gruppo elettrogeno — portano tutte e nove un annesso normativo intitolato «Mandatory XML structure and elements». Nella parte 3 è l’annesso D: «Annex D standardizes XML coding structures for these data». Nessuna è stata ritirata o modificata: pubblicate come erano fra il 2009 e il 2014.

Le due parti riviste nel 2025 no: la parte 11, del 26 settembre 2025, non ha alcun annesso XML. La parte 12 (RES/EE-02106, Publication all’11 settembre 2025) lo scrive nel proprio registro: «removed accuracy and sensor description as moved to part 1, delete reference to XML», e dichiara le tabelle in «natural language». Stessa sorte per le accuratezze di misura: sono passate nella parte 1 — ±3 % fra il 25 % e il 100 % del carico massimo, ±5 % fra il 5 % e il 25 %, tensione ±1 %, temperatura ±1 °C — e chi le richiamava citando la parte 12 rimanda a un documento che non le contiene più.

Il risultato pratico: un gruppo di continuità conforme alla parte 3 ha una struttura XML obbligatoria; un apparato ICT conforme alla parte 12 non ha più nessun formato prescritto. Due forniture conformi, due lingue, stesso sito. Dove la topologia dell’UPS decide già che cosa arriva alla supervisione, ora decide anche in che forma.

Cosa scrivere in capitolato, cosa verificare in accettazione

La parte applicabile con versione e data, non la serie: ES 202 336-3 V1.1.1 dice qualcosa, conforme alla serie ES 202 336 non dice niente.

Il formato di scambio nominato: la struttura XML dell’annesso normativo di quella parte oppure payload JSON o YANG su HTTP, con lo schema dei campi consegnato insieme all’apparato. La clausola la chiede il documento stesso: «At a minimum, full details of the interface (data, protocol, format) shall be provided without any restriction.»

Chi paga la mediazione: se il fornitore cambia formato in corso di contratto, o se un apparato nuovo ne porta uno diverso, l’unità di conversione e la riconfigurazione della supervisione restano a suo carico. È la riga che quasi nessun capitolato ha, ed è quella che decide se la migrazione la pagate voi.

In accettazione non si legge la dichiarazione: si preleva un documento dati vero dall’apparato e si controlla che il formato sia quello contrattuale, che i campi obbligatori ci siano tutti e che la supervisione lo legga senza adattamenti fatti a mano. Vale anche per una voce che nella parte 11 obbligatoria non è: se l’avete chiesta, deve arrivare, e leggibile.

Quello che non sappiamo

Abbiamo letto per intero la ES 202 336-1 V1.3.1, 73 pagine, scaricata il 21 settembre 2026, e aperto gli annessi delle parti da 2 a 12; numero, titolo, versione, data e stato sono verificati sul Work Programme ETSI. Della gemella ITU-T L.1395 abbiamo verificato la scheda di catalogo, non il testo. Non sappiamo quando le parti da 2 a 10 verranno riviste: della parte 9 risulta una revisione in corso, a bozza iniziale al 12 giugno 2026. Non sappiamo quale formato consegni oggi un singolo prodotto: dipende dall’apparato e dal contratto, e non lo qualifichiamo per nessuno. Le norme IEC citate dal testo sono a pagamento — compresa la IEC 61557-12, che l’ETSI dichiara più accurata della propria prescrizione: non le abbiamo lette. Un ETSI Standard vincola se il contratto lo richiama: non abbiamo verificato se una disposizione italiana lo imponga negli appalti di rete.

I due assi, su un formato che può cambiare

Primo asse: nel capitolato che verifichiamo il formato di scambio smette di essere implicito — parte con versione, codifica nominata, schema consegnato, onere della mediazione assegnato — e in accettazione si preleva un documento dati vero e lo si fa leggere alla supervisione, con verbale e documentazione insieme all’impianto.

Secondo asse: un sito con due generazioni di formato è un sito in cui metà dei dati non si confronta con l’altra metà. Con CSIDIA, l’altra società del gruppo, letture, allarmi, eventi e registri dei vari apparati vengono normalizzati una volta sola e diventano una mappa unica del sito, dove un’AI legge le serie — il campo sparito dopo una sostituzione, l’allarme che il nuovo apparato chiama diversamente — e la squadra interviene prima che manchi il dato che serve. Gira on-premise o in cloud dedicato con data center in Italia, per una centrale di rete come per la sala dati di un’amministrazione.

Dal sopralluogo, senza costi, esce l’elenco degli apparati che alimentano la vostra supervisione: la parte a cui ciascuno è dichiarato conforme, in che formato consegna i dati, se lo schema dei campi esiste per iscritto e chi pagherebbe il traduttore. Parlatene con un tecnico: un formato non fa rumore quando cambia, lo fa la prima volta che serve un dato e non arriva.