Luarea deciziilor la marginea infrastructurii utilizând senzori AI – Partea a 2a

Luarea deciziilor la marginea infrastructurii utilizând senzori AI

Există numeroase abordări prin care se poate adăuga mai multă inteligență sistemelor industriale, inclusiv inteligența artificială (AI) la margine (edge) și în cloud, combinată cu senzori cu componente analogice și digitale. Având în vedere diversitatea abordărilor AI, proiectantul de senzori trebuie să ia în considerare o serie de cerințe concurente, inclusiv latența pentru luarea deciziilor, utilizarea rețelei, consumul de energie/durata de viață a bateriei și adaptarea modelului AI pentru mașini. Articolul anterior s-a axat pe descrierea generală și proiectarea hardware a Voyager4: un senzor wireless de monitorizare a stării, bazat pe AI. Acest articol se concentrează pe arhitectura software și pe algoritmul AI creat pentru un senzor edge inteligent. Este prezentată o abordare completă la nivel de sistem pentru dezvoltarea modelului AI pe Voyager4.

Proiectarea software a unui senzor de monitorizare a stării

Voyager4 este o platformă wireless de monitorizare a stării motoarelor dezvoltată de Analog Devices pentru a permite proiectanților să implementeze și să testeze rapid o soluție wireless la o mașină sau la o instalație de testare. Soluțiile de monitorizare a stării motoarelor, cum ar fi Voyager4, sunt utilizate în întreaga industrie, în domenii precum robotica și mașinile rotative, de exemplu turbinele, ventilatoarele, pompele și motoarele.

Dezvoltarea software-ului pentru un astfel de dispozitiv edge wireless poate fi dificilă. Încă de la începutul proiectării senzorului, dezvoltatorul trebuie să ia în considerare arhitectura generală a sistemului, ținând cont de modul în care vor funcționa părțile individuale ale sistemului, de modul în care diferitele componente vor fi integrate pentru a funcționa împreună și de modul în care pot fi aplicați și implementați algoritmi și instrumente de analiză utile, cum ar fi rețelele neurale, pentru a adăuga inteligență la margine.

Obiectivul oricărui astfel de proiect este de a crea un software pentru dispozitivul terminal și pentru gazda conectată, care să fie ușor de înțeles, modificabil și actualizabil. În cadrul Voyager4 există două microcontrolere și multe dispozitive periferice, inclusiv senzori, plăci de gestionare a energiei, memorie flash și interfețe de comunicație. Dezvoltarea codului necesar pentru a controla și combina fiecare dintre aceste elemente este o sarcină dificilă.

Scopul acestui articol este ca, prin prezentarea procesului de proiectare utilizat în timpul dezvoltării Voyager4, prin evidențierea etapelor parcurse și prin unele exemple specifice de implementare, cititorul să poată înțelege mai bine cum să-și dezvolte propriul senzor edge.

Prezentare generală

Figura 1: Modurile de operare ale Voyager4. (Sursa imaginii: ADI)

Chiar dacă începem cu o scurtă recapitulare a operării dispozitivului Voyager, consultați partea 1 a articolului pentru mai multe informații referitoare la senzorii de monitorizare a stării și despre caracteristicile hardware, energetice și de securitate ale proiectului Voyager4.

Principiul de funcționare a senzorului pentru Voyager4 este prezentat în figura 1. Accelerometrul triaxial ADXL382 cu sistem microelectromecanic (MEMS) digital de 8 kHz este utilizat pentru colectarea datelor privind vibrațiile. În funcție de modul de operare, datele colectate pot urma diferite căi.

Calea A este parcursul urmat inițial, datele brute de vibrații fiind trimise direct la procesorul BLE (Bluetooth^® low energy) MAX32666. De aici, datele pot fi trimise utilizatorului prin radio BLE sau prin USB. Calea B este un mod alternativ de operare care poate fi utilizat după ce datele brute au fost colectate cu ajutorul Voyager și după ce un model este antrenat cu ajutorul instrumentelor externe MAX78000. Datele nu sunt trimise utilizatorului, ci sunt direcționate către un algoritm AI pentru a prezice eventualele defecțiuni ale mașinii. Căile C și D acoperă cazurile de utilizare în care o defecțiune a motorului este detectată, respectiv nu este detectată. În cazul în care se detectează o defecțiune, un indicator sau o alertă a utilizatorului poate fi trimisă prin procesorul BLE către gazdă. În schimb, dacă o defecțiune nu este detectată, senzorul revine în modul de așteptare până la următorul eveniment de detectare.

