Jak bezbłędnie połączyć system MFC z WMS

Co jest czym podczas integracji?

Piszę ten artykuł z całą świadomością tego, że sam nie jestem specjalistą w dziedzinie IT i mając nadzieję, że nie wszyscy czytelnicy nimi są. Tak więc z pozycji praktyka i planisty, niebędącego guru w sprawach technologii informatycznych, postaram się w miarę zrozumiałych słowach przekazać gronu szanownych Kolegów Logistyków istotę problemu integracji dwóch systemów skazanych na współpracę podczas integracji w jeden spójny system mechanizacji i automatyzacji procesów wewnątrz magazynowych.

Na początek nieco historii. Projekty mechanizacji magazynów realizowane 20-15 lat temu musiały ze względu na stan techniki być realizowane bez fizycznego łącza pomiędzy systemami WMS i PLC kierującymi układy przenośników. Sygnały służące do informowania danego napędu odcinka przenośników były przekazywane za pomocą fotokomórek i listków odblaskowych. I tak na przykład pracownik kompletujący towary w stacji posiadał list kompletacyjny wydrukowany na papierze wraz z instrukcją, według której ustawiał listki z folią odblaskową w odpowiedniej odległości od listka referencyjnego. W ten sposób fotokomórka potrafiła poprzez układ PLC „wyliczyć”, czy dany pojemnik ma wjechać do stacji kompletacyjnej, czy też pojechać do kolejnej, do której był dedykowany. Interfejsem łączącym zatem polecenia WMS kompletacji w stacji do przenośnika była pośrednio lista kompletacyjna i wykonana czynność przemieszczenia listka.

W układach tego typu oczywiście nie mogło być mowy o sterowaniu w czasie rzeczywistym i ilość błędów związanych z odczytem lub wynikającym z błędów ludzkich była odpowiednio duża. Niemniej systemy te były stosowane ze względu na prostotę i znikomy nakład pracy podczas integracji systemów.

Dalszy rozwój techniki zarówno w dziedzinie programowania jak i elektroniki spowodowały konieczność bezpośredniego i fizycznego połączenia tych systemów. Coraz bardziej zawiłe algorytmy WMS powodowały zwiększenie zapotrzebowania na szybką reakcję układów sterujących przenośnikami, które mogła w czasie rzeczywistym odpowiadać na sygnały.

W ten sposób wykreowany został system integracji poprzez wymianę plików z poleceniem. Tak zwany „string sterujący” posiadał zakodowane informacje o typie zlecenia lub o tym co w danym układzie skrzyżowania na przenośnikach ma wykonać zwrotnica, tak aby przekierować pojemnik na właściwy tor.

Podczas gdy na rynku istniało bardzo wiele typów osprzętu elektronicznego i programiści kreowali własne standardy, koniecznym było ustalenie pewnej konwencji budowania „stingów”, tak aby były zrozumiałe dla wszystkich współpracujących systemów. W przypadku integracji dwóch obcych systemów tworzono do niedawna specyfikacje obejmujące wszystkie typy komend i stojących za nimi zadań, tak aby odłożony przez system wydający w ściśle określonym obszarze serwera plik mógł być odebrany przez system odbierający. Ciągłe „odpytywanie” serwerów, czy mają coś do przekazania kreowało konieczność określenia, co jest informacją nową a co już raz odebraną. Tworzono zatem systemy tzw. „flag” informujących z jaką informacją mamy do czynienia lub ustalano np. czy po odebraniu wiadomości, ta ma być wymazany z pamięci nośnika. Ustalano również w specyfikacji systemowej, czy na dane pytanie ma „paść” odpowiedź i co ma ona zawierać.

