Book et møde EN

Teknik · Semantisk modellering med Brick Schema

Semantisk modellering med Brick Schema

Et CTS-anlæg kan have tusindvis af punkter med navne som JK057_02_019A_J90_HF03_BPA004. Navnet giver mening for den, der kender anlægget. For alle andre, og for enhver software, er det en streng.

Den semantiske model er det lag, der oversætter. Den beskriver, hvad hvert punkt måler, hvor det sidder, og hvad det hører til, på en måde både mennesker og maskiner kan arbejde med.

Uden modellen er en database bare tusind tal. Med modellen forklares det, hvad tallene betyder.

01Hvad Brick Schema er

Brick Schema er en åben ontologi for bygningsdata. En ontologi er et aftalt ordforråd: en liste over, hvilke slags ting der findes i en bygning, og hvordan de kan hænge sammen.

Den er udtrykt i RDF, den samme teknologi, som bruges til at beskrive viden på nettet, og en Brick-model er derfor en fil, som software kan læse og forespørge på.

Brick kom ud af et forskningssamarbejde og blev første gang beskrevet i en artikel i 2016. Blandt de oprindelige institutioner var Syddansk Universitet. I dag vedligeholdes den af Brick Consortium, en nonprofit, hvis medlemmer både er universiteter og store leverandører i branchen, blandt andre Carrier, Johnson Controls, Schneider Electric og Siemens.

Brick er udgivet under en BSD-licens og er fri at bruge. Den nyeste stabile version er 1.4.4 fra maj 2025, og version 1.5 findes som kandidat.

02Bygningen som ting og relationer

Modellen består af to slags udsagn. Det ene er, hvad en ting er. Det andet er, hvordan to ting hænger sammen.

Hvert udsagn har tre led: hvad det handler om, hvilken forbindelse der er tale om, og hvad det peger på. Det kaldes et triple, og det er den eneste byggesten i modellen. En samlet model indeholder mange af dem.

Håndtegnet forklaring af, hvordan modellen er bygget op. Øverst ét udsagn: kassen zone 1.07 forbundet med en pil til kassen TT-107 temperaturføler, hvor pilen bærer ordet hasPoint. Over de tre dele står subjekt, prædikat og objekt, og under dem står ét udsagn, kaldet et triple. Nederst er de samme slags udsagn sat sammen til en graf: VE01 ventilationsanlæg forsyner zone 1.07 med relationen feeds, og zonen har temperaturføleren TT-107 med relationen hasPoint. Fra føleren går en stiplet pil mærket ref:hasTimeseriesId ud til en databasecylinder mærket tidsserier, med noten at måleværdierne ligger der og ikke i modellen.Tryk for fuld størrelse

Tingene falder i tre hovedgrupper: udstyr, altså ventilationsanlæg, pumper, ventiler og målere, punkter, altså de steder hvor en værdi kan læses eller sættes, og steder, altså bygninger, etager, rum og zoner.

Relationerne er få og gennemgående. De vigtigste er:

  • hasPoint, som knytter et punkt til det udstyr eller det sted, det hører til
  • feeds, som siger, at noget forsyner noget andet, for eksempel at et ventilationsanlæg forsyner en zone
  • hasPart, som siger, at noget er en del af noget større
  • hasLocation, som placerer udstyr og punkter i huset

Hver relation har en modsat vej, så modellen kan læses fra begge ender. Det er dét, der gør det muligt at spørge både om, hvad der forsyner et rum, og om hvilke rum et anlæg forsyner.

Resultatet er ikke en tegning og ikke en tabel, men et netværk. Sådan virker det viser det samme med en illustration.

03Punktet er det centrale

Punktet er dér, hvor modellen møder virkeligheden. Brick deler punkter i seks typer, og forskellen mellem dem er vigtigere, end den ser ud:

  • Sensor, en målt værdi: rumtemperaturen er 21,4 grader
  • Setpoint, en ønsket værdi: rummet skal være 21 grader
  • Command, en ordre til anlægget: åbn ventilen 40 procent
  • Status, en tilstand: pumpen kører
  • Alarm, en meddelelse om, at noget er galt
  • Parameter, en indstilling, der sjældent ændres

Forskellen betyder, at en analyse kan sammenligne det målte med det ønskede uden at gætte på, hvad et navn betyder. Uden typen er en temperatur og et setpunkt bare to tal, der ligner hinanden.

Hvert punkt bærer desuden sin enhed. Brick bruger QUDT, en etableret ordbog over måleenheder, så en grad celsius betyder det samme i alle modeller.

Et tal uden enhed kan ikke sammenlignes med noget. Enheden er ikke en detalje.

04Referencer ud af modellen

Modellen beskriver bygningen, men indeholder ikke data. I stedet peger den ud på de steder, hvor data og geometri findes. Brick kalder det eksterne referencer, og der er tre slags, der betyder noget i drift.

En BACnet-reference siger, hvor punktet sidder i CTS-anlægget: objektets identifikator, navn og type. Den er broen fra beskrivelsen til det, der faktisk læses.

En tidsseriereference siger, hvor historikken for punktet er gemt, med et id og en angivelse af databasen. Brick bestemmer bevidst ikke, hvilken database det skal være.

En IFC-reference siger, hvilket rum i bygningsmodellen zonen svarer til, ved hjælp af rummets globalt unikke id. Det er den kobling, der gør, at en måling kan vises det sted i huset, hvor den hører hjemme.

