XBB i Sala har utvecklat en embedded-plattform för fordonsstyrning som i dag finns i omkring 150 000 installationer i Norden. Systemet används framför allt för att läsa information från bilens CAN-nät och styra extern utrustning, exempelvis extraljus.

Nu försöker företaget automatisera en betydligt svårare del av arbetet med hjälp av AI: att förstå vad signalerna på bilens CAN-buss faktiskt betyder.

– I prototypen har vi byggt en CAN-kompressor där data går från bilen via XBB Dongle till vår backend. Där kan AI-systemet analysera fordonsdatan med hjälp av våra egna skillsfiler och även köra Python-skript mot CAN-datan i en isolerad sandlåda, berättar Karl-Henrik Söderqvist på XBB.

AI-SYSTEMET KAN KÄNNA IGEN mönster i trafiken och exempelvis dra slutsatsen att fordonet sannolikt är en Mercedes Sprinter. Därefter kan det kontrollera XBB:s befintliga databas för att se vilka signaler som redan är kända för modellen.

– Om exempelvis helljussignalen redan är känd kan användaren direkt få den föreslagen och samtidigt se signalen förändras i realtid i telefonen. Med ett knapptryck kan den sedan läggas till i användarens eget recept.

Om signalen inte redan finns kan AI:n i stället hjälpa till att leta efter den i den inspelade CAN-trafiken.

Det kan förändra ett arbete som i dag till stor del görs manuellt.

– I dag behöver vi ofta ha bilen fysiskt hos oss. Vi ansluter utrustning, loggar CAN-trafiken och analyserar manuellt vilka meddelanden och bitar som motsvarar de funktioner vi söker.

MED DET NYA SYSTEMET kan en installatör i stället samla in CAN-datan ute vid bilen och skicka upp den via XBB Dongle för analys.

Samtidigt vill XBB undvika att en signal automatiskt betraktas som korrekt bara för att AI:n har hittat den en gång.

– Signalerna får därför en form av förtroendegrad baserad på hur många oberoende installationer som har hittat och verifierat samma funktion. En ny signal kan till exempel behöva verifieras av fem eller tio olika användare eller installationer innan den betraktas som en etablerad signal för den fordonsmodellen.

Systemet normaliserar också benämningarna. ”Helljus”, ”extraljussignal” och till och med en felstavad variant ska inte bli tre olika funktioner i databasen utan kopplas till samma begrepp, exempelvis HIGHBEAM.

– På det sättet byggs det successivt upp en strukturerad databas med fordonsmodeller, CAN-ID:n, signaler och deras betydelse. För varje ny bil och varje ny verifiering blir systemet lite bättre.

NÄSTA STEG ÄR att låta användaren beskriva den önskade funktionen med vanligt språk.

– Det kan vara väldigt enkelt: ”Tänd arbetsbelysningen när jag lägger i backen.”

Men Söderqvist säger att de mer avancerade specialfallen egentligen är den viktigaste orsaken till att systemet utvecklas.

En användare skulle exempelvis kunna skriva: ”En utgång ska vara aktiv när bilen kör under 10 km/h och höger sidoruta är nedvevad minst 80 procent.”

– Då behöver systemet identifiera vilka signaler som representerar hastighet och fönsterposition, kontrollera hur de är kodade i just den bilen och därefter generera logiken som kombinerar villkoren.

RECEPTEN SKRIVS i XBB:s eget programmeringsspråk TSharkRex, vars syntax påminner om IEC 61131-3 Structured Text. AI-systemet kan dessutom göra mer än att bara skriva ett kodstycke.

– Användaren kan exempelvis be den att lägga till en signal i ett recept, koppla en viss signal till en utgång eller skapa kontroller i appen, och systemet kan utföra dessa förändringar åt användaren.

Ett exempel är att be systemet skapa tre knappar i appen för arbetsbelysning, höger och vänster sida och samtidigt ange att all belysning ska släckas när tändningen stängs av.

Om det kräver ett modifierat recept kan AI-systemet skapa en kopia av XBB:s officiella recept på användarens konto, lägga till den nya logiken och installera det som ett användarspecifikt recept.

– Det är alltså mer likt att arbeta tillsammans med en programmerare som dessutom känner till bilen och XBB-systemet än en vanlig chatbot som bara skriver ett kodstycke i ett textfönster.

SJÄLVA AI-ANALYSEN sker i prototypen i XBB:s backend. När receptet väl är skapat behövs däremot ingen språkmodell för att bilen ska utföra funktionen.

– AI:n kör alltså inte kontinuerligt i bilen. När receptet väl är skapat körs den deterministiska logiken lokalt i XBB-systemet.

Dagens XBB Dongle bygger på Nordic Semiconductors nRF52832. Telefonen används bland annat som användargränssnitt, för konfiguration och för att visa signaldata.

– När installationen väl är färdig behöver bilen alltså inte stå uppkopplad mot en språkmodell för att exempelvis extraljuset ska fungera. Den färdiga logiken körs lokalt.

Prototypen använder i dag kommersiella språkmodeller, bland annat från Anthropic, tillsammans med XBB:s egna verktyg och skillsfiler. Företaget har även testat modeller som körs lokalt.

SÄKERHETEN TAR MEST TID. Tekniskt har projektet kommit långt. Den svårare frågan är vad AI-genererad logik ska få göra i ett fordon.

– Det här är faktiskt den del som tar mest tid för oss just nu. Den tekniska principen är att AI:n inte ska vara den komponent som garanterar säkerheten. Man måste utgå från att en språkmodell kan göra fel.

AI:n får därför bara arbeta genom begränsade verktyg och exekveringsmiljöer. Genererad kod får inte godtycklig åtkomst till processorns minne eller övrig firmware.

XBB-systemet används huvudsakligen för att läsa information från bilens CAN-nät och därefter styra extern utrustning. Men den tekniska möjligheten att sända CAN-meddelanden finns också.

– Därför arbetar vi mycket med vilka funktioner som ska exponeras, hur genererade recept ska begränsas och hur användaren ska informeras och verifiera funktionerna innan de används.

Det är också en viktig anledning till att den första målgruppen sannolikt blir professionella fordonsutrustare, installatörer och XBB:s återförsäljare snarare än vanliga bilägare.

– Vi har en fungerande prototyp i dag och kan redan göra mycket av det som beskrivs. Rent tekniskt är vi ganska långt framme. Det som återstår innan vi betraktar det som en produkt är framför allt att få rätt säkerhetsmodell, compliance, dokumentation, användaransvar och valideringsprocesser på plats.

Artikeln publiserades i Elektroniktidningen 7/2026. Den kan du läsa här.