W ten sposób prowadzona komunikacja pomiędzy systemami sterowania urządzeniami i zarządzania magazynem uzyskały po raz pierwszy status komunikacji w czasie rzeczywistym, chociaż czasy reakcji nierzadko osiągały 1 sekundę i więcej, co wymagało odpowiedniej odległości pomiędzy np. skanerem a zwrotnicą zmieniającą kierunek ruchu pojemnika. W przypadku braku odpowiedzi systemu na przekazaną informację, prowadziło to to odbycia przez pojemnik dodatkowej rundy (jeżeli taka możliwość była przewidziana) lub trafiały one do tzw. „kosza” z NO-READ-ami. Pojemniki bez celu jadące na przenośnikach były widokiem raczej częstym i powodowały frustrację obsługi linii. Wymagały identyfikowania błąkających się nośników i przynależnych do nich zleceń. Ponieważ najczęściej informacje zawarte w stringach były już wymazane, powstawała konieczność ponownej generacji takiego zlecenia i odłożenia już skompletowanych produktów na półki regałowe.

Sporym ograniczeniem tej metody integracji były również maksymalne ilości pojemników jednocześnie znajdujących się w systemie, co powodowało odpowiednio duże natężenie „pytań i odpowiedzi” skierowanych do serwerów. Jakość sieci w magazynie, wydajność procesorów, ale również czystość w hali decydowały o tym iż średnie przepustowości nie przekraczały 400 do 800 pojemników na godzinę. Większe ilości nośników powodowały jedynie tworzenie się zatorów i obniżenie wydajności całości systemu.

Wraz z rozwojem technologii internetowej powstał nowy typ logicznego połączenia różnych systemów informatycznych na bazie protokołu TCP/IP w oparciu o tzw. „wtyczki”. Dwa różne programy posiadające właśnie takie wtyczki będąc umieszczone na jednym lub różnych komputerach mogły wymieniać pomiędzy sobą zadania. Programy takie posiadające najczęściej własne archiwa mogły już przechowywać przez określony okres przyjęte lub wysłane informacje, co pozwalało na ich analizę nawet w przypadku wystąpienia błędów komunikacyjnych, były jednak kosztowo intensywne i wymagały stosunkowo długiego okresu przygotowania. Kilka ustawień wymaganych podczas konfiguracji (rys. 4) wystarczy za zwyczaj aby doprowadzić do możliwości komunikacji pomiędzy MFS i WMS.

Zaletą tej technologii jest również to, że rozwinięte systemy WMS potrafią nawiązywać jednym standardowym narzędziem komunikację z wieloma niezależnymi od siebie pod-systemami MFC, co zdarza się wówczas, gdy jest kilku dostawców urządzeń mechanizacji i automatyzacji w jednym projekcie, które wszystkie wymagają jednoczesnej komunikacji z WMS-em.

Najbardziej obecnie rozwiniętą formą komunikacji międzysystemowej jest ta, która opiera się na bezpośredniej komunikacji baz danych. Do największych korzyści z tytułu takiej komunikacji należy zaliczyć możliwość operowania z poziomu interfejsu użytkownika, który jest standardowy dla danej bazy danych, oraz możliwości wymiany całych kolumn danych pomiędzy bazami bez konieczności budowania dodatkowych interfejsów.

Przekaz każdego zadania jest „wyposażony” we własny niepowtarzalny identyfikator tzw. transfer-ID, co pozwala na identyfikacje każdej transakcji i jej skutków, jeżeli ich śledzenie zostało przewidziane po stronie systemu FMC.

Prowadzone pomiary wydajności takich systemów komunikacji wskazują (w zależności od konstrukcji) procesora na prowadzenie ok. 3.000 transakcji w ciągu jednej sekundy, co powoduje iż sterowany w ten sposób system posiada wyżej wspomnianą zaletę kontroli przepływu w czasie rzeczywistym i przepustowości mechaniczne systemów osiągają 3.500 pojemników na godzinę.

Jak połączyć ze sobą systemy MFC i WMS?

Wybór technologii opisanych wcześniej pozostawiam w gestii specjalistów IT i administratorów sieciowych, niemniej zalecam przygotowanie tego procesu w oparciu o następujące przesłanki:

• oczekiwana przepustowość mechaniczna linii
• planowane przyszłe rozbudowy linii o kolejne elementy technologiczne
• bezpieczeństwo danych i pewność w ich procesie wymiany (śledzenie i archiwizacja transakcji)
• koszty zakupu i eksploatacji (opłaty serwisowe dla baz danych)
• dostępność i kompetencje administratorów systemów

