Simularea și testarea unui program PLC înainte de punerea pe utilaj

Există un moment în orice proiect de automatizare în care programatorul urcă pe utilaj cu laptopul și dă drumul pentru prima dată. Dacă programul nu a fost testat înainte, acel moment devine o combinație de depanare, improvizație și presiune, cu producția oprită și cu jumătate de fabrică uitându-se peste umăr. Este cel mai scump loc din lume pentru a găsi o eroare de logică.

Testarea prealabilă nu elimină punerea în funcțiune, dar schimbă complet natura ei. Din vânătoare de erori de bază, devine reglaj fin. Diferența se măsoară în zile de oprire și în piese distruse, iar pentru un utilaj cu mișcări rapide, în risc pentru oameni.

De ce utilajul este cel mai prost loc de depanare

Pe utilajul real, fiecare încercare costă. Un ciclu greșit poate izbi o sculă de un dispozitiv, poate rupe un senzor sau poate rebuta o piesă. Ciclurile sunt lente, pentru că nimeni nu testează la viteză nominală o logică nesigură. Situațiile de excepție, exact cele care generează opriri în exploatare, sunt greu de reprodus: nu poți provoca la comandă o cădere de aer comprimat sau o piesă blocată la jumătatea transferului.

În simulare, toate acestea devin banale. Un semnal se forțează într-o secundă, o eroare se repetă de douăzeci de ori la rând, un ciclu rulează accelerat, iar dacă logica greșește, nu se rupe nimic. Costul unei erori descoperite la birou este de ordinul minutelor; aceeași eroare descoperită pe utilaj poate costa un schimb întreg.

Nivelurile de simulare, de la logică la model de proces

Nu toate proiectele au nevoie de același efort. În practică există patru niveluri, iar alegerea se face după complexitatea și riscul aplicației.

1. Simularea internă a mediului de programare. Aproape toate platformele moderne permit rularea programului fără hardware, cu forțarea manuală a intrărilor. Este suficientă pentru a verifica secvențe simple, temporizări, calcule și tratarea unităților de măsură. Nu spune nimic despre comportamentul mecanic.
2. Controler virtual cu ecran de operare conectat. Programul rulează pe un PLC emulat, iar interfața de operare se conectează la el ca la unul real. Aici se testează navigarea, alarmele, blocajele de comandă și tot ce ține de dialogul cu omul. Este momentul în care se văd butoanele care nu fac nimic și mesajele de alarmă care nu spun ce s-a întâmplat, probleme discutate pe larg în articolul despre interfața om-mașină și rolul ei pentru operatori.
3. Simulare cu model de proces. Se scrie, în paralel cu programul, un model simplificat al utilajului: cilindrii au timpi de cursă, senzorii se activează după acei timpi, un motor mișcă o poziție care crește liniar. Modelul nu trebuie să fie fidel fizic, trebuie doar să reacționeze plauzibil la ieșiri. Cu el se poate rula un ciclu complet, cap-coadă.
4. Model detaliat, cu cinematică și coliziuni. Nivelul cel mai costisitor, justificat la celule cu roboți, la mișcări coordonate pe mai multe axe sau la investiții mari, unde o coliziune înseamnă săptămâni de întârziere. Această abordare se apropie de ceea ce descrie articolul despre gemenii digitali industriali și problemele pe care le rezolvă concret, cu diferența că, la punerea în funcțiune, modelul are un scop precis și limitat: să nu spargă nimic la prima rulare.

În majoritatea proiectelor de linie clasică, nivelurile doi și trei acoperă peste optzeci la sută din erorile care ar fi ajuns pe utilaj. Modelul simplificat de proces se scrie de obicei în câteva zile și rămâne util pentru toate modificările ulterioare.

Ce trebuie să conțină un set de teste care chiar prinde erori

