System zdalnego monitorowania maszyn i operatorów – wybrane elementy

 

System for remote machines and operators monitoring - selected elements Abstract – The article is devoted to the conception and implementation of mobile testbed for machines and operators monitoring, which was created under the Manufacturing Control and Monitoring System project. The components of the prototype testbed are discussed and their selection is justified. Tested communication solutions are described, advantages and disadvantages of each configuration are considered. Data replication techniques used in project are presented and future works directions are signaled.

 

1. Wstęp

Projekt systemu monitorowania i sterowania produkcją [1] zakłada stworzenie platformy sprzętowo-programowej, która umożliwi polskim firmom produkcyjnym, w szczególności małym i średnim, zwiększenie konkurencyjności i sprostanie wzrastającym wymaganiom współczesnego globalnego rynku. Opracowana platforma będzie stanowiła podstawę do implementacji nowatorskich struktur organizacyjnych fabryk przyszłości oraz do zastosowania technik wieloagentowych i metod sztucznej inteligencji w polskich przedsiębiorstwach produkcyjnych. Potrzeba stosowania zaawansowanych technik informatycznych w obszarze zarządzania i sterowania procesami produkcyjnymi wynika z rosnącej złożoności tych procesów.

Projekt jest realizowany w ramach współpracy między Kołem Naukowym Automatyków i Robotyków ROBO, Katedrą Informatyki i Automatyki Politechniki Rzeszowskiej oraz trzema firmami z Klastra Technologicznego Zielona Kuźnia: dwoma produkcyjnymi, w których funkcjonują prototypowe wersje systemu, i jedną informatyczną. Pilotażowe stanowisko zostało również zainstalowane w firmie WSK „PZL Rzeszów”, będącej członkiem klastra Dolina Lotnicza. Ze względu na współpracę z firmami zrzeszonymi w klastrze Zielona Kuźnia wystąpiła potrzeba rozszerzenia podstawowej struktury systemu opisywanego w [1] o możliwość rejestracji danych z wielu obiektów rozproszonych przestrzennie. W artykule przedstawiono wyniki prac mających na celu skonstruowanie „mobilnego” stanowiska monitorowania maszyn i operatorów, które w przyszłości będzie stanowiło element infrastruktury zdalnego centrum monitorowania zasobów produkcyjnych klastra.

2. Architektura stanowiska

Projekt sprzętowej i programowej struktury stanowiska zakłada jego mobilność i autonomię. Wymagania te wynikają ze specyfiki projektu, a przede wszystkim konieczności wykorzystania stanowiska jako zestawu testowego, który może być czasowo instalowany w różnych firmach należących do klastra. Zestaw ma za zadanie umożliwić przedsiębiorstwom zapoznanie się z systemem we własnym środowisku produkcyjnym, bez ponoszenia kosztów związanych np. z instalacją infrastruktury komunikacyjnej. Stanowisko powinno umożliwić zdefiniowanie potrzeb i wymagań stawianych systemowi, z uwzględnieniem specyfiki profilu produkcji i struktury organizacyjnej konkretnego przedsiębiorstwa.

Mobilność rozumiana jest jako możliwość stosunkowo łatwego przemieszczania zestawu w ramach hal fabrycznych i pomiędzy nimi. Zgodnie z przyjętymi założeniami instalacja zestawu ma wymagać wykonania jedynie niezbędnych czynności, takich jak doprowadzenie zasilania sieciowego 230 V oraz sygnałów z monitorowanych maszyn, jak również zagwarantowania odpowiedniej ilości miejsca dla wygodnego dostępu do stanowiska przez operatorów.

Autonomia wiąże się z uniezależnieniem funkcjonowania stanowiska od infrastruktury sieciowej dostępnej w halach fabrycznych. Infrastruktura taka często nie jest dostępna, bądź możliwość jej wykorzystania jest ograniczona, ze względu na restrykcyjne procedury bezpieczeństwa stosowane w przedsiębiorstwach produkcyjnych.

Prototypowe stanowisko mobilne skonstruowano na bazie przyjętych założeń (rys. 1). Składniki sprzętowe stanowiska zainstalowane zostały w przemysłowej szafie komputerowej wyposażonej w kółka. Elementy sprzętowo-programowe umożliwiają rejestrację danych związanych z pracą maszyn i operatorów w czasie rzeczywistym oraz ich analizę. Zapewniają one także interfejs graficzny dla operatorów, pozwalając im na interakcję z systemem i podgląd stanu monitorowanych maszyn.

