Przykładowy model nr 2. Proces produkcji z trzema stanowiskami

PROCES PRODUKCJI Z TRZEMA STANOWISKAMI

Aby wyjaśnić działanie kolejnych trzech bloków panelu Basic Process, zmodyfi-kujemy przykład nr 1 z rozdziału 8.2.1.

Wyroby napływają na halę produkcyjną, tak jak poprzednio, w tempie opisanym rozkładem wykładniczym o średniej 5 minut. Po przybyciu kierowane są na pierwsze stanowisko (o nazwie Maszyna 1), gdzie poddawane są obróbce w czasie zgodnym

Rys. 8.17. Schemat przykładu nr 2

z rozkładem trójkątnym o parametrach (1, 3, 6) minut. Po opuszczeniu pierwszego sta-nowiska wszystkie wyroby kierowane są na drugie stanowisko (o nazwie Maszyna 2), gdzie poddawane są kolejnemu procesowi obróbki. Czas obsługi na stanowisku dru-gim opisany jest takim samym rozkładem jak dla stanowiska pierwszego. Po opusz-czeniu drugiego stanowiska następuje kontrola jakości wyrobów, która trwa dokładnie 5 minut. Kontrola jakości wykonywana jest na specjalnie do tego celu wyznaczonym stanowisku (o nazwie Stanowisko Kontroli). 80% wyrobów pomyślnie przechodzi test. System opuszczają wszystkie wyroby bez względu na wynik testu, ale wyroby uszko-dzone są znakowane. Co można powiedzieć o pracy systemu? Jak długie są kolejki, jaki jest czas oczekiwania, ile czasu wyroby przebywają w systemie?

Model dla przykładu nr 2 przedstawia rys. 8.17. Oprócz znanych nam bloków schematu Create, Process i Dispose, model zawiera dwa nowe bloki panelu Basic Process, tj. blok Decide i Record (trzeci nowy blok dodamy za chwilę).

Budowę modelu zaczynamy od znanego nam bloku Create, następnie umieszcza-my pierwszy blok Process, nadając mu nazwę Proces produkcji nr 1 i przydzie-lając mu jedno stanowisko obsługi o nazwie Maszyna 1. Następnie dodajemy drugi blok Process o nazwie Proces produkcji nr 2, który obsługiwany jest przez drugie (inne) stanowisko obsługi o nazwie _{Maszyna 2} (por. rys. 8.18, lewy). Czas trwania obróbki jest na obu stanowiskach opisany rozkładem trójkątnym o tych sa-mych parametrach. W kolejnym kroku dodajemy trzeci blok Process (rys. 8.18, pra-wy), który odpowiada kontroli jakości i realizowany jest na Stanowisku Kontroli. Czas trwania kontroli opisany jest za pomocą stałej wartości równej 5 minut.

Rys. 8.18. Okna dialogowe dla drugiego i trzeciego bloku Process

W ten sposób wprowadziliśmy do modelu trzy stanowiska obsługi, których defini-cje możemy obejrzeć w bloku danych Resource (rys. 8.19). Zauważmy, że automa-tycznie Arena utworzyła również trzy kolejki (por. rys. 8.20), ponieważ każdy z trzech bloków Process przewiduje zajmowanie/zwalnianie stanowisk obsługi.

Rys. 8.19. Zawartość modułu danych Resource

Rys. 8.20. Zawartość modułu danych Queue

8.3.2. BLOK SCHEMATU DECIDE

Blok Decide (rys. 8.21) pozwala podzielić strumień zgłoszeń na dowolną liczbę podstrumieni. Do wyboru mamy albo podział procentowy (by Chance), albo według zadanego warunku (by Condition). W przykładzie zastosujemy podział procentowy, ponieważ z opisu wynika, że około 80% wyrobów pomyślnie przechodzi test kontroli jakości, a 20% to wyroby wadliwe. Jeżeli strumień główny chcemy rozdzielić na dwa

podstrumienie (tak jak w naszym przykładzie), wybieramy 2-way by Chance i w polu Percent True wpisujemy jedną z wartości: 20 lub 80. Nie ma znaczenia, którą wartość wpiszemy, musimy jednak pamiętać, że wybranej przez nas wartości będzie odpowia-dał podstrumień opatrzony symbolem True (rys. 8.22) i dla tego strumienia musimy definiować bloki odpowiadające wpisanej wartości procentowej.

Rys. 8.21. Ikona i zawartość okna dialogowego bloku Decide

Gdybyśmy chcieli podzielić strumień główny na więcej podstrumieni (N), musieli-byśmy wybrać typ podziału jako N-way by Chance i przydzielić odpowiednie wartości procentowe N – 1 podstrumieniom (czyli przykładowo, dla czterech podstrumieni wartości procentowe przydzielamy trzem podstrumieniom). Do ostatniego podstru-mienia kierowany będzie procent zgłoszeń uzupełniający całość do 100%.