Această arhitectură reprezintă elementul central pentru dezvoltarea software-ului și a algoritmului AI pentru Voyager4. Pentru o înțelegere completă la nivel de sistem a acestei arhitecturi, articolul va analiza:

• Terminologia BLE
• Implementarea perifericului BLE
• Implementarea sistemului central BLE
• Antrenarea și implementarea algoritmului AI

BLE – Prezentare generală

Atunci când se proiectează un senzor edge industrial, conectivitatea este unul dintre factorii cheie de proiectare. Aceasta afectează totul, de la autonomie și fiabilitate până la durata de viață totală și dimensiunea dispozitivului, în funcție de puterea disponibilă/necesară. După cum se observă în tabelul 1, BLE beneficiază de câteva avantaje esențiale în comparație cu alte standarde de conectivitate. Raza de acțiune, puterea și fiabilitatea BLE au fost deosebit de importante pentru cazul nostru de utilizare de monitorizare industrială. Pentru a înțelege proiectarea și dezvoltarea unui dispozitiv edge BLE, trebuie să înțelegeți mai întâi câteva aspecte ale terminologiei de bază utilizate de orice proiect BLE.

 Tabelul 1: Comparație între standardele de conectivitate wireless

O explicație completă a tot ceea ce BLE are de oferit ar umple o carte, așa că acest articol se concentrează asupra anumitor concepte cheie pe care oricine implementează un dispozitiv BLE trebuie să le ia în considerare și anume:

• Stiva software
• Model periferic/dispozitiv central
• Protocoale și profiluri

Stiva software BLE

Figura 2: Stiva BLE. (Sursa imaginii: ADI)

Stiva software BLE este o colecție de protocoale standard care trebuie să fie implementate de un dispozitiv pentru ca acesta să fie considerat compatibil BLE. Denumirea este mai ușor de înțeles în figura 2, prin ilustrarea modului în care diferitele protocoale din cadrul stivei sunt stratificate. Funcționalitățile de nivel înalt, cum ar fi comunicația cu utilizatorul și conectarea dispozitivului, sunt susținute de protocoale de nivel inferior responsabile de sarcini fundamentale, precum încapsularea și analizarea datelor.

Din fericire, cunoașterea componentelor de bază ale stivei este adesea suficientă pentru dezvoltatori, care pot alege dintr-o gamă de dispozitive hardware care au implementat propriile versiuni ale acesteia. Astfel, utilizatorul trebuie doar să dezvolte o parte a aplicației care va controla dispozitivul în sine, utilizând în același timp o stivă BLE pre-construită.

Stiva BLE este adesea structurată în trei părți distincte: aplicație, gazdă și controler. Aplicația definește interfața cu utilizatorul și codul de aplicație specific (monitorizarea vibrațiilor) pe care utilizatorul îl implementează. Gazda se referă la straturile superioare ale stivei software BLE, care controlează funcționalitatea de nivel înalt, cum ar fi profilurile și protocoalele. Controlerul se referă la straturile inferioare ale stivei BLE, care se ocupă de stratul de legătură și de stratul fizic, cum ar fi modulul radio de 2,4 GHz în sine. Pentru acest proiect, a fost ales microcontrolerul BLE MAX32666. Acesta este un microcontroler Arm® Cortex®-M4 cu consum redus de putere cu un modul radio Bluetooth 5 LE cu suport pentru rază lungă de acțiune (4×) și debit mare de date (2 Mbps).

Model periferic/dispozitiv central

Figura 3: Un model periferic/dispozitiv central 1:1. (Sursa imaginii: ADI)

Un dispozitiv BLE poate fi definit ca periferic sau centru, în funcție de rolul său. Deoarece datele pot circula în ambele direcții, una dintre cele mai mari diferențieri între cele două este modul în care se conectează. Înainte de conectare, perifericele își anunță disponibilitatea de a se conecta. Dispozitivele centrale caută perifericele disponibile la care să se conecteze și inițiază conexiunea. Datele pot circula în ambele direcții între periferice și dispozitivul central, dar dispozitivul central este considerat gazdă. Referințele BLE mai vechi se referă, de asemenea, la periferice și dispozitive centrale ca servere și, respectiv, clienți.

