Witam.
Jak już pewnie się domyślacie tyczy się to pewnego projektu, który większość mi odradzała. Nie to jest tematem tego wpisu.
:D
Widziałem dziś z rana Twoje wpisy do repo Jakuba Palaska (szybko odpisuje), już miałem do Ciebie pisać w podobnej sprawie :)
Ustaliliśmy z klientem, że spróbujemy zrobić program, który na podstawie wytycznych rozplanuje odpowiednio produkcję.
Ambitnie.
To rozplanowanie produkcji na tę chwilę to zwyczajny Scheduler z widokiem typu Timeline, podzielony na sześć maszyn. Powiedzieliśmy klientowi, że będziemy dążyć do rozplanowania w taki sam sposób jakby rozplanował człowiek, albo (ambicje) lepiej niż człowiek.
Noo....
Problem polega na tym, że tych warunków jest tak dużo, że generuje to masę ifów, nie wspominając o rekurencji i zapętlenia tego tyle razy, aż nie otrzymamy poprawnego wyniku.
Tego nie ta się zrobić w ten sposób, aby efekt był lepszy od pracy człowieka w rozsądnym (a nawet skończonym) czasie.
I właśnie dlatego algorytmy genetyczne, które nie dają co prawda idealnych rozwiązań, ale są na tyle dokładne że są OK.
poza tym, są zdecydowanie szybsze od IFologi.
- Czy to już podchodzi pod uczenie maszynowe?
Nie, bo na czym tu się ma nauczyć?
Nie masz na razie danych.
Poza tym, uczenie maszynowe w takich problemach zazwyczaj wiąże się z innymi danymi z realnej produkcji.
Algorytmy ML potrafią niejako przewidzieć co się może wydarzyć, i te prognozy można wykorzystać jako nowe wartości zmiennych do optymalizacji harmonogramu.
Ale na to w Twoim przypadku jest raczej za wcześnie.
- Czy takimi ifami i pętlami jestem w stanie ogarnąć taki projekt?
Taki projekt jak adaptacyjne harmonogramowanie produkcji?
Nie ma mowy.
- Znacie jakieś biblioteki do "liczenia" czasu, aby wstawić appointment do schedulera w odpowiednim miejscu?
Nie rozumiem pytania.
Mam już sporo napisane, ale dokładanie kolejnych warunków powoduje, że poprzednie trzeba dostosować.
Nie uciągniesz tego w ten sposób, moim zdaniem.
Każde zamówienie ma swój kolor. Maszyny M1, M2, M3 są maszynami na których wykonuje się pierwsze etapy.
Kolejne etapy są zaczynane w momencie kiedy poprzednie się skończą.
Czyli standardowo, sekwencja operacji zależnych.
A co jeśli się nie skończą?
Na produkcji wszystko jest możliwe - każde zadanie może zostać przerwane bo coś - np. brak obsady, brak surowca, inne priorytety, awaria maszyny, itd. itp.
Niektóre etapy mogą być "dzielone" - przechodzą na następny dzień.
One nie są dzielone, one przechodzą na następny dzień.
Nie dziel zadań z tego powodu, ponieważ potem wpadniesz w kolejne problemy.
Ciemniejsze, puste pole to czas pomiędzy 22:00 a 6:00, wtedy się nie pracuje.
Czyi okres wyłączony z pracy.
Zadanie które zaczyna się przed okresem wyłączony, przechodzi przez niego i ma doliczony czas okresu wyłączonego do swojego czasu trwania.
Ja to rozwiązałem tak:
Problemem jest dowolność, ponieważ OK - nie pracujemy od 22:00 do 6:00, a weekend nie pracujemy od piątku od 22:00 do poniedziałku do 06:00.
Tak mówi standardowy kalendarz.
A teraz przychodzi szef i mówi - maszyna A i B pracują w weekend.
Wtedy konieczna jest korekta okresu wyłączonego ad-hoc, dla wskazanych maszyn i może to wyglądać tak:
Jest jeszcze parę niedociągnięć.
Rozwijam podobny system od lat, a mam tych niedociągnięć więcej niż parę i coraz więcej z upływem czasu ;-)
Tak jak ten niebieski i szary kafelek, który dzieje się w tym samym czasie, a taka sytuacja nie może mieć miejsca.
Może i nie może.
Może mieć miejsce na etapie planowania, to jest tzw. przeciążenie zasobu i jest normalną sprawą przy algorytmach harmonogramowania wstecz.
Brzydko to wygląda (a przede wszystkim daje mało realną informację o planowanych rozpoczęciach i zakończeniach poszczególnych zadań i całych zleceń), dlatego coraz częściej stosuje się jego mutacje.
Nie może mieć miejsca w czasie egzekucji, ponieważ maszyna nie jest w stanie wykonywać wielu operacji w tym samym czasie.
Problem polega na tym, ze to nie zawsze jest prawda, ale OK - to nie dotyczy każdej produkcji.
Praktycznie każdy system jaki znam wyraźnie stawia granicę pomiędzy tym co jest planem, a co wykonaniem tego planu.
Kiedy zaczynałam swój projekt, stwierdziłem że to głupawe rozgraniczenie i najlepsza będzie podeście hybrydowe.
Problem polega na tym, że nie byłem świadomy ogromu niebanalnych problemów algorytmicznych i architektonicznych które należy rozwiązać.
Zrobiłem to tak:
Gdzie:
- Ta pionowa zielona linia to jest teraz
- Wszystko co na prawo od tej linii to przyszłość, czyli plan. Tu mogą być przeciążenia.
- Wszystko co na lewo od tej linii to przeszłość, czyli wykonanie. Tu nie mogą być przeciążenia.
Mój system bez litości koryguje wszystko co jest wykonywane (czyli na lewo od linii now) i koryguje cały harmonogram (czyli na prawo od linii now) na podstawie realizacji produkcji w trybie ciągłym.
Do tego wszystkiego dojdzie jeszcze priorytetowanie
I pewnie inne ograniczania, jak podstawowe - lead time.
, dzielenie etapów na tej samej zmianie, brak możliwości podziału etapu,
Tego nie do końca rozumiem; dlaczego chcesz cokolwiek dzielić, kiedy nie jest to konieczne?
zazębianie się kolejnych etapów z poprzednim tego samego zamówienia itp itd.
To tzw. bufor międzyoperacyjny.
Może być statyczny lub dynamiczny.
Nie chce się rozpisywać tutać ze wszystkim, bo tego jest sporo. Nie przeraża mnie to. Nie chce tylko stracić czasu z powodu złego podejścia.
Większość z tych rzeczy mam od dawna zrobione i "trochę" więcej.
I też "trochę" brakuje.
Może powinniśmy połączyć siły? :)