Håndtegnet sammenligning af to modeller af den samme bygning. Til venstre bygningsmodellen i IFC, tegnet som et snit gennem en etage med tre rum, hvor det midterste er markeret, og et datafelt med IfcSpace, rum 1.07 og GlobalId 3aB9k7Qx. Under den står hvor det er. Til højre den semantiske model uden geometri, hvor kassen zone 1.07 er forbundet opad til ventilationsanlægget VE01 med relationen forsynes af og nedad til temperaturføleren TT-107 med relationen måler temperatur i. Under den står hvad det betyder. Mellem de to modeller går en enkelt linje mærket ref:IFCReference fra rummet til zonen.Tryk for fuld størrelse

Referencerne kom ind i Brick med version 1.3 i 2022 og er grunden til, at modellen kan være et selvstændigt lag frem for endnu en kopi af data. IFC og bygningsmodeller handler om den anden ende af den linje.

En reference siger, at punktet skulle have data. Den garanterer ikke, at de findes.

05Modellen kan spørges og kontrolleres

Fordelen ved at beskrive bygningen i RDF er, at modellen kan forespørges. Med SPARQL, forespørgselssproget til RDF, kan man stille spørgsmål som: find alle rum, der forsynes af et ventilationsanlæg, og giv mig deres temperaturfølere og setpunkter.

Spørgsmålet er skrevet i modellens begreber, ikke i bygningens punktnavne. Det er hele pointen.

Når to bygninger er beskrevet ens, kan den samme analyse køre på dem begge.

Modellen kan også kontrolleres. Brick skiftede med version 1.3 til SHACL, et sprog til at beskrive regler for en graf, og der følger regelsæt med selve ontologien. En model kan derfor valideres automatisk, så fejl findes, før analyserne bygges oven på.

Der findes åbne værktøjer til begge dele, blandt andet et Python-bibliotek fra Brick-projektet selv og BuildingMOTIF fra det amerikanske NREL, som arbejder med skabeloner for at gøre modelbygning mindre håndholdt.

06Brick, RealEstateCore, Haystack og ASHRAE

Brick står ikke alene, og det er værd at kende de tre naboer, fordi de ofte nævnes i samme sætning.

RealEstateCore

RealEstateCore kommer fra ejendomsbranchen og beskriver bygninger, arealer, lejemål og anvendelse. Brick og RealEstateCore blev harmoniseret fra 2022 med en klar arbejdsdeling: udstyr og punkter fra Brick, steder og forretningsbegreber fra RealEstateCore. Fra Brick 1.4 er Bricks egne stedklasser udfaset til fordel for RealEstateCores, og de to leveres i samme fil. De er altså ikke konkurrenter, man skal vælge imellem.

Project Haystack

Haystack kommer fra CTS-verdenen og bygger på tags sat på punkter i selve anlægget frem for på et klassehierarki i en separat model. Haystack 5, annonceret i 2025, introducerer et egentligt skemasprog og eksport til RDF, og det bringer de to verdener tættere på hinanden.

ASHRAE 223P

ASHRAE 223P er en foreslået standard for en semantisk datamodel til bygningsautomation, som beskriver fysik og topologi mere detaljeret end Brick. Den er udviklet i samspil med Brick og Haystack, men den er ikke publiceret endnu, og der er ikke sat en dato.

07Det, man møder i praksis

En Brick-model bliver sjældent til af sig selv. Den bygges ud fra CTS-anlæggets punktliste, ud fra regneark eller ud fra en eksisterende Haystack-model, og det arbejde er tungere, end det lyder.

Årsagen er velkendt for enhver, der har set en punktliste: navngivningen følger en konvention, der sjældent er skrevet ned, og et punktnavn bærer ofte information om både anlæg, placering og funktion på én gang. Det skal læses, ikke slås op.

AI kan hjælpe med at foreslå, hvilken type et punkt er, og forskningen på området viser lovende træfsikkerhed. Men en foreslået model er ikke en færdig model. Det, vi ser gå galt, går igen:

  • punkter, der er typet forkert, fordi navnet indeholder noget, der ligner en type, for eksempel en binær kontakt, der bliver til en CO2-føler
  • manglende enheder, så tallene ikke kan sammenlignes eller omregnes
  • referencer, der lover data, som ikke findes i databasen
  • manglende relationer mellem punkt og udstyr, så et punkt hænger frit i modellen

Derfor er kvalitetssikring ikke et ekstra trin i en etablering. Det er en del af den. Modellen valideres, og det, der ikke kan valideres, rapporteres som et fund i stedet for at blive rettet stiltiende.

08Hvorfor CX2 bruger Brick

Valget af Brick hviler på tre forhold.

Den er åben og uafhængig af leverandør. Modellen er en fil, bygningsejeren ejer, i et format med en åben licens og et konsortium bag. Den kan læses uden CX2.

Den gør analyser flytbare. Når bygningerne er beskrevet på samme måde, kan en analyse skrevet ét sted køre et andet sted. Det er forudsætningen for, at et bibliotek af driftsanalyser overhovedet giver mening.

Den kan kontrolleres. En model, der kan valideres maskinelt, kan også afleveres og modtages med en rapport i stedet for en tillidserklæring.

Brick er ikke længere ukendt hos leverandørerne. Flere CTS-systemer kan i dag sætte Brick-tags på punkter, blandt andet Niagara siden version 4.14 og Schneiders EcoStruxure Building Operation. Forskellen ligger i, hvad man får ud: understøttelsen er overvejende tagging inde i leverandørens eget system, og en dokumenteret eksport af en komplet model som RDF er ikke udbredt.

Har du et teknisk spørgsmål?

Book et møde på 45 minutter, eller skriv til os.

Book et møde

cx1@cx1.dk