openAut — v0.1 · Konceptstadie · Öppen källkod · MIT
⚠ Konceptprojekt under utveckling. openAut är ett öppet kunskaps- och konceptprojekt för att utforska hur AI med lokala modeller kan användas inom fastighetsautomation. Det är inte en färdig produkt och ska inte användas i skarp drift eller live-miljöer.

Din fastighet
genererar data.
Börja förstå den.

openAut är ett öppet tillägg till ett befintligt BMS — inte en ersättare. Det samlar in driftsdata, analyserar den lokalt med lokala AI-modeller, och kan peka tekniker mot vad som är fel och varför energiförbrukningen ökar.

Ingen molnanalys. Ingen leverantörslåsning. Driftsdata och inferens stannar i byggnaden — bara beslut och notiser går via Teams.

Se konceptet i praktiken GitHub →
Scrolla för att utforska
Så är det tänkt att fungera

Tre roller.
Samma idé.

Tanken är att openAut ska kunna ge olika svar till olika roller — i de verktyg de redan använder. Drifttekniker får larmkorrelation och rotorsak i sin chatt. Energisamordnare får automatiska veckoapporter och avvikelseanalyser. Förvaltare ser fastighetsstatus och underhållsprognos i en webbvy.

Drifttekniker

Från BMS-larm till åtgärd — utan ett enda pappersschema

03:22
BMS genererar regleravvikelselarm på By05 LA03: framledningstemperaturgivare GT04 visar 21 °C — under börvärde 28 °C. Larmet skrivs till Systemdatabasen.
03:23
openAut fångar larmet. Hämtar driftkortet för LA03 från Systemdatabasen — identifierar att givaren mäter framledningstemperatur på värmebatteriet i LA03 och styrs via styrventil SV01. Läser aktuell driftstatus: SV01 rapporterar 100 % öppning. GT04 visar 21 °C. Slutsats: ventilen kommenderas fullt öppen men värme uteblir — felet ligger troligen inte i ventilen utan i styrsignalen till ställdonet.

openAut hämtar AS-schemat för LA03 ur Systemdatabasen och identifierar att utsignalen till SV01:s ställdon utgår från analog utgångsmodul och trådad till plint 201 och 202 i apparatskåp AS03. Signalen ska vara 0–10 VDC.
06:45
Teams-notis till drifttekniker:

SV01 kommenderas 100 % men GT04 visar 21 °C — värmen uteblir trots fullt öppningskommando. Kontrollera spänningen mellan plint 201 och 202 i AS03. Vid korrekt funktion ska du mäta 10 VDC.
07:10
Teknikern i Teams: "Mäter 0 VDC mellan plint 201 och 202."
openAut svarar:

0 VDC bekräftar att styrsignalen aldrig når ställdonet. Trolig orsak: fel på analog utgångsmodul eller felaktigt programvärde i regulatorn. Kontrollera modulstatus i BMS-klienten — byt modul om ingen hårdvaruindikering syns.
08:15
Teknikern byter analog utgångsmodul. Mäter 10 VDC på plint 201–202. GT04 stiger mot börvärde. Larmet kvitteras i Systemdatabasen.
Fel åtgärdat på 5 timmar — utan att teknikern öppnade ett enda pappersschema.
Energisamordnare

AI ser vad BMS-larmet inte förklarar

Måndag 06:00
openAut läser energimätardata från fjärrvärmecentralen FJV01 och jämför primärsidans flöde mot levererad effekt på sekundärsidan. Identifierar en avvikelse som vuxit under 11 veckor: samma mängd energi ut — men primärsidan kräver allt högre flöde för att leverera den.

Primärsidans returtemperatur har stigit från 38 °C till 51 °C. Fjärrvärmeleverantörens avtalsgräns är 45 °C.
06:01
openAut hämtar information för FJV01 ur Systemdatabasen. Identifierar att anläggningen har en plattvärmeväxlare installerad 2019 utan dokumenterat servicetillfälle. Korrelerar trenden mot historiska driftdata — mönstret är konsistent med beläggning på värmeväxlarens primärsida.

BMS larmar inte. Sekundärsidan levererar rätt temperatur. Felet syns bara i relationen mellan primär- och sekundärsidans energibalanser — två datakällor som BMS aldrig ställer mot varandra.
06:15
Energisamordnaren får avvikelserapport i Teams:

