4. Message flows and specifications of the controllers

Messages can be identified from the concepts of the function model which contain `event’, `command’ or `request’ words. Although message requirements appear on the function model, the message flow sequence and its specifications have yet to be defined. The concepts on the function model only represent the set of messages flowing into and out from the activity box. In other words, the function model does not include the sequence of messages necessary to accomplish a specific process. It does not contain the specifications of each message, i.e. parameters, either.

4. Przepływy komunikatów i specyfikacje kontrolerów

Wiadomości mogą być identyfikowane z koncepcji modelu funkcyjnego zawierających słowa: “zdarzenie “, “polecenie” lub “żądanie”. Chociaż wymaganie komunikatu pojawia się na modelu funkcji, kolejność przepływu komunikatu i jego specyfikacje nie zostały jeszcze odpowiednio zdefiniowane. Koncepcje na modelu funkcyjnym stanowią jedynie zbiór komunikatów płynących do i z bloku działalności. Innymi słowy, model funkcyjny nie obejmuje kolejności komunikatów niezbędnych do osiągnięcia konkretnego procesu. Nie zawiera specyfikacji każdego komunikatu, tj. parametrów.

4.1. Message flow models

A message flow model describes the communication between controllers and function modules necessary to accomplish a specific scenario used as the basic organizing structure for establishing the focus and boundary conditions of the message flow. The model contains descriptions of message flow, i.e. messages and their temporal relations. This model will become an excellent tool for completely capturing detailed messages. Since the primary role of a scenario is to bind a context of a message flow, it is important to name and define it appropriately so that the message flow model can be easily associated with the real shop situations. The constructed model is based on the physical part flow and current states, as shown in table 1. This paper describes scenarios ( 1) , ( 3) , (5) and ( 8) in detail.

4.1. Modele przepływu komunikatu

Model przepływu komunikatów opisuje komunikację pomiędzy sterownikami i modułami funkcyjnymi, niezbędnymi do osiągnięcia konkretnego scenariusza używanego jako podstawowa struktura organizacyjna (celem ustalenia warunków brzegowych przepływu wiadomości). Model zawiera opisy przepływu komunikatów, tj. wiadomości i ich relacji czasowych. Model ten może być doskonałym narzędziem do całkowitego przechwytywania szczegółowych wiadomości. Odkąd podstawową rolą scenariusza jest nawiązanie kontekstu przepływu komunikatów, ważne jest, aby nazwać i zdefiniować go odpowiednio. Co za tym idzie, model przepływu komunikatów może być łatwo związany z realnymi sytuacjami magazynowymi, gdyż jest oparty na fizycznym przepływie części i aktualnych stanach, jak to pokazano w tabeli 1. Opisuje ona szczegółowo scenariusze (1), (3), (5) i (8).

A message flow model structure is designed on the basis of the IDEF3 process description capture method (Mayer 1992) . The IDEF3 method is designed to support the capture and structuring of descriptions of how a system works using UOBs (Units Of Behaviour), and their temporal and causal relations. It is noted that UOB names are often verb phrases. The IDEF3 diagram consists of boxes and links, where a box represents a type of UOB and a link represents the precedence relationships that hold between the UOBs being described. The IDEF3 method allows a UOB to be decomposed into a set of sub-UOBs and their precedence relations. The temporal precedence between messages and the decomposition structure in the message flow model are similar to those of IDEF3. However, the message flow model must be able to represent message name, message source and message destination as well. It contains an asynchronous junction ( &), which implies that a fan-out junction is followed by several message destinations and a fan-in junction is followed by the message source.

Struktura modelu przepływu komunikatów jest zaprojektowana na podstawie procesu IDEF3 - opisu metod przechwytywania (Mayer 1992). Metoda IDEF3 jest zaprojektowana do wspierania przechwytywania oraz strukturyzacji opisów, również określenia jak system działa przy użyciu systemu UOBs (Units Of Behaviour) oraz przechwytywania ich relacji czasowych i przyczynowych. Należy zauważyć, że nazwy UOB są często czasownikami. Schemat IDEF3 składa się z pudełek i linków, gdzie pudełko reprezentuje typ UOB, a link reprezentuje relacje pierwszeństwa, które są pomiędzy opisywanymi przez UOB. Metoda IDEF3 pozwala na rozłożenie UOB na zestaw podjednostek UOB i ich stosunków pierwszeństwa. Pierwszeństwo czasowe między komunikatami i rozłożoną strukturą w modelu przepływu komunikatów są podobne do tych z IDEF3. Jednak model przepływu komunikatów musi być w stanie nie tylko reprezentować nazwę komunikatu, ale także jego źródło i cel. Model zawiera asynchroniczne skrzyżowanie (&), co oznacza, że wyjście z węzła następuje w poszczególnych kierunkach komunikatu, a wejście przez źródło komunikatu.

The workstation controller starts with the acceptance of orders from the shop controller. In the hierarchical control architecture, an order from the supervisor to the subordinate is directly assigned. However, the scenario for a new part arrival requires many messages flowing among controllers and their function modules. The message flow model is illustrated in figure 10(a) for a new part arrival from the conveyor to a machine in the workstation . The message flow model is depicted in figure 10(b) for part leaving from a machine to the conveyor. Receiving a load message from the shop controller, the workstation executor sends a plan message to the workstation planner that then generates an MPG and sends a plan _done message to the workstation scheduler. The workstation scheduler then adds the new part to the part status data that contains a set of parts to be dispatched. If the workstation scheduler allows the new part to move to a machine, it sends a move message to the workstation executor. The workstation executor commands the robot controller to pick up the concerned part from the conveyor. Between robot controller and conveyor controller, synchronization is required, which is indicated by a grey shadow. Once the part is successfully allocated to the robot, the workstation executor informs the shop controller that the part was moved to the workstation, implying that the owner of the part becomes the workstation controller. The workstation executor continuously sends command messages to the robot and machine executor to transfer the part. Once the part is safely transferred to the machine, the machine executor invokes the machine scheduler and reports the successful acceptance of the part to the workstation executor.

Kontroler stacji roboczej rozpoczyna od przyjęcia zamówienia od kontrolera w magazynie. W hierarchicznej strukturze kontroli, zamówienie od przełożonego do podwładnego jest bezpośrednio przypisane. Jednak scenariusz przyjazdu nowej części wymaga wielu wiadomości płynących między kontrolerami i ich modułami funkcyjnymi. Model przepływu komunikatów dla nowoprzybyłej części z przenośnika do urządzenia na stanowisku pracy przedstawiono na ilustracji 10 (a). Model przepływu komunikatów od przejścia części z maszyny do przenośnika pokazano na ilustracji 10 (b). Odbierając wiadomość o ładunku od kontrolera magazynu, wykonawca ze stanowiska roboczego wysyła komunikat plan do planisty stanowiska, który następnie generuje MPG i wysyła wiadomość plan_done do planisty stacji roboczej. Planista następnie dodaje nową informację do danych o stanie części zawierającej zestaw części do wysyłki. Jeśli planista umożliwi nowej części przeniesienie do maszyny, to wysyła komunikat move do wykonawcy w stacji roboczej. Wykonawca poleceń daje komendę dla kontrolera (robota), aby podnieść konkretne części z przenośnika. Pomiędzy robotem i przenośnikiem wymagana jest pełna synchronizacja, co wskazuje szare tło. Po pomyślnym przeniesieniu części do robota, wykonawca informuje kontrolera w magazynie o przeniesieniu części do stacji roboczej, co oznacza, że właściciel części staje się kontrolerem stacji roboczej. Wykonawca ciągle wysyła wiadomości poleceń do robota i maszyn wykonawcy, aby przenieść część. Gdy część jest bezpiecznie przeniesiona na maszynę, wykonawca-robot wywołuje harmonogram i zgłasza udane przyjęcie części do wykonawcy.

Assume that on the basis of some event the workstation scheduler determines to move a part from machine to machine. The detailed message flow model for the part movement scenario from machine to machine is illustrated in figure 11( a) . The scheduler issues and sends a move message to the workstation executor. The workstation executor then sends an unload message to the machine executor and a pick message to the robot executor. Both robot and machine executors perform the synchronization activities to transfer the part, whose indication is shown in a grey shadow. The robot then picks the part from the machine. Once the workstation executor is informed of the successful transfer, it sends a load message to the machine executor and a put message to the robot executor. A machining activity is begun when the machine executor sends a plan message to the machine planner. A message flow model for machining task on a machine is depicted in figure 11(b) . After planning is completed, the machine planner sends a plan _done message to the scheduler. The scheduler then selects a feature to be firstly machined and sends a download message to the executor to download the related NC instruction to the machine control unit. When the assigned part feature is completely machined, a feature_done message is captured by the executor that forwards the message to the scheduler. If there exist no more features to be machined, the executor sends a task_done message to the workstation executor.

Załóżmy, że na podstawie pewnego zdarzenia planista stacji roboczej decyduje się przenieść część z maszyny do maszyny. Szczegółowy model przepływu komunikatów dla scenariusza przejścia części od maszyny do maszyny jest przedstawiony na ilustracji 11 (a). Planista wprowadza i wysyła komunikat move do wykonawcy stacji roboczej. Wykonawca następnie wysyła komunikat unload do maszyny wykonującej i przesyła komunikat pick do robota wykonującego. Zarówno robot jak i maszyna wykonująca wykonują synchroniczne działania, aby przenieść część (oznaczone przez szare tło). Robot następnie wybiera części z maszyny. Wykonawca zostaje poinformowany o zakończeniu transferu, wysyła komunikat load do maszyny wykonującej i komunikat put do robota wykonującego. Obróbka rozpoczyna się, gdy urządzenie wykonujące wysyła wiadomość plan do urządzenia planującego. Model przepływu komunikatów do obróbki na maszynie przedstawiono na ilustracji 11 (b). Po zakończeniu planowania, urządzenie planujące wysyła wiadomość plan_done do planisty. Planista następnie wybiera w pierwszej kolejności funkcję do wykonania i wysyła wiadomość download do wykonawcy, aby pobrał odpowiednie instrukcje NC do urządzenia sterującego maszyny. Gdy funkcja przypisanej części jest całkowicie zakończona, komunikat feature_done jest przechwytywany przez wykonawcę, który przekazuje komunikat do planisty. Jeśli nie ma innych funkcji do wykonania, wykonawca wysyła komunikat task_done do wykonawcy w stacji roboczej.

4.2. Message specifications

The main role of a message is a means of communication among controllers and functions. From the message requirements represented as the concepts in the function model, message flow models are captured, from which various messages required to accomplish several scenarios can be identified and specified. Messages activate other functions or controllers by telling what is to be done. A message belongs to one of two types: command and status. A command message flows in a hierarchical manner between controllers. A status message is used to reply as to whether the work assigned by a command message is finished. A status message can flow in any direction. A message carries some parameters that represent some information necessary for activating other functions or controllers. The specification of captured messages is illustrated in table 2. It should be noted that the messages for synchronization between two controllers are eliminated from the table.

4.2. Specyfikacje komunikatu

Główną rolą komunikatu jest bycie środkiem komunikacji między kontrolerami i funkcjami. Zgodnie z wymogami komunikatów reprezentowanymi jako pojęcia w modelu funkcyjnym, modele przepływu komunikatów są przechwycane. Z kolei z nich wiadomości wymagane do osiągnięcia kilku określonych scenariuszy, mogą być zidentyfikowane i zdefiniowane. Komunikaty aktywują inne funkcje lub kontrolery, informując je, co jest do zrobienia. Komunikat należy do jednego z dwóch typów: polecenie bądź status. Komunikat polecenia płynie w sposób hierarchiczny pomiędzy kontrolerami. Jego status jest stosowany do wystosowania odpowiedzi, czy praca przypisana do jego treści jest zakończona. Status komunikatu może przepływać w każdym kierunku. Zawiera on pewne parametry, które reprezentują określone informacje niezbędne do aktywacji innych funkcji lub kontrolerów. Szczegółową ilustrację przechwyconych komunikatów przedstawiono w tabeli 2. Należy zwrócić uwagę, że komunikaty synchronizacji pomiędzy dwoma kontrolerami są eliminowane z tabeli.