ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 78
Abonament PDF

Totuși, ce înseamnă I4.0?

Tudor Rusu
Software Developer @ Bosch
PROGRAMARE


În aceste vremuri, când singura constantă e schimbarea, oricine vrea să fie remarcat are nevoie de o notă de extravaganță. Iar în lumea tehnologiei cea mai sigură rețetă pentru aceasta reprezintă alegerea unui acronim criptic. Astfel "IoT" sau "IIoT" pot reprezenta o bună soluție. Dacă altcineva vrea să meargă mai departe, poate adăuga ceva semne de punctuație și cifre, făcând referire la stilul de incrementare a denumirilor născut în era dot-com, să spunem "I4.0", va avea toate șansele să treacă în față în captarea atenției oamenilor. În orice caz, aceste denumiri oarecum extravagante sunt necesare pentru a compensa o definiție neclară sau cel puțin, una în continuă evoluție. Acest articol prezintă un punct de vedere despre ce înseamnă Industry 4.0 (I4.0), cum Industrial (I) Internet of Things (IoT) se integrează în acest termen și care sunt celelalte tehnologii ale ecosistemului denumit generic I4.0. Termenul Industry 4.0 se referă la o a 4-a revoluție Industrială, definită în principal printr-o largă adopție a sistemelor bazate pe IoT. Primele trei pot fi sintetizate prin termeni ca revoluția motorului cu aburi, a liniei de asamblare și cea a digitizării. Desigur că toate aceste revoluții nu sunt puncte singulare în timp, iar acești termeni sunt aleși pentru a facilita reprezentarea unei evoluții în patru etape a progreselor industriei. De exemplu, pentru prima revoluție industrială, alături de motorul cu aburi, mai sunt menționate și puterea apei și mecanizarea, cea de-a doua este și despre apariția electricității, iar cea de-a treia se referă și la automatizarea asistată de calculator ca element ce a condus la digitalizarea mașinilor industriale. Argumentând că aceste schimbări nu au fost abrupte, unii contestă folosirea termenului de revoluție din definirea acestui concept de I4.0.

Odată identificate originile lexicale ale termenului I4.0, e important să vedem la ce se referă de fapt, acest termen. Alte referiri la acest concept folosesc termeni precum Smart Factory sau Connected Manufacturing. Dacă amestecăm acești termeni cu afirmația de mai sus despre I4.0 ca fiind bazată pe Internet of Things, ne putem imagina niște unelte și dispozitive cu o anumită putere de calcul, cu unele capabilități de detectare a proprietăților mediului înconjurător și, cu siguranță, dotată cu capabilități de interconectare digitală care le permit să acceseze chiar și Internetul. Cam aceasta înseamnă Internet of Things: orice dispozitiv, de obicei un senzor sau un actuator echipat cu orice nivel de putere de calcul care-i permite să-și transmită datele peste o rețea digitală. Pentru a fi cu adevărat un dispozitiv IoT, această rețea pe care o poate accesa, ar trebui să aibă cel puțin un dispozitiv de tip edge router prin care se poate accesa Internetul. Sau dispozitivul IoT ar putea accesa direct Internetul. Termenul de Industrial IoT sau IIoT a apărut când diversitatea dispozitivelor conectate la Internet a explodat și principalele caracteristici a sistemelor IoT, au putut fi grupate după domeniile în care erau folosite, cum ar fi mediul industrial, automatizarea clădirilor, aparate casnice, sectorul medical și altele.

