Cât durează, de fapt, un proiect AMR/AGV?

De la procesul actual la conceptul de automatizare

Un proiect ar trebui să înceapă cu procesul pe care vrem să-l automatizăm și cu motivul pentru care vrem să-l schimbăm. Poate exista o problemă de disponibilitate a personalului, un cost ridicat al transportului manual, trafic de stivuitoare pe care compania vrea să-l reducă, reducerea sau eliminarea traficului de stivuitoare din anumite zone din considerente de siguranță, nevoia de capacitate suplimentară sau dorința de a obține un flux mai predictibil.

Înainte să discutăm despre un anumit model de AMR sau AGV, trebuie să înțelegem cum funcționează astăzi transportul respectiv. Ce se transportă, între ce puncte, în ce volume, în câte schimburi și cu ce variații pe parcursul zilei? Cum este solicitată o misiune? Cât poate aștepta materialul? Ce se întâmplă atunci când punctul de predare este ocupat? Există buffers? Care sunt excepțiile pe care operatorii le gestionează astăzi aproape fără să le considere excepții?

Un proces manual poate fi foarte bine optimizat de specialiștii clientului și totuși să necesite anumite adaptări pentru automatizare. Operatorii compensează natural variabilitatea. Pot aștepta, pot schimba ordinea transporturilor sau pot reacționa la o situație neprevăzută. O parte dintre aceste decizii trebuie transformată, într-un sistem automatizat, în reguli pe care roboții, Fleet Manager-ul sau sistemele cu care sunt integrate le pot executa.

Este important și ce transportăm efectiv. Un europalet de 800 × 1.200 mm, un palet cu altă geometrie, o cutie, un cart sau un suport special pot conduce la roboți și mecanisme de manipulare diferite. Contează dimensiunile, greutatea maximă, poziția sarcinii și, unde aplicația o cere, stabilitatea și centrul de greutate.

De aici rezultă și ce arhitectură de robot are sens pentru aplicație. În practică, putem ajunge la o soluție underride/platform sau la una fork type, în funcție de unitatea transportată și de modul în care aceasta trebuie preluată și predată. Pentru carts, racks sau aplicații în care sarcina este manipulată printr-un modul dedicat, o platformă poate fi potrivită. Pentru paleți, trebuie ținut cont și de geometrie și de modul de preluare. În cazul anumitor closed pallets poate fi necesară o soluție counterbalance, care permite preluarea cu furcile fără elemente de susținere sub sarcină, dar are de regulă un gabarit mai mare din cauza contragreutății. Dacă aplicația presupune stacking sau transfer la înălțime, trebuie analizate și cursa de lift, stabilitatea sarcinii și geometria punctului de transfer.

După primele discuții, layout-ul devine unul dintre cele mai utile instrumente de lucru. Nu este punctul de plecare al proiectului, ci prima reprezentare prin care putem pune fluxurile înțelese anterior în contextul fabricii sau depozitului. Putem vedea împreună originile și destinațiile, distanțele, traseele posibile, intersecțiile dintre fluxuri și zonele în care mai multe procese folosesc același spațiu.

Layout-ul ne permite, în această etapă, să analizăm procesul așa cum a fost descris și reprezentat. Site survey-ul este momentul în care confruntăm această imagine cu ceea ce se întâmplă efectiv în fabrică.

Ce verificăm la site survey

Vizita în fabrică sau depozit adaugă informații pe care un layout nu le poate reda complet. Urmărim fluxul în desfășurare și verificăm dacă ipotezele făcute în etapa inițială rămân valabile atunci când vedem procesul în funcționare. Din experiență, există destule situații în care ceea ce vedem în teren diferă, uneori în detalii și alteori semnificativ, de procesul descris inițial în sala de ședințe.

Măsurăm lățimile culoarelor, dar ne interesează în egală măsură îngustările locale și spațiul disponibil în zonele în care robotul trebuie să facă manevre. Verificăm intersecțiile, vizibilitatea și zonele în care traseul roboților se suprapune cu traficul oamenilor sau al altor utilaje. Dacă există trafic mixt, contează ce tipuri de vehicule circulă acolo (stivuitoare, transpalete, tugger trains sau alte echipamente), precum și dimensiunile și modul lor de operare. La fel de important este să observăm cum se comportă în realitate operatorii acestor vehicule: unde opresc, cum abordează intersecțiile, ce trasee folosesc și ce reguli informale s-au format în timp. Toate acestea pot influența modul în care proiectăm traficul roboților.

Lățimea culoarelor și structura traseelor influențează inclusiv strategia de trafic. Într-o anumită zonă poate fi posibilă circulația în ambele sensuri, în timp ce într-un culoar mai îngust poate avea mai mult sens o regulă one-way. O astfel de decizie influențează distanțele parcurse, traficul și, în final, capacitatea flotei.