FJV01 visar försämrad värmeöverföring under 11 veckor. Primärsidans returtemperatur överskrider nu avtalsgränsen mot fjärrvärmeleverantören — risk för tilläggsdebitering vid nästa avläsning. Trolig orsak: beläggning i plattvärmeväxlare. Kemtvätt rekommenderas inom 2 veckor. Estimerad kostnad för utebliven åtgärd: 40–60 tkr/kvartal i förhöjd fjärrvärmekostnad plus eventuellt avtalsvite.

Sekundärsidan fungerade perfekt. Det var relationen mellan systemen som avslöjade felet.
Teknisk förvaltare

Underhållsprognos — inte brandkårsutryckningar

Kvartal
Kylmaskin KM1 (byggnad 07, kylmaskinrum plan 1) visar under 8 veckor gradvis stigande energiförbrukning per producerad kyleffekt. openAut hämtar DU för KM1 ur Systemdatabasen och jämför aktuell COP mot fabrikantens referensvärde och historiska säsongsvärden.

Vecka 1–8: COP sjunker från 3,8 → 2,9. Kondenseringstrycket stiger med 12 % utan motsvarande ökning av utetemperatur. Förångarsidan normal.
Prognos
openAut flaggar i den tekniska förvaltarens veckerapport: avvikelsemönstret är konsistent med kondensorbeläggning — inte köldmedieläckage (förångartrycket är stabilt). Servicebesök med kondensorrengöring rekommenderas inom 3 veckor. Estimerad energibesparing efter åtgärd: 18–22 % på KM1.
Resultat
Planerat servicebesök genomfört vecka 18. COP återgår till 3,7. Ingen haveri i juli — den månad då reservkapacitet saknas och akutkostnaden är som högst.
Guidad integration

Teknikern är händerna.
AI:n har läst manualen.

När du ansluter ny utrustning — en pump, en kylmaskin, ett luftbehandlingsaggregat — behöver du inte vara protokollexpert. Anslut din service-PC till openAut Engineers kontrollplan på plats (mgmt-nätet, bakom bastion · mTLS · MFA), ladda upp fabrikantens manual där och ange vilken edge-nod enheten sitter på. Engineer läser dokumentet, guidar dig steg för steg och driftsätter via SSH när du bekräftar varje steg. Teknikern utför. AI:n navigerar. Dokumentationen skriver sig själv.

openAut Engineer · Kontrollplanservice-PC · mgmt-nät
MN
Magnus N · Drifttekniker (service-PC)
Ska integrera Grundfos Magna3 65-120 på edge-nod EDGE-04 (UC byggnad 25 plan 2). Laddar upp manualen i kontrollplanet.
📄 Grundfos_Magna3_Installation_SE.pdf
openAut Engineer läser dokumentet · identifierar protokoll och registerstruktur
AI
openAut Engineer
Hittade Modbus RTU-stöd på sidan 47. Magna3 65-120 exponerar 18 holding registers från adress 1. Jag ser att EDGE-04 redan har en ledig RS-485-port.

Steg 1: Ställ in pumpens kommunikationsparametrar via frontpanelen:
→ Meny: COMM → Modbus → Adress: 5
→ Baudrate: 19200, Paritet: None, Stoppbitar: 1

Bekräfta när det är gjort så fortsätter vi.
MN
Magnus N · Drifttekniker (service-PC)
Klart. Inställt.
AI
openAut Engineer
Inställningarna stämmer. Jag driftsätter Modbus-drivrutinen mot EDGE-04 via SSH — bekräfta varje steg här i kontrollplanet.

Driftsatt. Kommunikation verifierad mot port RS485-2, adress 5. Grundregistren läses — flöde, tryckhöjd, effekt, driftläge, larmstatus.

Integration klar. Magna3 65-120 är nu aktiv i namnrymden EDGE-04/VVS/Pump/CIR-07. Semantisk taggning enligt Brick Schema tillagd automatiskt.

I/O-listan och nätverksdokumentationen för UC byggnad 25 plan 2 är uppdaterade. Du hittar dem i projektmappen.
01

Installera edge-noden vid utrustningen

