Simulation with Arena part.1

kelton5

Simulation with Arena

 

Simulation with Arena W. David Kelton, Randall P. Sadowski, David T. Sturrock

Strony: 201-231

 

ROZDZIAŁ 5

Modelowanie Szczegółowych Operacji

str. 201 Ten rozdział bada niektóre ze (nie wszystkie oczywiście) szczegółowych konstrukcji modelowania niższego poziomu dostępne w PANELACH ADVANCED PROCESS i  BLOCKS; drugi panel jest wyposażony w model logiczny najniższego poziomu, gdzie moduły korespondują z blokami z języka symulacji SIMAN, który stanowi podstawę Areny.

Użyjemy przykładu call center, włączając pomoc techniczną, sprzedaż, sprawdzanie stanu zamówień. Sekcja 5.1 opisuje początkowy system; Sekcja 5.2 mówi jak go modelować używając niektórych nowych pojęć Areny. Sekcja 5.3 opisuje podstawową strategię modelowania. Model logiczny i animacja są rozwinięte w Sekcji 5.4. W Sekcji 5.5 ‚upiększymy’ model i zaprezentujemy kilka nowych pojęć modelowania w Arenie. Potem pokażemy jak zmodyfikować model podstawowy, aby utworzyć model ‚upiększony’. Także, zapoznamy się z tematem niestacjonarnego (zależnego od czasu) procesu przybywania połączeń i wyższego poziomu dostosowania animacji zgodnie z indywidualnymi potrzebami. W Sekcji 5.6 dodaliśmy więcej pomiarów wyjściowych dla zaawansowanego modelu. Zamkniemy rozdział Sekcją 5.7 w sumie z różnymi rodzajami modeli, systemem inwentaryzacyjnym, a także skorzystamy z okazji, żeby przedstawić użycie najniższych i najbardziej szczegółowych poziomów modelowania, BLOCKS PANEL, który składa się na podstawę SIMAN.

Po przeczytaniu tego rozdziału powinieneś być w stanie stworzyć bardzo szczegółowe i złożone modele i być w stanie wykorzystywać bogaty i szeroki zakres poziomów modelowania Areny.

 

5.1 Model 5-1: Prosty system call center

str.202 Nasz podstawowy system call center stanowi główny numer w instytucji, do której dzwonią klienci po pomoc techniczną, informację o sprzedaży i po stan zamówienia. Połączenia przychodzące docierają w czasie interarrival (czas pomiędzy kolejnymi połączeniami), który wzrasta w postępie geometrycznym i jest rozdzielany ze średnią 0.857 minuty. Numer główny zasila 26 linii telefonicznych. Jeśli wszystkie 26 linii jest w użyciu, dzwoniący słyszy sygnał zajętości; na szczęście dzwoniący będzie próbował później, ale dla naszego modelu po prostu rozłącza się.  Klient, który się dodzwonił słyszy 3 nagrane opcje do wyboru: przekazanie do pomocy technicznej, działu sprzedaży albo zapytanie o status zamówienia (76%, 16% i 8% w kolejności). Szacowany czas dla tej czynności to UNIF (0.1, 0.6); wszystkie podane czasy są w minutach.

Jeśli dzwoniący wybiera pomoc techniczną, czyli drugi typ żądania spośród trzech typów produktu, jakie dzwoniący może wybrać, to wymaga to UNIF (0.1, 0.5) minut. Procent żądań dla produktów typu 1,2 i 3 są w kolejności 25%, 34% i 41%. Jeśli uprawniona osoba z pomocy technicznej jest dostępna, dla wybranego typu produktu, połączenie jest automatycznie przekierowane do tej osoby. Jeśli nikt nie jest obecnie dostępny, dzwoniący jest umieszczany w elektronicznej kolejce, gdzie słucha denerwującej muzyki rock, do czasu, gdy osoba z pomocy technicznej będzie dostępna. Szacowany czas dla pomocy technicznej to TRIA (3,6,18) minut bez względu na rodzaj produktu. Po wykonaniu połączenia klient wychodzi z systemu.

Połączenia dotyczące sprzedaży są automatycznie przekazywane do działu sprzedaży. Jeśli sprzedawca nie jest dostępny, klient potraktowany zostaje uspokajającą muzyką New Age (w końcu liczymy na sprzedaż). Szacowany czas dla sprzedażowych połączeń to TRIA (4,15,45) – sprzedawcy na ogół rozmawiają dłużej jak pomoc techniczna. Po wykonaniu połączenia szczęśliwy klient wychodzi z systemu.

Dzwoniący, którzy chcą się dowiedzieć o status zamówienia są automatycznie obsługiwani przez system telefoniczny, i nie ma limitu z iloma dzwoniącymi system może sobie poradzić (oprócz tego, że jest tylko 26 linii, co samo w sobie jest ograniczeniem, ponieważ trwające połączenie o status zamówienia zajmuje jedną z linii). Szacowany czas dla tej operacji to TRIA (2,3,4) minut, w tym 15% dzwoniących decyduje się na rozmowę z realną osobą po tym jak otrzymują informację o statusie zamówienia.

Te połączenia są przekazywane do działu sprzedaży, gdzie czekają z niższym statusem ważności niż połączenia dotyczące sprzedaży. To znaczy, że jeśli dzwoniący o status zamówienia czeka w kolejce do sprzedawcy, a w tym czasie nowe połączenie dotyczące sprzedaży nadejdzie, to połączeniu dotyczącemu sprzedaży będzie dane pierwszeństwo przed połączeniem dotyczącym statusu zamówienia i będzie odebrane jako pierwsze. Szacowany czas tych trwających połączeń z zapytaniem o status zamówienia będzie trwał TRIA (2,3,4) minut. Ci dzwoniący potem wychodzą z systemu.

Call center otwarte jest od 8.00 do 18.00, z małym odsetkiem personelu do 19.00. Jednakże system dla nowych połączeń zamyka się  o 18.00, wszystkie połączenia, które wejdą do systemu do godz. 18 są odebrana i obsłużone.

Przez cały dzień jest 8 pracowników pomocy technicznej, aby odbierać połączenia związane z pomocą techniczną. Dwie z nich są przeznaczone do połączeń Product Type 1; trzy do połączeń Product Type 2 i trzy do połączeń Product Type 3. Jest 4 sprzedawców do obsługi połączeń dotyczących sprzedaży i do tych o statusie zamówienia, którzy chcą rozmawiać z prawdziwą osobą.

Jako punkt zainteresowania, policzyliśmy liczbę klientów, którzy nie mogą trafić na wolną linię i w ten sposób są odrzucani z systemu (podobnie jak odmowa (balking) w systemie kolejkowym, przy czym odmowa znaczy zazwyczaj decyzję klienta o tym żeby nie wchodzić do systemu, a nie być z niego odrzuconym, jak w naszym modelu). Jednak nie będziemy się zajmować nie wytrwaniem na linii (reneging) – klientami, którzy początkowo dodzwaniają się, ale później odkładają słuchawkę przed tym jak zostaną obsłużeni (patrz sekcja 9.3 gdzie jest dyskusja jak modelować nie wytrwanie na linii).

str. 203 Trochę danych statystycznych, które są w obrębie zainteresowania dla tego typu systemu: liczba klientów odrzuconych (sygnał zajętości), całkowity czas rozmowy na linii liczony na typ klienta, czas oczekiwania na realną osobę przez typ klienta, liczba połączeń oczekujących na obsługę przez typ klienta, wykorzystanie personelu.

 

5.2 Nowe zagadnienia w modelowaniu

Z punktu widzenia modelowania ten problem jest inny niż te omawiane w rozdziałach 3 i 4. Najbardziej oczywistą różnicą jest to, że poprzedni system był zorientowany na produkcję, a ten jest natury usługowej. Mimo, że oryginalna wersja SIMAN (język symulacji, na którym Arena jest oparta) była rozwinięta dla aplikacji produkcyjnych, obecnie możliwości Areny również pozwalają na precyzyjne modelowanie systemu obsługi. Aplikacje w tej dziedzinie obejmują fast-foody, banki, firmy ubezpieczeniowe, centra obsługi i wiele innych. Mimo, że te systemy mają szczególne cechy charakterystyczne podstawowe wymagania modelowania są w dużej mierze takie same jak dla systemów produkcyjnych.

 

5.2.1 Odrzucanie i ODMOWA klientów

Połączenie generowane przez proces przybywania połączeń jest tak na prawdę klientem, który próbuje się dodzwonić na jedną z 26 linii. Jeśli wszystkie 26 linii jest obecnie w użyciu, klient słyszy sygnał zajętości, jest odrzucany i wychodzi z systemu. Termin ten nazywa się ODMOWA, jeśli jest zrobione dobrowolnie przez klienta, podczas gdy w naszym call center jest to niedobrowolnie, więc nazywamy to odrzuceniem; modelowanie i obsługiwanie ODMOWA i odrzucania jest do siebie podobne.

Weź pod uwagę restaurację fast-food dla zmotoryzowanych, która ma jedno okienko z miejscem tylko dla 5 samochodów czekających na obsługę. Przybywającymi jednostkami będą samochody włączające się do kolejki, żeby poczekać i schwycić zasoby zwane ‚Obsługa z okienka’. Musimy ustalić pojemność kolejki na 5. To pozwoli jednemu samochodowi być obsługiwanym i max 5 czekać w kolejce. Jeśli szósty samochód będzie próbował wejść do kolejki to dostanie odmowę (albo będzie odrzucony). Ty decydujesz, jako część swoich założeń modelowania, co się stanie z tym zatrzymanym/ odrzuconym samochodom albo jednostką. Mogą być usunięte albo możemy założyć, że będą jeździły dookoła bloku i będą próbowały trochę później jeszcze raz wejść w kolejkę.

