Ce merită cu adevărat automatizat cu IA într-o fabrică

Cea mai mare parte din ce decide soarta unui proiect de IA într-o fabrică nu este modelarea. Este numirea tipului de problemă pe care îl aveți, a verifica dacă datele dumneavoastră de execuție o pot susține și proiectarea a ceea ce se întâmplă atunci când modelul greșește.

Reguli, machine learning, optimizare și modele lingvistice: care se potrivește cărei probleme

Regulile și statistica vin primele și merită mai mult respect decât primesc. Dacă o regulă pe care un inginer o poate scrie pe hârtie aduce cea mai mare parte din valoare, comparația onestă pentru orice model este cu acea regulă, nu cu a nu face nimic.

Machine learning își merită locul acolo unde relația dintre intrări și rezultat este reală, dar nimeni nu o poate scrie: zeci de parametri de proces care interacționează, un defect care depinde de lotul de material, de umiditatea din hală și de poziția în cuib. Modelul cunoaște condițiile care i-au fost arătate și nu spune nimic util despre condiții pe care nu le-a văzut niciodată.

Optimizarea este o disciplină diferită și este etichetată în mod curent, greșit, drept IA. Programarea unei fabrici cu capacitate finită, secvențierea pentru minimizarea schimbărilor de fabricație, alocarea operatorilor calificați: acestea sunt probleme cu constrângeri și o funcție obiectiv. Nu au nevoie de exemple etichetate, dar au nevoie de timpi de proces și de constrângeri oneste, care de obicei trebuie măsurate, nu presupuse. Pentru planificare, un solver care poate exprima constrângerile dumneavoastră reale de scule și de uscare este aproape întotdeauna instrumentul potrivit, pentru că planificarea este o problemă cu constrângeri, nu o problemă de predicție.

Modelele lingvistice sunt ultimele sosite, iar potrivirea lor este specifică. Se pretează la muncă în formă de document și de conversație: citirea unei cereri de ofertă primite și redactarea uneia structurate, condensarea unui istoric lung de mentenanță în ceva ce un tehnician poate citi înainte să meargă la mașină, răspunsul la ce spune o instrucțiune de lucru despre un reglaj. Nu sunt instrumente de măsură: să ceri unui model lingvistic să prezică defectarea unui rulment din date de vibrații înseamnă să bați un șurub cu ciocanul.

De ce date are nevoie de fapt un proiect de IA într-o fabrică

Un model are nevoie de exemple care să lege o situație de un rezultat, cu suficient context încât o situație să se poată deosebi de alta: un semnal sau un set de condiții legate de un ordin de fabricație, o mașină, o sculă, un lot de material, un operator și un marcaj de timp care este adevărat. Marcajul de timp contează mai mult decât se așteaptă lumea. Dacă confirmările se introduc retroactiv la finalul schimbului, toate evenimentele din acel schimb au aproximativ aceeași oră, iar orice depinde de secvență sau de durată învață obiceiul de introducere a datelor, nu procesul.

Partea de rezultat stă de obicei și mai prost. Mentenanța predictivă are nevoie de defecțiuni consemnate ca defecțiuni, cu o cauză și o dată, nu ca o oprire neplanificată cu câmpul de motiv gol. Predicția calității are nevoie de rebuturi înregistrate pe operație și pe tipul de defect care le-a produs, nu agregate într-o cifră lunară. Prognoza are nevoie de un istoric de consum care să nu fi fost rescris în tăcere de corecții de stoc. În majoritatea fabricilor, intrările trăiesc în historian, iar rezultatele trăiesc într-un caiet de mentenanță sau în foaia de calcul a unei singure persoane.

Testul nu este câți gigaocteți ține historianul, ci dacă puteți extrage, pentru o linie și o familie de produse, un an de rânduri în care fiecare rând poartă condițiile și rezultatul, iar doi oameni care cunosc procesul sunt de acord că rândurile sunt adevărate. Dacă extragerea aceea cere o săptămână de reconciliere manuală, proiectul nu este modelul, ci înregistrarea datelor. De aceea calitatea datelor din MES și din historian este constrângerea determinantă, iar nicio sofisticare de modelare nu recuperează ce nu a fost captat niciodată.

Prognoza cererii și a consumului, unde investiția se recuperează cel mai repede