En Siemens SIMATIC IOT2050 monteras i närheten av anläggningsdelen — pump, kylmaskin, AHU. Den kör standard Linux och ansluts till OT-nätverket. openAut Engineer når noden via SSH och installerar protokolldrivrutiner — efter att du bekräftat i kontrollplanet. Ingen proprietär middleware krävs.

02

Ladda upp manualen från din service-PC

Teknikern ansluter sin service-PC till Engineers kontrollplan på plats (mgmt-nät, bastion · mTLS · MFA) och laddar upp fabrikantens manual där. openAut Engineer läser dokumentet, identifierar kommunikationsprotokoll, registerstruktur och inställningsparametrar — utan att teknikern behöver leta.

03

AI guidar, teknikern utför

openAut Engineer ger exakta steg-för-steg-instruktioner för frontpanelsinställning, kabelanslutning och adresskonfiguration. Teknikern bekräftar varje steg i kontrollplanet. Engineer testar kommunikationen via SSH och verifierar att data flödar korrekt.

04

Integrationen verifieras automatiskt

När kommunikation är etablerad läser Engineer alla tillgängliga register och validerar värden mot förväntade fysikaliska gränser. Pumpen börjar omedelbart ingå i Advisors anomalidetektering och energianalys.

05

Dokumentationen skriver sig själv

I/O-lista, kommunikationstabell, MQTT topic-schema och nätverksdiagram genereras automatiskt av Engineer som en sidoeffekt av driftsättningen. Nästa tekniker har fullständig dokumentation från dag ett — oavsett vem som utförde driftsättningen.

🔄

Teknikern styr. AI:n navigerar.

Rollen är omvänd mot traditionell automation. openAut ersätter inte teknikern — det ger teknikern specialistkunskap on-demand, direkt i det verktyg hen redan använder. Varje integration bygger organisationens samlade kunskapsbas och bidrar till projektets delade dokumentation.

Varför det behövs

Du har datan.
Men den får inte lämna huset.

Du har redan datan. Dina system registrerar temperaturer, tryck, energiuttag, driftlägen och larmstatus dygnet runt. Det är inte tillgången till data som är problemet.

Problemet är vad som krävs för att analysera den. Marknadens AI-tjänster förutsätter att du skickar driftsdata till en molnplattform — deras plattform. Känslig information om dina byggnaders tekniska status, energimönster och driftslägen hamnar hos en extern leverantör, under deras villkor, till ett löpande abonnemangspris som kan förändras.

För offentliga fastighetsägare är det här inte ett acceptabelt utbyte. Driftsdata om samhällsviktig infrastruktur ska inte lämna nätverket. Verksamheten ska inte bli beroende av en extern tjänst som kan sägas upp, prisändras eller läggas ned.

openAut löser det genom att köra all AI-analys lokalt — i din fastighet, på din hårdvara, under din kontroll. Inget moln för analys och lagring. Inga abonnemang. Din driftsdata stannar i byggnaden — bara beslut och notiser går vidare till Teams.

01

Data lämnar nätverket

Molnbaserade AI-tjänster kräver att driftsdata skickas externt. Teknisk status, energimönster och driftslägen hamnar hos en leverantör — under deras villkor och i deras infrastruktur.

02

Löpande abonnemang binder upp verksamheten

Abonnemangsbaserade analystjänster skapar ett kontinuerligt beroende. Priser kan höjas. Villkor kan förändras. Tjänsten kan avvecklas. Och att byta är alltid dyrare än att stanna.

03

Datakontroll och suveränitet

Vem äger insikterna som genereras från dina byggnader? Med molntjänster är svaret oklart. Träningsdata, beteendemönster och driftloggar kan användas på sätt som är svåra att granska eller begränsa.

04

Lokal AI har krävt datahallsinvestering — tills nu

On-premise AI-infrastruktur med tillräcklig kapacitet för stora språkmodeller har tidigare kostat miljoner och krävt dedikerade maskinrum. En ny generation lokal LLM- och ML-hårdvara — från kompakta AI-system till GPU-servrar — förändrar den ekvationen.

05

NIS2, AI Act och LOU ställer krav

Offentliga fastighetsägare klassade som samhällsviktig verksamhet omfattas av NIS2-direktivets och AI Acts krav på informationssäkerhet. Molntjänster med oklar datahantering är svåra att förena med dessa skyldigheter.

Teknisk grund