La punctele de pickup și delivery verificăm nu numai dacă robotul poate ajunge, ci și dacă are spațiul necesar pentru poziționare și manevră. Analizăm cum este prezentată sarcina, toleranțele pe care procesul actual le produce și dacă stațiile existente pot fi folosite așa cum sunt sau necesită modificări.

Starea pardoselii este un alt element pe care îl verificăm. Rosturile, denivelările, pantele sau diferențele de nivel pot fi relevante în funcție de robot și de sarcina transportată. În anumite medii trebuie luate în calcul și temperatura, umezeala sau alte condiții specifice.

Urmărim apoi infrastructura cu care sistemul trebuie să interacționeze. Dacă pe traseu există uși automate, acestea trebuie incluse în conceptul de automatizare: robotul trebuie să poată solicita deschiderea, iar sistemul trebuie să gestioneze corect confirmarea și trecerea. Același lucru este valabil pentru conveyors, lifturi, înfoliatoare, stații automate sau alte mașini cu care roboții trebuie să schimbe semnale.

Wi-Fi-ul și infrastructura IT sunt analizate suficient de devreme pentru ca eventualele modificări să nu fie descoperite în perioada de commissioning. În funcție de platformă și de politica IT a clientului, trebuie clarificate Fleet Manager-ul, serverul sau mașina virtuală pe care va rula, rețeaua, interfețele și accesul necesar pentru integrare și suport.

În paralel trebuie analizate safety-ul și celelalte riscuri ale aplicației. Un robot poate veni cu o arhitectură safety bine definită, dar proiectul trebuie evaluat în mediul concret în care va opera: oameni, alte vehicule, intersecții, puncte de transfer și mașini cu care interacționează.

Site survey-ul nu este, așadar, o verificare dacă robotul „încape pe culoar”. Este etapa în care procesul pe care l-am înțeles inițial este confruntat cu spațiul, infrastructura și modul real de operare.

Dimensionarea și integrarea sistemului

Abia după ce avem suficiente date despre proces putem dimensiona soluția cu mai multă încredere.

Numărul de transporturi este important, dar nu este suficient pentru a stabili numărul de roboți. Contează distanțele, timpii de pickup și delivery, viteza medie realizabilă în mediul respectiv, perioadele de așteptare, regulile de trafic, charging-ul și modul în care cererea de transport variază pe parcursul unui schimb.

Peak-urile sunt deosebit de importante. Două aplicații pot avea același număr total de transporturi pe zi și totuși să necesite capacități diferite dacă într-una dintre ele misiunile sunt relativ uniform distribuite, iar în cealaltă o parte importantă se concentrează într-o perioadă scurtă.

La fel de importante sunt ipotezele folosite în calcul. Dacă presupunem că un culoar este bidirecțional, dar după analiza de safety trebuie operat one-way, traseele se modifică. Dacă roboții trebuie să aștepte frecvent la o intersecție cu stivuitoare, viteza nominală din datasheet nu mai spune mare lucru despre cycle time-ul real. Dacă punctul de predare este deseori ocupat, trebuie să știm ce se întâmplă cu robotul și cu misiunea în acel interval.

Pentru aplicațiile relativ simple, aceste variabile pot fi modelate suficient de bine prin calcule de dimensionare. Pe măsură ce flota crește, traseele se intersectează mai mult și apar mai multe constrângeri, simularea poate deveni utilă pentru a verifica throughput-ul, congestia, charging-ul și regulile de trafic înainte de implementare.

Tot în această etapă se definește integrarea.

Într-o aplicație standalone, fără integrare cu sisteme third-party, o misiune poate fi solicitată local de un operator, printr-un buton fizic sau virtual. În alte aplicații, comenzile vin din WMS, WES, MES sau ERP. Pot exista PLC-uri, conveyors, uși automate, lifturi, înfoliatoare sau alte mașini care trebuie incluse în logica sistemului. Trebuie stabilit cine generează misiunea, ce confirmări sunt necesare și cum sunt tratate situațiile în care una dintre componente nu este disponibilă.

Aceste interfețe influențează și calendarul de implementare. Dacă integrarea necesită dezvoltare din partea clientului, a unui furnizor WMS/MES sau a producătorului unui alt echipament, proiectul nu mai depinde numai de integratorul AMR/AGV.

De la concept la buget și pregătirea implementării

Pentru o ofertă de bugetare nu este întotdeauna necesar ca toate verificările din teren să fie deja închise. Dacă avem date suficient de clare despre fluxuri, volume, unitățile transportate, layout și punctele de pickup și delivery, putem construi un concept, o estimare preliminară și, unde este relevant, o analiză ROI inițială. În alte proiecte, mai ales când spațiul, traficul sau integrarea pot schimba semnificativ soluția, site survey-ul este util încă din această etapă. Ipotezele folosite la bugetare trebuie însă validate pe măsură ce proiectul avansează și înainte ca soluția finală să fie stabilită.