Głównym urządzeniem służącym do rejestracji i przetwarzania danych jest sterownik PAC (Programmable Automation Controller). Urządzenia typu PAC sukcesywnie zastępują klasyczne sterowniki PLC (Programmable Logic Controller), szczególnie w obszarach, w których wymagana jest integracja systemów automatyki i systemów informatycznych. Główną zaletą PAC jest zintegrowanie w jednym urządzeniu funkcjonalności PLC oraz możliwości oferowanych przez systemy operacyjne ogólnego przeznaczenia, np. Windows CE/Windows XP Embedded/Linux. W konsekwencji sterownik PAC może realizować równocześnie wiele zadań, związanych nie tylko ze sterowaniem i akwizycją danych, ale również z komunikacją z systemami informatycznymi przy użyciu standardowych protokołów i technologii (Ethernet, TCP/IP, Web Services). Umożliwia również stosunkowo wygodny zapis informacji do lokalnych i zdalnych baz danych, komunikację z urządzeniami peryferyjnymi (np. suwmiarką, czytnikiem kodów kreskowych) oraz możliwość uruchamiania graficznego interfejsu użytkownika bezpośrednio w warstwie systemu operacyjnego aplikacji [2].

Sterownik zainstalowany w zestawie mobilnym wyposażony jest w system Windows CE oraz rozproszone moduły wejść i wyjść cyfrowych pozwalające na rejestrację sygnałów związanych z pracą monitorowanych maszyn (tj. praca/brak pracy, tryb pracy, liczba wyprodukowanych sztuk itp.) oraz sterowanie urządzeniami pomocniczymi. Sterownik obsługuje również urządzenia peryferyjne umożliwiające interakcję operatorów z systemem, w tym monitor dotykowy, czytnik kodów kreskowych, czytnik kart zbliżeniowych RFID oraz wieżę sygnalizacyjną. W sterowniku funkcjonują dwie warstwy oprogramowania: program PLC działający w podsystemie soft PLC oraz aplikacja dla systemu Windows CE. Program PLC rejestruje sygnały z wejść sterownika i na podstawie zaimplementowanej logiki określa bieżące stany maszyn. Aplikacja pracująca w warstwie Windows CE komunikuje się z programem PLC pobierając informacje o stanach monitorowanych maszyn. Dostarcza ponadto HSI (Human System Interface) dla operatorów i komunikuje się, wykorzystując technologię Web Services i sieć Ethernet, z serwerem danych i aplikacją przetwarzania danych [3].

Istotnym elementem zestawu jest komputer PC, pełniący rolę lokalnego serwera danych. Pod jego kontrolą funkcjonuje SZBD (System Zarządzania Bazą Danych) PostgreSQL oraz serwer aplikacji GlassFish, w ramach którego działa moduł komunikacji, rejestracji i przetwarzania danych.

Serwer GlassFish zawiera także aplikacje WWW umożliwiające podgląd (z poziomu przeglądarki internetowej) stanu monitorowanych maszyn oraz analizę wskaźników statystycznych obliczanych na bazie zarejestrowanych danych. W porównaniu do stanu opisanego w [1], moduł monitorowania i moduł statystyk wydzielone zostały do odrębnych aplikacji wykonanych w nowej wersji technologii. Aplikacje przygotowano dla platformy Java EE 6 (Enterprise Edition), z wykorzystaniem technologii JSF 2.0 (Java Server Faces) i komponentów PrimeFaces. Ich wygląd zaprezentowano na rys. 2 i 3.

Omówione składniki stanowiska umożliwiają jego autonomiczne działanie na poziomie hali fabrycznej. Ze względu na założenia projektu, funkcjonowanie stanowiska nie powinno wymagać integracji z infrastrukturą sieciową przedsiębiorstwa. Aby umożliwić dostęp do informacji o bieżącym stanie monitorowanych maszyn, postępie realizacji produkcji czy wskaźnikach statystycznych spoza hali fabrycznej, np. z biura kierownictwa zakładu, w zestawie zainstalowano przemysłowy router GSM. W celu zabezpieczenia przed niepowołanym dostępem do systemu wykorzystano wirtualną sieć prywatną (VPN), zbudowaną przy pomocy oprogramowania OpenVPN.

