Foto: Colourbox 

Gør din CTS klar til Big Data

af: Lektor Mikkel Baun Kjærgaard, Center for Energy Informatics, University of Southern Denmark

Open source-metoden Brick giver dig styr på, hvad din bygnings data betyder, så du lettere kan håndtere mange datastrømme fra samme bygning og nemt kan skalere din analyse af data til en hel bygning - og kan genbruge din software på tværs af data fra forskellige bygninger.


 

Big data repræsenterer et paradigmeskifte i, hvordan man indsamler og anvender data fra bygninger. Nye generationer af central tilstandsstyringssystemer (CTS) øger i dag mulighederne for at indsamle data og anvende avanceret software til at behandle og anvende dem. Dertil kommer alle de muligheder, som skabes af decentrale Internet of Things (IoT) enheder for data indsamling og brug af data.

OU44 bygningen på SDU i Odense er bygget med en Big Data vision. Bygningen rummer en lang række sensorer og målere, der gør det muligt – helt ned på rumniveau - at måle strøm og varmeforbrug, indendørs komfort samt hvor mange mennesker der er i lokalet.

Det giver rigtig mange forskellige datastrømme at holde styr på. Og det er en udfordring, når man skal udvikle software, der skal bruge data fra bygningen.

Derfor har Center for Energy Informatics på SDU i projektet COORDICY sammen med en række internationale partnere været med til at skabe en ny metode til at beskrive, hvad data betyder, med det formål at gøre det lettere at arbejde med Big Data fra bygninger. Metoden hedder Brick.

Hvad er Brick?

Brick er en semantisk repræsentation for de forskellige ressourcer i bygninger og deres systemer (se figur 1, 2 og 3). Den semantiske repræsentation beskriver, hvad data betyder i relation til disse ressourcer og systemer.

 

 

 

 

Foto: Jason Koh, Creative Commons Licensen

Figur 1 - Brick klassehierarki 

Foto: Jason Koh, Creative Commons Licensen

Figur 2- Brick relationer 

Grundlæggende beskriver Brick en bygning som en graf med knuder og kanter. Entiteterne i en bygning (fx rum eller komponenter) er repræsenteret som knuder i en Brick-model. Hver entitet er en instans af en specifik klasse og kan have relationer til andre entiteter. Klasserne er defineret som et udvidbart hierarki for at sikre fleksibel brug.

Brick indeholder også relationer fx hvilke data der er tilknyttet en given ressource eller system. Figur 1 og 2 giver eksempler på en del af hierarkiet og de definerede relationer. I it-tekniske termer er Brick en ontologi skrevet i RDF og kan forespørges via sproget SPARQL.

 

Eksempel på en bygning

I figur 3 er der vist et eksempel på en bygning. Her er infrastruktur, komponenter og rum både fysisk og konceptuelt forbundne med hinanden.

Bygningssystemernes egenskaber og adfærd bliver tilpasset via sensorer og kontrolleret af aktuatorer. I dette eksempel har vi en Air Handling Unit (AHU), som leverer luft til en Variable Air Volume (VAV) boks, der kontrollerer den termiske zone, som består af de to rum. Et af rummene har en kontrolleret lyskilde for lys.  Figur 4 viser Brick-beskrivelsen af denne bygning.

Hver entitet er tilknyttet en klasse, som vist til højre i figuren. Figur 5 viser et eksempel på, hvordan man bruger denne Brick-model. Her laver vi en SPARQL-forespørgsel på modellen efter alle temperatur sensorer i bygningen og de rum, de er placeret i. Når vi har resultatet, kan vi derefter finde frem til eventuelt tilknyttet data til disse entiteter. Derved kan vi arbejde med data for bygningen uden at kende de specifikke navne for rum eller ID’er for data.

Foto: Jason Koh, Creative Commons Licensen

Figur 5 - Eksempel på forespørgsel I SPARQL

Foto: Jason Koh, Creative Commons Licensen

Figur 3 - Example building 

Foto: Jason Koh, Creative Commons Licensen

Figur 4 - Example Building Modeled in Brick (visualized)

Hvorfor bruge Brick?

 

Dækning: Brick kan beskrive de entiteter og relationer, som findes i kommercielle bygninger. Skemaet er blevet valideret på seks bygninger fra forskellige dele af verden. Resultatet var, at skemaet kunne dække 98 % af de bygningskomponenter og relationer, som var nødvendige for software-applikationer til bygninger fundet i eksisterende litteratur.

Udvidelser: Da klasser er sammensat af tags, er det muligt at via semantiske sammensætninger at lave nye klasser.

Fleksibilitet: Da klasser er hierarkisk defineret, kan applikationsudviklere og bygningsansvarlige udtrykke deres datakrav og modellere deres bygningskomponenter på forskellige niveauer af abstraktion og stadigvæk have korrekt funktionalitet.

Konsistens: Brick-klasser garanterer maksimal indbyrdes kompatibilitet ved at forhindre inkonsistent brug -fx at en gruppe af tags kan beskrive det samme koncept.

Udtryksmuligheder: Faste relationer muliggør, at Brick kan udtrykke de relationer, som kræves af forskellige applikations kategorier som fejlfinding og tilstedeværelsesbaseret kontrol.

Brugbarhed: Alle eksisterende standardværktøjer til ontologier som fx RDF og SPARQL kan udnyttes til at understøtte lagring, forespørgsler, sammensætning og visualisering af Brick-modeller.

Brick adskiller sig fra eksisterende BIM standarder (fx IFC) ved at være designet til at kunne beskrive de relevante relationer for data i stedet for de relationer, som er nødvendige under opførelsen af en bygning. Derudover adskiller det sig fra den mest kendte metode for at beskrive data fra bygninger (Haystack) på følgende måder:

Brick

Haystack

6 konverterede bygninger, 8 konverterede applikationer, offentlig tilgængelig

Begrænset offentlige reference-implementationer

Understøtter SPARQL forespørgsler, som gennemsøger Brick som en graf

Restriktiv forespørgselsmekanisme, som ikke gennemsøger relationer

Indfanger relationer indenfor og på tværs af bygningssystemer

Kan lave links mellem entiteter, men kan ikke klassificere disse relationer

Hierarkiske klasser

Flad tag-struktur

Hvordan kommer jeg i gang?

Brick blev startet af forskere fra syv forskellige institutioner i 2015. Brick er open-source software og er tilgængelig under en BSD licens. Det primære forum for Brick diskussioner kan findes her.

For at gøre det let at komme i gang med Brick, findes der en række eksempler på, hvordan man kan bruge Brick. De dækker fx, hvordan man tilføjer en Brick-model til data fra sit CTS system, eller hvordan man kan lave dataanalyse understøttet af Brick.

For at udbrede brugen af Brick er vi er interesseret i mange former for samarbejde om Brick. Fx:

  • Repræsenter din bygning med Brick og del dine resultater
  • Lav en applikation med Brick, så andre kan bruge dem
  • Integrer Brick med dit virksomhedssystem
  • Udvid Bricks ordforråd for at møde dine krav