Anatomia cyfrowego krwiobiegu: Jak zhakowaliśmy chaos fabryki za pomocą Middleware i AI. Techniczne Case Study wdrożenia WMS/MES [2/2]

Część IV: Logika biznesowa i algorytmika

Sercem systemu nie jest baza danych, ale logika, która przetwarza surowe informacje w decyzje biznesowe. Najciekawszym wyzwaniem była optymalizacja strat materiałowych.

Case: Algorytm podziału szpuli

Produkcja filamentu jest procesem ciągłym. Z linii zjeżdża „nieskończona” żyłka, która jest nawijana na szpule. Problemem były końcówki serii przy dużych zamówieniach B2B.

Scenariusz: Klient B2B zamawia 100 kg. Produkcja wytworzyła 103 kg. Te 3 kg to odpad? Wcześniej tak.

Rozwiązanie: Zaimplementowaliśmy algorytm decyzyjny w Middleware.

Logika algorytmu:

1. Trigger: Sygnał z wagi na końcu linii produkcyjnej (MES) o zakończeniu zlecenia głównego.

2. Input Data:

• Waga pozostałego materiału (np. 3.4 kg).
• Kolejka zamówień B2C (sklep internetowy).
• Zdefiniowane SKU produktów detalicznych (np. szpule 1kg, 0.5kg).

3. Processing: System symuluje podział reszty. Czy z 3.4 kg można zrobić 3x 1kg + 1x 0.4kg (próbka)?

4. Action: Jeśli tak, system automatycznie generuje w MES „pod-zlecenie” na przewinięcie końcówki, drukuje nowe etykiety dla produktów detalicznych i natychmiast aktualizuje stan magazynowy w sklepie E-commerce jako „Dostępny od ręki”.

To nie jest „Rocket Science” w sensie matematycznym, ale w sensie procesowym to rewolucja. Kod zamienił odpad w produkt.

Zarządzanie wydajnością

Wspomniane „wąskie gardło” w postaci ERP wymusiło na nas kreatywne podejście do wydajności. Nawet jeśli sklep internetowy generuje 100 zamówień na minutę (np. podczas promocji Black Friday), nasz Middleware przyjmuje je natychmiast (wysoka responsywność dla klienta), ale do ERP „kropluje” je w tempie, które ten jest w stanie przetrawić (np. 10 faktur na minutę). Zastosowaliśmy wzorzec CQRS (rozdzielenie zapisu i odczytu) – E-commerce czyta stany z szybkiego Redis/PostgreSQL w Middleware, a nie z wolnego ERP.

Część V: Data Science i AI – Od mitów do inżynierii

Słowo „AI” jest nadużywane w marketingu. W inżynierii oznacza konkretne modele matematyczne. W projekcie MAG-SELL stanęliśmy przed problemem Cold Start – brakiem danych historycznych do trenowania modeli.

Faza 1: Data mining (Rok pierwszy)

Nie da się przewidzieć awarii maszyny, jeśli nie wiesz, jak wygląda jej „zdrowa” praca. Przez pierwsze 12 miesięcy nasz system MES pełnił rolę „czarnej skrzynki” rejestrującej parametry pracy (SCADA integration):

• Amperaż silników.
• Temperatury głowic (sampling co 5 sekund).
• Mikro-przestoje raportowane przez operatorów na tabletach (powód przestoju wybierany z listy, a nie wpisywany ręcznie – kluczowe dla czystości danych!).

Faza 2: Machine learning (Rok drugi)

Po zebraniu datasetu, nasz zespół Data Science przystąpił do pracy. Wybraliśmy algorytm Drzew Decyzyjnych (ID3/C4.5).

Dlaczego? Ponieważ są one interpretowalne. Model „Deep Learning” (sieć neuronowa) dałby wynik „Awaria za 4h”, ale nie powiedziałby dlaczego. Drzewo decyzyjne pozwala wyśledzić ścieżkę: Jeśli Temp > 220C ORAZ Wibracje > Poziom_X -> Ryzyko Awarii Łożyska.

To było kluczowe dla zaufania zespołu utrzymania ruchu. Oni musieli wiedzieć, dlaczego system każe im zatrzymać maszynę.

MLOps w praktyce

Model nie działa w próżni. Wdrożyliśmy prosty pipeline MLOps. Dane z produkcji spływają do Data Lake. Model jest okresowo (raz na kwartał) retrenowany, a zaktualizowane wagi drzewa decyzyjnego są wgrywane do logiki biznesowej MES. To proces ciągłego uczenia się systemu.

Część VI: UI/UX w środowisku „Hostile”

