PROSJEKT
Del artikkel
Skrevet av: Sondre Ninive Andersen (Development Engineer)
PROSJEKT
Del artikkel
Skrevet av: Sondre Ninive Andersen (Development Engineer)
Elektronikk blir mer og mer innvevd i miljøet rundt oss, og det er i dag mulig å bruke sensorenheter til å overvåke nesten hva som helst. Sensorer, prosessorer, og radioer med eksepsjonelt lavt energiforbruk gjør det mulig for sensorsystemer drevet av et lite batteri, eventuelt hjulpet av energihøsting, å oppnå nesten ubegrenset levetid. Denne overfloden av tilgjengelige komponenter, ikke bare radioer og prosessorer, men også sensorer, batterier, og løsninger for energihøsting, skaper imidlertid en utfordring når det kommer til å sette sammen et system. Denne artikkelen tar for seg en simulerings-basert metode, og presenterer noen fordeler den kan ha. Artikkelen er basert på en forskningsartikkel fra IEEE ICIT 2022 konferansen.
Når et IoT-system blir designet er et av de første stegene å bestemme hvilke komponenter som skal brukes. Et typisk IoT-system består av en prosessor, en sensor, en løsning for trådløs kommunikasjon, en energibuffer, og muligens en form for energihøsting. Systemets hensikt vil bestemme kravene til disse komponentene, men ikke nødvendigvis på en enkel måte.
Spørsmålet er da hva som er beste måten for å velge komponenter. En typisk prosess starter kanskje med design-målene, som for eksempel «enheten må ha en levetid på seks måneder, og må fange opp minimum 80% av interessante hendelser». Med dette som utgangspunkt, og kanskje etter det er bestemt at et solcellepanel vil være den mest gunstige energihøstingsmetoden, kan man fortsette med å vurdere hvor mye energi som trengs for å ta målinger, on-board prosessering av disse, og transmisjon. Deretter kan man gjøre en kvalifisert gjetning på hvor ofte hendelser skjer.
Til sammen vil dette kunne gi et energikrav, som man så må dekke ved å velge et stort nok solcellepanel. Til slutt må det en energibuffer til, for å holde systemet forsynt med energi igjennom natten. Siden denne metoden er basert på gjennomsnitt og tilnærminger, blir det nødvendig med store sikkerhetsmarginer for å kunne stole på at spesifikasjonene blir møtt.
Hovedproblemet med tilnærmingen over er at den kun baserer seg på gjennomsnittlige verdier, og ignorerer all minutt-til-minutt transient oppførsel når det gjelder tilgjengeligheten av både energi og data. Dette medfører en risiko for kraftig over-dimensjonering av komponenter når man prøver å gi systemet nok margin til at de gjennomsnittlige verdiene blir gyldige.
Hvis man i stedet lager en virtuell modell av systemet, blir det mulig å kjøre parameteriserte simuleringer, som betyr at hundrevis av kombinasjoner av komponenter i forskjellige størrelser kan evalueres. Dette kan både gi detaljert innsikt i hvordan systemet vil operere, og gi et mye bedre datagrunnlag for å velge og dimensjonere komponenter.
Det første steget i denne prosessen er å definere en konkret modell av systemet. Denne kan være ganske enkel, men må fange opp nok detaljer til at de relevante komponentene kan modelleres. Modellen må inkludere både IoT-systemet, og miljøet det skal operere i, inkludert en modell av energihøstingspotensialet, og fenomenet som skal måles.
Sammen med denne modellen må det defineres metrikker som kan brukes til å evaluere operasjonen. Dette kan være interne ting, som for eksempel andelen tid systemet står uten noe tilgjengelig energi, eller ting relatert til målingene, som for eksempel den gjennomsnittlige kvaliteten på dataene. Hvis sensoren måler hendelser etter hvert som de skjer kan en interessant metrikk være andelen av hendelser som blir målt og sendt.
Når modellen er definert kan et simuleringsrammeverk implementeres, og simuleringer kan kjøres. Dette kan være enkeltsimuleringer som evaluerer operasjonen til én enkelt konfigurasjon, eller det kan være batch-simuleringer som sammenligner en mengde konfigurasjoner, eller som tester mange verdier av en eller flere parametere.
Hvis man kjører en batch-simulering hvor to parametere blir justert over et område med verdier, kan hver av de definerte metrikkene plottes på et 2D-plot. Disse plottene kan da gi innsikt inn i forskjellige operasjonsmodi, og avveininger som kanskje eksisterer i konfigurasjonsrommet.
Flere detaljer om dette eksempelet finnes i den akademiske artikkelen fra IEEE ICIT 2022 konferansen.
Som et eksempel, skal vi ta for oss et IoT-system som skal overvåke vibrasjoner i en bru, med hensikt å oppdage endringer i strukturen over tid. Sensoren vil være solcelledrevet, og skal bruke et akselerometer til å måle nedringningen som skjer etter et kjøretøy har passert og eksitert strukturen. Dette betyr at muligheter for måling kommer som hendelser. For å spare på energi forbundet med den trådløse kommunikasjonen vil sensoren prosessere målingene lokalt, og vi antar at kvaliteten på målingene kan estimeres både før og, mer nøyaktig, etter denne prosesseringen (for eksempel ved å vurdere mengden støy på målingen). Dette gir følgende data-pipeline:
Det er mange mulige parametere å justere i denne modellen, inklusive størrelsen på solcellepanelet, størrelsen på energibufferen, energikravene til sensoren, prosesseringen, og transmisjonen (ES, EP, og ET respektivt i figuren), og mye mer. I dette tilfellet skal vi imidlertid fokusere på algoritmen som styrer energiforbruket.
Energistyringsalgoritmen vi skal se på fungerer på følgende måte: Den vil alltid måle hendelsene som skjer (forutsatt at sensoren har nok energi til dette), og lagrer hendelser i en prioritert kø som har en kapasitet på maks n hendelser. Når systemet har tilstrekkelig med energi vil algoritmen velge den høyest evaluerte hendelsen, og prosessere og sende denne. I tillegg blir hendelser forkastet hvis de på noe tidspunkt blir vurdert til å ha en verdi lavere enn en grense, θ.
Til slutt skal vi definere tre metrikker for å evaluere systemet. Den første er andelen av hendelser som blir prosessert og sendt ut av sensornoden (fT), den andre er den gjennomsnittlige tiden som løper fra en hendelse skjer, til den blir sendt (τ̄), og den siste er den gjennomsnittlige kvaliteten av sendte hendelser (v̄).
Når de tre metrikkene og de to parameterne er definert kan vi implementere og simulere systemet, og plotte metrikkene på 2D-plots. Disse plottene viser mye interessant informasjon om hvordan systemet oppfører seg, og kan brukes som en rettesnor når systemet skal designes.
I disse plottene representerer hvert punkt en individuell simulering. Den vertikale aksen viser kapasiteten på køen, og den horisontale aksen viser grenseverdien for kvalitet. Fargeskalaen viser verdien av hver av metrikkene. Plottene er delt inn i tre regioner, A, B, og C, hvor systemet oppfører seg på kvalitativt forskjellige måter.
I region A ser vi at både andelen hendelser som sendes og deres gjennomsnittlige kvalitet er rimelig konstante. Samtidig ser vi at den gjennomsnittlige tidsforsinkelsen øker med økende kø-kapasitet, og synker med økende kvalitetsgrense.
Hvis kø-kapasiteten senkes for mye, går vi imidlertid over i region B. Her begynner den gjennomsnittlige kvaliteten å svekkes, siden køen blir for liten til å prioritere de mest verdifulle hendelsene på en tilstrekkelig måte. Vi kan se at dette er en avveining mellom kvaliteten og tidsforsinkelsen på hendelsene, som styres av kapasiteten på køen. Andelen hendelser som sendes forblir imidlertid noenlunde konstant.
Den siste regionen, region C, defineres av en kvalitativt annerledes operasjonsmodus. Her har grenseverdien blitt justert høyt nok til at den tilgjengelige energien er tilstrekkelig til å fullt håndtere alle hendelser med høy nok kvalitet. I dette regimet har alle hendelser null tidsforsinkelse, og gjennomsnittlig kvalitet og andelen hendelser som sendes er kun bestemt av verdien grenseverdien, θ, settes til.
Ved å benytte disse plottene, og holde i bakhodet at hverken simuleringen eller parameterne vi brukte er perfekte, kan vi for eksempel beslutte at en grenseverdi på θ=0.3 og en kø-størrelse på n=5 kanskje er gode valg for disse parameterne. Denne posisjonen gir fornuftige verdier for alle metrikkene, men ligger langt nok unna de bratteste gradientene til at små feil i modelleringen vår ikke vil gi massivt annerledes ytelse.
Det er åpenbart en kostnad forbundet med denne tilnærmingen, ettersom både en modell av systemet, og en simulering må utarbeides. I tillegg krever metoden en viss innsikt i både systemarkitekturen og miljøet systemet skal operere i.
Likevel er det potensielle fordeler. Simuleringene kan gi en dypere innsikt i systemets operasjon, som gjør det mulig å hente ut interessante statistikker. Spørsmål som ville vært vanskelige å besvare med statisk analyse, som for eksempel «Hvor stor sannsynlighet er det for at systemet vil kunne fange opp en hendelse som skjer kl. 02:00 på natten», kan enkelt besvares gjennom statistisk analyse av simuleringsdata.
Dette gir systemutvikleren en mulighet til å redusere marginene i valg av komponenter, og gjør det mulig å justere inn styringsalgoritmen før systemet plasseres ut i felten. Dette kan da ikke bare redusere kostnadene forbundet med produksjon og operasjon av systemet, men også øke tiltroen til at systemet vil fungere som forventet.
R&D Manager