În sistemul nostru, platforma Voyager este dispozitivul periferic care colectează și trimite date către un centru. În acest proiect, pentru a simplifica dezvoltarea și pentru a facilita înțelegerea, accentul se pune inițial pe cazul cel mai simplu al unui singur centru care interacționează cu un singur periferic, așa cum se observă în figura 3.

Protocoale și profiluri

Protocoalele și profilurile sunt părți ale terminologiei Bluetooth ușor de confundat. Simplu spus, protocoalele sunt blocuri funcționale de bază care definesc operarea dispozitivului: încapsularea datelor, formatare, rutare etc. Profilurile sunt pachete de funcționalități care se combină pentru a permite moduri de operare de bază. În esență, este vorba de o combinație de protocoale pentru a realiza o anumită funcție generală, de exemplu, un profil de serviciu al bateriei, care poate fi utilizat pentru a interoga autonomia rămasă a bateriei unui dispozitiv. Toate dispozitivele BLE trebuie să implementeze profilurile GAP (Generic Access Profile) și GATT (Generic ATTribute Profile) pentru a le permite să se conecteze la alte dispozitive BLE. GAP acoperă funcționalitatea de nivel scăzut – advertising (transmiterea de semnale pentru a anunța prezența dispozitivului), descoperirea dispozitivelor și gestionarea conexiunilor. GATT gestionează organizarea și transferul datelor de nivel înalt între dispozitive, permițându-le acestora să citească și să scrie pe o conexiune stabilită.

Figura 4: Profil de server cu comenzi personalizate. (Sursa imaginii: ADI)

Alte profiluri sunt completări opționale pentru o funcționalitate suplimentară a unui dispozitiv, cum ar fi un profil de proximitate. Acestea includ profiluri predefinite create de Bluetooth Special Interest Group (SIG). Utilizarea unui set predefinit de profiluri poate fi utilă la dezvoltarea unui dispozitiv tipic, cum ar fi un ceas inteligent sau un contor inteligent, dar poate fi restrictivă pentru dispozitivele care implementează o mulțime de funcționalități personalizate.

Profiluri personalizate

Sunt permise și profilurile personalizate care nu sunt definite de Bluetooth SIG, oferind o flexibilitate mai mare în proiectare, cu prețul unei portabilități reduse. Fiecare profil își organizează datele în servicii, care sunt compuse din mai multe caracteristici (funcții), așa cum este ilustrat în figura 4.

Atunci când se formează o conexiune între dispozitivul central și cel periferic, dispozitivul central poate solicita profilurile și serviciile asociate perifericului respectiv. Figura 5 prezintă structura profilurilor GAP, GATT și personalizate (și a serviciilor acestora) ale Voyager atunci când sunt solicitate de dispozitivul central.

Figura 5: Structura unui profil Voyager. (Sursa imaginii: ADI)

Pentru Voyager, definim profilurile de bază GAP și GATT la care se adaugă un profil personalizat unic, utilizat ca server de comandă, în care sunt prelucrate comenzile de la centru și sunt returnate date sau este actualizată configurația perifericului însuși.

Implementarea firmware-ului

În centrul arhitecturii se află microcontrolerul BLE, care gestionează schimbul de date între senzori, dispozitive periferice și dispozitivul central BLE.

Configurarea dispozitivului

Având stiva BLE preintegrată pe MAX32666, construim aspectul perifericelor noastre completând funcțiile relevante de configurare. De exemplu, în figura 6, definim o lungime a datelor, un tip de advertising și o listă de caractere pentru matricea noastră de descoperire a datelor de scanare, apelată de funcția de configurare a perifericului de fiecare dată când Voyager este pornit.

Figura 6: Setarea datelor de scanare Voyager. (Sursa imaginii: ADI)

