Orice inginer de automatizări cu câțiva ani de experiență are în memorie cel puțin un program pe care l-a deschis și l-a închis imediat. Variabile numite M12.3, blocuri fără niciun comentariu, o logică pe care autorul o ținea evident în cap și nicăieri altundeva. De obicei autorul a plecat din firmă, iar utilajul stă oprit.
Documentația unui program PLC nu este birocrație. Este diferența dintre o avarie rezolvată în două ore și una rezolvată în două zile, cu un specialist adus din alt oraș care trebuie mai întâi să descifreze ce a vrut să spună predecesorul.
Începe cu numele, nu cu comentariile
Cea mai eficientă formă de documentație este codul care nu are nevoie de explicații. Asta începe de la denumirea variabilelor. O convenție consecventă, aplicată de la prima linie, face mai mult decât o sută de comentarii adăugate ulterior.
O schemă care funcționează bine în practică arată aproximativ așa:
- prefix pentru tipul semnalului – intrare, ieșire, marker intern, temporizator;
- identificatorul zonei sau al subansamblului, corelat cu numerotarea din schema electrică;
- descrierea funcției, scrisă în cuvinte, nu în abrevieri inventate pe loc;
- sufix pentru starea semnalizată, atunci când există ambiguitate între activ și inactiv.
Regula de aur este corespondența cu documentația electrică. Dacă în schemă senzorul de capăt de cursă al cilindrului de împingere este B14, în program nu are ce căuta sub un alt nume. Cine depanează are schema într-o mână și programul pe ecran; orice traducere mentală între cele două este timp pierdut și sursă de erori.
Structura contează mai mult decât densitatea comentariilor
Un program bine structurat se citește pe niveluri. Blocul principal ar trebui să spună povestea utilajului la nivel înalt: inițializare, mod manual, mod automat, tratarea avariilor, comunicație. Detaliile coboară în blocuri funcționale, fiecare cu o responsabilitate clară.
Împărțirea pe zone fizice ale utilajului este de obicei mai utilă decât împărțirea pe tipuri de operații. Cine intervine caută stația 4, nu caută toate temporizatoarele din program. Când structura programului seamănă cu structura utilajului, orientarea devine aproape automată.
Un detaliu subestimat: constantele. Timpi de așteptare, praguri, limite, poziții – toate ar trebui declarate într-un singur loc, cu nume vorbitoare, nu împrăștiate ca valori numerice prin zeci de rețele. Când clientul cere ca temporizarea de la evacuare să crească de la 1,5 la 2 secunde, modificarea trebuie să fie o singură intervenție, nu o vânătoare.
Comentariile care ajută și cele care nu
Un comentariu care repetă ce se vede deja în cod nu ajută pe nimeni. Un comentariu care explică de ce este scris ceva într-un anumit fel valorează enorm.
Merită documentate în mod special situațiile neevidente: o întârziere adăugată pentru că un senzor dă semnal fals la vibrație, o condiție suplimentară cerută de client după un incident, o secvență care ocolește un comportament ciudat al unui drive. Aceste lucruri nu se deduc din logică, iar cine vine după și nu le știe le va șterge, considerându-le redundante. Apoi vor reapărea aceleași probleme, iar nimeni nu va înțelege de ce.
La fel de utilă este o listă a alarmelor, cu textul afișat operatorului, cauza probabilă și acțiunea recomandată. Este documentul care ajunge cel mai des în mâna oamenilor din schimb și, într-o linie automatizată, se leagă direct de felul în care sunt împărțite rolurile între PLC și sistemul de supervizare.
Versiuni, backup și predarea către altcineva
Fără evidența versiunilor, restul eforturilor se pierd. Minimul acceptabil este un antet în programul principal cu data, autorul, versiunea și ce s-a modificat față de versiunea anterioară. Fișierele salvate trebuie să poarte același număr de versiune, iar arhiva trebuie să stea într-un loc accesibil și fabricii, nu doar laptopului integratorului.
Un test simplu arată dacă documentația este suficientă: dați proiectul unui coleg care nu a lucrat niciodată la utilajul respectiv și cereți-i să localizeze cauza unei alarme și să adauge o mică funcție. Dacă reușește într-o oră fără să vă întrebe nimic, documentația își face treaba. Dacă vine cu cinci întrebări în primele zece minute, acele cinci răspunsuri trebuie scrise undeva.
Merită spus și partea comercială. Într-un proiect de retrofit al unui utilaj vechi, clauza privind predarea programului comentat și a surselor editabile este la fel de importantă ca specificația tehnică. Un program livrat doar compilat, fără surse, transformă orice modificare viitoare într-o negociere cu un singur furnizor. Documentația este, în cele din urmă, o formă de independență.