Pierwszą przetestowaną strukturę stanowiska przedstawiono na rys. 4. Aplikacje WWW zainstalowane zostały na lokalnym serwerze danych, zaś dostęp do nich wymagał tworzenia tunelu VPN między stacją kliencką a serwerem lokalnym. Testy wykazały, iż takie rozwiązanie nie jest wygodne w użytkowaniu, ze względu na ograniczoną szybkość połączenia internetowego realizowanego za pośrednictwem sieci GSM (w zasięgu EDGE średnio około 128 kb/s dla wysyłania i 384 kb/s dla odbierania) oraz opóźnieniami transmisji (średnio ponad 250 ms). W aktualnej wersji aplikacja WWW wymaga przesłania około 200 kB danych w celu wyświetlenia strony z podglądem stanu maszyn. W praktyce czas pierwszego wyświetlenia takiego podglądu wynosił kilkadziesiąt sekund, i to przy korzystaniu z aplikacji jedynie przez jednego użytkownika.

Aby zapewnić szybki i wygodny dostęp do systemu dla użytkowników końcowych, przeniesiono aplikacje WWW i SZBD na zdalny serwer, ze stosunkowo szybkim łączem internetowym (symetryczne DSL o przepływności 2 Mb/s). Na jego rzecz zrezygnowano całkowicie z lokalnego serwera w stanowisku mobilnym. Skonfi gurowano tunel VPN między modemem GSM w stanowisku a serwerem zdalnym, zapewniając w ten sposób łączność sterownika PAC z serwerem (rys. 5). Przeprowadzone testy wydajności aplikacji użytkowników końcowych wykazały wzrost komfortu obsługi systemu w porównaniu do wcześniej opisanego rozwiązania, ujawniły jednak dwie zasadnicze wady tego rozwiązania. W związku z komunikacją z serwerem przez sieć GSM, pogorszył się komfort obsługi interfejsu graficznego działającego w sterowniku PAC i przeznaczonego dla operatorów maszyn. Pomimo mniejszych wymagań związanych z ilością przesyłanych danych (komunikacja przy użyciu Web Services), podstawowe operacje trwały kilkakrotnie dłużej niż w pierwotnej konfi guracji, zdarzały się ponadto błędy ich wykonania związane z utratą łączności w sieci GSM. Dodatkowo pojawiło się niebezpieczeństwo utraty rejestrowanych przez sterownik danych w przypadku dłuższego zaniku komunikacji GSM lub awarii po stronie serwera zdalnego. Aplikacja sterownika ma co prawda zaimplementowany lokalny bufor dla rejestrowanych zdarzeń, jednak jest on ograniczony pojemnością pamięci Flash.

Ostatecznie, na bazie opisanych doświadczeń, powstała konfiguracja łącząca zalety dwóch poprzednich (rys. 6). W stanowisku mobilnym pozostawiono lokalny serwer danych, z którym komunikuje się sterownik PAC, zaś klienci końcowi łączą się do zdalnego serwera z szybszym łączem internetowym. Taka konfiguracja wymaga synchronizacji danych między serwerem lokalnym i zdalnym. W tym celu tworzony jest pomiędzy serwerami tunel VPN, a sama wymiana danych odbywa się na poziomie SZBD PostgreSQL i wykorzystuje mechanizm replikacji danych.

3. Replikacja danych

Mechanizm replikacji polega na powielaniu i utrzymywaniu identycznych danych w środowisku wielu baz danych rozmieszczonych w różnych lokalizacjach (węzłach). Jest to osiągane poprzez wymianę komunikatów między węzłami – przechwytywanie modyfi kacji dokonywanych w określonym węźle i ich przesyłaniu do pozostałych węzłów. Kryteria stawiane idealnemu modelowi replikacji to: spełnianie przez transakcje kryteriów ACID (Atomicity, Consistency, Isolation, Durability), natychmiastowa propagacja modyfikacji między węzłami, symetryczność, duża wydajność i skalowalność [4].

W praktyce istnieje kilka typów replikacji, implementujących wybrane cechy modelu idealnego: replikacja synchroniczna, asynchroniczna (metoda wymiany danych między replikami), master-slave i multi-master (kierunek wymiany danych między replikami). Replikacja synchroniczna charakteryzuje się natychmiastowym przekazywaniem modyfikacji do wszystkich węzłów w ramach transakcji modyfikującej dane. Wyklucza ona występowanie konfliktów, ale wymaga stabilnego połączenia między węzłami i jest kosztowna czasowo. Replikacja asynchroniczna przechowuje wykonane modyfikacje w tzw. kolejce transakcji odroczonych, która jest dystrybuowana do pozostałych węzłów co określony czas. Ta metoda ma mniejsze wymagania związane ze stabilnością i szybkością komunikacji między węzłami, lecz podczas synchronizacji danych mogą wystąpić konflikty. Proces replikacji może odbywać się między węzłami jednokierunkowo (master-slave) lub dwukierunkowo (master-master). W dwukierunkowej replikacji istnieje większa możliwość wystąpienia konfliktów (np. jednoczesnej aktualizacji tego samego rekordu w dwóch węzłach) [4–6].

