In che modo gli edifici possono condividere i dati in un distretto?

La risposta allettante è collegare ogni edificio a una piattaforma distrettuale e lasciargli leggere tutto ciò di cui ha bisogno. La migliore è un insieme di interfacce concordate, ciascuna contenente un insieme definito di informazioni con il proprio significato, qualità e regole di accesso intatti. Ogni edificio pubblica ciò che lo scopo condiviso richiede, il distretto lo consuma e l'edificio rimane libero di modificare i propri sistemi finché continua a onorare l'interfaccia.

Il punto di partenza è la decisione condivisa, ovvero ciò che il distretto ha effettivamente bisogno di sapere o fare. Solo allora qualcuno dovrebbe specificare le informazioni minime che ciascun edificio deve fornire per supportarlo.

Il contratto d'informazione

Il documento principale è un contratto informativo, talvolta chiamato specifica di condivisione dei dati, concordato tra il distretto e ciascun edificio. Si comincia con gli identificatori di siti, edifici, spazi, contatori e asset, in modo che la stessa cosa abbia ovunque lo stesso nome. Definisce quindi il significato di ciascun campo: cosa rappresenta il valore, in quale unità e in quale intervallo. Se sbagli, i confronti saranno fuorvianti senza preavviso; il totale del distretto diventa privo di significato se un edificio riporta la potenza istantanea e un altro riporta l'energia accumulata in un'ora sotto lo stesso nome di campo.

Il contratto deve inoltre indicare la data e l'ora e il fuso orario e se i valori sono misurati, stimati o calcolati. Dovrebbe contenere indicatori di qualità che distinguano i valori buoni, sospetti, stimati e mancanti e stabiliscano la frequenza di aggiornamento e la latenza su cui il distretto può fare affidamento. Infine, fissa le regole di accesso, ovvero chi può leggere ciascun set di dati e per quale scopo, e il controllo delle modifiche: come ciascuna parte propone una modifica e quanto preavviso viene dato.

Modelli tecnici

Qualunque sia il modello scelto, l'interfaccia dovrebbe essere formalmente documentata. La specifica OpenAPI, gestita dall'iniziativa OpenAPI, è un modo ampiamente utilizzato per descrivere le API HTTP in formato leggibile dalla macchina; la linea 3.2 è stata introdotta nel settembre 2025 e la sua ultima patch, 3.2.1, è seguita nel settembre 2026, mentre le precedenti linee 3.1 e 3.0 rimangono pubblicate e in uso.

Concordare sul significato

I nomi dei campi condivisi sono un inizio, ma i distretti più grandi beneficiano di un modello semantico condiviso. SAREF (Smart Applications REference ontology) di ETSI è progettato come un modello centrale condiviso che consente a diversi modelli di dati di relazionarsi tra loro senza una mappatura dedicata per ogni coppia, e SAREF4CITY lo estende al dominio delle città intelligenti. Negli ecosistemi di dati delle città, i meccanismi minimi di interoperabilità (MIM) della rete Open & Agile Smart Cities stabiliscono un livello minimo e sufficiente di interoperabilità, inclusa la messa a disposizione dei dati tramite API e la loro rappresentazione in formati basati su standard; indica NGSI-LD come uno standard moderno per condividere informazioni su entità del mondo reale in modo comune e coerente.

Nessuno di questi garantisce di per sé l’interoperabilità. Le parti devono ancora concordare quale versione e quale sottoinsieme utilizzeranno e come verrà verificata la conformità.

Mantenere gli edifici autonomi

L'accesso al distretto non deve mai diventare una dipendenza dai controlli propri di un edificio. La maggior parte degli scambi dovrebbe essere di sola lettura. Laddove il distretto può avanzare richieste che modificano il funzionamento, come chiedere una riduzione della domanda, l’accordo deve definire chi le autorizza, i limiti fissati da ciascun edificio, come un edificio rifiuta o forza (override) una richiesta e cosa succede se il collegamento viene perso.

I dati mancanti richiedono la stessa attenzione. Un edificio che interrompe temporaneamente la segnalazione dovrebbe apparire come non disponibile o obsoleto. Non deve mai contribuire silenziosamente con un vecchio valore al totale del distretto attuale.

Mettere la relazione per iscritto

Il contratto informativo descrive i dati. Le parti necessitano anche di un accordo sul rapporto, soprattutto nel caso in cui gli edifici abbiano proprietari diversi. Dovrebbe indicare per cosa possono essere utilizzati i dati condivisi e che qualsiasi nuovo utilizzo necessita di un nuovo accordo. Dovrebbe indicare chi gestisce la piattaforma distrettuale, chi è responsabile dell'feed di ciascun edificio e chi ogni partito chiama quando qualcosa si rompe.

I dati personali e commercialmente sensibili necessitano di particolare attenzione. I consumi per una piccola locazione, o gli eventi di accesso, possono riguardare persone identificabili o rivelare l'attività di un'impresa. La prima domanda è se tali dati siano davvero necessari; ove lo scopo lo consenta, dovrebbero essere aggregati e, laddove rimangano dati personali, i consulenti per la privacy dovrebbero confermare i ruoli e gli obblighi di ciascuna parte.

L’accordo deve anche regolare i costi e l’affidabilità: chi paga per la connessione lato edificio, la piattaforma e le successive modifiche, quali utilizzi dipendono dalla correttezza dei dati (riaddebito, ad esempio), e quale livello di servizio e rimedio applicare quando non lo sono. Dovrebbe spiegare come si unisce un nuovo edificio, cosa succede alla storia di un edificio quando viene venduto o ritirato, quanto spesso viene rivisto l'accordo e come vengono risolti i disaccordi.

In una proprietà gestita privatamente questi termini possono figurare in contratti di gestione o locazione di proprietà; in un campus pubblico, in un contratto di servizio interno. In ogni caso, i consulenti legali redigono il documento. Il compito del team tecnico è assicurarsi che venga descritto ciò che effettivamente faranno i sistemi.

Un ordine di lavoro sensato

Il lavoro inizia con una decisione condivisa e un nome del proprietario, seguita da un elenco onesto di ciò che ciascun edificio può fornire oggi e con quale qualità. La versione 1 del contratto informativo copre solo il set minimo di dati e il modello tecnico è quello che l'edificio partecipante meno maturo può supportare. Un pilota con due o tre edifici, includendo deliberatamente i più deboli, arriva prima che gli altri si uniscano nelle ondate pianificate.

I test dovrebbero essere eseguiti dall’inizio alla fine, con dati rappresentativi provenienti da diversi edifici. È necessario dimostrare che:

• i valori, comprese le relative unità e intervalli, sono interpretati correttamente;
• le autorizzazioni limitano ciascuna parte a ciò che ha diritto di vedere;
• i dati non aggiornati e mancanti vengono contrassegnati;
• il quartiere si ripristina correttamente dopo che un edificio o il collegamento sono stati offline;
• una modifica all'interfaccia segue il processo concordato.