Predictive maintenance Del 2

Digital Signal Processing (DSP), feature extraction kalla det vad du vill, men en strömmad signal är inget vi kan använda rakt av som den är.

Låt mig försöka förklara, men innan jag går vidare så vill jag bara vara tydlig med att jag är 100% självlärd och ingen har heller någonsin kommenterat mina kunskaper så antiken är det jag skriver helt fel eller ganska nära sanningen. Nåväl det här är min historia låt oss fortsätta.

I vårat projekt har vi en accelerometer som ger ifrån sig en eller flera digitala strömmar. I detta fall ett flyttal som representerar negativ eller positiv g-kraft (eller liknande) som sensorn utsätt för. Talet läses av drygt 4000ggr per sekund och formar en signal. Tänk dig att sensorn sitter på en symaskinsnål då skulle signalen nästan likna en sinuskurva.

Problemet är att jag vill kunna ta ett prov/sampel skicka till en ML modell och få tillbaka ett svar. Min modell skulle kunna vara flera olika sensorvärden vid den givna tidpunkten men nu vill jag istället bara använda mig av en sensor. Stoppar jag tiden och ta ut det aktuella värdet skulle det kunna se ut såhär.

Detta säger ingenting och kommer inte heller hjälpa varken mig eller en dator att förstå något om signalen. Jag måste alltså kolla på signalen över tid, jag skulle kunna göra det genom att skicka de 10 senaste värdena.

Men om jag bara skiftar inläsningen med ett steg så blir tabellen helt annorlunda, jag skulle kunna göra som jag gjorde I ett annat projekt där jag försökte hitta en start-bit och hela tiden utgå ifrån denna punkt. I det projektet analyserade jag en människas puls och signalen var mycket förutsägbar. Nu vet jag inte alls hur signalen ser ut och kan därför inte göra på detta sätt. Eller I alla fall inte lika kontrollerat, (kom ihåg även sånt som ser värdelöst ut kan vara användbart I en ML modell så varför inte använda båda). I fallet med pulsen tog jag ut Max och Min amplitud I varje hjärtslag samt tiden från max till min, min till max och tillbaka i den andra kammaren (eller vad som gör den lilla taggen I pulsen). Detta visade sig vara mycket effektivt och data modellen blev då tex.

Men denna gång så har jag bestämt mig för att använda FFT (Fast Fourier transform). Teorin är att alla signaler kan skapas av att addera flera perfekta sinus kurvor I olika frekvenser. På samma sätt kan vi bryta ner en signal till vilka frekvenser dom består av. Man pratar om signalen som time-domain och det transformera resultatet som Frequency domain.

Det skulle ge en sinus på 50hz och 10amplitud en spik på 50e kolumnen. Eller en kombinerad signal som ovan skulle kunna se ut som följande. (fastna inte på siffrorna i tabellerna eller graferna dom är helt fiktiva och har inget med nått att göra).

Detta är något vi kan jobba vidare med. Nu när vi är nere på en frekvens domän som också kräver ett sample över tid så har vi redan data över tid I en rad, med flera features.

Men vi kan göra mer! Vi kan aggregera dessa samples över tid.

Max över tid, snitt över tid, ackumulerat absolut värde över tid osv. Sky is the limit 🙂

Vi kan också minska antalet features till frekvensgrupper 0-10Hz 11-50Hz osv detta kan minska data kvalitén men och öka prestanda I form av träningstid, överföringshastighet mm. Det är en balans vi måste hitta.

Att komma ihåg här är att jag fick en 2D bil att ta kurvor själv med bara ett 20 tal features och kunde klassificera en pulsrytm typ 3 olika personer med 7 features.

Andra features som vi skulle kunna extrahera är majoritets- och minoritetsfrekvenser.

Eftersom motorn snurrar i ca 6500rpm så borde vi få en likande frekvens rent naturligt. Tyvärr vet jag inte om sensorn är snabb nog att läsa va en så hög frekvens, dock skulle vi kunna läsa av varvtalet med en halleffekt sensor eller likande. Nåväl vi börjar såhär och skulle jag missat något, skriv i så fall en kommentar här på bloggen.

Men nu när vi har lite mer kött på benen, vart ska vi då göra all beräkning? Jag har faktiskt redan börjat göra den direkt på klienten (maskinen), dock anser jag att detta är fel och kommer med högsta sannolikhet bryta ut det till en Azure tjänst eller klass bibliotek som kan användas i stream analytics eller liknande tjänst. Givetvis finns det en god orsak. Om data transformeras innan den lämnar enheten är rådata förbrukad ifall den inte lagras dubbelt. Detta skulle betyda att vi kan behöva göra om mycket träning ifall vi väljer att processa signalen på annat vis.

Tanken är att flytta all logik till Azure för att sedan docker-paketera den och lyfta hem den till hårdvaran när allt är klart (IoT edge). Men om vi någonsin kommer dit vet jag inte.