AI inom inbyggda system idag innebär nästan alltid att man använder maskininlärning, ofta förkortat ML (se faktaruta). Maskininlärning innebär att man först tränar en modell på något, till exempel att känna igen människor, och sedan använder den modellen i en tillämpning, till exempel ett kamerasystem som räknar människor som passerar.

I princip skulle man kunna bygga ett sådant AI-system som ett traditionellt IoT-system, till exempel en uppkopplad kamera, som sedan kommunicerar med en molntjänst, där intelligensen ligger. Men av olika skäl (se nedan) vill man ofta lägga in mer av intelligensen i själva IoT-systemet. Man pratar då om Edge AI eller Tiny ML (”Tiny machine learning”).

Joakim Eriksson, som är chef för uppkopplad intelligens på forskningsinstitutet Rise (RISE), nämner tre områden som kan vara utmaningar när det gäller maskininlärning inom inbyggda system: batteritid, omogna verktygskedjor och juridiska aspekter.

Batteritid sätter begränsningar

Det första är att många inbyggda system går på batteri. Det ger kraftiga begränsningar av hur mycket beräkningskraft man kan lägga i enheten.

– Har man ett inbyggt system som ska ha en batterilivslängd på 10 år, så kan man i praktiken inte ha någon inlärning i det, säger Joakim Eriksson.

Omogna verktygskedjor

Den andra utmaningen är de verktyg man använder. Det vanligaste programmeringsspråket för att bygga maskininlärningsmodeller är Python, och det finns en stor mängd programbibliotek för maskininlärning för Python. Men eftersom Python är ett dynamiskt språk är det inte särskilt snabbt och kräver väsentligt mer minne än till exempel ett program skrivet i C eller Rust. Även i system som har lite mer prestanda måste man använda nedbantade versioner av standardprogramvara.

Ett exempel på det är Micropython, som är en bantad version av Python som passar för olika microcontrollers. Flera ML-bibliotek för Python har porterats till Micropython, men dessa verktygskedjor är betydligt mer omogna än för serverdatorer. Ett alternativ då är att istället utveckla systemet på en skrivbordsdator i Python, och sedan omvandla det till C-kod. Men även detta kan vara svårt.

Samma sak gäller hårdvara. För serverdatorer dominerar Intelarkitekturen för cpuer och Nvidia har en liknande ställning för de grafiska processorer, gpuer, som oftast används för att träna ML-modeller. Det gör att de som skriver verktyg vet vilken typ av hårdvara systemen oftast kommer att köra på. Men för mindre system är det mycket mer öppet. För gpuer och andra AI-acceleratorer finns det inte någon dominant aktör för mindre system. Detta leder till att man har fler val, men även att programvarustödet för hårdvaran kan vara en utmaning.

Juridiska aspekter

Den tredje utmaningen Joakim Eriksson tar upp är den juridiska.

GDPR begränsar hur man får hantera persondata. Men det är inte bara uppenbara saker, som namn eller porträttbild, som räknas som persondata. Allt som skulle kunna användas för att unikt identifiera en person räknas som persondata, till exempel gångstil (om man spelar in video), eller MAC-adressen för en mobiltelefon. Och även om en enskild datapunkt i sig inte är tillräcklig för att identifiera en person, så kan en kombination av flera till synes oskyldiga datapunkter tillsammans utgöra persondata.

Så bygger man en tillämpning för att räkna människor kan man behöva byta ut videokameran mot en en lågupplöst värmekamera, som gör att man bara kan se att det finns en människa i bild, men inte vem det är.

En annan metod är att göra så mycket som möjligt av beräkningarna i noden, så att man inte behöver skicka upp känsliga data för lagring i servern. Det ställer givetvis högre krav på hårdvaran.

En annan juridisk utmaning är vem som har rättigheterna till insamlade data.

– Tänk dig att man utvecklat en enhet som kan se att skruvar är tillräckligt åtdragna och att man gjort det genom att samla in data från en Volvofabrik. Får man då sälja den utrustningen till Scania?

Ett praktiskt exempel

