Hoppa till huvudinnehåll

Fastighet

En böjd gångväg mellan moderna byggnader i solnedgång, glas på ena sidan och ett skulpturalt tak på den andra

Fastigheter har varit delvis automatiserade i decennier. Avancerade system utvecklades till specialiserade lösningar, och dessa aggregerades ofta i ett centralt fastighetsstyrsystem. Följden är att ett bestånd samlar på sig system snarare än väljer dem: ett styrsystem per byggnad, ett bokningssystem, ett energisystem, mätare från den som råkade leverera dem, och sensorer tillagda ett projekt i taget.

Vart och ett besvarar sin egen fråga väl. Den återkommande svårigheten är att vart och ett länge varit en isolerad enhet som inte lätt kopplas till de andra, inte ens inom samma byggnad:

  • Många system och komponenter, från olika generationer och olika leverantörer.
  • Slutna lösningar, där det svåra är att komma åt data och funktionalitet.
  • Begränsningar i dokumentationen.
  • Svårt att fånga och kombinera nya slags realtidsdata.
  • Inga gemensamma standarder eller datamodeller.

Yggio är lagret som gör beståndet till en sak. Sensorer och system matar in, data valideras och berikas, regler och modeller agerar på den, och resultatet kommer ut som dashboards, larm och styrning.

sensorer & system -> insamling, -> regler + AI -> dashboards, larm
validering och regelmotor, & styrning
berikning modeller, automation i realtid

Det praktiska rådet som följer av det: börja med ett användningsfall och skala upp till en gemensam plattform, i stället för att specificera plattformen först. En läckagepilot eller en närvaropilot sätter samma Yggio-instans på plats som nästa användningsfall behöver.

Varför en horisontell arkitektur​

Att fortsätta bygga på slutna vertikala system skalar inte, och skälet är inte att systemen är dåliga. Det är att vart och ett äger sin egen hårdvara, sin egen uppkoppling, sin egen data och sitt eget gränssnitt, så att varje ny funktion innebär ännu en stack bredvid den förra.

En horisontell arkitektur separerar i stället de lagren: hårdvara, uppkoppling, integration, och tjänsterna ovanpå. Yggio är integrationslagret, vilket är varför samma plattform bär en läckagesensor, en punkt i ett styrsystem och ett bokningssystem utan att någon av dem känner till de andra.

Samma arkitektur uppritad. Under gränsen för edge och lokal drift matar datakällor en lokal Yggio-instans: inomhusklimat, luftkvalitet, lokalutnyttjande, central mätning, lokal mätning och extern data som väder, Nord Pool-elpris och energifakturor. Bredvid når byggnadssystem samma instans över M-Bus, Modbus och BACnet, och ägarens IT-miljö bidrar med drift- och kontextdata. Ovanför gränsen, på internetsidan, kopplar en Yggio-instans ut mot AI- och BI-verktyg som ChatGPT och Power BI, och mot specialiserade tjänster som SCADA och ruttoptimering

Vad det ger en fastighetsägare:

  • Färre gränssnitt och komponenter att underhålla.
  • Öppna standarder och en gemensam datamodell, så att samma dashboard fungerar i nästa byggnad.
  • Minskat beroende av någon enskild leverantör.
  • Flera fastigheter hanterade genom ett gränssnitt.
  • Sensorer och deras data återanvända över tillämpningar. En närvarosensor köpt för beläggningsrapportering driver också ventilation och skrivbordsbokning, vilket är det som faktiskt sänker kostnaden per användningsfall.
  • Lätt att koppla in moderna IoT-enheter och AI-modeller, och lätt för en extern part att bygga en ny tjänst ovanpå.

Vad det förändrar för upphandlingen​

Att separera lagren får en upphandlingskonsekvens. När gränssnitten väl är standard kan en systemupphandling delas i funktionella moduler och upphandlas var för sig - hårdvara från en leverantör, programvara från en annan, AI-tjänster från en tredje, alla talande samma standarder.

Ett vertikalt system går inte att dela så, eftersom delarna bara är garanterade att fungera med varandra. Det är den praktiska innebörden av inlåsning, och den visar sig vid förnyelse snarare än vid köp.

Suveränitet​

Principen under alltihop är att ägaren behåller kontrollen över sin egen infrastruktur och sin egen data, och avgör vad som delas och med vem. I praktiken betyder det att dataägarskap och lagringstid är ert att sätta, att plattformen körs där ni väljer, och att allt som krävs för att lämna

  • exporter, enhetsnycklar, hårdvaran själv - ingår i leveransen i stället för att vara en förhandling.

Vad beståndet drivs av​

Det här är sådant fastighetsägare ofta bygger på Yggio när datan väl finns på ett ställe. Vart och ett är en vanlig kombination av plattformens delar snarare än en separat produkt.

