Dobra praktyka: Kontrola wydajności produkcji czyli jak sprawnie analizować postoje

Dlaczego nie realizujemy założonych planów produkcji? Co zrobić jeśli wydajność jest na niezadowalającym poziomie? W jaki sposób przyspieszyć produkcję? Gdzie szukać przyczyny słabnących wskaźników? Jakie awarie powodują przestoje i jak często one występują oraz ile czasu trwa ich zlokalizowanie czy naprawa? Takie pytania na porządku dziennym stawiają sobie managerowie odpowiedzialni za zarządzanie produkcją.

Brak narzędzi do analizy przestojów
Nasz Klient działający w branży spożywczej, posiadający bardzo nowoczesne linie produkcyjne, borykał się na co dzień z problemem częstych postojów na poszczególnych liniach. Co istotniejsze, w zakładzie brakowało jednolitego i zautomatyzowanego systemu analizy przyczyn takiej sytuacji. Dotychczas wszystkie awarie w zakładzie oraz czasy przestojów spisywane były przez team leaderów na podstawie danych podawanych przez operatorów maszyn. Liczby te określane były z dużym przybliżeniem, a więc niedokładnie. Brakowało także narzędzi pomiarowych oraz jednolitych i jasnych procedur postępowania w przypadku wystąpienia usterki. Ponadto, przyczyna awarii oraz czas jaki mijał od jej wystąpienia do przybycia technika i naprawy konkretnego uszkodzenia nie były w żaden sposób monitorowane.
W wyniku braku tak wielu informacji dotyczących zdarzeń awaryjnych, trudno dotrzeć do źródła problemu i w miejsce doraźnych działań wprowadzić plan naprawczy. Zaproponowaliśmy więc rozwiązanie pozwalające na precyzyjny pomiar wymienionych czynników tak, aby wyniki pomiarów mogły stanowić punkt wyjścia do analizy występujących problemów. Znając przyczynę zatrzymania linii można bowiem zapobiegać, a przynajmniej minimalizować występowanie błędów i awarii. Przykładowo, jeśli za awarię odpowiada konkretny element maszyny, można monitorować jego stan. Gdy problem pojawia się wielokrotnie, jest to informacja dla pracowników utrzymania ruchu, że część jest wadliwa i prawdopodobnie należy wymienić ją na nową. Następnie, na podstawie danych o czasie naprawy usterki można zdecydować co jest bardziej opłacalne – wymiana części czy jej ciągła naprawa.

Rozwiązaniem okazał się czytnik…
Aby mógł powstać system integrujący istotne informacje pochodzące z danego procesu produkcji, muszą zostać opisane i zidentyfikowane wszystkie sygnały awaryjne przypisane do wejść sterownika PLC. W przypadku wystąpienia awarii urządzenia, pojawia się określony sygnał, który następnie zostaje rozpoznany przez system i wpisany do raportu. Dodatkowo, generowane raporty powinny wykazywać kto pracował na maszynie w danej chwili oraz jaki rodzaj materiału był wtedy pobierany.
Doskonałym pomysłem okazało się wprowadzanie tych danych do systemu za pomocą kodów kreskowych. W tym celu zastosowaliśmy czytnik kodów kreskowych Motorola Symbol LS2208, w oprogramowanie którego wprowadzone zostały indywidualne kody zarówno każdego operatora jak i skanowanego materiału. Rozwiązanie takie niweluje konieczność ręcznego wprowadzania danych na panelu operatorskim, a przez to pozwala na oszczędność czasu i eliminuje błędy.

Czytnik kodów kreskowych Motorola Symbol LS2208 oraz
przykładowy kod kreskowy przetwarzanego materiału