Un astfel de dispozitiv BLE va trebui configurat printr-un număr foarte mare de setări, printre care puterea de transmisie a stației radio și tipurile de date returnate. Este recomandabil să începeți cu toate exemplele pre-construite disponibile cu hardware-ul pe care îl utilizați și să faceți modificări personalizate de acolo. MAX32666 oferă un exemplu de cod pentru un server de date BLE (periferic) numit BLE DATS care a fost utilizat ca bază pentru proiectul Voyager. După configurare, atunci când dispozitivul central scanează pentru dispozitivele disponibile, numele perifericului apare ca Voyager. Acest lucru poate fi utilizat și pentru a filtra lista de căutare, astfel încât centrul să afișeze doar dispozitivele cu numele așteptat.

Figura 7: Afișarea numelui dispozitivului. (Sursa imaginii: ADI)

După cum se vede în figura 7, numele dispozitivului este afișat alături de adresa MAC a dispozitivului și de indicatorul de intensitate a semnalului recepționat (RSSI).

Alte setări de configurare din cadrul stivei controlează numele și comportamentele așteptate pentru alte moduri ale dispozitivului, cum ar fi ID-ul producătorului, răspunsurile la comenzile de citire/scriere etc.

Figura 8: Diagrama bloc a hardware-ului Voyager4 folosind MAX3207E, DS28C40A, ADXL382, ADG1634, MAX32666, ADXL367, MAX78000, MAX17262, MAX20335 și MAX38642. (Sursa imaginii: ADI)

Serverul de comandă

Întrucât atât partea centrală, cât și cea periferică a aplicației Voyager4 au fost proiectate în tandem, interfața periferică poate fi simplificată prin utilizarea unui profil personalizat cu un singur serviciu BLE. Acest profil va fi responsabil pentru primirea comenzilor de la dispozitivul central și returnarea răspunsurilor sub formă de date de accelerometru, date de temperatură și alte informații despre dispozitiv.

Acest serviciu personalizat unic nu respectă în totalitate practicile obișnuite de comunicație BLE într-un dispozitiv atât de complex precum Voyager, dar are câteva avantaje. Acesta permite compatibilitatea cu versiunile anterioare ale Voyager și îmbunătățește flexibilitatea comenzilor, deoarece utilizarea șirurilor de caractere ca intrare de comandă pentru perifericul Voyager permite o varietate de tipuri de comenzi și valori în funcție de modul în care datele sunt analizate.

Odată ce se stabilește o conexiune între periferic și dispozitivul central, pentru a stabili o comunicație bidirecțională, dispozitivul central va emite o comandă de notificare către funcția personalizată, după cum se observă în figura 11. Aceasta stabilește un sistem de notificare pe partea periferică și atribuie o funcție callback corespunzătoare pe partea centrală. Prin urmare, de fiecare dată când există date actualizate atribuite acelei funcții personalizate, dispozitivul central este notificat, noile date sunt transferate și se declanșează funcția callback a dispozitivului central.

Arhitectura firmware

Diagrama hardware din figura 8 evidențiază conținutul inclus în Voyager, precum și căile de date și sursele de alimentare aferente. Cea mai mare parte a dezvoltării software a avut loc pe microcontrolerul BLE, deoarece acesta operează ca centru de comandă, coordonând atât interfața BLE cu dispozitivul, cât și fluxul intern de date ale senzorilor și microcontrolerului. Pentru a interacționa cu diferiții senzori și microcontrolerele sistemului nostru, trebuie să dezvoltăm drivere de dispozitiv care să fie utilizate de microcontrolerul BLE și de microcontrolerul AI, așa cum se discută în secțiunea AI. În practică, dezvoltarea și integrarea acestor drivere reprezintă o mare parte din activitățile de programare necesare pentru un senzor edge conectat.

Figura 9: Arhitectură generică BSP-HAL. (Sursa imaginii: ADI)

Scrierea codului portabil

În timpul dezvoltării firmware-ului nostru, am împărțit codul în mai multe straturi de abstractizare, separând detaliile specifice pentru un anumit microcontroler de codul aplicației și al driverului. Este o problemă bine cunoscută și este abordată, deseori, prin separarea responsabilității codului în trei straturi distincte, pe lângă stratul aplicației. Acestea sunt HAL (hardware abstraction layer), BSP (board support package) și driver layer. Arhitectura este prezentată în figura 9.