Mechanizmy replikacji wykorzystane w projekcie przedstawia rys. 7. Z uwagi na połączenie stanowiska z serwerem przez sieć telefonii komórkowej, co wiąże się z opóźnieniami, niską szybkością transmisji i możliwością wystąpienia okresowych zaników komunikacji, zdecydowano się wykorzystać replikację asynchroniczną.

Wydzielono dwa obszary replikacji w bazie danych systemu. Pierwszy dotyczy istotnych danych produkcyjnych, tj. zdarzeń dotyczących pracy maszyn i operatorów. Jako że dane te są rejestrowane na poziomie stanowiska mobilnego, zastosowano w tym obszarze replikację jednokierunkową master-slave, z lokalną bazą danych stanowiska jako główną (master) i bazą serwera zdalnego jako podrzędną (slave). Drugi obszar wymaga dwukierunkowej wymiany mniej istotnych danych, związanych np. z komunikacją tekstową z operatorami maszyn z poziomu aplikacji WWW. Wykorzystano w tym przypadku replikację master-master.

Przeprowadzono testy, które wykazały, iż zastosowane mechanizmy działają z wystarczającą szybkością i są odporne na utratę łączności między serwerami.

4. Podsumowanie

Pierwsze prototypowe stanowisko mobilne o opisanej strukturze zostało zainstalowane w lutym 2011 r. w firmie produkcyjnej należącej do klastra Zielona Kuźnia i jest aktualnie testowane w rzeczywistym środowisku produkcyjnym. W przyszłości planowane jest udoskonalenie zestawu mobilnego i obniżenie jego kosztu.

Długoterminowym celem projektu jest opracowanie rozwiązania, które umożliwi stworzenie zdalnego centrum inteligentnej analizy danych wykorzystywanego na potrzeby członków klastra Zielona Kuźnia. Centrum będzie miało za zdanie wspierać przedsiębiorstwa w zakresie zwiększania wydajności i efektywności procesów produkcyjnych.

Autorzy składają podziękowania firmom produkcyjnym z klastra Zielona Kuźnia za umożliwienie wykonania testów systemu oraz firmie Bernacki Industrial Services Sp. z o.o. za udostępnienie sprzętu, oprogramowania i wsparcie techniczne.

Bibliografia

1. Mączka T., Czech T., Żabiński T.: Innowacyjny system monitorowania i sterowania produkcją jako element fabryki przyszłości. Pomiary Automatyka Robotyka 2/2010, 38–39.
2. Żabiński T.: Implementation of Programmable Automation Controllers – Promising Perspective for Intelligent. Management and Production Manufacturing Systems Engineering Review, 2/2010 (lipiec).
3. Żabiński T., Mączka T.: Human System Interface for Manufacturing Control – Industrial Implementation. 3^rd International Conference on Human System Interaction HSI, Rzeszów, 13–15.05.2010.
4. Świder K., Rak T.: Replikacje baz danych w praktyce. [w:] Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.): Bazy Danych: Struktury, Algorytmy, Metody, rozdział 16, WKŁ 2006.
5. Khadzynov W., Maksymiuk M.: Realizacja replikacji w systemach heterogenicznych baz danych. [w:] Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.): Bazy Danych: Struktury, Algorytmy, Metody, rozdział 17, WKŁ 2006.
6. Wolski A.: Embedding data recharging in mobile platforms. Real-Time & Embedded Computing Conference (RTEC’01), Milan, Italy, November 26–29, 2001. 

mgr inż. Tomasz Mączka

Asystent w Katedrze Informatyki i Automatyki Politechniki Rzeszowskiej. Były członek SKN ROBO, obecnie jego współopiekun. Jako członek Koła uczestniczył w projekcie systemu monitorowania i sterowania produkcją, realizował pracę magisterką związaną z tym projektem. Aktualnie zajmuje się dalszym rozwojem systemu, planując w ramach działalności naukowej zastosować metody sztucznej inteligencji do analizy rejestrowanych danych.

dr inż. Tomasz Żabiński

Adiunkt w Katedrze Informatyki i Automatyki Politechniki Rzeszowskiej. Jego zainteresowania zawodowe to klasyczne i inteligentne metody sterowania urządzeniami mechatronicznymi, inteligentne systemy wytwarzania oraz systemy szybkiego prototypowania układów sterowania. Aktualnie prowadzi zajęcia z przedmiotów: automatyka i sterowanie, automatyka i regulacja automatyczna, przemysłowe systemy sterowania układami mechatronicznymi, przemysłowe systemy CNC.