Byggt på NemoClaw.
Sammansatt för fastigheter.

openAut är inte ett AI-system byggt från grunden. Det är ett domänspecifikt ramverk — en uppsättning skills, protokollintegrationer och sammansättning — ovanpå en etablerad och beprövad agentstack. Grunden är NVIDIA NemoClaw och OpenClaw: den snabbast växande öppna källkodsmiljön för persistenta, alltid-på AI-agenter. openAut tillför det som saknas för att den stacken ska fungera i en fastighets verkliga driftmiljö.

Agentmiljö · grund
OpenClaw
MIT-licens
Självhostad, persistent AI-agentmiljö. Betraktas som "operativsystemet för personlig AI" — en öppen plattform för autonoma agenter som kör verktyg, läser filer, anropar API:er och driver flerstegiga arbetsflöden kontinuerligt. Alla agents (claws) kommunicerar via strukturerade kanaler och kan delegera uppgifter mellan varandra.
Alltid-på agenter Multi-agent orkestrering Verktygsstöd Teams-kanal Självhostad 250 000+ GitHub-stars (mars 2026)
NemoClaw lägger säkerhet och lokal inferens ovanpå OpenClaw
Säkerhet · inferens · livscykel
NemoClaw
NVIDIA · Apache 2.0
NVIDIAs härdade referensimplementation ovanpå OpenClaw. Installeras med ett kommando och tillför OpenShell-sandbox (Landlock + seccomp + nätverksisolering), policy-baserade säkerhets- och integritetsskydd, lokal inferens med öppna modeller (open weights) och livscykelhantering. All inferens körs lokalt — ingen data lämnar nätverket. Körs på valfri lokal AI-hårdvara med tillräcklig inferenskapacitet. NemoClaw är i tidig fas (alpha, lanserad mars 2026) — openAut pinnar därför verifierade versioner och kapslar in stacken bakom stabila gränssnitt, så att grunden kan utvecklas utan att din driftmiljö påverkas.
OpenShell sandbox Lokal inferens · öppna modeller Policy-baserade guardrails Auditloggning IEC 62443-anpassad ISO 27001-anpassad NIS2-kompatibel CRA-redo AI Act-kompatibel Hårdvaruagnostisk
openAut bygger fastighetsdomänen ovanpå NemoClaw
Domänramverk · skills · integration
openAut
MIT-licens · öppen källkod
Det som NemoClaw inte vet: hur en shuntgrupp fungerar, vad ett BACnet-objekt betyder, hur man tolkar en Modbus-registerförteckning, vad som är ett normalt ΔT på en VVC-krets. openAut tillför fastighetsdomänens kunskap som skills — strukturerade verktyg, protokolldrivrutiner och sammansättning som gör att NemoClaw-agenten förstår och kan agera i en verklig BAS/BMS-miljö. Domänkunskapen avgör också vilken modell som passar vilken uppgift — en lättviktig LLM för rutinfrågor, en resonerande modell för rotorsaksanalys och klassisk tidsserie-ML för prognos och avvikelsedetektering — medan NemoClaw kör inferensen lokalt. Ramverket är modulärt: varje applikationsprofil är en fristående konfiguration av skills, modellval och integrationer.
BACnet-skill Modbus-skill M-Bus-skill LoRa-skill FDD-skill (feldetektering) Energianalys-skill Integrationsguide-skill Dokumentations-skill SSH edge-access Python I/O-skill Edge-reglerings-skill MQTT over TLS (stream + req/resp) Teams-integration Forge-skills (Forgejo) Webb-HMI
RAMVERK

Skills är byggstenarna

Varje skill är ett självständigt verktyg som agenten kan anropa: läs Modbus-register, tolka BACnet-larm, generera I/O-lista, guida integration. Nya skills läggs till utan att kärnarkitekturen förändras — och publiceras öppet så att hela ekosystemet drar nytta.

SAMMANSÄTTNING

Applikationsprofiler styr helheten

En applikationsprofil definierar vilka skills som aktiveras, vilka protokoll som används, vilken edge-nod som kopplas in och vad AI:n ska analysera. Det är konfiguration — inte programmering. En ny fastighet driftsätts genom en ny profil, inte ett nytt system.

INTEGRATIONER

Öppet mot hela ekosystemet