Są dwie metody, żeby przedstawić ODMOWA/odrzucenie w Arenie. Pierwszą metodą jest zastosowanie QUEUE MODULE z panelu BLOCKS PANEL i zdefiniowanie pojemności kolejki jako 0. Przybywająca jednostka (w naszym modelu przychodzące połączenie) wchodzi w zerową pojemność kolejki i niezwłocznie usiłuje schwycić zasoby zwane ‚Linia telefoniczna’ (Trunk Line). Jeśli jednostka jest dostępna, jest przydzielona do połączenia i połączenie wchodzi do systemu. Jeśli jednostka z zasobu nie jest dostępna to obiekt próbuje stać w kolejce. Ale jeśli kolejka ma pojemność 0 połączenie będzie odprawione z kolejki, a potem odrzucone. Druga metoda będzie używała DECIDE MODULE jako jednostki przychodzącej, aby sprawdzić czy jednostka z zasobu ‚Linii telefonicznej’ jest dostępna. Jeśli jest ona dostępna to obiekt dostaje pozwolenie na kontynuowanie i schwytanie zasobu. Jeśli żadna jednostka nie jest dostępna to obiekt jest wysyłany do sekcji ODMOWA. Użyjemy drugiej opcji w naszym modelu. ODMOWA i odrzucanie wyraźnie reprezentuje rodzaj porażki systemu w zaspokojeniu potrzeb klientów, więc policzymy ile razy się to stało w symulacji; mniejszy wynik jest lepszy.

 

5.2.2 Trójkierunkowa decyzja

STR. 204 Jak tylko połączenie jest przydzielone do linii telefonicznej i wchodzi do systemu, wówczas musimy określić rodzaj połączenia, aby skierować je do odpowiedniej części systemu, aby je obsłużyć. Aby to zrobić, potrzebujemy umiejętności wysyłania jednostek, albo połączeń do 3 różnych części systemu na podstawie podanego prawdopodobieństwa. To samo wymaganie musi być spełnione dla technicznych połączeń, ponieważ są 3 różne rodzaje produktu.

Moglibyśmy wyjąć kalkulator i obliczyć prawdopodobieństwo pojęć i obliczyć prawdopodobieństwo dla każdego rodzaju połączenia – w sumie jest ich 5. Moglibyśmy potem zdefiniować SEQUENCES – patrz rozdział 7.1 – dla każdego rodzaju połączenia i ustalić kolejność operacji w systemie. Mimo, że mogłoby to działać, musielibyśmy obliczać prawdopodobieństwo za każdym razem, kiedy zmieniana jest dystrybucja do rodzajów połączeń, którą możesz chcieć wykonać, żeby przetestować elastyczność albo stabilność systemu.

Nie musisz sobie z tego zdawać sprawy, ale uprawnienie jest dostarczane do rozgałęzień programu w 3 albo więcej różnych kierunkach w tym samym DECIDE MODULE, którego używaliśmy w modelach w rozdziale 4.

 

5.2.3 Zmienne i Wyrażenia

W wielu modelach możemy chcieć ponownie wykorzystać dane w kilku różnych miejscach. Np., w naszym call center, będzie kilka miejsc gdzie będziemy musieli wprowadzić dystrybucję dla czasu, żeby obsługiwać połączenia pomocy technicznej. Jeśli zdecydujemy się na zmianę tej wartości podczas wykonywania doświadczenia będziemy musieli otworzyć każde okno dialogowe, które zawierało czas połączenia i zmienić wartość. Są inne sytuacje, w których możemy chcieć uaktualniać na bieżąco całkowitą liczbę jednostek w systemie albo w części systemu. W innych przypadkach, możemy chcieć używać złożonych wyrażeń przez cały model. Np., możemy chcieć, aby czas przetwarzania bazował na typie elementu. Narzędzia Areny Zmienne i Wyrażenia pozwalają nam na łatwe wykonywanie takich operacji.

VARIABLE MODULE pozwala na zdefiniowanie swoich własnych zmiennych globalnych i ich początkowych wartości. Zmienne mogą mieć potem swoje odnośniki w modelu z własnymi nazwami. Mogą być również określone jako jedno- albo dwu- wymiarowe tablice. EXPRESSION MODULE pozwala na zdefiniowanie wyrażeń i ich wartości skojarzonych. Podobnie do zmiennych, wyrażenia mogą mieć swoje odnośniki w modelu z własnymi nazwami i mogą być także określone jako jedno- albo dwu- wymiarowe tablice. Mimo, że zmienne i wyrażenia mogą się wydawać podobne służą one wyraźnie innym funkcjom.

Zdefiniowane przez użytkownika Zmienne przechowują w pamięci rzeczywistą wartość wielkości, która może być ponownie przypisana podczas wykonywania symulacji. Np., możemy zdefiniować Zmienną zwaną Czas Oczekiwania z początkową wartością 2 i wprowadzić nazwę Zmiennej wszędzie gdzie czas oczekiwania był wymagany. Możemy też zdefiniować Zmienną o nazwie Liczba w Systemie z początkową wartością 0, dodawać 1 do tej zmiennej za każdym razem, kiedy nowa część wejdzie do systemu, i odejmować 1 od niej za każdym razem, kiedy część odejdzie z systemu. Dla naszego call center użyjemy trzech zmiennych. Pierwsza z nich będzie uaktualniać na bieżąco liczbę połączeń w systemie, a dwie pozostałe zostaną użyte, aby zakończyć generowanie połączeń przychodzących po 10 godzinach.

str.205 Zdefiniowane przez użytkownika EXPRESSIONS, z drugiej strony, nie przechowują wartości w pamięci. Zamiast tego, zapewniają sposób skojarzenia nazwy z matematycznym wyrażeniem. Ilekroć nazwa ma swój odnośnik w modelu, skojarzone wyrażenie jest oszacowane i jego wartość liczbowa powraca. Zazwyczaj, wyrażenia są używane, aby obliczać wartości z dystrybucji, albo ze złożonego równania bazującego na cechach wartości jednostki, albo nawet na obecnych zmiennych wartościach systemowych. Jeśli matematyczne wyrażenie zostało użyte tylko w jednym miejscu modelu, może być łatwiejsze wprowadzenie go wtedy, kiedy jest to wymagane. Jednak, jeśli wyrażenie jest użyte w kilku miejscach albo, jeśli forma wyrażenia, która będzie użyta, zależy od cech jednostki, wyrażenie zdefiniowane przez użytkownika jest zawsze lepsze. Dla naszego call center użyjemy EXPRESSION MODULE, żeby zdefiniować wyrażenie do wygenerowania czasu pomocy technicznej.

Zmienne i Wyrażenia mają wiele innych funkcji, które mamy nadzieję staną się dla Ciebie oczywiste z czasem jak będziesz się lepiej zapoznawał z Areną.

 

5.2.4 STORAGES (PAMIĘĆ,MAGAZYN)

Storage jest pojęciem programu Arena, która pozwala użytkownikowi na animowanie prezentacji jednostek, które nie mieszczą się w kategorii standardowych cech animacji, jakie do tego momentu widziałeś. Wszystkie nasze wcześniejsze modele pokazują jednostki w Kolejce, na Zasobach, albo poruszanie się w obrębie Ścieżek. Uwzględnij przykład, gdzie następuje przybycie jednostki, która początkowo wprowadza opóźnienie przed tym jak ma pozwolenie na przejście do następnego modułu. Jeśli opóźnienie przedstawia czas podróży w systemie z jednego obszaru do innego, możesz użyć pojęcia STATIONS i ROUTES. To pozwoli Ci na animowanie ruchu jednostki przechodzącej przez system, tak jak robiliśmy w Model 4-4. Ale jeśli podczas opóźnienia jednostka nie przemieszcza się, to potrzebujemy funkcji STORAGES, żeby ją animować.

STORAGE przechowuje nieuporządkowany zbiór jednostek, które czekają na swoją kolej; np., koniec pierwotnie zdefiniowanego czasu opóźnienia, przybycie żądanego przenośnika, który jest na ścieżce, etc. Możesz myśleć o STORAGE jako o zmiennej, którą możemy inkrementować (powiększać) i dekrementować (zmniejszać) za pomocą dodanej cechy, która może być animowana jako jednostka, która jest w STORAGE. Umieszczenie jednostki w STORAGE nie usuwa jednostki z systemu, ale pozwala jej na uczestniczenie w modelu logicznym. Np., możemy umieścić jednostkę w STORAGE, a potem pokazać ją w animacji, podczas, gdy wprowadza opóźnienie, a potem ciągnie się przez model logiczny, dopóki nie zdecydujemy się jej usunąć ze STORAGE w późniejszej części modelu. Podczas całego czasu jednostka będzie wyświetlona na animowanej STORAGE.

Są dwie metody żeby umieścić jednostkę w STORAGE, a potem ją usunąć. Pierwsza z nich wykorzystuje moduły STORE i UNSTORE znajdujące się w ADVANCED PROCESS PANEL. Druga metoda proponuje wykorzystanie modułu, który ma pole danych, aby wprowadzić Storage ID. Przykładem jest DELAY MODULE z BLOCKS PANEL. Pokażemy Ci jak używać obu podczas rozwoju naszego modelu.

 

5.2.5 Terminating or Steady-State (zakańczanie albo stan stacjonarny)

Większość (nie wszystkie) symulacji może być sklasyfikowana jako terminating albo steady-state. Jest to głównie kwestia rezultatu albo raczej celu badań, bardziej niż ma to coś wspólnego z wewnętrznym modelem logicznym, albo konstrukcją.

