Qual è la differenza tra Brick Schema e Project Haystack?

Brick e Project Haystack sono entrambi approcci aperti alla descrizione di attrezzature, punti e spazi dell'edificio in modo che il software possa interpretare i dati dell'edificio in modo coerente. Sono cresciuti da punti di partenza diversi e hanno convenzioni e comunità di modellazione diverse. Brick modella un edificio come un grafo di entità tipizzate unite da relazioni esplicite, utilizzando il modello dati RDF. Haystack ha iniziato con i tag, brevi etichette standard attaccate ai dati, e da allora ha aggiunto definizioni formali, una tassonomia e un'ontologia.

Chiedere quale sia superiore in astratto non porta il proprietario da nessuna parte. La domanda che conta è quale approccio gli strumenti proposti, i fornitori e il team operativo possono implementare, convalidare e mantenere per i casi d’uso che contano.

"Solo tag" contro "una vera ontologia"

Una stenografia comune sostiene che Haystack è solo tag mentre Brick è una vera ontologia. Ciò svende l’attuale Haystack. La sua documentazione descrive un modello semantico a tre livelli: un vocabolario di termini tag formalmente definiti, una tassonomia che organizza tali termini in un albero di sottotipi e un'ontologia che modella relazioni più complesse. Anche il prestito va nella direzione opposta. La documentazione di Brick rileva che prende il concetto di tag da Haystack per l'annotazione flessibile, senza fare affidamento solo sui tag per decidere cosa sia un'entità.

Come differiscono nella pratica

Entrambi sono ancora in evoluzione e lo standard 223P proposto da ASHRAE, non ancora definitivo, rappresenta un'ulteriore opzione. Dovrebbero quindi essere fatti dei confronti sulle versioni effettivamente implementate dai fornitori, qualunque cosa dicano i loro opuscoli. Un fornitore può supportare solo parte di un approccio o aggiungere convenzioni specifiche del progetto che limitano il riutilizzo.

Mettili entrambi alla stessa prova

La valutazione più rivelatrice è quella pratica. Chiedere a ciascuna soluzione proposta di modellare lo stesso piccolo campione: un'unità di trattamento dell'aria, le sue unità terminali, le zone e gli ambienti che servono, nonché i relativi contatori e punti. Esegui query identiche su ciascuno, ad esempio "tutti i sensori della temperatura dell'aria di mandata sulle unità che servono il terzo piano" e controlla ciò che ritorna. Poi guarda gli strumenti di validazione, i formati di esportazione, la documentazione e lo sforzo necessario per aggiungere un secondo edificio. Infine, chiediti chi nella tua organizzazione o catena di fornitura potrebbe mantenere il modello una volta che il fornitore se ne sarà andato.

Quando un portafoglio utilizza entrambi

Alcuni portafogli finiscono per avere entrambi, perché strumenti diversi favoriscono approcci diversi. In tal caso è necessario definire la mappatura tra loro e qualcuno deve mantenerla. La traduzione non è automaticamente priva di perdite, poiché un modello può contenere relazioni o estensioni che l'altro non può rappresentare direttamente.