Rys. 8.22. Blok schematu Decide

8.3.3. BLOK SCHEMATU RECORD

Po zdefiniowaniu wszystkich operacji pozostaje nam już tylko wyprowadzenie wy-robów z systemu (por. rys. 8.17) za pomocą dwóch bloków Dispose, wcześniej jednak umieścimy na naszym schemacie dwa (nowe) bloki Record (rys. 8.23).

Arena automatycznie zbiera i umieszcza w raporcie końcowym bardzo dużo sta-tystyk, jednak czasami będziemy chcieli zebrać jeszcze inne, dodatkowe dane.

Jed-nym ze sposobów na ich uzyskanie jest blok Record, który nie stanowi elementu modelowanego systemu, ale pełni ważną rolę w gromadzeniu danych o działaniu systemu.

Rys. 8.23. Ikona i okno dialogowe bloku schematu Record Działanie bloku jest uzależnione od wyboru pozycji w polu Type. I tak:

• Count zmniejszy lub zwiększy wartość licznika o nazwie jak w polu Counter Name o wskazaną wartość (jak w polu Value).

• Entity Statistics wygeneruje ogólne statystyki związane ze zgłoszeniem.

• Time Interval obliczy i zapamięta różnicę między wartością wskazanego atry-butu (zamiast pola Value pojawi się wtedy pole Attribute Name) a bieżącym czasem symulacji.

• Time Between wyznaczy i zapamięta czas między wejściem dwóch kolejnych zgłoszeń do modułu.

• Expression obliczy wartość podanego wyrażenia.

W naszym przykładzie bloki Record posłużą nam jako liczniki w celu określenia liczby wyrobów wadliwych i bez wad. Wartości obu liczników pozwolą nam zweryfi-kować działanie bloku Decide. Przypomnijmy, że około 80% wyrobów to wyroby po-zbawione wad, a więc w naszym modelu takich właśnie wartości liczników powinni-śmy oczekiwać.

8.3.4. BLOK SCHEMATU ASSIGN

Trzecim nowym blokiem, który wprowadzimy do modelu, będzie blok Assign. Jest to blok, który odgrywa bardzo ważną rolę w procesie modelowania, ponieważ dzięki niemu możemy między innymi definiować atrybuty i nadawać wartości zmiennym w modelu. W przykładzie wykorzystamy blok Assign do tego, aby zmienić ikonkę wy-robów wadliwych (por. rys. 8.24), tak aby w trakcie symulacji można było rozróżnić obie grupy wyrobów. Być może w naszym prostym modelu nie jest to koniecznie

(wy-roby wadliwe i te bez wad przemieszczają się wzdłuż odrębnych procesów), ale w bardziej złożonych modelach taki zabieg może nam pomóc w badaniu poprawności przebiegu symulacji.

Rys. 8.24. Zmodyfikowany model nr 2 – dodany blok Assign zmieniający ikonkę wyrobów wadliwych

Rys. 8.25. Ikona i okno dialogowe bloku schematu Assign

Wprowadzenie bloku Assign (rys. 8.25) powoduje, że każde zgłoszenie, które przejdzie przez ten blok, doświadczy wszystkich zmian w nim zdefiniowanych. Zmia-ny (Assignments) wprowadzane są za pomocą przycisku Add i mogą dotyczyć (pole Type): nadawania wartości atrybutom (Attribute), nadawania wartości zmiennym (Va-riable), zmiany typu zgłoszenia (Entity Type), zmiany ikonki zgłoszenia (Entity Pictu-re) i innych (Other).

Ponieważ chcemy zmienić wygląd wyrobów wadliwych, umieścimy blok Assign w odgałęzieniu, którym przemieszczają się wyroby z wadami, wybierzemy typ zmiany jako Entity Picture i wybierzemy dowolną z dostępnych ikonek (inną oczywiście od ikonki wybranej pierwotnie).

8.3.5. WYNIKI SYMULACJI DLA MODELU NR 2

Po uruchomieniu i przeprowadzeniu symulacji (parametry jak dla przykładu nr 1), odczytujemy wyniki. Okazuje się, że wąskim gardłem jest kontrola jakości, przed któ-rą ustawia się długa kolejka (por. rys. 8.26), licząca średnio 10,622 wyrobów. Bardziej niepokojące jest jednak to, że maksymalna odnotowana długość kolejki wynosi 37 czekających wyrobów. Z długą kolejką związany jest również długi czas oczekiwania – wynosi on średnio 52,118 minut, a najdłuższy zaobserwowany czas to 180,91 minu-ty (czyli 3! godziny). Gdybyśmy sprawdzili dane dominu-tyczące wykorzystania stanowiska kontroli, okazałoby się, że pracuje właściwie bezustannie, średnie bowiem wykorzy-stanie sięga 96%,