Symulacja ‚terminating’ jest taką, który dyktuje określony początek i warunki zakończenia jako naturalne odzwierciedlenie tego, jak docelowy system faktycznie działa. Jak sama nazwa sugeruje, symulacja będzie zakończona zgodnie z określoną zasadą modelu albo warunkiem.

str.206  Np., sklep otwiera się o 9.00 bez żadnych klientów obecnych w sklepie, zamyka drzwi o 21.00 i kontynuuje pracę, aż do momentu, kiedy ostatki klient wyjdzie. Innym przykładem jest produkcja jednostkowa (job shop), która działa przez tak długo jak wyprodukuje nakład 500 ukończonych identycznych elementów (assemblies) określonych przez komendę. Kluczowym pojęciem jest to, że rama czasowa symulacji jest wyraźnie określona, (chociaż prawdopodobnie nie jest znana na początku) i ma naturalny koniec, tak samo jak wyraźnie zdefiniowany sposób zaczynania.

Symulacja steady-state , z drugiej strony, to taka, w której wielkość, która ma być oszacowana, jest zdefiniowana długoterminowo; czyli, teoretycznie, przez nieskończoną ramę czasową. W zasadzie (jednak nie w praktyce), początkowe warunki dla symulacji nie mają znaczenia. Oczywiście, symulacja steady-state musi się kiedyś zatrzymać, i jak możesz zgadnąć, może to trwać dość długo, więc musisz coś zrobić, aby być pewnym, że trwa ona wystarczająco długo. To jest temat, którym zajmiemy się w rozdziale 7.2.  Np., pediatryczny oddział pomocy doraźnej nigdy w zasadzie się nie zatrzymuje albo restartuje, więc symulacja steady-state może być odpowiednia. Czasami ludzie tworzą symulację steady-state systemu, który faktycznie kończy się, w celu zaprojektowania go przy założeniu najbardziej niekorzystnych warunków albo w sytuacji szczytowego obciążenia.

Musimy teraz zdecydować, który z nich wykonamy dla tego modelu call center. Mimo, że prowadzimy do tego, żebyś uwierzył, że rozróżnienie pomiędzy systemami terminating (zakończonym) a non-terminating (nieskończonym)jest bardzo wyraźne, rzadko się to zdarza. Niektóre systemy na początku wydają się być jednego typu, ale przy bliższym zbadaniu okazuje się, że są inne. Ten temat jest bardziej skomplikowany przez fakt, że niektóre systemy zawierają elementy obu typów, a system klasyfikacji może zależeć od rodzajów zapytań, jakie badacz musi wziąć pod uwagę. Np., zwróć uwagę na restaurację fast food, która otwiera się o 11.00 i zamyka o 23.00. Jeśli będziemy zainteresowani dzienną eksploatacją informacji w tej restauracji, przeanalizujemy system jako terminating. Jeśli będziemy zainteresowani tylko operacjami podczas godzin szczytu, które pojawiają się przez 2 godz podczas lanchu, to założymy, że jest to stały proces przybywania w szczytowej wartości przybywania i przeanalizujemy system jako system steady-state .

Nasze call center zdecydowanie wydaje się być systemem, terminating. System wydaje się otwierać i kończyć jako pusty i nieobciążony, więc będziemy postępować z analizą jak z systemem terminating.

 

5.3. Podejście do modelowania

Na Figure 1-2 w rozdziale 1, krótko omówiliśmy hierarchiczną strukturę Areny. Ta struktura pozwala na dowolne łączenie modelowanych konstrukcji z jakichkolwiek poziomów w jeden system symulacji. W rozdz. 3 i 4 byliśmy w stanie rozbudować nasze modele używając tylko konstrukcji znajdujących się w BASIC PROCESS PANEL, mimo, że potrzebowaliśmy ADVANCED PROCESS PANEL dla awarii i specjalnych statystyk, i ADVANCED TRANSFER PANEL dla przemieszczania niektórych jednostek.

Ogólne podejście, które polecaliśmy podczas kreowania modelu było pozostanie na najwyższym możliwym poziomie tak długo jak się da. Jednak, tak szybko jak zorientujesz się, że ten wysoki poziom konstrukcji nie pozwala wychwycić koniecznych detali, sugerujemy zejście do niższego poziomu dla niektórych części modelu niż poświęcanie dokładności symulacji modelu (oczywiście, są elementy oceniania sytuacji przy podejmowaniu decyzji). Możesz mieszać modelowanie konstrukcji z różnych poziomów i paneli w tym samym modelu. Jak będziesz się zapoznawał z różnymi panelami (i poziomami modelowania) zauważysz, że robisz to naturalnie. Zanim będziemy kontynuować, omówimy krótko dostępne panele.

str.207.  BASIC PROCESS PANEL zapewnia najwyższy poziom modelowania. Jest zaprojektowany, aby pozwolić na utworzenie w sposób łatwy i szybki modeli wysokiego poziomu większości systemów. Użycie kombinacji modułów CREATE, PROCESS, DECIDE, ASSIGN, RECORD, BATCH, SEPARATE, DISPOSE pozwala na dużą elastyczność. Właściwie, jeśli spojrzy się na te moduły to znajdzie się w nich wiele dodatkowych elementów, których jeszcze nie omawialiśmy. W wielu przypadkach, te moduły samodzielnie zapewniają wszystkie detale wymagane w projekcie symulacji. Te moduły zapewniają wspólne funkcje wymagane przez prawie wszystkie modele, więc jest prawdopodobne, że ich użyjesz bez względu na zamierzony poziom detali.

ADVANCED PROCESS PANEL powiększa BASIC PROCESS PANEL przez dostarczenie dodatkowych i bardziej szczegółowych możliwości modelowania. Np., sekwencja modułów SEIZE – DELAY – RELEASE zapewnia zasadniczo te same podstawowe układy logiczne modelowania, jak PROCESS MODULE, ale pozwala na większą elastyczność niż PROCESS MODULE. Poręcznym w użyciu elementem modułów ADVANCED PROCESS PANEL jest możliwość zestawiania ich razem w prawie każdej kombinacji wymaganej dla twojego modelu. W zasadzie, wielu doświadczonych modelarzy zaczyna od tego poziomu, ponieważ uważają, że osiągnięty rezultat modelu jest bardziej zrozumiały dla użytkownika, który może być lub nie być modelarzem.

ADVANCED TRANSFER PANEL zapewnia modelowanie konstrukcji dla transportu bliskiego i przeładunku materiałów [material-handling activities] (takich jak transportery i przenośniki) i przemieszczanie jednostek w ogóle. Podobnie jak w ogólnych możliwościach modelowania dostępnych w ADVANCED PROCESS PANEL, moduły ADVANCED TRANSFER PANEL dają większą elastyczność.

BLOCKS PANEL [część szablonu SIMAN] dostarcza nawet niższy poziom możliwości modelowania. W zasadzie, zapewnia on podstawowy zespół funkcji, które były użyte do stworzenia wszystkich modułów, które można znaleźć w panelach: BASIC PROCESS, ADVANCED PROCESS i ADVANCED TRANSFER. Na dodatek, zapewnia on wiele innych specjalizowanych konstrukcji modelowania, które nie są dostępne w wyżej poziomowych modułach. Jako przykład można podać ‚instrukcję pętli’, połączone rachunki prawdopodobieństwa, rozgałęzienie układów logicznych i automatyczną wyszukiwarkę elementów. Możesz zauważyć, że kilka modułów ma takie same nazwy jak te z wyżej poziomowych modułów. Mimo, że nazwy są identyczne, to moduły nie. Można je rozróżnić za pomocą koloru i formy.

Różnicę między BLOCKS PANEL, z jednej strony, a panelami: BASIC PROCESS, ADVANCED PROCESS i ADVANCED TRANSFER, z drugiej, łatwo jest wyjaśnić, jeśli używałeś wcześniej SIMAN, gdzie definiowałeś model i ramy eksperymentu oddzielnie, nawet  jeśli możesz to robić w Arenie. Różnica jest najprawdopodobniej najlepiej widoczna pomiędzy ASSIGN MODULE na dwóch panelach. Kiedy używasz BASIC PROCESS PANEL modułu ASSIGN, masz możliwość wyboru rodzaju przyporządkowania jakie chcesz zrobić. Jeśli zrobiłeś przypisanie do nowego atrybutu, to Arena automatycznie definiuje ten nowy atrybut i dodaje go do listy rozwijanej w dół dla atrybutów wszędzie w twoim modelu. Jeden z powodów pozostania na najwyższym możliwym poziomie jest taki, że BLOCKS ASSIGN MODULE pozwala tylko na zrobienie przypisania – a nie definiuje atrybutu. Nawet z tym niedociągnięciem, jest wiele potężnych i użytecznych elementów dostępnych tylko w BLOCKS PANEL.

str. 208. Dodatkowo, ELEMENTS PANEL zarządza eksperymentalną ramą modułów. Np., kiedy używasz ATTRIBUTES MODULE, żeby zdefiniować swój nowy atrybut. Rzadko będziesz potrzebował tych elementów, ponieważ są połączone z modułami szablonów Areny, ale jeśli potrzebujesz najniżej poziomowego elementu modelowania specjalnego (możesz iść do Visual Basic albo C, jeśli jesteś cierpiętnikiem,) jest on, tak jak wszystko inne, dostępny przez interfejs Areny.

PANELE BLOCKS I ELEMENTS również zapewniają moduły zaprojektowane dla modelowania układów ciągłych (jako przeciwieństwo nieciągłego (dyskretnego) procesu omawianego do tej pory). Będzie to w rozdziale 11, z omówieniem FLOW PROCESS.