openAut integrerar med befintliga system som Siemens Desigo, Schneider EcoStruxure, Trend Controls, Regin — utan att kräva proprietära drivrutiner. Har du redan Kepware-licens ansluts den. Kärnlösningen kräver det aldrig. Alla integrationer är dokumenterade och reproducerbara.

Systemarkitektur

Fyra lager.
Ett sammanhängande system.

LAGER 01 — FÄLT
Din befintliga utrustning
openAut ersätter ingenting. Sensorer, mätare, PLC:er och BMS-enheter fortsätter att reglera sig själva exakt som tidigare. Python-baserad reglering kan driftsättas på edge-noden mot fältets I/O — alltid med explicit konfigurerat regleringsuppdrag och med befintliga styrsystem i behåll som prioritet.
Befintliga styrsystem behåller prioritet. Inga omprogrammeringar av PLC:er eller DDC-regulatorer.
BACnet IP / MS·TP
Modbus RTU / TCP
M-Bus (energimätare)
KNX · DALI
Kontrollerad skrivåtkomst
LAGER 02 — EDGE
Linux-baserade edge-noder
Siemens SIMATIC IOT2050-noder kör standard Linux och nås av openAut Engineer via krypterad SSH. openAuts protokolldrivrutiner körs direkt på noden och läser data från fältutrustning via Modbus, M-Bus, LoRa eller annat fältprotokoll. Data transporteras krypterat till EMQX-brokern via MQTT over TLS — både som kontinuerlig mätström och som on-demand request/response via topics. Ingen proprietär middleware.
openAut Engineer (via NemoClaw) sköter installation och konfiguration via SSH. Inga manuella ingrepp på noden. Engineer kan via samma SSH-åtkomst även driftsätta Python-baserade regleringsskript direkt på edge-noden. Skripten kör slutna reglerloopar mot lokal I/O — utan rundtur till AI-servern — och uppdateras, versionshanteras och återkallas centralt. Regleringskod behandlas som konfiguration: granskningsbar, reproducerbar och driftsatt först efter operatörens godkännande, steg för steg.
SSH-åtkomst (krypterad)
Modbus RTU / TCP
M-Bus · LoRa
Lokal 24–72h buffer
Python edge-reglering
Versionshanterad regelkod
→ MQTT over TLS (EMQX-broker)
→ Stream · On-demand req/resp
LAGER 03 — AI
Systemdatabas & AI-analys
EMQX-brokern tar emot MQTT over TLS från alla edge-noder. Telegraf skriver tidsseriedata och larm till TimescaleDB, medan enheter, metadata, konfiguration och ärendekö ligger i Systemdatabasen (PostgreSQL). En delad AI-backend kör öppna modeller lokalt och betjänar både openAut Advisor (read-only, Teams) och openAut Engineer (SSH/deploy) — samma modellvikter och GPU, men egen sandbox och egna credentials per instans. Analyser, larm och åtgärdsförslag skrivs tillbaka utan externa anrop. Kod, manualer, genererad dokumentation och migrationer versionshanteras i en lokal Forge (Forgejo) som både människor och AI hämtar från, med CI- och granskningsgrindar innan något blir betrott eller driftsatt. On-demand-förfrågningar till edge-noder sker via MQTT request/response-topics.
Driftsdata stannar i byggnaden. GDPR-säkert per design.
EMQX-broker (MQTT over TLS)
Telegraf (ingest → TimescaleDB)
TimescaleDB (tidsserie) · PostgreSQL (Systemdatabas)
Lokal Forge (Forgejo) — kod · manualer · dok
Lokal LLM-inferens
Feldetektering (FDD)
Energioptimering
Anomalikorrelation
Rotorsaksanalys
LAGER 04 — GRÄNSSNITT
Operatörens verktyg
Insikter når de som behöver dem — i verktyg de redan använder. Chatten (openAut Advisor) för drifttekniker. Dashboarden och Power BI för energisamordnare och förvaltare. API:et för integrationsteamet.
Inget nytt system att lära sig. Rådgivande — aldrig styrande.
Microsoft Teams
Webb-HMI & dashboard
Power BI Report Server (on-prem, read-only)
Larmhantering
Automatisk dokumentation
REST API
openaut — drifttekniker, Stadshus Kvarter A
openaut> status --byggnad "Stadshus-A"
▸ 312 datapunkter online · 3 aktiva avvikelser · senaste synk 4s sedan
 
