📅 · 4 min czytania · Zespół Meta Smart Factory
Prawie każde demo AI pokazywane producentowi działa. Pożyteczne pytanie brzmi, czy to samo zadziała również na Twojej hali, na Twoich danych, w przyszłym kwartale, gdy osoba odpowiedzialna za to rozwiązanie będzie na urlopie. Ta strona jest dla inżyniera, który ma realny problem i nie potrafi jeszcze rozróżnić, która z czterech czy pięciu różnych rzeczy nazywanych wspólnie „AI” jest mu właśnie oferowana.
O losie projektu AI w fabryce w większości nie decyduje modelowanie. Decyduje nazwanie tego, jaki rodzaj problemu się ma, sprawdzenie, czy dane z realizacji produkcji są w stanie go udźwignąć, i zaprojektowanie tego, co się dzieje, gdy model się myli.
Reguły i statystyka są pierwsze i zasługują na więcej szacunku, niż dostają. Jeśli reguła, którą inżynier potrafi spisać, daje większość wartości, uczciwym punktem odniesienia dla każdego modelu jest właśnie ta reguła, a nie nicnierobienie.
Uczenie maszynowe zarabia na swoje miejsce tam, gdzie zależność między danymi wejściowymi a wynikiem jest realna, ale nikt nie potrafi jej spisać: dziesiątki wzajemnie oddziałujących parametrów procesu, wada zależna od partii materiału, wilgotności otoczenia i położenia w gnieździe formy. Model zna warunki, które mu pokazano, i nie mówi nic sensownego o warunkach, których nigdy nie widział.
Optymalizacja to osobna dyscyplina i rutynowo bywa błędnie nazywana AI. Harmonogramowanie zakładu o skończonych mocach produkcyjnych, sekwencjonowanie minimalizujące przezbrojenia, przydzielanie wykwalifikowanych operatorów: to problemy z ograniczeniami i funkcją celu. Nie potrzebują przykładów z etykietami, potrzebują natomiast uczciwych czasów procesu i ograniczeń, które zwykle trzeba zmierzyć, a nie założyć. Do planowania niemal zawsze właściwym narzędziem jest solver potrafiący wyrazić Twoje rzeczywiste ograniczenia oprzyrządowania i suszenia, bo planowanie jest problemem z ograniczeniami, a nie problemem predykcyjnym.
Modele językowe są najnowszym przybyszem i ich dopasowanie jest konkretne. Nadają się do pracy o kształcie dokumentu i rozmowy: przeczytanie przychodzącego zapytania i sporządzenie na jego podstawie ustrukturyzowanego, sprowadzenie długiej historii utrzymania ruchu do czegoś, co technik może przeczytać, zanim podejdzie do maszyny, odpowiedź na pytanie, co instrukcja pracy mówi o danym ustawieniu. Nie są przyrządami pomiarowymi: proszenie modelu językowego o przewidzenie awarii łożyska na podstawie danych drganiowych to wbijanie wkrętu młotkiem.
Model potrzebuje przykładów łączących sytuację z wynikiem, z kontekstem wystarczającym, by odróżnić jedną sytuację od drugiej: sygnał lub zestaw warunków powiązany ze zleceniem, maszyną, narzędziem, partią materiału, operatorem i ze znacznikiem czasu, który jest prawdziwy. Znacznik czasu ma większe znaczenie, niż się ludziom wydaje. Jeśli potwierdzenia są wprowadzane wstecz na koniec zmiany, wszystkie zdarzenia tej zmiany mają ten sam przybliżony czas, a wszystko, co zależy od kolejności lub czasu trwania, uczy się nawyku wprowadzania danych zamiast procesu.
Ze stroną wyniku jest zazwyczaj gorzej. Utrzymanie predykcyjne potrzebuje awarii zarejestrowanych jako awarie, z przyczyną i datą, a nie jako nieplanowany postój z pustym polem przyczyny. Predykcja jakości potrzebuje braków zaksięgowanych na operację i na typ wady, która je spowodowała, a nie zagregowanych do miesięcznej liczby. Prognozowanie potrzebuje historii zużycia, która nie została po cichu przepisana przez korekty stanów magazynowych. W większości zakładów dane wejściowe żyją w historianie, a wyniki w zeszycie utrzymania ruchu albo w arkuszu jednej osoby.
Testem nie jest to, ile gigabajtów mieści historian, lecz to, czy potrafisz wyciągnąć dla jednej linii i jednej rodziny produktów rok wierszy, w których każdy wiersz niesie warunki i wynik, a dwie osoby znające proces zgadzają się, że te wiersze są prawdziwe. Jeśli taki eksport zajmuje tydzień ręcznego uzgadniania, to projektem nie jest model, tylko zapis danych. Dlatego to jakość danych MES i historiana jest wiążącym ograniczeniem, a żadne wyrafinowanie modelowania nie odzyska tego, czego nigdy nie zarejestrowano.
Prognozowanie ma zwykle najkrótszą drogę do pieniędzy, bo alternatywa jest widocznie słaba: większość zakładów bierze zeszły rok i dodaje procent albo prosi sprzedaż o liczbę, która tak naprawdę jest celem. Model korzystający z historii zamówień, sezonowości, miksu klientów, otwartego lejka sprzedaży i efektów kalendarzowych bije to na indeksach o regularnym, powtarzalnym popycie. Na indeksach sporadycznych i projektowych, czyli często na większości numerów katalogowych i małej części wolumenu, zwykle nie bije, a naiwny punkt odniesienia lub metoda Crostona są trudne do pobicia. Uczciwa wersja najpierw segmentuje katalog i pozostawia te indeksy polityce zapasów i ocenie człowieka.
Wartość ujawnia się dalej w procesie, a nie w samej prognozie: zmieniają się zapasy bezpieczeństwa, zmienia się moment zakupu indeksów o długim czasie realizacji, a awaryjne przezbrojenia rujnujące harmonogram stają się rzadsze. Procent dokładności prognozy na slajdzie nie jest korzyścią; korzyścią są dni zapasu i liczba zamówień przyspieszonych.
Wszystko zależy tu od tego, czy uszkodzenie rozwija się stopniowo i zostawia sygnaturę w czymś, co da się zmierzyć. Degradacja łożyska, niewyważenie, niewspółosiowość, postępujące zatykanie filtra lub obiegu chłodzenia, dryf ciśnienia hydraulicznego, prąd silnika rosnący na tej samej operacji: to rozwija się przez tygodnie lub miesiące, sporadycznie tylko przez godziny, co zwykle jest zbyt późno, by opłacało się oprzyrządowanie, i widać to w drganiach, prądzie, temperaturze lub ciśnieniu. Model może to zobaczyć, a często może też dobrze dobrany próg, i właśnie dlatego porównanie z prostą statystyką ma tu znaczenie.
Padnięcie płyty sterownika, narzędzie złamane przez wadliwą płytkę, uszkodzenie wynikające z błędu operatora: to zdarzenia praktycznie natychmiastowe i żaden model nie przewidzi ich z trendu, którego nie ma.
Drugim warunkiem jest to, że ostrzeżenie musi kupić czas, który da się wykorzystać. Jeśli część ma długi czas dostawy, a linia nie może się zatrzymać przed weekendem, inwestycją, która się zwraca, jest polityka części zamiennych, a nie model. Ustal okno interwencji przed budżetem na czujniki.
Jakość to obszar, w którym zwykle leży najwięcej pieniędzy i w którym wymagania wobec danych są najostrzejsze. Atrakcyjna wersja przewiduje na podstawie warunków panujących podczas produkcji, które detale lub partie są zagrożone, tak aby ktoś mógł skorygować proces, zanim powstanie brak, zamiast wykrywać go na kontroli końcowej.
Działa to wtedy, gdy proces jest oprzyrządowany w rozdzielczości tego, co chcesz przewidzieć, i gdy brak niesie realny kod przyczyny przypisany do operacji. Zawodzi po cichu, gdy braki księguje się na koniec zlecenia na całe zlecenie, bo model nie potrafi wtedy powiedzieć, które warunki wywołały którą wadę.
Jeden nieefektowny krok zwraca się, zanim zrobi to jakikolwiek model: rejestrowanie przyczyn braków przy maszynie, w momencie ich powstania, z krótkiej listy przyczyn, które operator rozpoznaje. Wiele zakładów proszących o predykcję jakości odkrywa z samych tych danych, że niewielka liczba przyczyn odpowiada za większość strat, i zamyka największą z nich zmianą konstrukcyjną. To dobry wynik, a nie nieudany projekt.
Jeśli plan sypie się co tydzień, przyczyną rzadko jest brak inteligencji, a zwykle brak ograniczeń. Zmienia to system harmonogramowania uwzględniający współdzielone oprzyrządowanie, rodziny przezbrojeń, uprawnienia operatorów, czasy sezonowania oraz okna utrzymania ruchu, których zamierzasz dotrzymać.
Uczenie pomaga tu w jeden wąski, ale realny sposób: czasy procesu. Harmonogram zbudowany na normatywach, których nikt nie zmierzył ponownie od lat, jest precyzyjny co do złych liczb, a rzeczywiste czasy trwania rejestrowane przez MES mogą zaktualizować dane, na których planuje system harmonogramowania. Oceniaj propozycję systemu harmonogramowania po ograniczeniach, które potrafi wyrazić, i po tym, jak szybko przeplanowuje, gdy coś się psuje; plan, którego regeneracja trwa całą noc, i tak zostanie nadpisany ręcznie na porannej odprawie.
Wykrywanie anomalii uczy się, jak wygląda normalność, i sygnalizuje odchylenie. Nadaje się do sygnałów ciągłych, gdzie masz dużo dobrego zachowania i mało oznaczonych usterek: pobór energii na cykl, zużycie sprężonego powietrza, sprawność agregatu chłodniczego, sygnał procesowy o kształcie stabilnym, gdy wszystko jest w porządku.
Jego siłą jest reagowanie na to, czego nikt nie przewidział. Jego słabością jest to, że mówi tylko, iż coś jest nietypowe, nigdy zaś, co jest nie tak, a zakład otrzymujący niewyjaśnione alerty uczy się je ignorować. Pracą projektową jest nie detektor, lecz routing: które alerty trafiają do kogo, jaka jest pierwsza czynność sprawdzająca i jak zapisuje się reakcję, aby kolejny alert o tym samym kształcie przyszedł już z dołączoną historią.
Handlowa strona firmy produkcyjnej działa na dokumentach i rozmowach: zapytania, specyfikacje, oferty, potwierdzenia zamówień, pytania o dostawę, reklamacje. To jest naprawdę miejsce, w którym modele językowe pasują, bo praca polega na czytaniu, wyciąganiu danych, redagowaniu i streszczaniu.
Konkretnie: przychodzące zapytanie rozłożone na indeks, ilość, żądaną datę i wymagania specjalne, z podciągniętymi obok wcześniejszymi ofertami. Wątek e-mailowy sprowadzony do wpisu w CRM niosącego złożone zobowiązanie i następne działanie.
Dwie zasady chronią to przed wykolejeniem. Model redaguje, a człowiek wysyła, przynajmniej dopóki nie jest znany poziom błędu w danym przepływie pracy. I wszystko, co jest faktem, czyli cena, czas realizacji, stan magazynowy, obiecana data, pochodzi z systemu źródłowego, a nie z modelu, który powinien cytować odczytaną wartość, a nigdy jej nie generować. Automatyzacja CRM, która wymyśla czas realizacji, jest gorsza niż jej brak, bo zobowiązuje firmę.
Nazwij stratę w jednostkach, które Twój zakład już śledzi: koszt braków miesięcznie na danej rodzinie produktów, godziny nieplanowanych przestojów na maszynie stanowiącej ograniczenie pomnożone przez to, ile taka godzina jest tam warta w marży pokrycia, a nie w stawce maszynowej, fracht ekspresowy, zapasy zamrożone w indeksach, którymi ruszyłaby prognoza, godziny tygodniowo spędzane na przepisywaniu danych między systemami.
Następnie oszacuj, pesymistycznie, jaką część tej straty dane zastosowanie jest w stanie realnie objąć. Utrzymanie predykcyjne nie eliminuje przestojów; w najlepszym razie zamienia część nieplanowanych postojów w planowane, dla tych postaci uszkodzeń, które obejmuje. Model jakościowy nie usuwa braków; skraca czas między tym, jak proces zaczyna schodzić z toru, a tym, gdy ktoś to zauważy.
Jeśli ta uczciwa liczba, zestawiona z całkowitym kosztem w okresie, który faktycznie byś zaplanował, wraz z integracją i ludźmi, którzy będą to prowadzić, nie przechodzi progu, jaki Twój dział finansowy stosuje do każdej innej inwestycji tej wielkości, to projekt jest eksperymentem naukowym. To jest dozwolone, ale powinno być jako takie finansowane i oceniane.
Model jest zwykle tanią częścią; koszt siedzi w szwach. Najpierw trzeba ściągnąć sygnały z maszyn, a realny zakład to mieszany park: część maszyn mówi OPC UA, część Modbusem lub protokołem szeregowym, część udostępnia styk bezpotencjałowy, a przy części zamkniętych sterowników trzeba doposażyć czujnik na wrzecionie, w obiegu hydraulicznym albo na linii zasilania. Potem wynik musi wylądować gdzieś, gdzie wywoła działanie: na ekranie, na który operator i tak patrzy, w zleceniu pracy założonym w utrzymaniu ruchu, w ograniczeniu przekazanym do systemu harmonogramowania, w blokadzie nałożonej w jakości.
Potem przychodzi uzgadnianie danych podstawowych, którego nikt nie wycenia. Indeksy różniące się sufiksem między systemami, jednostki miary, które się nie zgadzają, BOM utrzymywany w dwóch miejscach, identyfikatory maszyn zmienione przy przestawianiu linii. Nic z tego nie jest trudne i wszystko trwa dłużej niż oprogramowanie. Oferta, która wycenia model i pozostawia szwy jako „integrację do doprecyzowania”, nie jest ceną.
Każdy wdrożony model potrzebuje właściciela z imienia i nazwiska, a pytaniem zakupowym jest, kto w Twojej organizacji nim będzie. Ta osoba musi wiedzieć, na czym model był uczony, jakie warunki wykraczają poza to, dlaczego wygenerował dany wynik i jak wyjąć go z pętli bez zatrzymywania produkcji. Model, który przestaje odpowiadać, musi wrócić do tego, co sterowało procesem wcześniej, czyli do planu kontroli, progu albo sprawdzenia przez operatora, a nie do otwartej bramki ani do zablokowanej linii. Zdecyduj przed uruchomieniem produkcyjnym, które z nich to będzie.
Wyjaśnialność nie jest na hali produkcyjnej zmartwieniem filozoficznym, tylko warunkiem przyjęcia rozwiązania. Rekomendacja mówiąca, który sygnał się zmienił, o ile i względem jakiej bazy, spotyka się z działaniem. Wynik bez uzasadnienia zostaje nadpisany, a gdy nadpisywanie staje się rutyną, system jest dekoracją.
Nadmiar alertów niszczy zaufanie szybciej niż niewykryte przypadki, z tego samego powodu, dla którego na stanowisku kontroli niszczy je nadmierne odrzucanie: fałszywy alarm jest widoczny natychmiast i dla wszystkich, a przeoczenie pozostaje niewidoczne aż do awarii. Zaprojektuj częstość alertów wokół uwagi, która jest faktycznie dostępna na hali, a pasmo niepewności kieruj do człowieka, a nie na linię.
Model jest migawką Twojego procesu z chwili, w której był uczony, a Twój proces się zmienia: nowy dostawca, regeneracja narzędzia, rewizja detalu, przestawienie linii, zmieniony miks produktów, czujnik wymieniony na nieco inny. Każda z tych rzeczy może przesunąć dane wejściowe na tyle, że wczorajszy model jest dziś po cichu błędny, a postacią awarii nie jest komunikat o błędzie, lecz stopniowo coraz gorsze podpowiedzi.
Monitoruj dane wejściowe, a nie tylko wyniki, bo dryf wejść ujawnia się wcześniej niż pogorszenie rezultatów. Utrzymuj odłożony zbiór testowy z rzeczywistymi przypadkami, łącznie z granicznymi, aby nowy model dało się uczciwie porównać z obecnym. Wersjonuj model i zapisuj, która wersja wygenerowała którą rekomendację; po ponownym uczeniu wczorajsze wyniki pochodzą od innego sędziego.
I zabudżetuj bieżący nakład pracy. Model na produkcji jest utrzymywanym zasobem, bliższym wyposażeniu procesowemu niż kupionemu raportowi. Jeśli nikt nie ma przydzielonego czasu na ponowne uczenie, przeglądanie alertów i sprawdzanie, czy dane wciąż napływają, model będzie się degradował, aż ludzie przestaną go używać.
Wybierz jedną nazwaną stratę na jednej linii lub jednej rodzinie produktów, wyrażoną zdaniem, w którym jest liczba: tyle a tyle braków generujemy na tej operacji, tyle godzin tracimy na tej maszynie stanowiącej ograniczenie, tyle zapasu trzymamy, bo nie potrafimy prognozować tej rodziny. Jeśli projektu nie da się tak sformułować, nie jest gotowy.
Zanim cokolwiek kupisz, zrób eksport danych. Rok, jedna linia, warunki i wyniki w tych samych wierszach, dwie osoby znające proces potwierdzające, że wiersze są prawdziwe. Potem porównaj z prostą alternatywą: progiem, kartą kontrolną albo oceną obecnego planisty.
Zapisz kryteria akceptacji w jednostkach zakładu przed uruchomieniem produkcyjnym, parami, tak aby kompromis był jawny. Dla utrzymania predykcyjnego: określona liczba objętych postaci uszkodzeń wykrytych z wyprzedzeniem co najmniej tygodnia, przy ograniczonej liczbie fałszywych alertów miesięcznie. Dla prognozowania: określone obniżenie dni zapasu na modelowanych rodzinach bez wzrostu braków towaru. Dla jakości: określone obniżenie braków na docelowej operacji w porównaniu z tymi samymi miesiącami rok wcześniej, wraz z zapisanymi obok zmianami procesu.
Nazwij w tym samym dokumencie właściciela, zachowanie w razie awarii i harmonogram ponownego uczenia oraz wyznacz datę przeglądu z uczciwą opcją zatrzymania. Pierwszy projekt kończący się decyzją o nierozszerzaniu, podjętą na podstawie dowodów, jest sukcesem. Pilotaż, który staje się stałym pokazem, nie jest.
Meta Smart Factory jest modułowa i ma to tu znaczenie, bo moduł AI i uczenia maszynowego siedzi na warstwie realizacji produkcji, a nie obok niej. MES dostarcza zdarzenia i kontekst, łączność IIoT i OPC UA dostarczają sygnały z maszyn, moduł jakości dostarcza braki z przyczynami, utrzymanie ruchu dostarcza historię awarii, a APS konsumuje wynik tam, gdzie odpowiedzią jest harmonogram, a nie predykcja.
Możesz zacząć od jednego modułu na jednym nazwanym ograniczeniu i dołożyć kolejny, gdy pierwszy będzie już używany. Czego żadna platforma nie usuwa, to trudna część: uzgodnienie, co znaczą liczby, doprowadzenie do rejestrowania przyczyn przy maszynie i zdecydowanie, kto jest właścicielem modelu, gdy ten się myli. Rozmowa o tej kolejności dla konkretnego zakładu jest pożyteczniejszą pierwszą rozmową niż demonstracja, bo demonstracja zawsze zadziała.
Porozmawiaj z naszymi ekspertami