Data kom fram. Betydelsen gjorde det inte.

Ett fastighetsautomationssystem exponerar tusentals datapunkter. En gateway publicerar värden. En historikdatabas lagrar dem. Ett API lämnar ut dem på begäran.

Tekniskt sett fungerar integrationen.

Sedan börjar frågorna:

• Vilken givare hör till tilluftsflödet?
• Vilken utrustning försörjer det här rummet?
• Är värdet en mätning, ett kommando, ett börvärde eller ett larm?
• Vilket överordnat system påverkar den här underordnade zonen?
• Var kan programvara hitta realtidsvärdet bakom den här logiska datapunkten?

Svaren finns ofta i punktnamn, ritningar, leverantörsmanualer, kalkylblad och minnet hos personen som driftsatte systemet. Data är tillgängliga, men sammanhanget är det inte.

Data utan sammanhang är ett vällevererat mysterium.

Det är den luckan Brick fyller. Fokus ligger inte på att flytta värden mellan ändpunkter, utan på att göra den omgivande betydelsen så uttrycklig att människor och programvara kan använda den konsekvent.

En ontologi är ett vokabulär med relationer.

Brick är en öppen ontologi och ett metadataschema för att beskriva fysiska, logiska och virtuella entiteter i byggnader, tillsammans med relationerna mellan dem.

Enkelt uttryckt ger Brick oss fyra byggstenar:

Entiteter är objekten

En entitet kan representera något fysiskt, till exempel en pump eller ett rum; något virtuellt, till exempel en givarpunkt; eller något logiskt, till exempel en HVAC-zon.

Klasser anger vilket slags objekt det är

En klass är en namngiven kategori med en definition. En entitet kan anges som en instans av brick:Pump, brick:Air_Handling_Unit eller en mer specifik givarklass.

Relationer skapar omgivningen

Relationer gör sammanhanget uttryckligt. Ett luftbehandlingsaggregat kan ha en temperaturgivare genom brick:hasPoint, försörja en terminalenhet genom brick:feeds och vara placerat i ett fläktrum genom brick:hasLocation.

Grafen gör det möjligt att ställa frågor

Brick representerar dessa påståenden som en riktad, etiketterad graf med RDF. Entiteter blir noder. Relationer blir kanter. Programvara kan söka efter ett betydelsemönster i stället för att avkoda ett lokalt namngivningsmönster.

En ontologi är inte en påse med bättre taggar. Det är ett styrt sätt att ange vad objekt är och hur de hänger samman.

Sluta avkoda etiketter. Börja fråga grafen.

En traditionell integration börjar ofta med en sträng som B4_AHU03_SAT. En sakkunnig person kan läsa ut byggnad 4, luftbehandlingsaggregat 3 och tilluftstemperatur. Programvara ser bara tecken tills någon skriver reglerna för avkodningen.

I en Brick-modell är de användbara påståendena åtskilda och uttryckliga:

Nu kan en applikation söka efter tilluftstemperaturgivare som hör till luftbehandlingsaggregat, eller följa luftens väg mot de zoner som aggregaten påverkar. Namnen kan skilja sig mellan byggnader. Det uttalade mönstret kan förbli detsamma.

En tagg är komprimerad lokal kunskap. En graf är uttalad gemensam kunskap.

Brick förmedlar mer mening. Men klassen är fortfarande inte vardagsnamnet.

Beteckningar enligt IEC 81346 är precisa, men precision gör dem inte till bra vardagsnamn. =H1.PA1.GPB1 kan vara en utmärkt styrd referens och samtidigt en dålig rubrik på en operatörsbild.

Bricks vokabulär känns mer naturligt eftersom klasser som brick:Pump, brick:Room och brick:Temperature_Sensor använder igenkännbara begrepp. Det hjälper både människor som utforskar modellen och programvara som tolkar den.

Men klassen är fortfarande inte det namn människor använder för den enskilda maskinen. En ren modell håller isär tre roller:

Det föredragna namnet kan vara flerspråkigt och kan ändras utan att entiteten behöver definieras om. Den semantiska klassen förblir en klassificering, inte ett smeknamn. Beteckningen förblir en styrd väg, inte en beskrivning i löptext.

Låt människor läsa namnet. Låt programvara förstå klassen. Låt referensbeteckningssystemet bevara vägen.

Sluta lära varje ny applikation hur byggnaden fungerar.

Utan en gemensam semantisk modell börjar varje ny instrumentpanel, analyspaket och optimeringsapplikation med ännu en kartläggning. Applikationen kan vara återanvändbar. Dess förståelse av byggnaden är det inte.

Brick syftar till att göra den förståelsen mer flyttbar. När olika anläggningar beskriver likvärdiga begrepp med samma klasser och relationer kan programvara upptäcka vad den behöver, i stället för att varje installation måste hårdkodas i förväg.

• Mindre integrationsarbeteMindre upprepad tolkning av leverantörsspecifika etiketter.
• Upptäckt över leverantörsgränserApplikationer kan hitta relaterade entiteter i flera delsystem i en byggnad.
• Återanvändbara analyserRegler kan riktas mot semantiska mönster i stället för taggsyntaxen på en viss anläggning.
• Spårbar dataåtkomstDatapunkter kan hänvisa till BACnet-objekt, tidsserieidentifierare eller andra externa representationer.
• Maskinell valideringBegränsningar kan kontrollera om de klasser, egenskaper och relationer som krävs finns på plats.
• SlutledningFormella axiom kan göra underförstådda klasser och inversa relationer uttryckliga.

Målet är inte att göra grafen klurig. Målet är att göra applikationer mindre beroende av tankeläsning.

IEC 81346 visar vägen. Brick beskriver omgivningen.

Brick kompletterar inte IEC 81346 som om något saknades i standarden. Brick tillför en semantisk förmåga som IEC 81346 inte försöker tillhandahålla.

Modellerna bör förbli sammankopplade, men inte slås ihop. Ett Brick-påstående med hasPart motsvarar inte automatiskt en beståndsdelsrelation enligt IEC 81346 i en vald aspekt. Liknande ord garanterar inte identisk omfattning.

En robust ägararkitektur kan koppla samman vyn enligt IEC 81346, Brick-vyn, operativa roller enligt ISA-95 och plattformsreferenser genom stabila kanoniska identiteter.

Identiteten talar om vilket objekt det är. Semantiken talar om vad det betyder här. Ett beständigt gränssnitt behöver båda.

Ett semantiskt lager är inte hela teknikstacken.

Brick kan fungera som ett semantiskt gränssnittslager när begreppet används med omsorg. Det kan ge en gemensam betydelse som hjälper applikationer att hitta samma begrepp. Brick flyttar inte självt värdena och ersätter inte alla omgivande modeller.

Bricks dokumentation föreskriver avsiktligt inte ett enda standardiserat API. Modellen kan i stället innehålla referenser som låter applikationer hitta realtidsdata eller historiska data genom externa system. Grafen beskriver sammanhanget. Andra system förblir auktoritativa för sitt datainnehåll.

Den sista varningen gäller organisationen. RDF-syntax skapar inte styrning. En Brick-modell kan vara tekniskt giltig och ändå innehålla fel entiteter, svaga relationer, inaktuella referenser eller okontrollerade lokala utökningar.

God semantik uppstår inte ur enbart syntax. Den skapas genom styrning.

Ge Brick det uppdrag som modellen är bra på. Gör kopplingarna till identitet, verksamhet och realtidsdata uttryckliga. Då blir det semantiska lagret infrastruktur i stället för ännu en övergiven modell.