openaut> diagnostik --system LA03
Analyserar 72h trenddata för LA03...
✔ Tillufttemperaturavvikelse detekterad sedan 06:14
Rotorsak (87% konfidens): hysteresfel på värmeventil SV01
Korrelerat: Tillufttemperatur +34°C med 0% utsignal på SV01
Åtgärd: Kontrollera ventil och ventilställdon SV01
 
openaut> energirapport --period vecka --format pdf
✔ Rapport genererad: /rapporter/2025-V22-stadshus-a.pdf
# Reglering kräver explicit konfigurerad applikationsprofil — loggad och versionshanterad
AI-hårdvara

Valfri AI-hårdvara.
I din egen infrastruktur.

openAut är hårdvaruagnostiskt — plattformen körs på valfri lokal LLM- och ML-hårdvara med tillräcklig inferenskapacitet, från kompakta AI-system till GPU-servrar. Det som styr valet är vilka modeller du vill köra — inte vilken leverantör plattformen råkar stödja. Välj det som passar din upphandling, ditt befintliga ramavtal eller din befintliga infrastruktur.

Kapacitetskrav — inte produktkrav

Lokal AI-server

Valfri leverantör · GPU eller annan AI-accelerator · x86_64 / ARM64

openAut ställer krav på kapacitet, inte på fabrikat. Allt som kör Linux och klarar lokal LLM-inferens med tillräckligt acceleratorminne för dina valda modeller fungerar — en GPU-server, en AI-workstation eller ett kompakt system med unified memory.

Linux
Ubuntu 24.04 LTS
Lokal
All inferens on-premise
≥2 TB
Lagring (rekommenderat)
Air-gap
Dataplan — Teams undantaget
Ingen hårdvarulåsning
Air-gap-bart dataplan
GPU-server
AI-workstation
Dimensionering efter behov

Modellen styr hårdvaran

Lättviktig LLM · resonerande modell · tidsserie-ML

Olika uppgifter kräver olika modeller — och olika mycket hårdvara. En lättviktig LLM för rutinfrågor klarar sig på ett kompakt system, medan stora resonerande modeller för rotorsaksanalys kräver mer acceleratorminne. Dimensionera efter din mest krävande modell och skala upp när behoven växer.

LLM
Lokal språkmodell
ML
Tidsserie · FDD · prognos
Skalbart
Workstation → GPU-server
Modulärt
Byt hårdvara, behåll plattform
LOU-anpassningsbar
Uppgradera vid behov
Edge-varianter möjliga

Varför hårdvaruagnostik är strategiskt rätt val

Hela openAut-stacken är öppen källkod och körs på både x86_64 och ARM64: pymodbus, BAC0, paho-mqtt och alla AI-ramverk. Inga proprietära beroenden i kärnlösningen. Det betyder att AI-hårdvaran kan väljas — och bytas — utifrån prestanda, pris och tillgänglighet, utan att plattformen påverkas. När modellerna växer uppgraderar du hårdvaran, inte systemet.

Öppen källkod & offentlig sektor

Tänkt för offentlig
upphandling. Från grunden.

En av de frågor konceptet utforskar är hur en öppen plattform skulle kunna passa offentlig sektor. För kommuner, regioner och offentliga fastighetsägare skapar LOU reella begränsningar för teknikval — och tanken är att openAut ska kunna fungera inom de begränsningarna, inte runt dem.

Eftersom openAut är MIT-licensierat och öppen källkod finns det ingen enskild leverantör att upphandla. Plattformen är gratis att använda. Vad din organisation upphandlar är kompetensen att implementera, konfigurera och förvalta den — tjänster som kan läggas ut på öppen anbudsgivning och tilldelas valfri regional konsult, befintliga ramavtalspartner, eller en intern driftsorganisation.

Det unika med öppen källkod i offentlig sektor är att investeringen stannar i det gemensamma. En lösning som en kommun utvecklar kan återanvändas av alla andra — och bidrag tillbaka till projektet stärker plattformen för hela ekosystemet.

Anta den öppna plattformen. Upphandla kompetensen. Äg resultatet.
Bidra tillbaka till det gemensamma.
01

Anta den öppna standarden