Pentru a interacționa cu diferite echipamente hardware, HAL oferă o soluție uniformă pentru programe, fără a fi nevoie să cunoască detaliile fiecărui dispozitiv. BSP definește software-ul dependent de hardware, iar stratul de driver definește detaliile mai fine ale fiecărui dispozitiv, cum ar fi maparea regiștrilor. De exemplu, în cadrul Voyager avem două microcontrolere, MAX32666 pentru conectivitate BLE și MAX78000 cu accelerator de rețea neurală convoluțională (CNN) încorporat. Așa cum se observă în figura 10, HAL din Voyager definește comenzile de comunicație de bază care vor fi utilizate de oricare dintre microcontrolere, SPI și I2C. De exemplu, un apel SPI emis de oricare dintre driverele dispozitivului va transfera inițial responsabilitatea către funcțiile SPI din HAL, care apoi caută informațiile specifice pentru ca BSP-ul să utilizeze comanda SPI corectă pentru microcontrolerul respectiv.

Figura 10: Arhitectura HAL BSP a platformei Voyager. (Sursa imaginii: ADI)

HAL

HAL rămâne același pentru fiecare placă din sistem, dar BSP-ul se actualizează pentru fiecare microcontroler. BSP este, de asemenea, responsabil pentru definirea blocurilor de construcție generice ale sistemului, care decuplează apelurile aplicațiilor de dispozitivul specific utilizat. În figura 10, blocul MAIN_ADXL din BSP este o abstractizare a accelerometrului de bază utilizat. Comenzile comune pentru orice accelerometru, cum ar fi Initialize și Read, sunt definite în cadrul stratului BSP, în timp ce funcțiile de nivel scăzut, cum ar fi get_raw_xyz_data, sunt definite la nivelul driverului în blocul ADXL382. La portarea codului driverului de la MAX32666 la microcontrolerul MAX78000, codul accelerometrului rămâne neschimbat deoarece se referă numai la accelerometrul în sine. Singurele fișiere actualizate pentru a permite comunicația cu noul microcontroler sunt cele din cadrul stratului BSP.

Acest lucru aduce, la rândul său, beneficii clare în ceea ce privește înlocuirea sau actualizarea părților din sistem. Un exemplu real în acest sens în cadrul Voyager a fost decizia de a actualiza accelerometrul principal folosit. În acest caz, a fost actualizat doar codul din cadrul stratului de driver, simplificând întreținerea, modificarea și testarea.

Fluxul de date și dispozitivul BLE Central

Deși informațiile privind temperatura și bateria sunt puse la dispoziția aplicației BLE centrale, la cerere, rolul principal al Voyager este acela de a monitoriza starea și senzorul de vibrații. Cerințele noastre în ceea ce privește fluxul de date și frecvența cu care trebuie trimise datele se vor concentra pe senzorul de vibrații și pe o configurație tipică de monitorizare a stării, de exemplu, o măsurare scurtă o dată pe zi. BLE nu permite un flux mare de date. ADXL382 este un accelerometru cu 3 axe, cu lățime de bandă mare, care colectează 16 000 de eșantioane per axă în fiecare secundă în modul de înaltă performanță. Există câteva opțiuni disponibile pentru trimiterea datelor în funcție de componentele incluse în sistem.

Trimiterea de date în timp real

În lipsa unei forme de stocare intermediară (buffering), trimiteți datele imediat ce sunt disponibile, în momentul în care acestea sunt solicitate de centru. Deși acest mod este util ca mod demonstrativ, prezentând datele accelerometrului de înaltă performanță în timp real, bateria se consumă rapid, iar pachetele de date sunt abandonate sau corupte deoarece cantitatea de date generate depășește rata la care pot fi trimise.

Trimiterea datelor din memorie

O altă opțiune este salvarea datelor în memoria flash. În acest fel, putem înregistra datele accelerometrului în siguranță, fără teama de a suprascrie valorile anterioare. Datele salvate sunt trimise apoi direct la centru sau raportate la primirea unei comenzi de la centru. Deoarece acest sistem nu mai este în timp real (datele ar putea fi vechi de câteva minute sau chiar zile), putem utiliza și sistemul de confirmare BLE pentru pachete, asigurându-ne că datele ajung complet intacte la centru și retrimițând orice date pierdute.

Această soluție este mult mai practică pentru o configurație tipică de monitorizare a stării industriale, dar durata de viață a bateriei dispozitivului este în mare parte irosită prin trimiterea de informații privind vibrațiile care nu se schimbă prea mult de la o zi la alta.

