Millwright: podgląd hali produkcyjnej na żywo
Panel pokazuje całą halę produkcyjną w jednym miejscu i sam przydziela zadania maszynom, także wtedy, gdy któraś nagle stanie.
Hala produkcyjna bez wspólnego obrazu sytuacji
Zlecenia i stan maszyn żyją w arkuszach, na tablicach i w głowach brygadzistów. Gdy maszyna się psuje albo wpada pilne zlecenie, nikt od razu nie widzi, gdzie przełożyć pracę i ile to będzie kosztować. Millwright pokazuje stan całej hali w jednym miejscu i sam decyduje, gdzie trafia każde zadanie, zanim człowiek zdąży policzyć to ręcznie.
Nacisk na przezbrojenia: algorytm MCT-S
- Sortowanie zadań
- Priorytet ustawia kolejność: najpierw Critical, potem Rush, na końcu Normal, ciasnota ograniczeń dogrywa zadania z mniejszą liczbą zdolnych maszyn, a LPT (najdłuższe zadanie pierwsze) porządkuje resztę pod kątem bin-packingu.
- Punktacja maszyn
- Score = (czas ukończenia zadania − bonus preferencji) × waga priorytetu, gdzie pilniejsze zadania dostają niższą wagę. Niższy wynik wygrywa; remisy rozstrzyga brak konieczności przezbrojenia.
- Work stealing
- Bezczynne maszyny same skanują przeciążone kolejki, sprawdzają zgodność zadania i przejmują je, gdy to się opłaca. Zero ręcznej interwencji.
- Wstawianie priorytetowe
- Nowe zadanie ląduje w kolejce maszyny na pozycji, jaką faktycznie zasługuje jego priorytet, nie zawsze na końcu. Pilne zlecenie potrafi wyprzedzić pracę, która już czeka, zamiast stać w ogonie aż się skończy.
Autorska heurystyka nazwana MCT-S (Minimum Completion Time with Setup Awareness): zachłanny wybór maszyny o najniższym wyniku, LPT jako reguła rozstrzygania remisów, koszt przezbrojenia wpisany wprost w formułę. Nazwa własna, nie formalny dowód optymalności z podręcznika teorii szeregowania.
Cele projektowe i liczby z symulacji
- poniżej 200 ms
- cel projektowy: czas od pojawienia się zadania w puli do przydziału na konkretną maszynę.
- poniżej 500 ms
- cel projektowy: pełne ułożenie kolejki na nowo po zgłoszeniu awarii maszyny.
- 500+/h
- cel projektowy: maksymalna liczba zadań rozdzielanych w ciągu godziny przy 8 maszynach, w warunkach optymalnych.
W założeniach projektu work stealing ma przesuwać około 15% zadań dynamicznie między maszynami, a grupowanie podobnych operacji ma ciąć czas przezbrojeń o około 40%: to cele projektowe, nie zmierzony benchmark. Panel analityczny liczy za to realny OEE (Availability × Performance × Quality) z faktycznych przestojów i czasu pracy każdej maszyny, nie z gotowego wzoru na pokaz.
Panel pokazuje jedną kwotę w złotych i pozwala zmienić obie liczby, z których wychodzi. Koszt godziny postoju ma domyślnie 8 000 zł: to utracona wartość dodana z przykładu na utrzymanieruchu.pl (20 000 zł/h wartości produkcji minus 12 000 zł/h materiałów). Drugie pole, 15 minut krótszego postoju na jedną awarię, jest podpisane na ekranie jako założenie, nie pomiar. Mnożnikiem są awarie faktycznie usunięte w trwającej sesji, a nie prognoza roczna.
Reszta liczb w panelu pochodzi z samej symulacji: OEE liczone z przestojów i czasu pracy każdej maszyny, przebieg przeliczenia harmonogramu mierzony w milisekundach po każdej awarii, karta kontrolna czasu realizacji z granicami wyznaczonymi z pierwszych 25 zleceń sesji.
Projekt własny. Zbudowaliśmy go i utrzymujemy sami. Hala i awarie w panelu to symulacja, nie dane z produkcji klienta.
Każdy wybór ma powód
| Warstwa | Wybór | Co to daje |
|---|---|---|
| Frontend | Next.js | Ekran zmienia się w tej samej chwili, w której zmienia się stan hali. |
| Stan | Zustand | Każdy panel widzi ten sam stan maszyn, więc dwa widoki nie pokazują dwóch prawd. |
| Styl | Tailwind CSS | Jeden jasny motyw czytelny na monitorze przy linii produkcyjnej. |
| Animacja | Motion | Przejścia prowadzą wzrok do zmiany, zamiast ozdabiać ekran. |
| Wykresy | Recharts | Obciążenie hali i liczbę zadań widzisz jako przebieg w czasie, nie jako jedną liczbę. |
| Eksport | ExcelJS | Raport z hali zapisujesz jako arkusz i otwierasz go w Excelu bez przepisywania. |