Kod kreskowy za pomocą interfejsu RS232 zostaje przesłany do modułu rozproszonego Allen-Bradley 1734-ACNR, w którym znajduje się karta 1734 – 232ASC posiadająca możliwość odbioru kodów ASCII (zakład wykorzystywał już opisaną strukturę sprzętową, ale do pełnienia zupełnie innych funkcji).
Do poprawnego odczytu danych ze skanera kodów kreskowych konieczna była rekonfiguracja istniejącego programu w sterowniku Controllogix 1756-L61, jak również przygotowanie danych dla
systemu Metrics. Z kolei dzięki dodaniu dodatkowego ekranu na panelu dotykowym PanelView 1000, operator uzyskał możliwość stwierdzenia, czy wprowadzone kody są poprawne. Na poniższej ilustracji znajdują się dwa pola. Pierwsze z nich pokazuje jaki operator aktualnie pracuje na maszynie, drugie pole pokazuje jaki materiał podlega przetwarzaniu.

Dodatkowy ekran dla czytnika kodów

…i oprogramowanie METRICS
METRICS firmy Rockwell Automation jest oprogramowaniem służącym przede wszystkim do zbierania danych z produkcji, ich analizy oraz generowania raportów. Podstawowym parametrem informującym o wydajności maszyny jest tzw. współczynnik OEE (Overall Equipment Effectiveness).

Współczynnik ten wyraża się wzorem:

OEE [%] = Availability × × Throughput × Quality

Availability – jest to stosunek czasu pracy do czasu, w którym maszyna mogła pracować

Throughput – jest to współczynnik określający jak blisko idealnego cyklu pracy jest maszyna w czasie swojej pracy.

Quality – jest to współczynnik określający ilość dobrego produktu do całkowitej ilości wyprodukowanego produktu.
Wykorzystanie współczynnika OEE pozwala osobom odpowiedzialnym za wydajność produkcji na określenie, która maszyna/linia/obszar roboczy ma najlepszą lub najgorszą wydajność.
Metrics to tak na prawdę grupa programów odpowiedzialna za różne elementy systemu i procesy przebiegające od pobrania danych do ich analizy.

Ogólnie możemy wyszczególnić cztery grupy:
• grupa zbierająca dane RSLinx Enterprise oraz FactoryTalk Transaction Manager
• grupa magazynująca dane Microsoft SQL Server 2005
• grupa tworzenia/odczytu raportów Report Expert
• grupa analizująca dane FactoryTalk Metrics

Aby dane mogły zostać przetworzone za pomocą systemu Metrics, najpierw muszą zostać rozpoznane na sterowniku PLC. Narzędziem wyspecjalizowanym w tym celu jest RSlinx Enterpise lub server OPC firmy Kepware. Następnie, administrator systemu Metrics powinien skonfigurować w narzędziu Configuration Console ścieżki dostępu do konkretnych zmiennych tak, aby po załączeniu programu Transaction Manager, zapis informacji do bazy danych MS SQL odbył się bez błędów.
Przystępując do realizacji projektu wiedzieliśmy, że dotychczasowe oprogramowanie zostało zainstalowane oraz skonfigurowane wcześniej przez inna firmę. Taka sytuacja jest znacznie trudniejsza dla programisty, który musi uważać, aby dodając swoją część aplikacji pozostawić resztę bez jakichkolwiek zmian.
Ponownej konfiguracji uległy takie elementy systemu jak Microsoft SQL 2005, źródła danych ODBC oraz FactoryTalk Administration Console.

Tworzenie raportów
Oprócz wyznaczenia wspomnianego już współczynnika OEE, ważną część stanowi zbieranie wszystkich niezbędnych sygnałów z analizowanych procesów np.: sygnałów awarii, alarmowych, czy sygnałów ciągłych takich jak prędkość, temperatura. Dla sygnałów ciągłych, producent przewidział dodatkowy program wchodzący w skład Metricsa nazywany Historianem. Za pomocą tego programu jesteśmy w stanie zapisywać wartości (np.: temperatura kleju z okresem próbkowania co 1 sekundę) i – co z tym związane – odtworzyć sygnał sięgając daleko wstecz.