Christer Norström är entreprenör och tidigare VD för forskningsinstitutet Sics (SICS) och har erfarenhet från flera IoT-projekt där man använder AI. Det första var en digital skidcoachingtilllämpning, Racefox, som mäter rörelsemönstret för skidåkare och löpare.

Rent konkret mäter systemet de viktigaste rörelserna hos en skidåkare, till exempel stakning, och ger återkoppling på hur väl rörelsen utförs och hur den kan förbättras. Modellen är byggd genom att mäta rörelsemönstret hos åkare på olika nivåer.

När systemet körs görs en dataanalys och filtrering, för att identifiera olika rörelsemönster och specifika nyckeltal. Detta används sedan i ett beslutsträd, där man digitaliserat best practise från biomekanik och träningslära för att kunna ge personligt anpassade råd.

– Datamängderna är i det här fallet ganska små, cirka 1,2 kbyte data per sekund, vilket gjorde det enklare att bygga modellen. Nyckeln till det var att vi visste vad vi letade efter och kunde filtrera ut precis den data som var intressant. Att ha bra data är ofta bättre än att ha mycket data, säger Christer Norström.

Efter att man byggt en tillämpning för skidåkare utökade man modellen till löpare också, vilket fungerade väl.

– Vi provade också att testa systemet på hockeyspelare, men det fungerade inte alls lika bra. Medan löpning och längdskidåkning är cykliska rörelser, är hockey mycket mer ryckigt och oförutsägbart, vilket gjorde att det var mycket svårare att veta vilka mönster man skulle leta efter, säger Christer Norström.

– När vi hittade ett avvikande beteende, till exempel en elitåkare med ett annat mönster än det vi hittat tidigare, fick vi uppdatera modellen i labbet och sedan uppdatera appen. Det skulle vara smidigt om systemet själv kunde göra det.

Färdiga ramverk

Artikeln är tidigare publicerad i magasinet Elektroniktidningen. Prenumerera kostnadsfritt!

När Racefox byggde sitt system fanns det inte så mycket färdiga system att utgå från och systemet var begränsat. Startar man ett projekt idag finns det betydligt fler färdiga ramverk att utgå från. Samtidigt har systemen blivit större och AI-tekniken har utvecklats. Det gör att den programvarustack man behöver för att bygga ett komplett system är betydligt större. Ett bolag som satsat på att göra detta lättare är svenska Imagimob i Stockholm.

– Vårt mål är att vem som helst, även sådana som inte har specialkunskap inom AI, inom 3 till 6 månader ska kunna ha en fungerande AI-lösning som går att sätta i en produkt, säger Åke Wernelind, som är affärsutvecklingschef på bolaget.

För att det ska vara möjligt har man gjort ett antal färdiga tillämpningar som man kan utgå från. Det gör att AI-delen kostnadsmässigt ofta är en mindre del av ett färdigt system.

– Typiska tillämpningar som vår plattform används för är förebyggande underhåll inom industrin, till exempel att känna igen missljud från en maskin som visar att något håller på att gå sönder, eller att känna igen rörelser som visar att någon har ramlat. Sådana tillämpningar kräver inte så mycket hårdvara, utan kan göras med en mikrokontroller som kostar mellan 1 och 10 dollar.

En utmaning som Åke Wernelind tar upp vad gäller industriella tillämpningar är tillgång till data.

– Ingen tycker att det är kul att samla in data. Gör man en tillämpning som analyserar bilder finns det massor av bildmaterial på internet att tillgå. Men du hittar knappast en massa exempeldata på vibrationer från en industriell maskin på internet. Så det måste man samla in själv, säger Åke Wernelind.

Precis som Christer Norström talar Åke Wernelind om att många gärna vill bygga in ”on device learning”, det vill säga att systemet kan förbättra sin modell själv.

– Men det är fortfarande få system som verkligen gör det idag, säger Åke Wernelind. Istället gör man förbättringarna batchvis i labbet. Eller, om systemet är uppkopplat mot internet, så kan man göra det genom en molntjänst.