Ce altceva înseamnă I4.0 pe lângă (I)IoT? A fost deja menționat un Edge Router care permite unui dispozitiv IoT să ajungă în Internet. O mențiune aici: prin Internet se poate înțelege și o rețea intranet, nu neapărat întregul Internet, soluție aleasă din diferite motive cum ar fi riscurile de securitate. Funcția acestui edge router este aceea de a media comunicația unui dispozitiv IoT conectat la el, peste un protocol specific, cu rețele de nivel superior, numite și backend, de obicei peste un protocol de tip IP. De exemplu, nu ar fi fezabil să încărcăm logica de comunicație a unui simplu întrerupător cu întregul protocol IP, când volumul datelor utile folosite de acesta pot fi chiar și de un singur bit. Un alt exemplu de sisteme IoT a căror arhitectură este construită în jurul unui edge router este acela al dispozitivelor cu conectivitate radio. Aceste protocoale au la bază pachete mici de date, pentru care utilizarea protocolului IP nu ar fi practică. De exemplu, stratul fizic al rețelei ZigBee trebuie să lucreze cu pachete de maximum 129 de bytes, în timp ce doar antetul protocolului IPv4 poate depăși cu ușurință 200 de bytes. Așa că unul din rolurile pe care le poate avea un edge router este acela de a conecta rețeaua dispozitivelor IoT, de obicei una radio de mică putere, de una de bandă largă, eventual conectată la Internet, precum Wi-Fi sau Ethernet. Pentru acest lucru, un edge router nu ar trebui să aibă constrângeri privind puterea de calcul ori consumul modului de comunicație. Această cerință nu reprezintă însă un dezavantaj semnificativ, deoarece un edge router poate deservi până la câteva mii de dispozitive IoT. O altă utilitate a unui edge router este aceea că poate prezenta dispozitivele IoT, peste Internet, cu ușurință, printr-o analiză IPv6 completă, de 16 bytes, în timp ce permite folosirea unor aliasuri mult mai scurte, de doi sau patru bytes, în cealaltă rețea, a dispozitivelor IoT. Acestea din urmă au de obicei, constrângeri legate de consumul energetic.

Mergând mai departe, întrebarea care apare este ce putem face cu o mulțime de date de senzori. Fluxul de date generat de un singur senzor, nu are o semnificație prea mare. Așa că avem nevoie să adunăm datele de la toate dispozitivele IoT într-un singur loc și să încercăm să vedem imaginea de ansamblu. Acest singur loc este Cloudul. Acest concept este descris în principal ca o stivă de servicii de procesare care pot fi accesate peste o rețea, de obicei peste Internet. Principalele servicii Cloud folosite de un sistem IoT Industrial sunt stocarea de date, diferite API-uri pentru achiziția datelor de la diferite edge routers sau alte servicii și, în final, rularea aplicațiilor de Big Data care reprezintă adevărata putere a conceptului de I4.0. Să ne imaginăm ce înseamnă să poți corela o creștere de 0.5 ppm (punct per milion) a ratei rebuturilor unui produs de tip electronic control unit (ECU) cu descărcarea unui transport de procesoare folosite pentru aceste ECU pe o vreme răcoroasă și umedă când condițiile de temperatură și umiditate coboară sub punctul de condens. Cu siguranță, unei persoane i-ar fi imposibil să găsească o astfel de legătură, dar un bun algoritm de Data Analysis care are acces la datele integrate ale senzorului ambiental ce a însoțit transportul de procesoare, datele de urmărire a acestor componente din magazie spre linia de producție și până la punctul de verificare a calității unde se observă mica creștere a ratei rebuturilor, ajutat de o bună interfață de vizualizare a datelor (Data Vizualization), poate indica unui inginer de la controlul calității, această corelație. Mai departe, dacă toate componentele sensibile la umezeală ar avea marcat un câmp subordonat acestui lucru în descrierea lor digitală, accesibil algoritmilor de analiză a datelor, iar un inginer marchează această corelație dintre un grad mare de umiditate al aerului și defectarea procesoarelor, un algoritm de tip Machine Learning poate merge mai departe să afle corelații între situații similare în care au fost implicate componente sensibile la umiditate, pentru ca în final să facă o listă cu furnizori care livrează aceste componente sensibile în ambalaje inadecvate.

O problemă privind calitatea datelor în mediul industrial este gradul lor de structurare, mai precis, gradul redus de structurare al acestora. Dacă noile implementate sisteme IoT, precum senzori conectați prin edge routers și gateway-uri vor livra seturi de date cu un grad mare de coerență, într-o fabrică pot fi găsite azi o mulțime de mașini digitalizate concepute în timpul precedentei revoluții industriale. Aceasta înseamnă că informații în format digital sunt disponibile dar într-un format nestructurat, prezentând de multe ori doar loguri în format text. Aceste date pot fi foarte valoroase pentru analiști, dar necesită un efort considerabil pentru a fi structurate, pentru aducerea acestora la un format care poate fi utilizat și, in special, integrat cu celelalte date din fabrică. Acest proces este denumit Data Mining și se bazează mult pe algoritmi de învățare, însă procesul de antrenare a acestor algoritmi necesită multă intervenție umană.