Efectuarea analizei la margine

Figura 11: Arhitectura mixtă (dispozitiv central/periferic) a sistemului Voyager. (Sursa imaginii: ADI)

Pentru a economisi din durata de viață a bateriei, este mai bine să efectuați unele analize la marginea sistemului pentru a vă asigura că numai datele relevante sunt comunicate prin legătura radio. Desigur, acest lucru este posibil numai dacă energia necesară pentru a crea informații semnificative la margine este semnificativ mai mică decât cea necesară pentru a trimite datele prin BLE (a se vedea partea 1 a articolului, pentru informații suplimentare în acest sens).

În figura 8, se poate observa că accelerometrul are o cale directă de transmitere a datelor către ambele microcontrolere. În cazul de utilizare în care vom efectua unele analize la margine, microcontrolerul AI poate citi direct datele privind vibrațiile de la accelerometru și poate efectua o analiză cu un model AI încorporat.

Proiectarea interfeței utilizatorului pentru dispozitivul central

Deoarece perifericul BLE a fost proiectat în tandem cu perifericul Voyager, a existat o mare flexibilitate în modul în care cele două interacționau. În general, dispozitivul central trebuia să scaneze și să se conecteze la un periferic Voyager, apoi să trimită comenzi de tip string și să proceseze valorile returnate. După conexiunea inițială, toate comenzile BLE sunt trimise direct către serviciul personalizat al perifericului pentru analiză. Centrul în acest caz este o interfață grafică cu utilizatorul (GUI) pe un PC Windows, scrisă în Python și care utilizează o bibliotecă de periferice BLE (BLEak) pentru a emite comenzi BLE standard. BLEak a fost construită pe baza bibliotecii standard asyncio pentru Python, permițând comenzilor BLE să fie executate asincron, asigurându-se că interfața cu utilizatorul rămâne interactivă și nu îngheață.

Atunci când interfața grafică se conectează cu succes la un periferic, este emisă automat o comandă de notificare către o caracteristică personalizată a Voyager, după cum se arată în figura 11. Acest lucru asigură că orice actualizare a acestei funcții este raportată la centru. Este important, deoarece comenzile ulterioare primesc o confirmare sau un răspuns de la Voyager care indică dacă au fost executate cu succes.

Cum sunt solicitate datele?

Datele sunt solicitate întotdeauna prin intermediul unor comenzi simple de tip string. De exemplu, centrul poate emite o comandă setphy 2 pentru a instrui Voyager să utilizeze modulul radio 2M, care permite o comunicație de date mai rapidă, în schimbul unei anumite raze de acțiune și fiabilități. Dispozitivul periferic analizează această comandă pentru a se asigura că este validă, înainte de a apela propria funcție internă setphy cu o valoare de intrare de 2 pentru a comuta radioul utilizat. Dacă această funcție este executată cu succes de Voyager, o comandă Return: OK este emisă înapoi către dispozitivul central și afișată utilizatorului.

Interpretarea datelor accelerometrului

Figura 12: Interfața grafică Voyager4 pentru trasarea datelor. (Sursa imaginii: ADI)

Înainte de primirea datelor, utilizatorul interfeței grafice poate configura opțional accelerometrul Voyager-ului conectat utilizând comanda setadxlcfg. Odată ce perifericul emite o comandă de pornire, debutează fluxul de date privind accelerometrul de la periferic la centru. În mod implicit, dispozitivele centrale și periferice funcționează în modul de date în timp real, deoarece acest lucru este util în scopuri demonstrative.

Pe partea periferică, bufferul intern FIFO (first-in-first-out) este încărcat cu cele mai recente date la rata de eșantionare specificată de utilizator. Odată ce FIFO este încărcat, este plasat un indicator pe serviciul personalizat Voyager, care notifică perifericul că sunt disponibile date noi. Apoi, datele sunt transmise perifericului care le analizează și le convertește în matrice formatate care conțin valorile accelerației pe cele trei axe: x, y și z. Datele sunt întotdeauna reprezentate grafic, iar utilizatorul poate selecta opțional o variantă de salvare a datelor, care permite salvarea acelorași date și într-un fișier csv pentru o analiză ulterioară.

Proiectarea algoritmului AI