Din organisation beslutar att basera sin fastighetsintelligensstrategi på openAut — fritt, utan att teckna något leverantörsavtal.

02

Specificera i öppet förfrågningsunderlag

Implementationskrav specificeras mot den öppet publicerade openAut-arkitekturen. Vilken kvalificerad integratör som helst kan lämna anbud — inte bara de med en proprietär plattformslicens.

03

Levereras av upphandlade konsulter eller befintliga leverantörer

Upphandlade integratörer — eller din organisations befintliga driftleverantörer — implementerar och driftsätter systemet med hjälp av full openAut-dokumentation. Alla leverabler är reproducerbara av annan part.

04

Din organisation äger konfigurationen

Applikationsprofiler, I/O-listor, AI-konfigurationer och driftsättningsprotokoll tillhör din organisation — inte konsulten. Byt integratör när som helst utan att tappa historik eller konfiguration.

05

Bidra tillbaka och stärk ekosystemet

Protokolldrivrutiner, applikationsprofiler eller AI-modeller som utvecklas i ditt projekt kan bidras tillbaka till det delade openAut-repot. Din investering stärker plattformen för varje annan offentlig organisation.

Äganderätt

Du äger din driftsättning

MIT är den mest permissiva licensen inom öppen källkod. Använd openAut kommersiellt, modifiera det fritt, integrera det i befintliga system — utan royalties, utan anmälan och utan tillstånd.

🔬
Transparens

Varje rad är granskningsbar

All konfiguration, alla applikationsprofiler, all AI-promptlogik — publicerad öppet. Säkerhetsrevisorer, tekniska förvaltare och din upphandlingsjurist kan granska exakt vad systemet gör med era data.

🌱
Ekosystem

Byggt på bidrag

Varje organisation som driftsätter openAut kan bidra med applikationsprofiler, protokolldrivrutiner och FDD-modeller. Ekosystemet förbättras med varje installation — sammansatt värde för varje deltagare.

🔌
Arkitektur

Ingen proprietär kärna

Hela stacken körs på öppen källkod: pymodbus, BAC0, paho-mqtt, EMQX, Telegraf, TimescaleDB. Om du redan har licens för Kepware eller liknande ansluts det — men det krävs aldrig.

🔄
Reproducerbarhet

Vilken tekniker som helst kan ta vid

Varje applikationsprofil är självständig: hårdvaruval, protokollkonfiguration, MQTT topic-schema, AI-parametrar, FAT/SAT-checklistor. En tekniker som aldrig sett din fastighet kan driftsätta openAut från dokumentationen.

🛡
Säkerhet

Säker by design

openAut håller sig inom fem ramverk — ISO 27001 (governance), NIS2 (verksamhet), IEC 62443 (OT), CRA (produkt) och AI Act (AI-funktion) — inbyggt från dag ett, inte tillagt i efterhand. VLAN-segmentering, MQTT over TLS med klientcertifikat, WireGuard VPN, RBAC och auditloggning är baskrav, inte tillval.

Om projektet

Ett öppet projekt
under utveckling.

openAut är i grunden ett kunskaps- och konceptprojekt: ett sätt att utforska hur AI med lokala modeller faktiskt kan användas inom fastighetsautomation — inte bara i teorin. Projektet befinner sig i konceptstadiet och är under aktiv utveckling.

Det här är ingen färdig produkt. openAut ska inte användas i skarp drift eller live-miljöer — det är byggt för att lära, experimentera och visa på möjligheter. Målet är att över tid förstå vad som krävs för att något liknande ska kunna mogna till en driftsäker lösning.

Arkitekturen hålls medvetet öppen, modulär och fri från inlåsning, så att den kan växa i den riktning som visar sig vara rätt — utan att något utesluts i förväg. Allt utvecklas öppet under MIT-licens, fritt att granska, ifrågasätta och bidra till.

Kom igång

Din fastighet pratar
redan. Låt oss utforska lyssnandet.

openAut är öppen källkod och ett konceptprojekt under aktiv utveckling — för att lära, inte för skarp drift. Utforska dokumentationen, granska arkitekturen, bidra med en protokolldrivrutin eller experimentera med en applikationsprofil.

Se projektet på GitHub Utforska arkitekturen IT/OT-säkerhet Systemtopologi