Un alt rol jucat de Cloud este acela de procesare a puternicilor algoritmi de identificare a modelelor de date (Data Models). Pentru a exemplifica la ce sunt utile aceste data models, să luăm exemplul unui senzor de vibrații care monitorizează o mașină de tip pick-and-place, care populează o placă electronică cu componente. Cu acest senzor dorim să monitorizăm starea de pornit - oprit a mașinii, stări mecanice critice și, în același timp, să numărăm câte plăci procesează. Pentru aceasta, trebuie să caracterizăm și să monitorizăm, pentru fiecare stare pe care dorim să o identificăm, cel puțin două atribute ale vibrațiilor: amplitudinea vârfurilor și frecvența acestora. Când mașina este oprită, vom avea doar un zgomot de fond foarte redus, când placa este încărcată ori descărcată din mașină, vom avea un semnal de vibrații asemănător cu un zgomot însă de o amplitudine mult mai mare. Când mecanismul de pick-and-place este acționat, vom avea vârfuri înalte care se vor diferenția clar de un semnal de zgomot. Având aceste stări caracterizate în termeni de amplitudini maxime ale vârfurilor și frecvențe ale vârfurilor cu amplitudini în anumite intervale, putem construi un algoritm care să monitorizeze citirile senzorului, să specifice în care dintre stări se află mașina, să numere câte plăci încarcă și descarcă ori să comande o oprire de urgență, dacă identifică stări anormale al regimului de vibrații, cum ar fi șocuri mecanice care pot indica o defecțiune gravă. Calculul acestor caracterizări presupune o putere de procesare semnificativă, care cu siguranță, nu e disponibilă pe microcontrollerul senzorului. Aceasta înseamnă că toate datele de la senzor trebuie transmise în Cloud pentru a fi monitorizate. Dar această abordare nu este una practică din cel puțin două motive: latențele și necesarul lățimii de bandă pentru transmiterea datelor. Pentru un senzor de vibrații folosit în acest scop, lățimea de bandă necesară poate trece ușor de 1 MBps - se poate considera câte o valoare float de minim 4 bytes pentru fiecare din cele trei axe plus diferite etichete necesare fiecărei citiri: cum ar fi una pentru timp ori pentru identificatorul senzorului, dar și antete provenind de la protocolul de rețea ori de la API. Toate acestea trebuie trimise cu o frecvență de cel puțin câteva zeci de kilohertzi. Cât despre latențe, trimiterea datelor de la senzor la Cloud și primirea răspunsului poate dura cel puțin câteva secunde, ceea ce nu este suficient pentru cerințele multor standarde de securitate. Din aceste cauze, o soluție ar fi aceea de a descărca aceste caracterizări, aceste modele de date, direct pe senzor. Pentru identificarea stărilor mașinii, poate fi suficient compararea fiecărei citiri cu un anumit interval, ceea ce poate fi făcut ușor de către procesorul unui senzor.

Dezvoltăm în continuare acest exemplu și presupunem că vrem să știm mai mult despre această mașină de pick-and-place, doar cu ajutorul acestui senzor de vibrații. De exemplu, vrem să verificăm dacă sunt amplasate toate componentele, identificând momentul în care întâlnește o lipsă a componentei în banda de pe rolă sau când încearcă să plaseze o componentă care nu se mai află pe feeder. În ambele cazuri, un algoritm poate identifica diferențe între modelul de vibrație atunci când feederul prinde cu succes o componentă ori când aceasta nu se află pe banda de pe rolă. La fel și cu așezarea componentei pe placă. Pentru a complica lucrurile și mai mult, să presupune că dorim să verificăm și faptul că sunt montate pe placă toate tipurile de componente identificând modelul de vibrație al fiecăruia în timpul prinderii piesei, a așezării acesteia și poate chiar în timpul deplasării acesteia. Dacă un asemenea scenariu ar fi posibil, atunci modelul rezultat nu ar mai putea fi rulat pe microcontrollerul unui senzor. Răspunsul la astfel de situații, a primit relativ recent un nume foarte plastic: Fog Computing. După cum sugerează numele, această procesare se face undeva "mai jos" decât în Cloud, dar totuși, deasupra senzorilor. Poate fi, de exemplu, în edge router care nu are de obicei restricții de putere consumată, dar nici nu este un server, este de obicei un mini PC. Un edge router poate fi ușor conectat la senzor peste o linie ce-i oferă o bandă largă de date și latențe foarte mici pentru a accesa întregul flux de date pe care să-l compare cu un model foarte complex.