Wystarczająco często inwestorzy (najczęściej nieznający specyfiki tej materii) polegają na opinii swoich współpracowników, którzy kierują się własnymi przesłankami nie mając wystarczająco doświadczenia w integracji tego typu systemów. I nie ma w mojej wypowiedzi podłoża złośliwości, a jedynie jest ona wynikiem wieloletnich obserwacji procesów integracyjnych, gdzie spierają się racje dostawcy i klienta.

Zalecamy wówczas naszym klientom przeprowadzenie warsztatów, których podsumowanie w postaci analiz typu SWAT pozwala w prosty sposób przedstawić wszystkie aspekty wdrożenia interesariuszom projektu.

Gdy znajdziemy wspólną platformę do wymiany danych pomiędzy MFC i WMS-em, powinniśmy rozpocząć testowanie komunikacji na długo przed przystąpieniem do uruchomienia. W tym celu możemy wykorzystać tzw. emulatory oprogramowania MFC, które to programy „udając” prawdziwą instalacje są w stanie przyjąć i po obróbce odesłać telegramy z informacjami. Informacje te zawierają logiczne reakcje urządzeń (wirtualnie zainstalowanych w emulatorze) i pozwalają na ocenę na ile prawidłowo skonfigurowany WMS potrafi postawić zadania do realizacji przez system MFC. Testy takie powinny opierać się na uprzednio przygotowanych scenariuszach i przewidywać wszystkie możliwe warianty współpracy systemów.

Jako że emulacje są jedynie wirtualnymi „uosobieniami” prawdziwie zainstalowanych systemów, przystępując do kolejnej fazy rozruchu (tzw. COLD-RUN) realizujemy program testowy opracowany uprzednio dla emulatorów i w praktyce na urządzeniach sprawdzamy jego przydatność do obsługi zadań.

W przypadku testów COLD-RUN stoją przed nami zadania zarówno operacyjne, jak i konfiguracji obu systemów, gdyż czas jaki mija w trakcie realizacji projektów automatyzacji magazynowej pozwala na to, że na rynku pojawiają się np. nowe wersje tzw. „switch-ów” lub API, które wymagają ponownego zestrojenia w systemie.

Podobnie ma się rzecz w przypadku ponownego dostrojenia praw dostępu (w przypadku bazy danych łub ustawień sieci), tak aby pliki z informacjami mogły być odłożone w danej przestrzeni wirtualnej lub stamtąd odebrane bez wywoływania konfliktów z zasadami bezpieczeństwa panującymi w danej sieci lub przestrzeni.

Zalecam również przed przystąpieniem do integracji sprawdzenie wszystkich elementów oprzyrządowania wspomagającego komunikację MFC i WMS. Nierzadko problemy z siecią wewnątrz magazynu, jak i elementami tej sieci, serwery i trasy kablowe są przyczyną powolnej pracy systemu lub wręcz ją uniemożliwiają.

Co następuje potem?

Kiedy uda nam się uruchomić już system mechanizacji i automatyzacji w magazynie, nie wolno nam zapominać o bieżących pracach serwisowych, które powinny być przygotowane podobnie jak przeglądy mechanicznej części instalacji w określonych przedziałach czasowych.

Szczególnej uwadze polecam przygotowanie procedur dla dokonania zmian systemowych lub wprowadzenia aktualizacji systemowych części lub całego oprogramowania. Najczęściej pojawiającym się podczas takich aktualizacji problem jest brak aktualizacji dla interfejsów lub baz danych, które powodują niemożliwość dalszej współpracy.

Problemy na linii komunikacji baza do bazy lub wewnątrz sieci mogą spowodować unieruchomienie całej instalacji w magazynie. Dlatego zalecam prowadzenie takich niezbędnych prac aktualizujących nasze oprogramowanie w dniach wolnych od pracy w magazynie i przygotowanie scenariusza powrotu do statusu sprzed wprowadzenia zmiany.

Dla zarządzania system rekomenduję również przygotowanie więcej niż jedna osoba i wprowadzenie reguł opisujących prawa dostępu i kompetencje podczas dokonywania zmian systemowych.