Powróćmy do call center, które wymaga elementów, jakich nie znajdziemy w BASIC PROCESS PANEL MODULES. Podczas rozbudowywania naszego modelu użyjemy modułów z paneli BASIC PROCESS, ADVANCED PROCESS I BLOCKS PANELS. W niektórych przypadkach, użyjemy niżej poziomowych konstrukcji, ponieważ są wymagane; natomiast w innych, użyjemy ich tylko żeby zilustrować ich możliwości. Kiedy modelujesz używając niżej poziomowych konstrukcji, potrzebujesz podejść do modelowania w trochę inny sposób. Używając wyżej poziomowych konstrukcji mamy tendencję do grupowania działań, a następnie używania odpowiedniego modułu. Używając niżej poziomowych konstrukcji musimy się skoncentrować na bieżących działaniach. Poniekąd, twój model stanie się szczegółowym schematem działania programu. Niestety, dopóki jesteś zaznajomiony z logiką w dostępnych modułach, ciężko będzie rozbudować ten schemat działania programu.

 

5.4 Budowanie Modelu

Na tym etapie, podzielimy nasz model na części i pójdźmy bezpośrednio do ich konstrukcji, gdzie możemy jednocześnie pokazać dostępne możliwości. 7 sekcji, w kolejności, w której będą prezentowane, to:

Sekcja 5.4.1: Tworzenie przybycia i Skierowanie do Serwisu

Sekcja 5.4.2: Logika przerwania przybycia

Sekcja 5.4.3: Połączenia z pomocą techniczną

Sekcja 5.4.4: Połączenia z działem sprzedaży

Sekcja 5.4.5: Połączenia z zapytaniem o status zamówienia

Sekcja 5.4.6: Wyjście z systemu i uruchomienie właściwości systemu

Sekcja 5.4.7: Animacja

W miarę czytania następujących 7 Sekcji możesz odnieść wrażenie, że jest to dokładnie sposób, w jaki rozbudowaliśmy model. Idealnie byłoby móc zaplanować konstrukcję modelu w tak prosty sposób. W rzeczywistości, jednak, często będziesz powracał do wcześniej stworzonych sekcji i będziesz dodawał, kasował albo zmieniał moduły albo dane. Więc jak zaczniesz konstruować bardziej skomplikowane modele, nie zakładaj, że zawsze wszystko będzie dobrze za pierwszym razem (u nas nie było).

 

Część 5.4.1: Tworzenie przybycia i Skierowanie do Serwisu

W miarę jak poznasz możliwości Areny i będziesz budował bardziej złożone modele, uznasz za konieczne planowanie układów logicznych z góry zanim zbudujesz model. W przeciwnym razie znajdziesz się stale w fazie przenoszenia modułów albo kasowania modułów błędnie wybranych. Jaką metodę wybierzesz do planowania swoich modeli zwykle będzie miało miejsce w naturalny sposób, ale możesz chcieć się zastanowić zanim modele staną się naprawdę złożone – a będą!

str. 209

Wielu modelarzy używa ołówka (albo pióra, jeśli są zbyt pewni siebie) i papieru, aby naszkicować ich układ używając dobrze znanej terminologii. Inni mają bardziej przepisowe podejście i tworzą logiczny schemat rodzajów używając standardowych symboli schematu blokowego. Jeszcze innym podejściem jest zbudowanie następującej po kolei listy działań, które muszą się pojawić. My utworzyliśmy taką listę dla układu, który jest wymagany do stworzenia i skierowania przybyć, (który wygląda podobnie jak schemat blokowy modułów z Figure 5-1).

Ten rodzaj podejścia pomoże ci sformalizować kroki modelowania i zmniejszyć liczbę błędów i zmian w modelu. Jak będziesz się stawał bardziej doświadczony, możesz nawet dojść do momentu kiedy zaczniesz robić projekty swoich podstawowych układów używając modułów Areny (w końcu są podobne do elementów schematów blokowych). Jednak, nawet wtedy polecamy robić projekty swoich układów zanim zaczniesz wypełniać je detalami.

CREATE MODULE, który tworzy jednostki (połączenia przychodzące) zgodnie z wcześniej zdefiniowanym procesem jest opisany na Display 5-1.

str. 210 Użyliśmy bardzo podobnego CREATE MODULE w modelach w rozdziałach 3 i 4, z wyjątkiem pozycji w Entities per Arrival i Max Arrivals Fields. Pamiętaj, że system zamyka się o 18.00 dla nowych połączeń przychodzących. Pokażemy Ci jak używać zmiennej MaxCalls, żeby zakończyć połączenie przychodzące w następnej sekcji.

W większości przypadków, kiedy definiujesz nowy obiekt (zmienną, atrybut, etc.) w modułach z BASIC PROCES i ADVANCED PROCESS PANELS, Arena automatycznie wpisze pozycję w odpowiedni moduł danych. Tak się zawsze dzieje, kiedy określisz Type, np., zmienną, atrybut, etc. Jednak, w tym przypadku, po prostu wpiszemy MaxCalls bez określenia typu. Zatem, musimy określić zmienną MaxCalls. Określamy ją w module VARIABLE DATA z panelu BASIC PROCESS, pokazanego na Figure 5-2. Otwórz ten moduł danych klikając na niego i podwójnie klikając żeby dodać nowy wiersz. Potem napisz w NAME naszej nowej zmiennej, MaxCalls. Potem kliknij na komórkę INITIAL VALUE, żeby otworzyć okno arkusza kalkulacyjnego, gdzie możesz wpisać początkową wartość. My wstawiliśmy wartość 999999, co oznacza, że proces przybywania zakończy się po 999999 przychodzących połączeniach (oczywiście jest to podstęp, co wyjaśnimy pod spodem). Również zdefiniowaliśmy zmienną CallsPerArrival i zainicjowaliśmy jego wartość jako 1 (ta inicjalizacja nie jest widoczna na ilustracji 5-2); znów, wyjaśnimy to trochę później.

Jak będziemy kontynuować rozbudowywanie tego modelu czasami będziemy myśleli z góry jak chcemy nasz model animować. Załóżmy, że chcemy nasz model zanimować jako czarną piłkę (black ball). Możemy przypisać obrazek używając ASSIGN MODULE, ale określiliśmy w naszym CREATE MODULE, że typ jednostki to IncomingCall, więc w takim wypadku powinniśmy kliknąć na ENTITY DATA i wybrać Picture.BlackBall z listy rozwijanej w dół w komórce INITIAL PICTURE.

W tym momencie w modelu chcemy zapisać liczbę usiłowanych połączeń używając RECORD MODULE , jak jest pokazane na Display 5-2.

Następnie musimy sprawdzić czy linia jest dostępna. Jeśli jest, to przechwytujemy ją; w przeciwnym razie połączenie jest odrzucane z systemu. W Sekcji 5.2.1 omówiliśmy dwa oczywiste sposoby (w każdym razie dla nas) żeby to osiągnąć. Dla tego modelu użyjemy DECIDE MODULE następującego po SEIZE MODULE (w ADVANCED PROCESS PANEL ) jeśli linia jest dostępna.

STR. 211 DECIDE MODULE jest używany żeby sprawdzić czy jednostki zasobu TrunkLine są dostępne. Możesz użyć Expression Builder żeby rozwinąć ten warunek. Wyrażenie NR (TrunkLine ) < MR (TrunkLine)  zawiera zmienne programu Arena – MR i NR. Zmienna NR jest bieżącą liczbą jednostek zajętych w zasobie, a zmienna MR jest bieżącą liczbą jednostek zaplanowaną w zasobie, albo całkowitą liczbą jednostek zasobu jakie obecnie istnieją (zajęte lub nie). Pola dla DECIDE MODULE są pokazane na Display 5-3.

Warunkiem może być jakiekolwiek prawidłowe wyrażenie, lecz typowo zawiera jakiś rodzaj porównania. Takie warunki mogą zawierać jakikolwiek zapis, pokazane jest to w Table 5-1. Wyrażenia logiczne też mogą być użyte.

Jeśli jednostka zasobu TrunkLine jest dostępna, pozwalamy jednostce przejść do SEIZE MODULE (Display 5-4 z ADVANCED PROCESS PANEL) gdzie przechwytujemy ten zasób. Normalnie użylibyśmy PROCESS MODULE, ale w tym przypadku potrzebuje oddzielić część przechwyć z PROCESS MODULE od części opóźnienia (wkrótce zobaczysz, dlaczego). Niepodobnie jak PROCESS MODULE, SEIZE MODULE zawiera tylko kolejkę i operację przechwyć. Kiedy definiujesz zasób w SEIZE MODULE , ten zasób będzie wprowadzony do RESOURCE DATA MODULE (BASIC PROCESS PANEL) automatycznie, ale jego pojemność będzie wartością domyślną 1. Ponieważ jest 26 linii potrzebujesz otworzyć RESOURCE DATA MODULE i zmienić pojemność na 26.

STR. 212

Po przechwyceniu jednego elementu zasobu Trunk Line, jednostka jest przesyłana do następnego ASSIGN MODULE (Display 5-5) gdzie zwiększamy zmienną TOTAL WIP. Ta zmienna będzie użyta, aby uaktualniać na bieżąco jak wiele aktywnych połączeń jest obecnie w systemie. Później użyjemy tej zmiennej żeby określić, kiedy zakończyć działanie symulacji.