Prognoza are de obicei cel mai scurt drum spre bani, pentru că alternativa este vizibil slabă: majoritatea fabricilor iau anul trecut și adaugă un procent sau cer vânzărilor o cifră care este de fapt o țintă. Un model care folosește istoricul comenzilor, sezonalitatea, mixul de clienți, pipeline-ul deschis și efectele de calendar bate acest lucru pe articolele cu cerere regulată, repetitivă. Pe articolele intermitente și conduse de proiecte — adesea majoritatea codurilor de articol și o mică parte din volum — de regulă nu îl bate, iar o bază naivă sau de tip Croston este greu de întrecut. Varianta onestă segmentează mai întâi nomenclatorul și lasă acele articole în seama unei politici de stoc și a judecății umane.

Valoarea apare în aval, nu în prognoză în sine: stocul de siguranță se mișcă, momentul aprovizionării se schimbă la articolele cu termen lung de livrare, iar schimbările de fabricație de urgență care distrug un program devin mai rare. Un procent de acuratețe a prognozei pe un slide nu este un beneficiu; zilele de stoc și numărul de urgențe sunt.

Mentenanța predictivă, doar acolo unde modul de defectare chiar este previzibil

Totul aici depinde de măsura în care defecțiunea se dezvoltă gradual și lasă o semnătură în ceva ce puteți măsura. Degradarea rulmenților, dezechilibrul, dezalinierea, înfundarea progresivă a unui filtru sau a unui circuit de răcire, deriva presiunii hidraulice, curentul motorului care crește lent la aceeași operație: acestea se dezvoltă pe parcursul a săptămâni sau luni, ocazional doar ore — ceea ce este de obicei prea târziu ca să merite instrumentat — și se văd în vibrații, curent, temperatură sau presiune. Un model le poate vedea și, de multe ori, la fel poate și un prag bine ales, motiv pentru care comparația cu statistica simplă contează aici.

O placă de comandă care cedează, o sculă ruptă de o plăcuță proastă, o avarie dintr-o eroare de operator: acestea sunt practic instantanee și niciun model nu le prezice dintr-un trend care nu există.

A doua condiție este ca avertizarea să cumpere timp pe care îl puteți folosi. Dacă piesa are un termen lung de livrare și linia nu poate opri înainte de weekend, investiția care se plătește este o politică de piese de schimb, nu un model. Stabiliți fereastra de intervenție înainte de bugetul de senzori.

Predicția calității și reducerea rebuturilor

Calitatea este acolo unde stau de obicei cei mai mulți bani și unde cerințele de date sunt cele mai exigente. Varianta atrăgătoare prezice, din condițiile din timpul rulajului, care piese sau loturi prezintă risc, astfel încât cineva să poată ajusta înainte ca rebutul să fie produs, în loc să îl găsească la inspecția finală.

Funcționează atunci când procesul este instrumentat la rezoluția lucrului pe care vreți să îl preziceți și când rebutul poartă un cod de cauză real, pe operație. Eșuează în tăcere atunci când rebutul este înregistrat la finalul comenzii, pe comandă în ansamblu, pentru că modelul nu mai poate spune ce condiții au produs ce defect.

Un pas neatrăgător se plătește singur înainte de orice model: captarea motivelor de rebut la mașină, în momentul respectiv, dintr-o listă scurtă de cauze pe care operatorul le recunoaște. Multe fabrici care cer predicția calității descoperă numai din aceste date că un număr mic de cauze produc cea mai mare parte a pierderii și o închid pe cea mai mare printr-o modificare tehnică. Acesta este un rezultat bun, nu un proiect eșuat.

IA pentru programarea producției: de ce este o problemă de optimizare, nu de predicție

Dacă planul alunecă în fiecare săptămână, cauza este rareori lipsa de inteligență și de obicei lipsa constrângerilor. Ce schimbă situația este un planificator (APS) care respectă sculele comune, familiile de schimbare de fabricație, calificările operatorilor, timpii de întărire și ferestrele de mentenanță pe care intenționați să le păstrați.

Învățarea ajută aici într-un singur mod îngust, dar real: timpii de proces. Un program construit pe timpi normați pe care nimeni nu i-a remăsurat de ani de zile este precis în privința cifrelor greșite, iar duratele reale captate prin MES pot actualiza valorile cu care planifică sistemul de planificare. Judecați o propunere de programare după constrângerile pe care le poate exprima și după cât de repede replanifică atunci când ceva se rupe; un plan care se regenerează peste noapte este oricum modificat manual la ședința de dimineață.

Detecția anomaliilor pe semnale de energie și de proces

Detecția anomaliilor învață cum arată normalul și semnalează abaterea. Se potrivește semnalelor continue, unde aveți din belșug comportament bun și puține defecte etichetate: consumul de energie pe ciclu, consumul de aer comprimat, performanța chillerului, un semnal de proces a cărui formă este stabilă când lucrurile merg bine.