Rys. 8.26. Przykładowe wyniki symulacji modelu nr 2

Wróćmy jeszcze na chwilę do dwóch zdefiniowanych w modelu procesów pro-dukcyjnych. Pamiętamy, że czas trwania obróbki w ramach jednego i drugiego proce-su opisany był tym samym rozkładem (trójkątnym), o tych samych parametrach. Wy-dawać by się mogło, że w związku z tym przechodzenie wyrobów z jednego procesu na drugi powinno odbywać się płynnie i przy drugim stanowisku nie powinna tworzyć się kolejka. Tymczasem obserwujemy tworzenie się kolejki zarówno przed pierw-szym, jak i przed drugim stanowiskiem. Oczywiście w modelu nie ma błędu – tworzą-ca się kolejka jest wynikiem losowych wartości generowanych przez rozkład losowy, które nie muszą być (i raczej bardzo rzadko będą) identyczne.

Sprawdźmy jeszcze poprawność działania bloku Decide, odczytując wskazania dwóch liczników zdefiniowanych w blokach Record. Wartości liczników odczytamy pod nową kategorią User Specified, która automatycznie została dodana przez Arenę w raporcie Category Overview (rys. 8.27). Nasze liczniki zarejestrowały średnio 65 wyrobów wadliwych i 211,2 wyrobów bez wad. Wynika z tego, że wyroby wadliwe stanowiły około 23,53% wszystkich wyrobów. Czy rozbieżność między zadeklarowa-ną (20%) a uzyskazadeklarowa-ną wartością jest duża, czy mała? Pamiętajmy, że rozdział zgłoszeń

za pomocą bloku Decide odbywa się w sposób losowy. Im więcej powtórzeń wykona-libyśmy, tym bardziej zbliżylibyśmy się do zdefiniowanych 20% i uzyskalibyśmy węższy przedział ufności. Przykładowo, 100 powtórzeń dałoby nam wynik 19,6% wy-robów wadliwych, a połowa przedziału ufności (Half width) byłaby równa jedynie 1,5 (w przykładzie z 5 powtórzeniami Half Width wynosi 5,69).

Rys. 8.27. Wartości wynikowe liczników z bloków Record

8.3.6. HARMONOGRAM PRACY NA STANOWISKU KONTROLI JAKOŚCI

Analizując wyniki symulacji zauważyliśmy, że problemy z utrzymaniem płynności ruchu pojawiają się na stanowisku Kontroli Jakości. Załóżmy zatem, że liczba kontro-lerów zmienia się w ciągu doby: na pierwszej zmianie pracuje jeden pracownik, na drugiej dwóch, na trzeciej ponownie jeden. Zmieniającą się w trakcie symulacji liczbę pracowników na stanowiskach obsługi możemy wprowadzić do modelu za pomocą harmonogramu pracy poprzez blok danych Schedule. Najpierw jednak musimy zmo-dyfikować blok danych Resource, zmieniając w wierszu Stanowisko Kontroli

pole Type na Based on Schedule i wprowadzając nazwę harmonogramu

Harm_Kontroli w polu Schedule Name (por. rys. 8.28).

Rys. 8.29. Zawartość modułu danych Schedule

Rys. 8.30. Definiowanie opcji harmonogramu w bloku danych Schedule

Następnie możemy już zdefiniować harmonogram. W bloku danych Schedule (por. rys. 8.29) klikamy na pole Durations. Zanim przystąpimy do zdefiniowania szczegółów, wybieramy przycisk Options (Opcje) znajdujący się w lewej dolnej stronie okna dialogowego i wprowadzamy następujące wartości parametrów (por. rys. 8.30): Time slot durations (kalibracja osi czasu) = _{1 hour}, Range (horyzont czasowy) = ₂₄, Maximum (maksymalna wartość osi Y) = ₂, Minimum (minimalna wartość osi Y) = 0.

Po wybraniu Apply (rys. 8.30) wprowadzamy szczegóły harmonogramu (rys. 8.31): zaznaczamy wartość 1 dla pierwszych 8 godzin, następnie 2 przez kolejne 8 godzin i znowu 1 na ostatniej ośmiogodzinnej zmianie. Akceptujemy harmonogram przyci-skiem OK.

Ponownie uruchamiamy symulację i w wynikach obserwujemy znaczącą poprawę obsługi na Stanowisku Kontroli (por. rys. 8.32).

Rys. 8.32. Wyniki symulacji po wprowadzeniu zmian w harmonogramie pracy na stanowisku Kontrola Jakości

8.4. PRZYKŁADOWY MODEL NR 3.