Scopul acestui proiect este de a detecta momentul în care sănătatea unui motor începe să se degradeze. Analiza AI la margine urmărește să înlocuiască sau să completeze analiza umană a datelor, prin crearea de metrici sau caracterizări ale stării de sănătate a motorului, pe baza uneia sau mai multor intrări, inclusiv audio, temperatură și vibrații. În prezent, vibrația este, de departe, cea mai utilizată în aplicațiile de monitorizare a stării.

Intrări

Majoritatea procesoarelor edge AI tind să consume multă energie, ceea ce contravine unuia dintre obiectivele oricărei soluții wireless de monitorizare a stării: durata de viață lungă a dispozitivului. MAX78000 (după cum s-a menționat anterior) poate face inferențe AI rapide, cu consum redus de putere, utilizând, în ansamblu, mai puțină energie decât modulul radio BLE. Totuși, atunci când se utilizează un procesor edge AI “low-power”, trebuie avut în vedere că dimensiunea rețelei neurale nu poate depăși specificațiile plăcii. Placa dispune de un accelerator CNN cu 512 kB de memorie de date. Acesta este destinat în principal detectării obiectelor, procesării audio și analizei datelor de tip serie temporală.

Datele disponibile pentru soluția noastră sunt accelerate în timp. Pentru a maximiza performanța algoritmului antrenat, au fost testate mai multe abordări de preprocesare pentru a determina care a avut cel mai mare efect asupra preciziei.

Antrenarea

Procesul de antrenare și implementare a unei rețele neurale pe MAX78000 este bine descris online pe platforma GitHub “Analog Devices AI”. În general, se creează mai întâi un model pe un PC gazdă utilizând seturi de instrumente convenționale precum PyTorch® și TensorFlow®. Acest model necesită date de antrenare (instruire) care trebuie salvate de dispozitivul țintă și transferate la PC. O subsecțiune a datelor de intrare devine setul de antrenare , fiind utilizată în mod specific pentru antrenarea modelului. O altă subsecțiune devine un set de validare, care se folosește pentru a observa modul în care funcția de pierdere (o măsură a performanței rețelei) se modifică în timpul formării.

Figura 13: Set de date Voyager pentru antrenarea modelului AI în condiții normale. (Sursa imaginii: ADI)

În funcție de tipul de model utilizat, pot fi necesare diferite tipuri și cantități de date. Dacă doriți să caracterizați defecțiuni specifice ale motorului, modelul pe care îl antrenați va avea nevoie de date etichetate care să contureze vibrațiile prezente atunci când sunt prezente diferitele defecțiuni, pe lângă datele privind vibrațiile sănătoase, atunci când nu este prezentă nicio defecțiune.

Voyager

Voyager a fost dezvoltat inițial cu o rețea neurală de tip autoencoder. Autoencoderele nu au nevoie ca datele să aibă etichete pentru a învăța cum să le clasifice. Deși acest tip de model nu este potrivit pentru clasificarea defectelor complexe, el poate fi antrenat rapid și utilizează numai date pe care clientul le are deja la îndemână, cum ar fi date despre motoare în stare bună de funcționare.

Determinarea cantității ideale de date pentru antrenare este unică pentru fiecare caz în parte, fiind necesar un volum suficient de date pentru a învăța tendințele generale ale funcționării normale a motorului, fără a exagera adaptarea datelor la datele de antrenare. Exemplul implicit implementat cu Voyager a fost antrenat cu doar 30 de secunde de date de accelerometru în stare normală de funcționare. Aceeași cantitate de date, dar cu un defect de dezechilibru prezent, a fost salvată pentru verificare. Ambele seturi de date au fost salvate direct pe PC-ul de antrenament utilizând interfața grafică (GUI) Python.

Figura 14: Testul Voyager cu date defecte. (Sursa imaginii: ADI)

Înainte de a fi utilizate pentru antrenarea modelului, datele de intrare au fost preprocesate. Scriptul de antrenare parcurge secvențial mai multe iterații ale antrenării și alege cel mai performant model. Unele date de intrare defectuoase sunt necesare în scopul testării. Nu puteți antrena un model pe date sănătoase și să vă exprimați încrederea în rezultatele obținute fără să testați mai întâi pe un exemplu de date defecte.

Cum este implementat algoritmul?