Wykres temperatury dwóch składników

Oprogramowanie zawiera gamę bardzo przydatnych funkcji konfiguracyjnych takich jak: wyświetlanie wszystkich wartości sygnałów, wyświetlanie wartości z danego zakresu czasu, czy wyświetlanie wartości od określonego czasu w przeszłości do chwili obecnej itd. Dodatkowo mamy możliwość tworzenia własnych filtrów np.: na wykresie pojawią się sygnały z określonego przedziału wartości i czasu. W opisywanym rozwiązaniu wyświetlane są przede wszystkim maksymalny czas pracy maszyny bez zatrzymania oraz czas pracy maszyny od ostatniego zatrzymania. Oprócz sygnałów ciągłych ważną role odgrywają sygnały pojawiające się wybiórczo (unschedule value) takie jak wspomniane alarmy czy awarie. Za pomocą raportów jesteśmy w stanie określić gdzie dany sygnał wystąpił, ile trwał, jaki operator wtedy pracował, jaki materiał był przetwarzany, ile wynosiła prędkość linii oraz wiele innych parametrów, które wystarczy ustawić przy konfiguracji systemu.

Na poniższym raporcie można zaobserwować alarmy, które wystąpiły w trakcie pracy kilku operatorów. Sygnały oznaczone na czerwono są specyficzne dla Operatora 1 co oznacza, że żaden inny pracownik nie zetknął się z tego rodzaju problemami.

Przykładowe wyświetlanie awarii i alarmów na maszynie

Przy analizie większego odcinka pracy tego operatora można dojść do wniosku, że wykonuje on jakąś operację nieprawidłowo, w sposób który powoduje powstawanie alarmu. Przedstawione dane można rozpatrywać również od strony ilościowej – np. u operatora Kamil sygnał alarmowy „Mach2_Starved” wystąpił 24 razy, co w porównaniu z ilością alarmów u innych osób daje wysoki wynik. Obserwacje te mogą prowadzić do wskazania potrzeby ponownego przeszkolenia operatora z prawidłowej sekwencji czynności, którą należy wykonać na danym stanowisku pracy. Oczywiście jest to wersja hipotetyczna.

Efekt wdrożenia
W przypadku naszego Klienta, prócz archiwizowania czterech sygnałów ciągłych, najważniejszą rolę odgrywały sygnały awarii i alarmów (było ich ponad 800). Raport wykazuje jakie zdarzenia
zachodzą na maszynie najczęściej, w jakiej liczbie i ile czasu zabierały operatorowi lub technikowi naprawy, i – co z tym związane – jak długo maszyna nie produkowała i dlaczego tak się działo. Znając te wartości, manager produkcji może podjąć odpowiednie kroki czy to w kierunku wymiany czujników/napędów czy to w kierunku dodatkowego przeszkolenia pracownika. Z drugiej strony, pomiary stałych wartości oraz współczynnik OEE pozwalają na określenie zdolności produkcyjnej maszyn, czyli maksymalnej ilości produktu jaką można wyprodukować w określonym czasie. W efekcie pozwala to na określenie stopnia wykorzystania tej zdolności i jej dopasowanie do planowanej podaży. W ten oto sposób od poprawiania wydajności przechodzimy do jej planowania.

Na zakończenie należy zaznaczyć, że mimo tego, iż wdrożenie zostało oparte o uniwersalne narzędzia, w każdym przypadku istnieje konieczność dopasowania go do potrzeb danego zakładu produkcyjnego i dostarczenia rozwiązania „szytego na miarę”. Co oczywiste, nasze wdrożenie nie znajduje odpowiedzi na wszystkie problemy na linii produkcyjnej. Dzięki systematycznemu zbieraniu istotnych i precyzyjnych danych ułatwia ono jednak analizę problemów i przyczynia się do opracowania działań korygujących.