Dacă acest ultim exemplu pare ușor dus la extrem atunci când ne gândim la complexitatea algoritmilor pe care i-ar presupune, iar din aceasta cauză devine nefezabil ori cel puțin ineficient, să încercăm să ne imaginăm ce avantaje ar putea aduce o astfel de implementare, dacă ar fi posibilă. De exemplu s-ar putea înlocui o unitate automată de control optic al calității de mii de euro printr-un simplu senzor de vibrații care nu ar depăși câțiva euro. Și să nu ignorăm reducerea costurilor dată de scurtarea timpului petrecut de ECU pe linia de producție dacă cel puțin un punct de control al calității este suprapus peste cel de montare a componentelor pe placă.

Alte tipuri de tehnologii care își fac loc în conceptul de I4.0 sau probabil, în mai noul Industry X.0, sunt dispozitivele purtabile (wearables) și realitatea augmentată - augmented reality. De la ceasurile inteligente care informează operatorul în timp real despre starea unei mașini la dispozitive de siguranță, care monitorizează cu precizie poziția unei persoane și o avertizează când este pe o traiectorie de coliziune cu un echipament în mişcare (cum ar fi un motostivuitor), acestea sunt tot mai întâlnite în mediul industrial. Cât despre realitatea augmentată, un manual pentru operatorii de echipamente industriale care se bazează pe suprapunerea instrucţiunilor grafice peste imaginea reală a echipamentului din faţa cursantului cu ajutorul ochelarilor virtuali se dovedeşte mult mai eficient decât paginile unui manual clasic.

Deși a apărut un consens despre beneficiile aduse de o abordare I4.0, multe astfel de implementări întâmpină dificultăți semnificative. Cea mai stringentă este aceea a lipsei ori slabei standardizări a acestor noi tehnologi aduse de I4.0. De exemplu, pentru senzorii wireless se folosește o gamă largă de soluții radio - Bluetooth, Wi-Fi, ZigBee și multe altele - dar până acum nici una dintre acestea, nu pare a deveni dominantă. Mai departe, uitându-ne la backend și la edge router, protocoalele de transfer a datelor variază și ele, deși in ultima perioada se pare că REST API ar prelua conducerea. Un alt lucru care îngreunează adoptarea de noi tehnologii, dacă e să comparăm cu alte sectoare, este nevoia imperativă de fiabilitate în mediul industrial. Aici multe situații în care echipamentele cedează ori nu funcționează corect, pot duce la opriri costisitoare ale producției sau chiar la situații periculoase.

O sinteză a conceptelor pe care se bazează Industry 4.0, se exprimă prin sistemele Internet of Things, dispozitivele de colectare a informației din mediul înconjurător, Cloudul ca suport pentru gestionarea datelor - Big Data și noul concept de Fog Computing care este practic, o unitate mai mică de gestionare a datelor ce se află mult mai aproape de sursa acestora și de beneficiarii procesărilor. Lucruri ca dispozitivele purtabile sau realitatea augmentată pot fi de asemenea incluse în Industry 4.0, deși acestea par a fi fost deja revendicate de noul concept apărut sub numele de Industry X.0. Aceasta din urmă denumire încearcă să descrie ideea de integrare continuă, a oricăror tehnologii noi care pot aduce un avantaj în mediul industrial.

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • MicroFocus
  • Colors in projects