Jednostka następnie wchodzi do STORE MODULE (z ADVANCED PROCESS PANEL) gdzie umieszczamy jednostkę w STORAGE INITIAL RECORDING DELAY STORAGE, pokazane na Display 5-6. Nawet, jeśli myślimy o tym jako o umieszczeniu jednostki w pamięci to nie usuwamy jej, ale uczestniczy ona dalej w modelu logicznym. Używamy tej STORAGE, więc możemy pokazać tę jednostkę na animacji podczas początkowego zapisu opóźnienia. Pokażemy Ci jak dodać tę pamięć animacji w sekcji 5.4.7.

 

str. 213. Jak jednostka jest już w pamięci, wchodzi ona do DELAY MODULE, gdzie osiąga opóźnienie UNIF (0.1,0.6) reprezentujące wynik i wybór opcji czasu, pokazane na Display 5-7.

Po zakańczaniu procesu opóźnienia, wchodzi ona w UNSTORE MODULE gdzie jednostka jest usuwana z pamięci gdzie była umieszczona wcześniej. Możesz zauważyć, że ustawiliśmy wartość domyślną w TYPE ENTRY, Display 5-8. Opcja domyślna usunie jednostkę z ostatniej pamięci, do której weszła, którą była INITIAL RECORDING DELAY STORAGE.

 

str.214.  Połączenie jest wtedy przesyłane do DECIDE MODULE opisane na Display 5-9, gdzie typ połączenia jest określany zgodnie z prawdopodobieństwem początkowo ustalonym. Wybraliśmy typ N-WAY BY CHANCE TYPE i określiliśmy procenty na 76 i 16, które reprezentują połączenia z pomocą techniczną i działem sprzedaży. Punkt wyjściowy ELSE będzie użyty żeby przekierować połączenia o status zamówienia (pozostałe 8%).

Pierwsza gałąź z panelu DECIDE reprezentuje połączenia z pomocą techniczną. Jednostki wchodzące w tę gałąź są wysyłane do ASSIGN MODULE gdzie przyporządkowujemy sekcję połączeń z pomocą techniczną naszego modelu. Jednostki wchodzące w drugą gałąź są wysyłane do sekcji działu sprzedaży naszego modelu, trzecia gałąź jest wysyłana do sekcji połączenia o status zamówienia.

Jak już uporaliśmy się z połączeniami przychodzącymi, które są pomyślnie przydzielone do linii, musimy sobie poradzić z tymi nieszczęsnymi połączeniami, które otrzymały sygnał zajętości – jednostkami odrzuconymi. Są one przesłane do RECORD MODULE gdzie policzymy nasze połączenia odrzucone w liczniku REJECTED CALLS, Display 5-10. Te jednostki są w końcu wysyłane do DISPOSE MODULE, gdzie wychodzą z systemu.

 

5.4.2 ARRIVAL CUTOFF LOGIC

W naszym opisie problemu w Sekcji 5.1 wskazaliśmy, że system zamyka się dla nowych połączeń po 18.00, ale wszystkie połączenia, które wejdą do systemu przed tym czasem zostaną odebrane i przetworzone. To oznacza, że pozwalamy połączeniom przychodzić od 8.00 do 18.00, w sumie 600 minut, ale musimy odrzucać połączenia przychodzące po 600 minutach. Jednak, zanim zakończymy działającą symulację musimy zająć się tymi, które przyszły przed 600. Pokażemy Ci jak określić, kiedy wszystkie połączenia zostały obsłużone i jak później zakończyć proces.

Jednym oczywistym sposobem na odcięcie połączeń po 600 minutach będzie wstawienie DECIDE MODULE tak, że połączenia przychodzące będą wpisane natychmiast po CREATE MODULE, który tworzy połączenia przychodzące. DECIDE MODULE sprawdzi czy czas bieżącej symulacji był mniejszy niż 600. Jeśli tak, jednostka będzie miała pozwolenie na kontynuowanie; w przeciwnym razie jednostka będzie wysłana do DISPOSE MODULE.

str.215. Mimo, że ta metoda odetnie połączenia przychodzące (jednak nie zakończy działania programu), może spowolnić działanie programu z tym extra sprawdzaniem każdego potencjalnego połączenia przychodzącego, więc wybraliśmy bycie troszkę przebiegłymi i wprowadziliśmy pojęcie jednostki logicznej, żeby odciąć nasze połączenia przychodzące.

W modelach budowanych do tej pory, każda jednostka, którą stworzyliśmy reprezentowała jakieś fizyczne obiekty, połączenie w przypadku naszego bieżącego modelu. Jednostki logiczne są takie same jak inne jednostki, ale są stworzone i używane, żeby wykonywać jakieś logiczne albo doświadczenie kontrolne. W tym przypadku, stworzyliśmy jednostkę logiczną, która odetnie połączenia przychodzące, a następnie zostanie zniszczona. Czynności, aby to osiągnąć są pokazane tutaj a moduły schematu blokowego są pokazane na Figure 5-3.

 

Możesz zauważyć, że te 3 moduły wydają się być całkowicie niezależne od reszty naszego modelu. Są, oprócz tego, że ta sekcja naszego modelu będzie oddziaływała z resztą modelu poprzez dwie globalne Zmienne. Zaczęliśmy od stworzenia naszej jednostki kontrolnej przy użyciu CREATE MODULE, Display 5-11. Określiliśmy CONSTANT ARRIVAL TYPE z wartością 999999. Jeśli to było wszystko, co wpisaliśmy, będziemy mieli przybycie o czasie 0 (arrival at time), a potem każdą jednostkę czasu, co 999999. Jednak, określiliśmy, że pierwsze połączenie pojawi się o czasie 600 (FIRST CREATION FIELD) i tak będzie tylko jedno połączenie przychodzące (MAX ARRIVAL FIELD). Jak się okazało mogliśmy wybrać jakikolwiek TYPE i jakąkolwiek VALUE ponieważ nie są one nigdy używane.

str. 216  Pojedyncza jednostka logiczna stworzona w czasie 600 wchodzi w następujący ASSIGN MODULE gdzie przypiszemy zmiennej MaxCalls wartość 1, i Zmiennej CallsPerArrival wartość 0, Display 5-12.

Przez ustawienie wartości zmiennej MaxCalls na 1, zatrzymaliśmy tworzenie połączeń przychodzących. Przypuszczamy, że możesz być trochę zakłopotany w tym momencie – powinieneś być. Wypełnijmy to wszystko detalami żebyś zrozumiał jak to działa. Na początku, kiedy wypełniliśmy  CREATE MODULE, który tworzy połączenia przychodzące, na Display 5-1, wpisaliśmy zmienną MaxCalls w pole Max Arrivals. Także przypisaliśmy tej zmiennej początkową wartość 999999 w VARIABLE DATA MODULE. Ponieważ mamy czas 600 minut w naszej działającej symulacji, możemy być pewni, że mieliśmy więcej jak jedno połączenie przychodzące, ponieważ FIRST CREATION miało czas 0. Do tej pory (w czasie 600) ustalenie wartości MaxCalls na 1 spowoduje zamknięcie naszego strumienia połączeń przychodzących.

Jednak, z powodu sposobu, w jaki CREATE MODULE pracuje, musimy zrobić jeszcze jedną rzecz w Cut Off Incoming Calls w ASSIGN MODULE teraz w czasie 600, żeby być pewnym, że żadne połączenie nie przyjdzie po czasie 600. Kiedy następuje tworzenie, Arena ustala harmonogram następnego tworzenia, tak długo jak Max Arrivals nie zostało osiągnięte. Więc jak nadchodzi czas 600 będzie ostatnie ‚prawne’ połączenie poprzedzające czas 600, i to połączenie zaplanuje jeszcze jedno ‚nieprawne’ połączenie, które faktycznie przyjdzie po czasie 600. Żeby ‚zniszczyć’ to nieprawne połączenie musimy teraz ustalić Zmienną CallsPerArrival na 0 (jest zainicjowana na 1 w VARIABLE DATA MODULE, więc będzie 1 do czasu 600, która jest to, co chcemy i wpisujemy ją w pole ENTITIES PER ARRIVAL FIELD w Create Call Arrivals CREATE MODULE). Więc kiedy to nieprawne połączenie nadejdzie w jakimś czasie po 600, zostanie ustalone na 0 jednostek, i efekt końcowy będzie taki, że tak naprawdę żadne połączenie nie wejdzie do systemu. Po tym czasie, żadne połączenie przychodzące nie będzie zaplanowane z powodu wpisania 1 w polu Max Arrivals.

Zakończywszy swoje jedyne zadanie, nasza jednostka logiczna zostanie wysłana do DISPOSE MODULE, który niszczy jednostki, w ten sposób kończąc naszą sekcję modelowania logicznego.

 

5.4.3 Połączenia z pomocą techniczną

W sekcji 5.4.1 użyliśmy DECIDE MODULE, żeby określić typ połączenia. Połączenia przychodzące były określone jako połączenia z pomocą techniczną, zajęły pierwszą gałąź i zostały wysłane do tej części modelu. Czynności, które służą pomocy technicznej są wyszczególnione tutaj i moduły schematu blokowego są pokazane na Figure 5-4.

str. 217                 Jeśli dzwoniący wybierze opcję pomocy technicznej, to jednostki będą wysłane do tej części naszego modelu, gdzie po raz pierwszy przyporządkowaliśmy Entity Type jako Tech Call, i Entity Picture jako Picture.RedBall, jak na Display 5-13.

Drugi zapis żąda/zgłasza, którego z typów produktu dzwoniący używa. W sekcji 5.4.1 zdecydowaliśmy umiejscowić połączenia przychodzące w STORAGE dla pierwszego zapisu, żeby móc je pokazać na naszej animacji. Zrobimy tu to samo, więc najpierw umieścimy jednostkę w pamięci Tech Call Recording Delay Storage, jak pokazane na Display 5-14.

 

