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

W świecie software developmentu istnieje pewna niepisana zasada: im bliżej fizycznego sprzętu znajduje się kod, tym trudniej go napisać, utrzymać i debugować. Większość software house’ów żyje w bezpiecznej bańce chmury obliczeniowej, REST API i kontenerów Docker, gdzie jedynym ograniczeniem jest przepustowość łącza lub limity pamięci RAM na instancji AWS. My, w GOTOMA SOFTWARE HOUSE, jako technologiczne ramię grupy GOTOMA GENERAL, operujemy w innej rzeczywistości. Nasz kod nie tylko przetwarza dane – on waży, mierzy, etykietuje i decyduje o ruchu materii w świecie rzeczywistym.

Poniższe studium przypadku to techniczna sekcja zwłok jednego z naszych najbardziej wymagających projektów transformacyjnych dla klienta z branży produkcji materiałów do druku 3D. Nie jest to historia o „sukcesie biznesowym” – to zostawiamy działom marketingu. To jest historia inżynieryjna o walce z długiem technologicznym, o integrowaniu systemów, które nigdy nie miały ze sobą rozmawiać, i o budowaniu architektury odpornej na najtrudniejszy czynnik w każdym systemie IT: czynnik ludzki w surowym środowisku przemysłowym.

Celem tego dokumentu jest pokazanie CTO i Tech Leadom, jak w praktyce wygląda proces cyfryzacji „od kabla do algorytmu”, z jakimi realnymi problemami (nie tymi z podręczników) przychodzi się zmierzyć i dlaczego w przemyśle 4.0 „czysty kod” to za mało, jeśli nie rozumie on praw fizyki.

Część I: Faza odkrywcza i definiowanie problemu technicznego

Kiedy wchodzimy do projektu jako Software House, zazwyczaj dostajemy specyfikację lub zestaw User Stories. W tym przypadku dostaliśmy chaos. Klient operował na „systemie” składającym się z arkuszy Excel, papierowych obiegów dokumentów i przestarzałego oprogramowania do fakturowania, które eufemistycznie nazywano ERP.

Stan zastany

Z perspektywy inżyniera, sytuacja wyglądała następująco:

• Brak struktury danych: Dane o stanach magazynowych istniały tylko w głowach pracowników lub na kartkach. Brakowało cyfrowej reprezentacji (Digital Twin) magazynu.
• Fragmentacja środowiska IT: System sprzedaży nie miał żadnego (nawet API) połączenia z produkcją. Synchronizacja danych odbywała się manualnie (retyping), co generowało błędy rzędu 15-20%.
• Shadow IT: Kluczowe procesy decyzyjne opierały się na rozłącznych arkuszach Excel i ręcznych notatkach, co uniemożliwiało bieżącą analizę danych i uzależniało firmę od pamięci poszczególnych pracowników.

Wyzwanie: zrozumieć niewypowiedziane

Największym wyzwaniem fazy odkrywania i definiowania problemu technicznego nie było zrozumienie, jaki kod napisać, ale zrozumienie, jak działa fabryka. Tradycyjne warsztaty z tablicą Miro zawiodły, ponieważ użytkownicy końcowi (magazynierzy, operatorzy) nie potrafili opisać swoich procesów w języku wymagań IT.

Zastosowaliśmy technikę prototypowania w oparciu o narzędzia UI/UX (Figma). Zamiast pytać: „Jakie pola ma mieć formularz przyjęcia towaru?”, stworzyliśmy interaktywną makietę na tablecie i daliśmy ją do ręki kierownikowi zmiany.

Reakcja: „To jest bez sensu, nie mam czasu klikać trzy razy. Mam brudne ręce”.

Wniosek: UI musi być „One-Click”, przyciski muszą być ogromne, a flow liniowe.

Dzięki temu stworzyliśmy Proof of Concept (PoC), który nie był kawałkiem kodu backendowego, ale wizualną reprezentacją logiki biznesowej. Zweryfikowaliśmy w ten sposób założenia dotyczące przepływu danych (Data Flow) między WMS (Warehouse Management System), MES (Manufacturing Execution System) i E-commerce, zanim zainicjowaliśmy środowisko deweloperskie.

Część II: Architektura systemu – decyzje i kompromisy

Projektowanie systemu dla przemysłu to sztuka kompromisu między nowoczesnością a niezawodnością. Nie mogliśmy użyć najmodniejszych frameworków JS, jeśli istniało ryzyko, że nie będą one stabilne na tabletach przemysłowych o ograniczonej mocy obliczeniowej.

Wzorzec architektoniczny: Modularyzacja z centralnym „Middleware”

Głównym problemem technicznym był istniejący system ERP (do fakturowania). Miał on zamkniętą architekturę, brak dokumentacji API i fatalną wydajność przy próbach równoległego odpytywania.

Zamiast integrować WMS, MES i E-commerce bezpośrednio z ERP, zbudowaliśmy autorską warstwę pośrednią – Middleware.

Rola Middleware:

• Single source of truth: To tutaj, a nie w ERP, znajduje się „prawda” o stanach magazynowych w czasie rzeczywistym.
• Buforowanie i kolejkowanie: Middleware przyjmuje tysiące zapytań z czujników IoT i tabletów, a do ERP wysyła tylko skonsolidowane dane (np. raz na 10 minut lub per zakończone zamówienie) w celu wystawienia dokumentów księgowych.
• Logika biznesowa: Cała inteligencja (algorytmy podziału, rezerwacje, walidacja) została zaszyta tutaj.