Vad det gör
EnergioptimeringVentilation, värme och belysning styrda på luftkvalitet, bokningsstatus, beläggning, väderprognos och elpris i stället för på ett schema
Beläggnings- och besöksmätningHur lokaler faktiskt används, per rum och per våningsplan. Se Lokalutnyttjande
AvvikelsedetekteringModeller tränade på en sensors egen historik flaggar avläsningar som inte passar in, vilket är det prediktivt underhåll byggs av
Laddstolpar och batterilagerLaddning och lagring styrda tillsammans med byggnadens övriga last
ArbetsmiljöTemperatur, luftkvalitet, buller och mögelrisk, övervakade där människor är
Behovsstyrd avfallshanteringHämtning driven av fyllnadsgrad i stället för en fast runda
Digital tvilling3D-visualisering av fastigheten, matad med realtidsdata på rumsnivå
Aktivitetsbaserade kontorBokningsbara skrivbord och rum, med bokningssystemet avstämt mot uppmätt närvaro

Plattformsförmågorna bakom dem​

FörmågaVad det innebär här
Regelmotor med AIAutomatiserar åtgärder på data, regler och modellresultat, inklusive PyTorch-baserad avvikelsedetektering
AI-assistent och MCPFrågor på naturligt språk mot realtidsdata från IoT över flera LLM:er. En Yggio MCP-server öppnar plattformen för vilken AI-integration som helst
FlerhyresgästSeparerar kunder, byggnader, användare och roller genom en Keycloak-baserad åtkomstmodell
Edge-moln-kontinuumLokal drift nära byggnaden med central uppföljning i molnet. Lokala regler och AI fortsätter köra genom ett molnavbrott
IntegrationerFastighetsstyrsystem, IoT, bokningssystem, energisystem och externa datakällor, inklusive Grafana, Power BI och verktyg för 3D-digitala tvillingar
Öppen plattformAPI:er, dashboards, appar och dataflöden på en standardiserad datamodell (FIWARE NGSI och RealEstateCore)

De två som oftast avgör arkitekturen är de två sista. En gemensam datamodell är det som låter en dashboard byggd för en byggnad fungera för nästa, och öppna gränssnitt är det som hindrar beståndet från att bli beroende av någon enskild leverantör - inklusive den här.

Flerhyresgäststödet är beståndsfunktionen​

En enskild byggnad kan drivas från nästan vad som helst. Ett bestånd kan det inte, eftersom samma instans måste betjäna människor som inte får se varandras data: en ägare, flera förvaltare, entreprenörer per plats, och hyresgäster.

Det är vad hierarkin i Organization Manager är till för. Åtkomst ges på en enhet och ärvs nedåt i trädet, så att en entreprenör med ansvar för två platser ser de två och en hyresgäst ser sitt eget våningsplan. Att få trädet rätt tidigt är det som senare avgör om det är en konfigurationsändring eller ett projekt att lägga till en byggnad.

Edge, och varför det dyker upp i fastighetsarbete​

Byggnader fortsätter fungera när internet inte gör det. Att köra en Yggio-instans i byggnaden betyder att de lokala reglerna och modellerna fortsätter köra genom ett molnavbrott, och att sensortrafiken stannar på plats, vilket också besvarar frågan en säkerhetsgranskning kommer att ställa om vad som lämnar byggnaden.

Den centrala instansen får fortfarande beståndsvyn. Se Fastighetsautomation för hur alternativen på plats står sig, inklusive vad var och ett kräver av brandväggen.

Att dela resultatet​

Dashboards kan bäddas in var som helst genom en säker länk - webbplatser, intranät, kundportaler och receptionsskärmar. I praktiken är det så beläggnings- eller energidata når hyresgäster utan att någon får ett konto, och det är värt att tidigt avgöra vem varje dashboard är till för, eftersom en dashboard byggd för driftteamet sällan fungerar som en för hyresgäster.

Att komma igång​

  1. Börja med ett användningsfall, inte med plattformen. En läckagepilot eller en närvaropilot sätter samma Yggio-instans på plats som varje senare användningsfall behöver, och den kommer med ett resultat vidhängande snarare än en specifikation.
  2. Få organisationshierarkin rätt tidigt. Den avgör senare om det är en konfigurationsändring eller ett projekt att lägga till en byggnad. Se Organization Manager.
  3. Välj en byggnad, och hämta frågan från något dokumenterat - en skadehistorik, en energifaktura, andelen uteblivna bokningar i ett bokningssystem.
  4. Kräv utträdesvillkoren i den första upphandlingen, medan ni fortfarande har förhandlingsläget: dataägarskap, lagringstid, export, enhetsnycklar. Inlåsning visar sig vid förnyelse, inte vid köp.
  5. Bygg ut till den gemensamma plattformen på vad den första byggnaden visade, genom att lägga till tillgångsslag och domäner i samma tenant i stället för bredvid den.

Relaterat​