Det finns IoT-lösningar för snart sagt varje segment, industriell IoT, medicinsk IoT och så vidare. I den här artikeln ska vi fokusera på det som på engelska kallas Massive IoT, något jag benämner storskalig IoT. Storskalig IoT utgörs av exempelvis sensorer som genererar data i stor mängd, data som kan ge insikter, data som kan vara grunden för beslut och data vi kan använda för att förändra beteenden.

Smarta sensorer
När webbsidan iot-analytics.com analyserade trender för 2023 var deras topp-trend smarta sensorer. Jag tycker att det är ett rimligt val. Det finns mycket att tjäna på smarta sensorer. Att överföra data via ett trådlöst nät kostar mer än att processa informationen lokalt. Kostnaderna för att överföra data kan vara skilda, alla kostnader är inte direkt monetära, som ökade abonnemangskostnader och ökad kostnad för lagring av mätpunkter i en molntjänst eller på en server. Nej kostnaderna kan även bestå i ökad strömförbrukning i sensorn med förkortad batterilivslängd och potentiellt tätare batteribyten som följd.

Strömförbrukningsförväntningar
Energiåtgången är viktig i applikationer med sensorer. I dessa situationer måste du normalt garantera att din enhet kommer att klara i 10+ år på ett batteri. Energiförbrukningen är storskalig IoT:s heliga gral. Det är en enkelt förklarad produktfördel – ”vår enhet klarar 10 år på ett batteri”. Ingen kommer att ifrågasätta om det behövs eller om det är realistiskt. Men det är IoT-måttstocken, som skapat en förväntning, en förväntning varje lösning måste jämföras med. Så hur når man dit? Min erfarenhet är att en del av batteritiden kan påverkas av smart filtrering av data i enheten, genom smart lagring av data lokalt och genom att inte ladda upp i realtid. Detta harmoniserar mycket med trenden på marknaden.

Trestegsmodell
Jag har själv varit med om att designa logiken i en IoT-sensor vi utvecklat (AKKR8) där en ganska enkel men nödvändig logik på sensornivå är designad från vetskapen att uppkoppling kostar, bättre att adressera problemet långt ut i nätet. Vår modell bygger på att filtrera data och då ta ställning till om vi skall förkasta mätvärdet, lagra mätvärdet eller ladda upp mätvärdet direkt. Förenklat kan det se ut så här.

Vi monterar en sensor för övervakning av temperatur i ett konferensrum. Alla är inte betjänta av femminuters mätvärdesuppdateringar av 20,4 °C från ett konferensrum. Men den installerade sensorn kommer att vakna upp och läsa av temperaturen. Säg att mätvärdesfönstret för normala värden är 20–21 grader, då kommer sensorn att spara detta värde i minnet första gången. Andra gången den vaknar och mäter, det är då 20,6 °C, då kommer den att spara 20,6 i minnet och kasta bort 20,4. Är följande temperaturmätningar inom intervallet 20–21 grader under en längre tid kommer dessa mätvärden att kastas, och intermittent laddas något värde upp men endast ett värde per ett längre tidsfönster. Vaknar sensorn upp och läser av 18 grader, ja då vill vi att den skickar detta värde vidare direkt för att uppmärksamma oss på att vi är utanför toleransen. I det läget kan vi gå in i ett larmläge där vi jobbar med tätare loggningar, som lagras lokalt, och skickas upp med tätare frekvens. Så med enkla mjukvarufunktioner så kan vi effektivt spara strömförbrukning vid överföring, utrymme för lagring lokalt, och minska lagring av onödiga mätvärden i molnet.

Sämre täckning, sämre batterilivslängd

Vi vet att ju sämre täckning en sensor har, oavsett om det är LoRaWAN eller 4G/5G så kommer batterilivslängden att påverkas. Den kan förkortas med en faktor fyra vid sämre förhållanden. Genom att med jämna mellanrum låta sensorn avgöra uppkopplingens signalstyrka och rapportera den, kan vi låta vår centrala data-analysplattform räkna ut en sweet-spot för hur ofta vi kan låta sensorn skicka mätvärden baserat på den ­aktuella signalstyrkan.

Så hur kan vi ändra och alternera inställningarna i sensorn? Jo vi låter den återläsa sådana uppdateringar när den ändå är uppkopplad mot och har skickat data. Säg att du använder dataprotokollet MQTT. Då kan du med hjälp av så kallade MQTT-callbacks låta din sensor återläsa uppdateringar om något i konfigurationen skall ändras. Vi har själva byggt så att vi kan aktivera och deaktivera funktioner på distans med callbacks. Det kan handla om att läsa mätvärden från ytterligare sensorer, styra frekvensen för mätvärdesuppdatering och så vidare. På så sätt kan vi enkelt anpassa funktion, utan att uppdatera den fasta mjukvaran på distans. Vi kan med hjälp av standardprotokoll på ett enkelt sätt påverka sensorernas egenskaper med vetskapen att uppkoppling kostar, så det handlar om att anpassa sig till situationen. MQTT är en ganska rudimentär väg att lösa detta på, det finns mer strömsnåla protokoll eller avancerade sätt att lösa det på.

Framtidens sensorer kommer sannolikt att kunna anpassa sig till miljön den ansluts till. Låt oss anta att en maskin får en sensor ansluten, en sensor som skall övervaka en elmotor avseende temperatur och vibrationer. Framtidens sensor lär sig hur maskinen beter sig och vad som inte är normalt och kan då själv sätta larmgränser för uppdatering av avvikelser. Den här typen av smarta sensorer är snart runt hörnet, men under tiden jobbar vi med det vi kan göra för att spara batteri, pengar och miljö