Odată ce aplicația este suficient de bine definită, oferta poate avea mai multă substanță. Nu mai discutăm doar despre prețul roboților, ci despre sistemul necesar pentru aplicația respectivă: roboți, charging, Fleet Manager, engineering, integrări, commissioning, training și suport, plus eventualele modificări de infrastructură.

Am discutat separat despre diferența dintre prețul robotului și costul proiectului în articolul „Cel mai ieftin robot poate deveni cea mai scumpă automatizare”. În etapa de bugetare, ideea devine foarte practică. Două oferte pot porni de la roboți cu prețuri diferite, dar comparația are sens numai dacă includ aceeași aplicație și un scope comparabil.

Pentru companiile care construiesc bugetul cu multe luni înainte de achiziție apare și problema timpului dintre estimare și comanda efectivă. Într-o piață în care costurile tehnologiei, componentelor, transportului sau serviciilor pot varia, nu aș presupune automat că prețurile obținute în perioada de bugetare vor rămâne neschimbate până la execuția proiectului în anul următor. Cursul valutar poate introduce la rândul lui variație, în funcție de structura ofertei. Nu cred că există un procent universal care ar trebui adăugat preventiv unui proiect. Mai util este ca beneficiarul să înțeleagă perioada de valabilitate a ofertei, ce componente ale prețului pot fi revizuite și să prevadă o rezervă rezonabilă acolo unde politica sa de bugetare permite acest lucru.

Scopul nu este creșterea artificială a CAPEX-ului, ci evitarea unei situații în care un proiect aprobat intern ajunge la achiziție cu un buget care nu mai acoperă soluția pe baza căreia a fost construit business case-ul.

Tot înainte de deployment trebuie închise lucrurile care țin de pregătirea site-ului. Integratorul trebuie să livreze la timp configurația, documentația și cerințele tehnice de care depinde implementarea. Beneficiarul trebuie să poată asigura infrastructura și accesul convenite, disponibilitatea oamenilor implicați în proiect și eventualele modificări aflate în responsabilitatea sa.

Cu cât aceste dependențe sunt clarificate mai devreme, cu atât perioada de commissioning este mai predictibilă.

Când roboții ajung în fabrică

Într-un proiect bine pregătit, commissioning-ul nu mai este etapa în care încercăm să descoperim cum ar trebui să funcționeze procesul. Aplicația, stațiile, traseele, interfețele și logica principală au fost deja definite, iar o parte importantă din configurare poate fi pregătită anterior.

În fabrică verificăm și finalizăm ceea ce a fost proiectat. Validăm harta și stațiile, testăm misiunile și interfețele, verificăm comportamentul roboților în condițiile reale de trafic și instruim oamenii care vor lucra cu sistemul. Pentru o flotă, urmărim și interacțiunile dintre roboți, regulile de trafic, charging-ul și comportamentul în situațiile care nu apar într-un test simplu cu un singur robot.

Pentru proiectele cu câțiva roboți și fluxuri relativ standard, această pregătire ne-a permis în unele cazuri să ajungem la Go-Live în a doua zi de deployment. Au existat și proiecte mai complexe în care commissioning-ul a durat una-două săptămâni, ceea ce consider perfect rezonabil raportat la complexitatea aplicației. Durata trebuie privită în raport cu ceea ce trebuie efectiv implementat, nu izolată ca indicator al calității proiectului.

După Go-Live urmează de regulă câteva zile de hypercare. Monitorizăm sistemul onsite și/sau remote și observăm cum se comportă în procesul real. Uneori apar ajustări ale unei priorități, ale unui parametru sau ale modului în care sistemul gestionează o anumită situație. Este firesc: operarea continuă, pe mai multe schimburi și în interacțiune cu oamenii și celelalte echipamente, oferă informații pe care testele de commissioning nu le pot reproduce complet.

Ulterior, sistemul intră în regimul normal de operare și suport. Echipa clientului trebuie să știe cum îl utilizează, ce situații poate gestiona intern și când este nevoie de intervenția integratorului.

Când proiectul este planificat pentru anul următor

O companie care își pregătește astăzi bugetul pentru un proiect de automatizare nu trebuie să aibă deja selectat robotul și nici toate detaliile tehnice rezolvate. Ar fi, de multe ori, prea devreme.

Perioada de bugetare poate fi folosită pentru clarificarea procesului și pentru construirea unui concept suficient de matur încât estimarea tehnică și financiară să se bazeze pe ipoteze apropiate de realitatea din fabrică. În același timp, pot fi identificate din timp interfețele, aprobările interne, modificările de infrastructură și responsabilitățile care necesită implicarea altor echipe.

Pentru companiile care analizează acum un proiect AMR/AGV pentru anul următor, nu este necesar ca toate deciziile tehnice să fie luate imediat. Este însă util ca aplicația să fie suficient de bine definită încât bugetul și calendarul de implementare să poată fi construite pe o bază realistă.