Un test care rulează doar ciclul normal, de la început până la sfârșit, dă o falsă siguranță. Ciclul normal funcționează aproape întotdeauna, pentru că este singurul la care s-a gândit programatorul în timp ce scria. Erorile stau în altă parte. Setul minim de scenarii:

• Pornirea din stare necunoscută. Utilajul se alimentează cu o piesă rămasă la jumătatea transferului și cu cilindrii în poziții amestecate. Programul trebuie să refuze pornirea automată și să ceară o secvență de aducere în poziția inițială, nu să pornească orbește.
• Oprire de urgență în fiecare pas al ciclului. Nu doar în repaus. Se verifică ce rămâne alimentat, ce cade, ce se pierde din memorie și dacă repornirea este posibilă fără intervenție mecanică.
• Lipsa unei utilități. Cădere de aer comprimat, presiune hidraulică sub prag, o fază lipsă la alimentare.
• Senzor care nu comută. Se blochează în simulare semnalul unui senzor de capăt de cursă și se verifică dacă programul dă o alarmă clară după temporizarea prevăzută, în loc să aștepte la nesfârșit.
• Senzor care comută prea devreme sau tremură. Situația reală a unui contact murdar, care generează impulsuri parazite.
• Valori la limite. Rețetă cu parametru minim și maxim, contor la valoarea maximă, lot cu o singură piesă.
• Comenzi date în ordine greșită de operator. Cine apasă butoane în ordine neașteptată găsește, de regulă, jumătate din erorile rămase.
• Comunicația întreruptă. Cablu de rețea scos între controler și un echipament subordonat, apoi reconectat, pentru a vedea dacă sistemul își revine singur.

Fiecare scenariu se notează cu rezultatul așteptat înainte de a fi rulat. Un test fără criteriu de acceptare scris dinainte se transformă, invariabil, într-o discuție despre ce ar fi trebuit să facă utilajul.

Ce nu poate fi testat în simulare

Onestitatea în privința limitelor este parte din metodă. Simularea nu verifică cablarea reală, deci nu confirmă că intrarea I2.4 este chiar senzorul pe care scrie în schemă. Nu verifică polaritatea semnalelor, nu detectează un fir slăbit și nu spune nimic despre frecări, jocuri mecanice sau despre comportamentul unui material real în dispozitiv. Nu înlocuiește, sub nicio formă, verificarea funcțiilor de siguranță pe echipamentul montat, care se face cu un protocol propriu și cu documentația cerută de nivelurile descrise în articolul despre siguranța funcțională și nivelurile SIL și Performance Level. Circuitele de siguranță se testează fizic, cu declanșare reală, de personal calificat, indiferent cât de bine arată simularea.

Trecerea de la birou la utilaj

Ordinea de pornire care reduce cel mai mult riscul este aceeași de zeci de ani. Întâi se verifică intrările, una câte una, acționând fizic fiecare senzor și confirmând pe controler că se aprinde exact bitul așteptat. Apoi ieșirile, cu utilajul în stare sigură, comandate individual, la presiune și viteză reduse. Abia după aceea se rulează secvențe în regim pas cu pas, cu mâna pe butonul de oprire. Viteza nominală vine ultima.

Rezultatele testelor din simulare se păstrează, pentru că devin baza protocolului de recepție. Modul în care se leagă acestea de restul procedurii este descris în articolul despre testarea și punerea în funcțiune a unei linii automatizate noi, iar suprapunerea dintre cele două liste economisește zile bune de lucru.

Ultimul pas, cel mai des sărit, este păstrarea mediului de test după punerea în funcțiune. Peste șase luni va apărea o modificare de rețetă sau o cerință nouă, iar dacă modelul de simulare a fost aruncat, orice schimbare se va testa din nou direct pe utilaj, în producție. Un mediu de simulare arhivat împreună cu versiunea programului, cu aceleași reguli de identificare și comentare descrise în materialul despre documentarea unui program PLC astfel încât altcineva să îl poată modifica, transformă fiecare intervenție ulterioară dintr-un risc într-o rutină.