Puterea ei este că reacționează la ce nu a anticipat nimeni. Slăbiciunea ei este că spune doar că ceva este neobișnuit, niciodată ce anume este greșit, iar o fabrică ce primește alerte neexplicate învață să le ignore. Munca de proiectare nu este detectorul, ci rutarea: ce alerte merg la cine, care este prima verificare și cum se consemnează răspunsul, astfel încât următoarea alertă de aceeași formă să sosească însoțită de istoric.

IA în vânzări și în operațiunile cu clienții, acolo unde munca are formă de document

Partea comercială a unei companii de producție funcționează pe documente și conversații: cereri de ofertă, specificații, oferte, confirmări de comandă, întrebări despre livrare, reclamații. Aici se potrivesc cu adevărat modelele lingvistice, pentru că munca înseamnă citire, extragere, redactare și rezumare.

Concret: o cerere de ofertă primită, descompusă în reper, cantitate, dată solicitată și cerințe speciale, cu ofertele anterioare aduse alături. Un fir de e-mail condensat într-o înregistrare CRM care poartă angajamentul asumat și următoarea acțiune.

Două reguli împiedică derapajul. Modelul redactează, iar omul trimite — cel puțin până când se cunoaște rata de eroare în acel flux de lucru. Și orice este factual — preț, termen de livrare, stoc, dată promisă — vine din sistemul de referință, nu din model, care ar trebui să citeze o valoare căutată și niciodată să genereze una. O automatizare de CRM care inventează un termen de livrare este mai rea decât niciuna, pentru că angajează compania.

Estimarea câștigului înainte de a cumpăra ceva

Numiți pierderea în unități pe care fabrica dumneavoastră le urmărește deja: costul rebuturilor pe lună pe familia de produse în cauză, orele de oprire neplanificată pe mașina-constrângere înmulțite cu cât valorează o oră acolo în contribuție, nu în tarif de mașină, transportul de urgență, stocul imobilizat în reperele pe care o prognoză le-ar mișca, orele pe săptămână petrecute retastând date între sisteme.

Apoi estimați, pesimist, ce parte din acea pierdere ar putea aplicația să atace plauzibil. Mentenanța predictivă nu elimină opririle; în cel mai bun caz transformă unele opriri neplanificate în opriri planificate, pentru modurile de defectare pe care le acoperă. Un model de calitate nu elimină rebutul; scurtează timpul dintre momentul în care procesul o ia razna și momentul în care cineva observă.

Dacă acea cifră onestă, pusă față în față cu un cost total pe durata de viață pentru care ați planifica realmente, inclusiv integrarea și oamenii care îl vor opera, nu trece pragul pe care departamentul dumneavoastră financiar îl aplică oricărei alte investiții de mărimea aceea, proiectul este un experiment științific. Este permis, dar ar trebui finanțat și judecat ca atare.

Cât costă de fapt integrarea

Modelul este de obicei partea ieftină; costul stă în îmbinări. Mai întâi vine scoaterea semnalelor din mașini, iar o fabrică reală are un parc eterogen: unele active vorbesc OPC UA, altele Modbus sau un protocol serial, unele oferă un contact uscat, iar unele unități de comandă închise cer un senzor de retrofit pe arbore, pe circuitul hidraulic sau pe linia de alimentare. Apoi rezultatul trebuie să ajungă undeva unde provoacă o acțiune: un ecran la care operatorul se uită deja, un ordin de lucru deschis în mentenanță, o constrângere transmisă planificatorului, o blocare aplicată în calitate.

După aceea vine reconcilierea datelor de bază, pe care nimeni nu o include în ofertă. Coduri de articol care diferă printr-un sufix între sisteme, unități de măsură care nu se potrivesc, o listă de materiale întreținută în două locuri, identificatori de mașini care s-au schimbat când linia a fost rearanjată. Nimic din toate acestea nu este dificil și toate durează mai mult decât software-ul. O ofertă care pune preț pe model și lasă îmbinările ca „integrare de definit” nu este un preț.

Cine operează modelul și ce se întâmplă când greșește

Fiecare model pus în producție are nevoie de un proprietar cu nume, iar întrebarea de achiziție este cine din organizația dumneavoastră va fi acela. Omul acela trebuie să știe pe ce a fost antrenat modelul, ce condiții cad în afara acelui domeniu, de ce a produs un anumit rezultat și cum să îl scoată din buclă fără să oprească producția. Un model care nu mai răspunde trebuie să cadă înapoi pe ceea ce controla procesul înaintea lui — planul de eșantionare, pragul, verificarea operatorului — și nu pe o poartă deschisă sau pe o linie blocată. Decideți care dintre acestea este înainte de punerea în funcțiune.