str.218.                Jak jednostka została umieszczona w pamięci, weszła w DELAY MODULE           gdzie osiąga opóźnienie UNIF (0.1,0.5) reprezentujące zapis i wybór opcji czasu, jak na Display 5-15.

Po zakończeniu opóźnienia, wchodzi do UNSTORE MODULE gdzie jednostka zostaje usunięta z pamięci, w której została umieszczona, jak na Display 5-16. Ponownie, opcja domyślna usunie jednostkę z ostatniego miejsca w pamięci, w którym było wpisane.

Połączenie następnie jest wysłane do DECIDE MODULE, jak na Display 5-17, gdzie typ produktu jest określony zgodnie z prawdopodobieństwem pierwotnie określonym. Wybraliśmy N-way by Chance type i określiliśmy procenty na 25 i 34, które reprezentują produkt typ 1 typ 2 połączeń pomocy technicznej. Punkt wyjściowy Else będzie użyty żeby skierować połączenia produktu typ 3 (pozostałe 14%).

Każda z trzech gałęzi z tego DECIDE MODULE łączy się z PROCESS PANEL żeby służyć temu typowi połączeń pomocy technicznej. Jednostki dla każdego z trzech modułów są bardzo podobne, więc tylko Cię poprowadzimy przez pierwszą, dla produktu Type 1 pomocy technicznej, Disply 5-18. Wybraliśmy SEIZE – DELAY – RELEASE ACTION i zażądaliśmy schwycenia jednego elementu zasobu Tech1. Jak z zasobem Trunk Line, musisz otworzyć też RESORCE DATA MODULE i zmienić pojemność z domyślnej (1) na 2. Po opóźnieniu, zasób Tech1 jest uwalniany i zakończone połączenie jest wysłane do części wyjścia naszego modelu.

 

str.219

Wyrażenie TechTime jest zdefiniowane przy użyciu EXPRESSION DATA MODULE z ADVANCED PROCESS PANEL. Kliknij na moduł, kliknij dwa razy żeby dodać nowy wiersz i wpisz nazwę wyrażenia, TechTime. Potem kliknij na komórkę Expression Values, która otworzy arkusz kalkulacyjny i wpisz wyrażenie TRIA (3,6,18), jak pokazane na Figure 5-5.

Pozostałe dwa PROCESS MODULES w tej sekcji wykonają to samo zadanie dla produktu Type 2 i 3 które potrzebują schwycić zasób Tech2 i Tech3, w odpowiedniej kolejności. Pojemności dla obu zasobów również muszą być ustalone na 3 w RESOURCE DATA MODULE.

 

5.4.4 Połączenia z działem sprzedaży

Połączenia z działem sprzedaży z naszego DECIDE MODULE w sekcji 5.4.1 są wysłane do tej części naszego modelu. Logika dla połączeń z działem sprzedaży jest bardzo podobna dla tych opisanych dla połączeń z pomocą techniczną. Jednakże, jest wiele mniej modułów wymaganych (w sumie tylko dwa), ponieważ nie mamy złożoności wielokrotnych typów produktu i różnych zasobów. str.220. Wymagane kroki logiczne dla połączeń z działem sprzedaży są pokazane tutaj a moduły schematu blokowego na Figure 5-6.

Przychodzące połączenie z działem sprzedaży jest wysyłane do ASSIGN MODULE gdzie przyporządkowujemy Entity Type do Sales Call, i Entity Picture do Picture.GreenBall, jak na Display 5-19.

Potem połączenie przechodzi do PROCESS MODULE (Display 5-20,) gdzie jedna jednostka zasobu Sales jest przechwycona, opóźnia w stosunku do pomocy tech TRIA (4,15,45) minut, i uwalnia swoją jednostkę zasobu Sales.

 

5.4.5 Połączenia o status zamówienia (Order-Status Calls)

Połączenia o status zamówienia są automatycznie obsługiwane, więc co najmniej początkowo nie wymagają zasobu innego niż jedna jednostka TrunkLine. Kroki logiczne dla połączeń o status zamówienia  to: (na str.221).

str.221 Układ logiczny Areny jest pokazany na Figure 5-7.

Przychodzące połączenie o status zamówienia jest wysyłane do ASSIGN MODULE (Display 5-21) gdzie jednostka Type jest przyporządkowana do Order Status Call, i Entity Picture do Picture.Blue Ball.

Połączenia przychodzące o status zamówienia są automatycznie załatwiane przez system telefoniczny, co oznacza, że początkowo osiągają opóźnienie tak samo jak połączenia przychodzące i o pomoc techniczną. Tak jak z poprzednimi dwoma opóźnieniami, chcemy pokazać połączenie na animacji  więc możemy użyć kombinacji STOR-DELAY-UNSTORE MODULE, tak jak zrobiliśmy dla dwóch poprzednich opóźnień. Ale tym razem inaczej podejdziemy do sprawy i użyjemy DELAY MODULE z BLOCKS PANEL. Używając tego modułu, możemy zapisać te samą funkcyjność jak zrobiliśmy z poprzednią kombinacją modułów ponieważ zawiera ona STORE/UNSTORE LOGIC. Jednostka będzie umieszczona w zdefiniowanej pamięci, osiągnie opóźnienie, i jednostka zostanie usunięta z pamięci. Zrobiliśmy wpisy dla Label (tak samo jak Name), i Storage ID, pokazane na Dispaly 5-22.

 

str.222

Kiedy używasz modułów z BLOCKS PANEL, musisz zdawać sobie sprawę jak określiłeś BASE TIME UNITS w oknie dialogowym RUN>SETUP>REPLICATION PARAMETERS i upewnić się, że jednostki dla każdej wartości czasu (np. Duration w DELAY MODULE) są takie same. W naszym modelu, wybraliśmy minuty, więc jesteśmy konsekwentni. Jeśli wybrałeś żeby używać DELAY MODULE z ADVANCED PROCESS PANEL powinno zawierać wpis dla jednostek czasu. Kiedy używamy STORAGE MODULE żeby umiejscowić jednostkę w pamięci, Arena automatycznie wpisze nazwę pamięci w STORAGE DATA MODULE (ADVANCED PROCESS PANEL). Tak się nie dzieje dla DELAY MODULE z BLOCKS PANEL. Więc teraz musisz kliknąć na STORAGE DATA MODULE i wpisać nazwę pamięci, Order Status Delay Storage.

Kiedy skończymy opóźnienie, jednostka wchodzi w DECIDE MODULE, na Display 5-23, gdzie zdecydowaliśmy czy jest konieczne połączenie z żywą osobą. Jeśli nie, jednostka jest wysyłana do wyjścia z systemu. W innym przypadku, potrzebuje schwycić sprzedażowa żeby ukończyć połączenie. My zdecydowaliśmy, w sposób dowolny, że „TRUE” oznacza naprawdę sprawę gdzie żaden sprzedawca nie jest wymagany (stąd jest module Name i 85 wpisów % dla True).

str.223

W naszym początkowym opisie problemu wskazaliśmy, że połączenia o status zamówienia są przekierowane do działu sprzedaży gdzie będą czekały z niższym priorytetem ważności niż połączenia sprzedażowe. To oznacza, że jeśli połączenie o status zamówienia jest w kolejce czekając na połączenie z osobą z działu sprzedaży to, jeśli przyjdzie nowe połączenie sprzedażowe, to połączenie sprzedażowe będzie miało priorytet przed połączeniem o status zamówienia i będzie odebrane jako pierwsze (jednak nowe połączenie sprzedażowe nie udaremni połączenia o status zamówienia, które może być właśnie w toku). W tym punkcie, w celu znalezienia rozwiązania naszego problemu, musimy zrobić dygresję i wyjaśnić jak Arena przydziela zasoby dla czekających jednostek.

Mamy nadzieję, że do tej pory proces przydzielania jest całkowicie jasn,y gdzie jednostki żądające zasobu są rezydentne (stale znajdujące się w pamięci operacyjnej komputera) w tej samej kolejce i mają ten sam priorytet. Jednak, jeśli jest kilka miejsc wewnątrz modelu (różne kombinacje QUEUE – SEIZE) gdzie te same zasoby mogą być przydzielone, musimy zastosować specjalne zasady. Rozpatrzmy najpierw różne okoliczności zgodnie, z którymi zasób może być przydzielony do jednostki:

  • żądanie jednostki o zasób, a zasób jest dostępny,
  • zasób staje się dostępny i jednostki żądające go są tylko w jednej  z kolejek, albo
  • zasób staje się dostępny i są jednostki żądające zasobu w więcej jak jedna kolejce.

Powinno to być raczej oczywiste, co się dzieje zgodnie z dwoma pierwszymi scenariuszami, ale i tak je opiszemy.

