Integrazione dei dati e ontologie
Cos’è un’ontologia edilizia?
Cos'è un'ontologia edilizia, le principali opzioni e perché un'ontologia da sola non crea interoperabilità.
Integrazione dei dati e ontologie
Specifica il Brick per ambito, versione, convalida e gestione, non solo per nome.

I sistemi di gestione degli edifici sono pieni di nomi di punti come "B2_AHU1_SAT". Un ingegnere di solito può indovinare cosa significa. Il software non può, e questa lacuna è ciò per cui Brick è stato costruito per colmare.
Brick è un'ontologia open source, ovvero un vocabolario di concetti e relazioni formalmente definito, per descrivere le attrezzature, gli spazi e i punti dati in un edificio e il modo in cui si relazionano tra loro. Consente al software di capire cosa rappresenta un punto dati e dove si trova nell'edificio, senza che una persona interpreti manualmente i nomi criptici.
Il vantaggio deriva dalla ripetizione. Quasi tutte le applicazioni di analisi, rilevamento guasti o energia necessitano dello stesso contesto: quale sensore appartiene a quale apparecchiatura e quale apparecchiatura serve quale spazio. Catturato una volta, in un formato standard, questo contesto consente alle applicazioni di essere riutilizzate in tutti gli edifici invece di essere riconfigurate per ciascuno di essi.
La documentazione di Brick descrive un modello di edificio come un grafo orientato ed etichettato, rappresentato con il modello di dati RDF del W3C, in cui i nodi sono entità e i bordi sono relazioni. Le entità possono essere fisiche, come un'unità di trattamento dell'aria, un contatore o una stanza; virtuali, come punti dati per la lettura di un sensore di temperatura o un comando di posizione della serranda; o logico, come una zona HVAC. Le classi danno alle entità il loro tipo e sono organizzate in una gerarchia, in modo che un sensore della temperatura dell'aria di mandata sia inteso come una sorta di sensore di temperatura.
Le relazioni collegano le entità e Brick le raggruppa per prospettiva: composizione (hasPart), topologia (feed, hasLocation) e telemetria (hasPoint, isPointOf). La documentazione descrive anche le relazioni di controllo, come controlli e isControlledBy, che documenta per la prossima versione 1.5; l'ultima versione elencata nella pagina delle risorse di Brick è la 1.4.4 (maggio 2025). Conferma su quale versione lavora un fornitore.
Un piccolo frammento, scritto in un linguaggio semplice:
| Soggetto | Relazione | Oggetto |
|---|---|---|
| AHU-1 | feed | VAV-2-04 |
| VAV-2-04 | feed | Zona HVAC 2-04 |
| Zona HVAC 2-04 | haParte | Sala 2.17 |
| VAV-2-04 | hasPoint | sensore di temperatura dell’aria in uscita dal terminale |
| AHU-1 | hasPoint | Sensore della temperatura dell'aria di mandata |
Da queste cinque affermazioni il software può rispondere "quali sensori mi dicono dell'aria immessa nell'ambiente 2.17?" senza conoscere la convenzione di denominazione di nessuno.
Brick prende in prestito l'idea dei tag da Project Haystack e dalla versione 1.4.0 (aprile 2024) il download di Brick contiene anche l'ontologia RealEstateCore nello stesso file.
La portabilità è l'ovvio vantaggio: una regola di analisi scritta rispetto alle classi e alle relazioni Brick può essere eseguita su qualsiasi edificio con un modello Brick corretto. Meno ovvio è il controllo. Il modello è un artefatto apertamente documentato che il proprietario può conservare, una registrazione del contesto indipendente dal fornitore che nessun software del singolo fornitore può bloccare. E quando Brick è il risultato finale specificato, diversi integratori lavorano per lo stesso obiettivo.
Un modello Brick non raccoglie dati, non ne garantisce la qualità né fa interagire automaticamente due prodotti. Descrive il contesto; le letture provengono ancora dal sistema di gestione dell'edificio (BMS) e dai contatori attraverso le proprie interfacce. Né l'applicazione delle etichette Brick a una manciata di punti rende complete le informazioni di un edificio.
Un modello Brick è una risorsa vivente e rimane utile solo con una certa disciplina. La prima decisione è la versione Brick, con una politica per aggiornarla. La modellazione può quindi iniziare con le attrezzature, i punti e le relazioni necessarie per le applicazioni concordate ed estendersi successivamente. La convalida ha due metà, contro le regole di Brick e contro l'edificio stesso, e un modello che nessuno aggiorna quando le attrezzature vengono sostituite o gli spazi vengono ripianificati presto descrive un edificio che non esiste più. Modello e dati restano separati ma collegati: il modello descrive un punto, mentre la serie temporale dei suoi valori vive altrove, collegata da un identificatore.
Specificare bene Brick è soprattutto una questione di portata e accettazione: quali attrezzature, quali relazioni, come viene convalidato il modello e chi lo mantiene. Inserite questi quattro requisiti nei requisiti e il modello smetterà di dipendere dalla conoscenza non documentata del fornitore.
Questo articolo si collega al nostro lavoro su I nostri servizi.
Possiamo discutere come questo tema entra nel brief del progetto.
Contatta Pagin Consulting