Odată ce modelul este antrenat, acesta trebuie cuantificat și sintetizat utilizând setul de instrumente online al ADI. Cuantizarea ajustează valorile ponderilor modelului generat la un set mai mic de intervale (bins) prin rotunjire sau trunchiere, permițând, astfel, o reducere a memoriei necesare pentru stocarea modelului. Aceasta este o procedură standard în cazul implementării rețelelor neurale pe dispozitive periferice mai mici. Synthesis convertește modelul cuantificat în fișiere “c” care pot fi înțelese de microcontroler.

Sunt generate trei fișiere, care trebuie apoi copiate în proiectul activ pentru microcontroler și încărcate cu următoarea actualizare a firmware-ului. Două dintre fișiere (cnn.h și cnn.c) conțin scrierea regiștrilor pentru configurarea CNN și alte funcții utile pentru modelul care este încărcat. Al treilea fișier (weights.h) conține ponderile modelului antrenat (și cuantificat).

Odată ce noul firmware este încărcat, fie prin intermediul unei actualizări prin cablu prin portul de depanare, fie wireless printr-o actualizare over-the-air (OTA), modelul este implementat și poate fi interogat de microcontrolerul BLE pentru a face inferențe AI la cerere.

Cum este utilizat odată ce a fost implementat?

Figura 15: Comunicația SPI a microcontrolerului. (Sursa imaginii: ADI)

Odată ce noul firmware este implementat, microcontrolerul AI operează ca o mașină cu stare finită, acceptând și reacționând la comenzile de la controlerul BLE prin SPI.

Atunci când este solicitată o inferență, microcontrolerul AI se trezește și solicită date de la accelerometru. Este important de reținut că acesta efectuează apoi aceleași etape de preprocesare a datelor seriilor temporale ca și cele utilizate în procesul de antrenare. În final, rezultatul acestei preprocesări este furnizat rețelei neurale implementate, care poate raporta o clasificare.

Ca măsură de economisire a bateriei, microcontrolerul AI a fost proiectat să emită automat o inferență la trezire, ceea ce permite microcontrolerului BLE să fie pornit doar atunci când este necesară o analiză.

Figura 16: Mașina de stare de inferență AI. (Sursa imaginii: ADI)

Într-o configurație tipică, microcontrolerul BLE se poate trezi dintr-un mod de așteptare cu consum redus de putere pentru o perioadă scurtă în fiecare zi, poate solicita o inferență AI a datelor accelerometrului prezente și poate reveni la modul de așteptare dacă datele nu îndeplinesc un criteriu stabilit de utilizator, cum ar fi faptul că modelul afirmă că datele par sănătoase cu o certitudine de 99%. În cazul opus, în care datele par anormale sau nu pot fi identificate cu încredere ca fiind sănătoase, microcontrolerul BLE se poate conecta la o gazdă BLE din apropiere și poate partaja datele. În acest fel, analiza de la margine elimină sarcina de înțelegere a datelor de la sistemul gazdă și economisește astfel durata de viață a bateriei.

Concluzie

În acest articol, am prezentat Voyager4, un sistem wireless de monitorizare a vibrațiilor care utilizează analiza AI pentru a-și îmbunătăți inteligența și durata de viață ca instrument de monitorizare a stării. Proiectarea unui senzor eficient de monitorizare a stării necesită o serie de considerente. Am discutat despre lanțul de semnal hardware pentru Voyager4 și despre firmware-ul care a fost utilizat pentru a integra împreună diferite elemente ale sistemului, pe lângă imaginea externă a dispozitivului ca periferic BLE. Am explorat, de asemenea, utilizarea AI în Voyager, oferind unele perspective asupra modului în care trebuie să luați în considerare dezvoltarea și implementarea modelelor voastre edge AI.

Autor: Tom Sharkey, Systems Applications Engineer, ADI

Despre autor

Tom Sharkey este inginer de aplicații de sisteme și lucrează în cadrul Unității Edge, Motion și Robotics Industrial de la Analog Devices. Tom a obținut o diplomă de licență în inginerie electronică și informatică de la Universitatea din Limerick în 2020. Are experiență în domeniul senzorilor de monitorizare a stării, al proiectării de firmware/software și al controlului motoarelor.

Analog Devices

Vizitați https://ez.analog.com