Jeśli jednostka żąda zasobu a zasób jest dostępny, przypuszczasz, że tak, zasób jest przydzielony do jednostki. W drugim przypadku, jeśli zasób staje się dostępny i są zasoby w jednej z kolejek, wtedy zasób jest przydzielony do jednostki w tej kolejce. Tutaj czynnikiem determinującym, dla której jednostki w kolejce zasób zostanie przydzielony jest zasada klasyfikacji kolejki użyta, aby porządkować jednostki. Arena zapewnia 4 opcje klasyfikacji: FIRST IN FIRST OUT (FIFO), LAST IN FIRST OUT (LIFO), LOW VALUE FIRST i HIGH VALUE FIRST. Domyślnie, FIFO klasyfikuje jednostki w kolejności, w której weszły w kolejkę, więc jednostka, która była w kolejce najdłużej dostanie zasób. LIFO stawia najnowszą jednostkę na początku kolejki (tak jak umiejscowić/usunąć ze stosu), więc jednostka, która dołączyła do kolejki jako najnowsza dostanie zasób. LOW VALUE FIRST i HIGH VALUE FIRST klasyfikują kolejkę na podstawie wartości atrybutów jednostek znajdujących się w nim; to zależy od Ciebie jak zdefiniujesz wyrażenie dla takiego atrybutu. Np, jak każda jednostka przybywa do systemu to możesz przyporządkować Termin wykonania do atrybutu jednostki. Jeśli wybrałeś LOW VALUE FIRST bazujące na tym terminie wykonania atrybutu, dostaniesz równoważną zasadę klasyfikacji kolejki najwcześniejszego terminu wykonania. Jak każda kolejna jednostka przybywa do kolejki, jest umiejscowiona w pozycji bazującej na wzrastających terminach wykonania.

Ostatni przypadek, gdzie jednostki w więcej niż jednej kolejce żądają zasobu, jest trochę bardziej skomplikowane. Arena najpierw sprawdza priorytety chwytania; jeśli jeden z priorytetów chwytania jest liczbą mniejszą (wyższy priorytet) niż reszta, to zasób jest przydzielony do pierwszej jednostki w kolejce poprzedzającej to chwytanie. Moglibyśmy wykorzystać tę metodę i powrócić do PROCESS MODULE, którego używaliśmy w logice połączeń sprzedaży i zmienić Priority selection na High (1). Użylibyśmy potem innego PROCESS MODULE, aby schwycić zasób sprzedaży dla naszych połączeń o status zamówienia i ustalić Priority selection na Medium (2) i Low (3). To by rozwiązało nasz problem z przydzielaniem zasobu. Ale kontynuujmy naszą dyskusję na temat przydzielania zasobów i sprawdźmy czy jest inny sposób.

str.224

Jeśli wszystkie priorytety są równe, Arena zastosuje domyślną regułę przerywającą powiązanie/połączenie (tie-breaking rule), a zasób jest przydzielony na podstawie jednostki, która czekała najdłużej bez względu na kolejkę, w której się znajduje. Zatem, zasadniczo potrzebna jest FIFO reguła przerywającą powiązanie/połączenie między połączeniami związanych ze sobą kolejek. To znaczy, że jeśli twoje kolejki były sklasyfikowane zgodnie z najwcześniejszym terminem wykonania, wtedy jednostka, która odpowiada kryterium nie zawsze musi mieć przydzielony zasób. Np, późne zadanie (late job) może właśnie wejść do kolejki, podczas gdy wczesne zadanie (early job) może być na przedzie innej kolejki i może czekać dłużej.

Arena zapewnia rozwiązanie tego potencjalnego problemu w formie współdzielonej kolejki. Współdzielona kolejka jest tym, co jej nazwa sugeruje – pojedynczą kolejką, która może być dzielona przez dwie lub więcej czynności chwytania. To pozwala Ci na zdefiniowanie pojedynczej kolejki, gdzie wszystkie jednostki żądające zasobu zostaną umiejscowione bez względu na to, gdzie ich czynności chwytania są umieszczone wewnątrz modelu. Arena wykonuje księgowanie żeby upewnić się, że jednostka we współdzielonej kolejce utrzymuje się na właściwym miejscu w modelu logicznym, kiedy zasób jest przydzielany.

W naszym modelu, każde połączenie sprzedażowe i mała procentowość (15%) połączeń o status zamówienia będą wymagały jednostki zasobu Sales. Ponieważ te czynności są modelowane oddzielnie, użyjemy współdzielonej kolejki, kiedy będziemy próbowali schwycić jednostkę zasobu Sales. Obu typom połączeń jest przydzielona jednostka zasobu Sales na bazie zasady FIFO, albo najdłuższego czasu oczekiwania, więc współdzielona kolejka  nie jest wymagana w naszym modelu żeby upewnić się że zasób został przydzielony do odpowiedniej jednostki. Jednakże, współdzielona kolejka także pozwala w łatwy sposób na gromadzenie złożonych statystyk całkowitych liczb połączeń czekających na zasób Sales i zapewnia zdolność pokazania tych oczekujących połączeń w tej samej kolejce – jeśli zdecydujemy się na zanimowanie tej kolejki.

Ponieważ nie przypisaliśmy priorytetu połączeniom sprzedażowym, wykorzystamy fakt, że dla naszej jednostki z wartością nieprzypisaną dla atrybutu, ta wartość będzie domyślnie wynosiła 0. Teraz użyjemy ASSIGN MODULE, żeby zdefiniować nowy atrybut, Sales Call Priority, dla tych połączeń o status zamówienia wymagających jednostki zasobu Sales i ustalimy jego wartość na 1, jak na Display 5-24.

Rezultatem będzie to, że połączenie sprzedażowe będzie miało Sales Call Priority z wartością 0, a połączenie o status zamówienia będzie miało Sales Call Priority z wartością 1. Następnie wyślemy jednostkę do SEIZE MODULE. Możesz zapytać dlaczego używamy SEIZE MODULE a nie PROCESS MODULE.  Okazuje się, że jeśli użyjemy PROCESS MODULE to nazwa kolejki ma wartość domyślną „module name” z rozszerzeniem „.queue”, które nie może być zmienione. Ponieważ chcemy użyć tej samej kolejki, która była zdefiniowana dla schwytania połączeń sprzedażowych, musimy użyć SEIZE MODULE zamiast PROCESS MODULE, co pozwala nam na zmianę domyślnej nazwy kolejki.

str. 225.

Zrobimy te kolejkę, współdzieloną kolejką przez, najpierw, umieszczenie i wypełnienie SEIZE MODULE i wybranie nazwy kolejki, Process Sales Call.Queue, z listy rozwijanej w dół, jak na Display 5-25.

Jak zostanie to zrobione , musisz iść do BASIC PROCESS PANEL i otworzyć QUEUE DATA MODULE. Twoja kolejka będzie już w widoku arkusza kalkulacyjnego, i musisz sprawdzić SHARED BOX żeby zrobić go dostępnym jako kolejka współdzielona. Potem, kliknij na komórkę Type dla naszej kolejki i wybierz opcje Lowest Attribute Value. To pozwoli Ci wybrać atrybut z rozwijanej w dół listy w komórce Attribute Name. Powinieneś wybrać Nazwę Atrybutu Sales Call Priority.

Teraz obie jednostki z połączeń sprzedażowych i statusu zamówienia będą się znajdowały w tej samej kolejce. Ponieważ jednostki połączeń sprzedażowych mają priorytet 0, zawsze będą przydzielone dostępnemu zasobowi Sales jako pierwsze. Jednostki połączenia o status zamówienia będą przydzielone do dostępnego zasobu tylko jeśli nie będzie aktualnie jednostek połączeń sprzedażowych w kolejce. To rozwiązuje nasz problem z przydzielaniem zasobów.

Po schwyceniu zasobu Sales, jednostka wchodzi do DELAY MODULE, jak na Display 5-26, z opóźnieniem TRIA (2,3,4) minut.

str. 226

Następnie jest wysyłana do RELEASE MODULE (ADVANCED PROCESS PANEL) gdzie upuszczamy zasób Sales, pokazane na Display 5-27.

Po upuszczeniu zasobu Sales jednostka jest wysyłana do wyjścia z systemu.

 

5.4.6 Wyjście z systemu i uruchomienie właściwości systemu

Po zakończeniu swojej misji, połączenia sekcji z pomocy technicznej, sprzedaży i statusu zamówienia są wszystkie wysyłane do tej części modelu. Kroki logiczne są pokazane tutaj, a moduły schematu blokowego na Figure 5-8.

Przychodzące jednostki wchodzą do RELEASE MODULE gdzie upuszczamy zasób TrunkLine, Display 5-28.

Po wyjściu z RELEASE MODULE, wchodzą do ASSIGN MODULE gdzie dekrementujemy aktywny licznik połączeń, zmienną Total WIP, Display 5-29.

Możemy użyć RECORD MODULE do zapisu zakończonego połączenia w liczniku CompletedCalls, na Display 5-30.

str. 227

Jednostka jest w końcu wysyłana do DISPOSE MODULE gdzie jest niszczona.

Zanim będziemy mogli przetestować nasz model, musimy otworzyć okno dialogowe RUN SETUP i zrobić wpisy dla PROJECT TITLE, ANALYST NAME i PROJECT DESCRIPTION, funkcje znajdują się w PROJECT PARAMETERS TAB. Także przyjęliśmy domyślne ustawienia dla STATISTIC COLLECTION SECTION, co oznacza, że automatycznie dostaniemy statystyki z jednostek, zasobów i kolejek. Teraz idź do REPLICATION PARAMETERS TAB gdzie żądaliśmy pojedynczego powielenia bez okresu przygotowania do pracy, nieskończonej długości powielania, i gdzie określiliśmy podstawowe jednostki czasu jako minuty.

str.228