Software house’y często zapominają, że ich użytkownik nie siedzi w klimatyzowanym biurze na fotelu Herman Miller. Użytkownik MAG-SELL stoi przy wtryskarce, w hałasie 80dB, w rękawicach roboczych.

Projektowanie dla operatora (Industrial UX)

Kontrast i jasność: Interfejsy (tryb High Contrast) dostosowane do hal, gdzie oświetlenie bywa ostre lub niedostateczne. Wykorzystaliśmy czujniki światła w tabletach do auto-regulacji.

Obsługa błędów: Komunikaty błędów nie mogą być subtelnym dymkiem „Toast notification”. Błąd na produkcji musi „krzyczeć”. Czerwony ekran, wibracja tabletu, wymóg fizycznego potwierdzenia „Zrozumiałem”.

Logika „Happy Path”: Domyślna ścieżka (wszystko OK) wymaga minimum kliknięć. Często zero – jeśli waga się zgadza i skan kodu jest poprawny, system sam przechodzi dalej. Operator interweniuje tylko przy anomaliach.

Część VII: DevOps i proces wytwórczy

Jak zarządzać projektem, który łączy IT i OT (Operational Technology)?

Metodyka: Water-Scrum-Fall

Czysty Agile w projektach hardware’owych to samobójstwo. Nie da się „zwinne” zamówić i zamontować 50 wag przemysłowych.

Waterfall: Użyliśmy go do harmonogramowania prac infrastrukturalnych, zakupów sprzętu i integracji fizycznych. Tu deadline’y są sztywne.

Scrum: Wykorzystaliśmy go w zespole deweloperskim (Software). Dwutygodniowe sprinty, Daily Stand-upy, JIRA (własny system OMB). Pozwalało nam to adaptować UI i logikę biznesową w reakcji na feedback z hali, ale w ramach sztywnych ram czasowych wdrożenia sprzętu.

QA i Testy

Nie mogliśmy pozwolić sobie na 100% pokrycia testami jednostkowymi (ograniczenia budżetowe klienta).

Strategia Testów:

• Unit Tests (30%): Tylko kluczowe algorytmy (przeliczniki jednostek, logika podziału szpuli, obliczenia finansowe).
• Integration Tests (Priorytet): Testy API, testy komunikacji z hardwarem. Tutaj nie było kompromisów.
• Manual Testing on Site: Nasi testerzy spędzili dni na hali produkcyjnej, w kaskach, klikając w tablety w realnym procesie. Tego nie zastąpi żaden Selenium.
• Podsumowanie: Czego nauczyliśmy się jako Software House?

Projekt MAG-SELL był dla nas poligonem doświadczalnym, który zredefiniował nasze podejście do B2B.

Kluczowe wnioski techniczne:

• Infrastruktura to fundament Software’u. Bez stabilnej sieci LAN (decyzja GOTOMA GENERAL) nasz zaawansowany React na frontendzie byłby bezużyteczny.
• Symulacja hardware’u – posiadanie fizycznych urządzeń (wag, drukarek) w biurze deweloperskim skróciło czas integracji o 50%.
• Zamiast próbować naprawiać stary ERP, obudowaliśmy go nowoczesnym Middleware. To technika „duszenia” (Strangler Pattern), która pozwala na ewolucję systemu bez rewolucji.
• Dane przed AI. Nie sprzedawaj algorytmów, sprzedawaj infrastrukturę do zbierania danych. AI jest wisienką na torcie, ale najpierw musisz upiec tort.

Dla nas, jako inżynierów, największą satysfakcją nie jest faktura opłacona przez klienta. Jest nią moment, w którym wchodzisz na halę i widzisz, że operator nie przeklina na tablet, ale używa go tak naturalnie, jak klucza francuskiego. Widzisz, że Twój kod steruje fizyczną materią, redukuje odpady i sprawia, że fabryka działa jak szwajcarski zegarek.

To jest właśnie przewaga software house’u, który rozumie przemysł. Przewaga grupy GOTOMA GENERAL.

Jak podsumowuje tę współpracę Tomasz Gołąb prezes zarządów spółek GOTOMA GENERAL&GOTOMA SOFTWARE HOUSE?

Cieszę się, że przypadła nam realizacja elementu całego systemu. Zdobyliśmy wiele nowych umiejętności, niemniej bez właściwej koordynacji ze strony generalnego wykonawcy, nie bylibyśmy w stanie zapanować nad całością. Skorzystam z cytatu: Samemu idzie się szybciej, ale we dwójkę dociera się dalej.

Czy chciałbyś porozmawiać o architekturze Twoich systemów produkcyjnych? Jesteśmy inżynierami, nie handlowcami – zapraszamy do kontaktu z naszymi specjalistami.