Explicabilitatea nu este o preocupare filozofică în hala de producție, este o condiție de adopție. O recomandare care spune ce semnal s-a mișcat, cu cât și față de ce referință este pusă în practică. Un scor fără explicație este ignorat, iar odată ce ignorarea lui devine rutină, sistemul este decor.

Excesul de alerte distruge încrederea mai repede decât ratările, din același motiv pentru care o rată prea mare de respingere o distruge la o stație de inspecție: o alarmă falsă este imediat vizibilă și pentru toată lumea, o ratare rămâne invizibilă până când sosește defecțiunea. Proiectați rata de alertare în jurul atenției realmente disponibile în hală și rutați banda incertă către un om, nu către linie.

Guvernanță, derivă și povara de întreținere pe care nimeni nu o bugetează

Un model este un instantaneu al procesului dumneavoastră din momentul în care a fost antrenat, iar procesul dumneavoastră se mișcă: un furnizor nou, o recondiționare de sculă, o revizie de reper, o rearanjare de linie, un mix de produse schimbat, un senzor înlocuit cu unul ușor diferit. Fiecare poate deplasa intrările suficient încât modelul de ieri să fie, în tăcere, greșit azi, iar modul de defectare nu este un mesaj de eroare, ci un sfat din ce în ce mai prost.

Monitorizați intrările, nu doar ieșirile, pentru că deriva intrărilor apare înaintea degradării rezultatelor. Păstrați un set de test reținut, cu cazuri reale, inclusiv cele la limită, ca un model nou să poată fi comparat onest cu cel curent. Versionați modelul și consemnați ce versiune a produs ce recomandare; după o reantrenare, rezultatele de ieri au venit de la un alt judecător.

Și bugetați efortul continuu. Un model în producție este un activ întreținut, mai aproape de un echipament de proces decât de un raport cumpărat. Dacă nimeni nu are timp alocat pentru reantrenare, pentru analiza alertelor și pentru verificarea faptului că datele încă sosesc, se va degrada până când oamenii încetează să îl mai folosească.

Un prim proiect realist, cu criterii de acceptanță

Alegeți o singură pierdere numită, pe o linie sau pe o familie de produse, enunțată ca o propoziție cu o cifră în ea: rebutăm atât pe operația asta, pierdem atâtea ore de constrângere pe mașina asta, ținem atâta stoc pentru că nu putem prognoza familia asta. Dacă proiectul nu poate fi enunțat așa, nu este pregătit.

Înainte să cumpărați ceva, faceți extragerea de date. Un an, o linie, condiții și rezultate în aceleași rânduri, doi oameni care cunosc procesul confirmând că rândurile sunt adevărate. Apoi comparați cu alternativa simplă: un prag, o fișă de control sau judecata actualului planificator.

Scrieți criteriile de acceptanță în unități de fabrică înainte de punerea în funcțiune, în perechi, astfel încât compromisul să fie explicit. Pentru mentenanța predictivă, un număr declarat de moduri de defectare acoperite, prinse cu cel puțin o săptămână de avertizare, față de un număr plafonat de alerte false pe lună. Pentru prognoză, o reducere declarată a zilelor de stoc pe familiile modelate, fără creșterea rupturilor de stoc. Pentru calitate, o reducere declarată a rebuturilor pe operația-țintă față de aceleași luni ale anului trecut, cu modificările de proces consemnate alături.

Numiți proprietarul, comportamentul la defectare și programul de reantrenare în același document și stabiliți o dată de revizuire cu opțiunea onestă de a opri. Un prim proiect care se încheie cu decizia de a nu extinde, luată pe dovezi, este un succes. Un pilot care devine o demonstrație permanentă nu este.

Unde se încadrează Meta Smart Factory

Meta Smart Factory este modular, iar asta contează aici pentru că modulul de IA și machine learning stă deasupra stratului de execuție, nu alături de el. MES-ul furnizează evenimentele și contextul, conectivitatea IIoT și OPC UA furnizează semnalele de la mașini, modulul de Calitate furnizează rebuturile cu cauze, Mentenanța furnizează istoricul defecțiunilor, iar APS-ul consumă rezultatul acolo unde răspunsul este un program, nu o predicție.

Puteți începe cu un singur modul pe o singură constrângere numită și îl puteți adăuga pe următorul odată ce primul este în uz. Ce nu elimină nicio platformă este partea grea: să cădeți de acord asupra semnificației cifrelor, să obțineți captarea cauzelor la mașină și să decideți cine deține un model atunci când acesta greșește. O discuție despre această succesiune pentru o fabrică anume este o primă conversație mai utilă decât o demonstrație, pentru că o demonstrație va funcționa întotdeauna.