Tech Stack (Stos Technologiczny) – Pragmatyzm inżynieryjny

Dlaczego wybraliśmy te technologie? Oto nasza argumentacja za i przeciw:

Backend: Symfony (PHP) + .NET Core

Dlaczego Symfony? Potrzebowaliśmy dojrzałego frameworka do obsługi skomplikowanej logiki biznesowej w Middleware. PHP 8.x w połączeniu z Symfony zapewnia szybkość developmentu, doskonałą obsługę DI (Dependency Injection) i łatwość znalezienia programistów (utrzymywalność).

Dlaczego .NET? Do komunikacji ze sprzętem (wagi, drukarki etykiet). Biblioteki C# najlepiej radzą sobie z natywnymi sterownikami urządzeń przemysłowych i protokołami szeregowymi (COM/USB). Stworzyliśmy mikroserwisy w .NET działające jako „przejściówki” (adapters) między hardwarem a naszym API.

Baza Danych: Relacyjna (SQL)

Decyzja: W systemach klasy WMS/E-commerce, gdzie każda sztuka towaru przelicza się bezpośrednio na przychód, spójność danych (Data Consistency) jest nienegocjowalna. Odrzuciliśmy rozwiązania typu NoSQL („eventual consistency”) na rzecz klasycznej, transakcyjnej bazy danych zgodnej ze standardem ACID. Priorytetem była integralność danych przy wysokiej współbieżności zapytań generowanych przez Middleware oraz niezawodność w relacjach wiele-do-wielu (zamówienia-produkty-lokalizacje).

Komunikacja: Hybryda REST i GraphQL

REST API: Wykorzystane do komunikacji System-to-System (np. waga -> middleware). Jest lekkie, bezstanowe i łatwe do debugowania.

GraphQL: Zastosowane w panelach zarządczych (Dashboardach). Managerowie potrzebują widzieć zagregowane dane z wielu źródeł (produkcja + sprzedaż + magazyn) w jednym widoku. GraphQL pozwolił uniknąć problemu over-fetching i under-fetching danych, drastycznie przyspieszając działanie frontendy analitycznego.

Frontend: React

Wybrany ze względu na komponentowość i wydajność wirtualnego DOM. Kluczowe było stworzenie interfejsów PWA (Progressive Web Apps), które działają płynnie na tabletach przemysłowych, nawet przy chwilowych spadkach jakości połączenia sieciowego (choć to ryzyko zminimalizowaliśmy infrastrukturą, o czym później).

Część III: „Hard” w software – Integracja z IoT i światem fizycznym

To jest ten moment, w którym większość software house’ów „wykłada się” na projektach przemysłowych. Kod musi wyjść poza serwer.

Wyzwanie 1: Sterowniki i protokoły

Musieliśmy zintegrować system z wagami przemysłowymi (DIBAL), drukarkami etykiet (Zebra) i terminalami płatniczymi/fiskalnymi (Novitus). Każdy producent dostarcza SDK, ale…

SDK często są przestarzałe lub niekompatybilne z nowymi wersjami systemów operacyjnych.

Dokumentacja bywa szczątkowa.

Urządzenia zachowują się inaczej w warunkach laboratoryjnych, a inaczej na hali (zakłócenia).

Rozwiązanie: Dzięki przynależności do GOTOMA GENERAL, mieliśmy dostęp do fizycznych urządzeń na etapie dewelopmentu. Zbudowaliśmy w biurze „symulator stanowiska pakowania”. Każdy commit dotyczący modułu ważenia był testowany na prawdziwej wadze podłączonej do komputera dewelopera. Napisaliśmy własną warstwę abstrakcji (wrapper) w .NET, która ujednolicała komunikację. Niezależnie od tego, czy podłączyliśmy wagę marki X czy Y, nasz Middleware dostawał ten sam sformatowany obiekt JSON.

Wyzwanie 2: Sieć i infrastruktura

W fazie koncepcyjnej rozważaliśmy oparcie komunikacji tabletów na hali o sieć WiFi Mesh. Wydawało się to nowoczesne i elastyczne. Jednak nasi koledzy „od kabli” z GOTOMA GENERAL ostrzegli nas: Hala produkcyjna to elektromagnetyczne piekło. Silniki, falowniki, metalowe regały – to wszystko zabija WiFi.

Decyzja architektoniczna: Tablet przy maszynie nie jest urządzeniem mobilnym – jest terminalem stacjonarnym. Zdecydowaliśmy się na sztywne połączenie Ethernet (LAN) doprowadzone do każdego stanowiska (doków tabletów). Z perspektywy software’u oznaczało to, że mogliśmy zrezygnować ze skomplikowanych mechanizmów synchronizacji offline/online i buforowania dużej ilości danych w LocalStorage przeglądarki. System mógł działać w trybie ciągłym online, co uprościło architekturę frontendu i wyeliminowało problemy z konfliktami danych (np. dwóch magazynierów rezerwuje ten sam towar w trybie offline).

Już teraz dostępna jest druga część, w której m.in. pokażemy:

Dlaczego „czysty kod” nie zawsze sprawdza się w brudnym środowisku przemysłowym?

To nie będzie tekst marketingowy. To będzie inżynierska spowiedź o debugowaniu rzeczywistości.

Jeśli chcesz dowiedzieć się więcej, zapraszamy do kontaktu z naszymi specjalistami.