Edge sau cloud? În mediul industrial, aceasta este întrebarea greșită

În proiectele de digitalizare industrială apare în mod regulat aceeași întrebare: edge sau cloud?

Ca și cum ar trebui să alegem între două viziuni care se exclud reciproc. Pe de o parte, procesarea la fața locului; pe de alta, cloudul. Una este rapidă și independentă, cealaltă scalabilă și administrabilă centralizat.

În realitate, un sistem industrial care funcționează bine le folosește aproape întotdeauna pe amândouă. Nu după moda tehnologică, ci în funcție de locul în care anumite date sau o decizie pot fi gestionate cel mai sigur, cel mai rapid și cel mai economic.

Ce înseamnă de fapt edge?

Edge-ul nu este neapărat un server special aflat lângă linia de producție. În această categorie poate intra orice capacitate de calcul și de decizie care funcționează aproape de locul în care sunt generate datele.

Poate fi:

• un senzor inteligent;
• un PLC;
• un gateway IoT industrial;
• un calculator local;
• un server la nivelul amplasamentului;
• un serviciu de procesare a datelor care rulează într-un container.

Rolul edge-ului nu este doar acela de „a trimite mai puține date în cloud”. Poate gestiona local funcțiile pentru care contează latența redusă, independența față de rețea, protecția datelor sau siguranța în exploatare.

Ce nu trebuie lăsat în seama conexiunii la distanță

Dacă o decizie trebuie luată în milisecunde sau secunde, drumul dus-întors prin rețea poate reprezenta un risc. Același lucru este valabil atunci când procesul tehnologic trebuie să funcționeze și fără conexiune la internet.

De regulă rămân la nivel local:

• comanda directă a mașinilor și a proceselor;
• funcțiile de siguranță funcțională (safety);
• intervenția de protecție imediată;
• preprocesarea datelor eșantionate la frecvență ridicată;
• stocarea temporară (buffering) a datelor;
• funcțiile locale de bază pentru operatori;
• adaptarea protocoalelor de comunicație.

De exemplu, dacă un senzor de vibrații generează câteva mii de eșantioane pe secundă, nu merită neapărat ca fiecare valoare brută să fie trimisă continuu către un sistem central. Procesarea locală poate calcula indicatori caracteristici, poate detecta depășirea pragurilor și poate transmite doar rezumatul relevant sau secvența de eșantioane din jurul unui eveniment.

Unde procesarea centrală sau în cloud este mai puternică

Mediul central este avantajos acolo unde trebuie corelate datele mai multor amplasamente, ale unor perioade lungi sau ale mai multor sisteme de afaceri.

Aici merită gestionate, de exemplu:

• comparația între amplasamente;
• analiza istorică;
• monitorizarea dispozitivelor la nivel de flotă;
• raportarea la nivel de companie;
• gestionarea centralizată a drepturilor de acces;
• antrenarea modelelor;
• procesele de mentenanță și de afaceri;
• gestionarea versiunilor și a configurațiilor.

Avantajul cloudului nu constă doar în faptul că „serverul se află în altă parte”. Poate oferi capacitate flexibilă, accesibilitate centralizată, operare unitară și procesarea comună a datelor provenite din mai multe surse.

Cinci criterii reale de decizie

Împărțirea sarcinilor între edge și cloud merită stabilită după cel puțin cinci criterii.

1. Latența

În cât timp trebuie să se reacționeze? O intervenție de protecție a mașinii și un raport energetic lunar nu fac, evident, parte din aceeași categorie.

2. Fiabilitatea conexiunii

Ce se întâmplă dacă se întrerupe conexiunea WAN sau cea mobilă? Procesul local trebuie să funcționeze în continuare în siguranță, iar datele trebuie, la nevoie, stocate temporar și sincronizate ulterior.

3. Volumul de date

Transmitem serii de date brute sau indicatori deja procesați? Lățimea de bandă, costul de stocare și scopul analizei determină împreună răspunsul corect.

4. Securitate și gestionarea datelor

Ce date pot părăsi amplasamentul? Din ce direcție sunt permise conexiunile? Unde au loc autentificarea, criptarea și jurnalizarea?

5. Ciclul de viață și operarea

Cine actualizează componenta locală? Cum poate fi gestionată configurația a o sută de amplasamente? Cum se poate reveni de la o versiune defectă? Dispozitivul edge nu poate fi o cutie neagră uitată.

Funcționarea offline nu este o excepție, ci o stare de proiectare

Într-o soluție industrială, întreruperea rețelei trebuie proiectată nu ca un accident excepțional, ci ca o stare a sistemului tratată din timp.

Trebuie stabilit:

• câte date pot fi stocate local;
• în ce ordine se face reîncărcarea datelor;
• cum se gestionează duplicatele;
• ce se întâmplă în cazul unor comenzi contradictorii;
• ce funcții rămân disponibile;
• când și cui transmite sistemul alerte.

Abordarea OrigSmart privind gateway-ul și platforma gestionează această continuitate. Conectivitatea din teren, logica locală, transmiterea mesajelor, procesarea centrală a datelor și procesele de afaceri nu sunt proiecte separate, ci părți ale unui sistem proiectat cap-coadă (end-to-end).

Într-un sistem bidirecțional, granița contează și mai mult

Telemetria simplă trimite date doar în sus. O platformă operațională reală poate însă acționa și asupra funcționării fizice: modifică un punct de consemn (setpoint), reglează un invertor, programează consumul, confirmă o alarmă sau pornește un proces local.

În astfel de cazuri trebuie separate clar:

• recomandarea de comanda executabilă;
• optimizarea centrală de limita locală de siguranță;
• drepturile utilizatorului de autorizarea la nivelul dispozitivului;
• funcționarea normală de modul de rezervă sigur (fallback).

Sistemul central poate indica faptul că reducerea unei sarcini ar fi avantajoasă din punct de vedere economic. Comanda locală trebuie însă să împiedice orice intervenție care ar încălca o limită tehnologică sau de siguranță.

Surse

• Comisia Europeană – Politica Europei privind internetul obiectelor
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• OrigSmart – Sistem de operare pentru afaceri, bazat pe web