W tym miejscu, może pamiętasz (zgadujemy, że już zapomniałeś), że wcześniej w początkowej części sekcji 5.4.1 powiedzieliśmy, że użyjemy zmiennej Total WIP żeby pomóc zdefiniować kiedy zakończyć symulację. Call center akceptuje połączenia przychodzące od 8.00 do 18.00 (600 minut), ale wszystkie połączenia, które są w systemie o 18.00 muszą być ukończone. Moglibyśmy ustalić długi czas powielania w sposób dowolny, ale rezultatem tego będą niedokładne statystyki, w szczególności zasobu wykorzystania i inne statystyki czasu ciągłego. Są dwa warunki, które muszą być prawdziwe zanim będziemy mogli zamknąć system i zakończyć działanie symulacji. Pierwszy warunek jest taki, że czas trwania symulacji musi trwać najmniej 600 minut. Drugi warunek jest taki, że musimy zakończyć wszystkie połączenia. Ponieważ zmienna Total WIP jest użyta, aby uaktualniać na bieżąco, to jak wiele połączeń jest obecnie w systemie, musimy tylko sprawdzić czy jest ona zero, co oznacza, że wszystkie połączenia zostały zakończone. Więc wpisujemy wyrażenie TNOW >= 600.0 && TOTAL WIP == 0 do TERMINATING CONDITION FIELD; && znaczy „i”(and). Tak naprawdę użyliśmy EXPRESSION BUILDER żeby skonstruować wyrażenie.

Zdefiniowaliśmy zmienną specjalnie dla naszych zamiarów, mimo, że mogliśmy użyć opcji Areny zmiennej NR (TrunkLine). Ta zmienna mówi nam ile linii jest obecnie zajętych, więc jeśli jej wartość jest zero, nie ma żadnych aktywnych połączeń w systemie.

Do tej pory powinieneś już całkiem nieźle rozumieć jak używać modułów z ADVANCED PROCESS PANEL, i mamy nadzieję, lepiej rozumiesz, jakie główne moduły zapewnia BASIC PROCESS PANEL. Może zauważyłeś, że układ logiczny dla ostatnich dwóch sekcji, połączeń sprzedażowych i o status zamówienia, ma wiele wspólnych elementów. Przez zdefiniowanie i przyporządkowanie typu połączenia i wyrażeń dla czasów opóźnienia, mogliśmy stworzyć jedną ogólną sekcję układu logicznego, która mogłaby dać sobie radę z oboma typami połączeń. (Zastanawialiśmy się nad tym). Jednak, takie podejście może być czasami dość skomplikowane, i taki typ układu jest rzadko oczywisty dla innego modelarza (albo klienta), jeśli ktoś inny musi używać lub modyfikować Twój model. Jeżeli nie możesz łączyć znaczących ilości modelu logicznego i stworzyć ich zrozumiale, polecamy żebyś rozrysował każdą sekcję układu oddzielnie, nawet, jeśli może to być czasami przestarzałe/niepotrzebne. W zasadzie to jest kwestia gustu.

To zakańcza proces tworzenia naszego modelu, ale zanim spróbujemy sprawić żeby nasz model działał, zajmijmy się rozbudowaniem animacji.

 

5.4.7 Animacja

Nie chcemy się przywiązywać do animacji naszego modelu, ale chcemy zaprezentować działanie modelu. Zanimujemy nasz zapis opóźnienia (Storages), zasoby, kolejki zasobów, liczbę aktywnych połączeń w każdej części modelu, i całkowitą liczbę linii telefonicznych w użyciu. Nasza końcowa animacja jest pokazana na Figure5-9. Pokazuje ona stan w przybliżeniu 281.6 minut w działającej symulacji.

str. 229.

Zacznijmy umieszczeniem pamięci animacji dla zapisanych opóźnień. Obiekt pamięci animacji znajduje się w ANIMATE TRANSFER TOOLBAR, który możesz potrzebować dodać do swojego modelu. Wybranie przycisku STORAGE otworzy okno dialogowe STORAGE pokazane na Display 5-31. Możesz potem wybrać pamięć, jaką chcesz animować z listy IDENTIFIER rozwijanej w dół. Zanimowana pamięć zawiera takie same opcje jak zanimowana kolejka. Wybraliśmy, aby użyć ustawień domyślnych, co w rezultacie da pamięć liniową.Naciśnięcie OK umieści pamięć liniową na twojej animacji. Kiedy jednostka jest w tej pamięci, pojawi się na animacji tak jakby była w kolejce.

Po umieszczeniu pamięci dla początkowego zapisu opóźnienia, potem umieścimy pamięci dla połączeń z pomocą techniczną i o status zamówienia zapisu opóźnienia.

str. 230.

Za każdym razem jak umieścimy PROCESS MODULE (z Action albo SEIZE-DELAY albo SEIZE-DELAY-RELEASE) albo SEIZE MODULE w naszym modelu, Arena automatycznie stworzy niezależną kolejkę animacji. Te kolejki są przyłączone do części animacji twojego modelu, ale jest jeden subtelny punkt, który powinieneś poznać. Te kolejki są przyłączone do modułu, który je stworzył. Jeśli przeniesiesz kolejkę do swojej animacji a potem przeniesiesz moduł, zanimowana kolejka również będzie przeniesiona. Może być to trochę denerwujące jak zdasz sobie sprawę, że tworzysz początkową animację a potem przenosisz moduły żeby twój model wyglądał ładnie i żeby dodać logikę. Są dwa sposoby żeby przezwyciężyć ten problem. Pierwszym jest usunięcie wszystkich kolejek, które są tworzone, kiedy moduł jest umieszczany a potem dodanie ich z powrotem używając QUEUE OBJECT z ANIMATE TOOLBAR. Bardziej praktycznym sposobem jest kliknięcie na kolejkę, naciśnięcie klawisz CUT (albo Ctrl-X) żeby ją usunąć z animacji a potem użyć klawisza PASTE (albo Ctrl-V) żeby ponownie dodać. Zrobiliśmy tak dla naszych 4 kolejek – 3 połączeń z pomocą techniczną i połączenia z działem sprzedaży.

Potem dodaliśmy zasób animacji dla pomocy technicznej i sprzedaży, tak jak na Model 3-3 (sekcja 3.5.2), Model 3-5 (sekcja 3.5.3), Model 4-4 (sekcja 4.3.3) i Model 4-4 (sekcja 4.4), jak pokazane na Figures 5-9 i 5-10.

Następnie dodaliśmy zmienną, aby wskazać całkowitą liczbę połączeń w głównych obszarach – trzech obszarach pomocy technicznej i obszarze sprzedaży. Użyliśmy dwóch sposobów żeby otrzymać tę informację w naszej animacji. Najpierw spójrzmy, co zrobiliśmy w obszarze sprzedaży. Dodaliśmy zmienną używając klawisza Variable z ANIMATE TOOLBAR i wpisaliśmy wyrażenie NR (Sales) + NQ (Process Sales Call.Queue). To wyrażenie reprezentuje bieżącą liczbę zajętych jednostek zasobu Sales plus liczbę połączeń w kolejce czekających na zasób.

Do obszaru połączeń z pomocą techniczną mieliśmy inne podejście. Jest całkiem duża liczba zmiennych, które są przechowywane przez Arenę, więc sugerujemy użycie Arena Help żeby dowiedzieć się więcej o dostępnych zmiennych. Dla naszych potrzeb jest odpowiednia zmienna. Dla każdego PROCESS MODULE, który umieściłeś w modelu, Arena automatycznie definiuje zmienną NAME.WIP, gdzie NAME jest nazwą, jaką wpisałeś dla modułu. Również okazuje się, że kiedy umieszczać i ładujesz dane do PROCESS MODULE, Arena zapewnia zmienną jako część standardowej animacji dla tego modułu, wraz z kolejką.

str. 231.

Jeśli bliżej przyjrzysz się swojemu modelowi, kiedy działa to zobaczysz czerwone 0 umiejscowione dokładnie pod każdym PROCESS MODULE. Dla pomocy technicznej produktu Type 1, który okazał się być zmienną Process Product Type  1 Tech Call.WIP. Możesz umieścić nową zmienną używając przycisku Variable i wpisać nazwę – nie jest na liście rozwijanej w dół – albo możesz CUT i PASTE (wytnij i wklej) zmienną, w co jest wyposażony PROCESS MODULE. My użyliśmy funkcji wytnij i wklej w naszej animacji. Arena nie pozwoli Ci na animowanie wielokrotnych kolejek albo zasobów z tą samą nazwą, ale pozwoli na to zmiennym. Użyliśmy tego podejścia żeby dodać 3 zmienne WIP dla części animacji z pomocą techniczną.

Ostatnią rzeczą, jaką dodaliśmy do naszej animacji była całkowita liczba linii tel (trunk lines) będących w użyciu. Mogliśmy użyć zmiennej NR (TrunkLines), która dała by nam bieżącą liczbę połączeń w systemie. Zamiast tego, zdecydowaliśmy się dodać wykres (plot), tej samej zmiennej, co dało nam dobry pogląd na to jak wymagania w naszym systemie się zmieniły podczas działania symulacji. Żeby ukończyć naszą animację dodaliśmy, etykiety, kolor tła.

Jeśli twój program pracuje, możesz zauważyć spoglądając na wykres zajętych linii, że system jest albo pełny albo blisko bycia pełnym przez większość czasu; maximum połączeń na wykresie na wysokości 26 potwierdza naszą logikę przybyć, że odrzuca ona połączenia przychodzące, kiedy 26 linii jest aktualnie zajętych. Patrząc na wynik po zakończeniu działania systemu, widzimy, że było 734 połączeń próbujących się dodzwonić, z nich 643 było załatwione i 91 odrzuconych albo odmownych. Możesz również zauważyć, że długość działania symulacji była ponad 637 minut. Ostatnie 37 minut było czasem, który zabrało załatwieni połączeń, które przyszły o 18.00; zauważ, że wykres linii tel obniża się do zera pod koniec symulacji, potwierdzając naszą logikę systemu terminating opisaną powyżej.

 

Korekta i tłumaczenie: Monika Wosztyl

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s