Osiągnięcie sukcesu w integracji sprzętu modułowego, wykorzystywanego w operacjach związanych z produkcją wsadową, może być sporym wyzwaniem. Postępowanie zgodnie z najlepszymi praktykami, takimi jak standaryzacja komunikacji między systemami oraz definiowanie informacji zwrotnych dotyczących statusu, może sprawić, że realizacja procesu produkcji będzie znacznie płynniejsza.
Wdrażanie nowych procesów lub rozbudowa istniejących zwykle obejmuje zainstalowanie sprzętu modułowego mobilnego, montowanego na płozach/ramie montażowej (skid mounted equipment, skids), pochodzącego od producentów wyposażenia oryginalnego (OEM). Zaletą wykorzystania takiego sprzętu modułowego jest krótszy czas wdrożenia nowego procesu w stosunku do konwencjonalnego systemu procesowego budowanego od podstaw.
Sprzęt modułowy montowany na płozach, ruchomych ramach, może zapewnić szybszą instalację oraz stanowić opłacalne rozwiązanie o wysokiej jakości – zarówno dla dostarczania mediów (np. energia elektryczna czy sprężone powietrze), jak i realizacji głównych funkcji procesowych. Integracja sprzętu modułowego może mieć charakter uproszczony, jeśli choć w niewielkim stopniu moduły współdziałają z ogólnym systemem technologicznym w zakładzie. W takim przypadku wymagane jest tylko zbieranie danych lub minimalny poziom współdziałania, aby możliwa była współpraca takiego sprzętu z głównym rozproszonym systemem sterowania (DCS) lub komputerowym systemem sterowania procesami technologicznymi i produkcji (SCADA). Jednak płynna integracja sprzętu modułowego z ogólnym procesem produkcyjnym w zakładzie może być wyzwaniem. Ścisła integracja sprzętu modułowego z działaniami związanymi z produkcją, takimi jak operacje wsadowe, wymaga głębszego poziomu spójnego współdziałania w celu osiągnięcia wyższego poziomu efektywności procesu.
Wyzwania związane z integracją sprzętu modułowego z operacjami wsadowymi
Podstawowym wyzwaniem dla integrowania systemu pochodzącego od dostawcy zewnętrznego z procesem jest to, że operacje typu upstream (wydobycie i dostawa surowców) i downstream (przetwarzanie surowców, produkcja i sprzedaż wyrobów) muszą być skoordynowane i korzystać ze spójnej filozofii operacyjnej. Montowany zwykle na płozach lub ruchomych ramach sprzęt modułowy, obsługujący np. dostarczanie mediów, po prostu realizuje na żądanie wymagane funkcje z zaprojektowaną wydajnością. Z drugiej strony pochodzący od producenta typu OEM sprzęt modułowy, który staje się elementem łańcucha lub działa jako element układanki w znacznie większym procesie, wymaga dodatkowej koordynacji jednostek upstream i downstream w celu osiągnięcia lepszych efektów.
Większość sprzętu modułowego jest dostarczana z dedykowanym sterownikiem (procesorem) oraz wejściami/wyjściami. Sprzęt taki jest zasadniczo projektowany do pracy niezależnej. Oznacza to, że działa bez przewidywania dostaw surowców (informacje od działów upstream) lub popytu klientów (informacje od działów downstream). Co więcej, często jest wymuszana taka realizacja całego procesu, aby obejść charakterystykę funkcjonalną producenta OEM. W wielu okolicznościach operacje realizowane przez sprzęt modułowy są bezpośrednim wynikiem programowania jego systemu, a nie ograniczeniem możliwości sprzętu. Oznacza to, że sprzęt modułowy OEM nie jest produkowany tak, aby działał w trybie podporządkowania (slave) z punktu widzenia ogólnego koordynatora procesu lub głównego sterownika procesu.
Zasada niezależnego funkcjonowania sprzętu modułowego produkcji OEM jest wynikiem trendu w produkcji modułów. Zmiany istniejącej funkcji operacyjnej stwarzają bowiem ryzyko dla tych producentów, tak więc są oni zazwyczaj niechętni do rozszerzania funkcji systemowych na żądanie. Integracja modułów mobilnych (na płozach) z istniejącym systemem produkcji wsadowej jest utrudniona, ponieważ większość takich modułów nie jest programowana przy użyciu standardów ISA S88.01: Sterowanie Procesami Wsadowymi.
Większość programów do obsługi urządzeń modułowych jest pisana w języku drabinkowym, który został pierwotnie opracowany dla dostarczania wielu opcji i funkcji przetwarzania sygnałów sterowania. Pozwala to pojedynczej aplikacji programowej obejmować wiele opcji przetwarzania. Logika języka drabinkowego może być wykorzystana do realizacji zgodności ze standardami programowania, jednak wymaga to dodatkowego wysiłku. Brak wykorzystania standardowych praktyk programowania, zbytnie komplikowanie aplikacji za pomocą wielu funkcji przetwarzania, które nie są ostatecznie wykorzystywane, oraz unikanie ryzyka przez producenta – wszystko to może sprawić, że szybka integracja systemów w celu uzyskania całościowego rozwiązania sterowania produkcją wsadową będzie trudna.
Integracja systemów dla celów operacji wsadowych
Integrowanie sprzętu modułowego produkcji OEM z całym systemem zarządzania produkcją wsadową wymaga jasno zdefiniowanego poziomu koordynacji między systemami sterowania (DCS lub SCADA) – podrzędnymi (slave) a nadrzędnymi (master). Proste polecenia dla systemu podrzędnego nie dają operatorowi wizualnego wglądu w status systemu sterowania. Jeśli wszystko działa perfekcyjnie, to proste polecenie z systemu nadrzędnego dla systemu podrzędnego będzie wystarczające. Jednak gdy wystąpią jakieś
wyjątkowe warunki, będzie bardzo trudno wykryć i/lub rozwiązać problem bez osobistego udania się do lokalnego interfejsu operatorskiego (HMI) danego urządzenia, aby określić, co jest jego przyczyną.
Takie podejście generuje opóźnienia w realizacji operacji, zwiększając czas cyklu wsadowego, zmniejsza stopień wykorzystania sprzętu oraz ogólną efektywność operacyjną. Możliwe jest jednak uzyskanie rozwiązania dla ścisłej integracji podrzędnego systemu produkcji OEM z ogólnym głównym systemem technologicznym przez przestrzeganie czterech prostych zaleceń. Należy:
→ dokonać alokacji trybów operacyjnych,
→ przestrzegać standardowych stanów operacyjnych,
→ zdefiniować informacje zwrotne dotyczące statusu,
→ wykonać standaryzację komunikacji pomiędzy systemami.
Projekt powinien synchronizować dwa różne elementy sprzętowe przez zdefiniowanie uzgodnionej metody współdziałania. Elastyczne rozwiązanie sterowania produkcją wsadową obejmuje odpowiednią izolację pomiędzy różnymi funkcjami, co prowadzi do standaryzacji sposobu ich sprzęgania z innymi funkcjami. Ten typ definicji pozwala jednostkom sprzętowym na niezależne funkcjonowanie i promuje ponowne użycie podstawowego kodu funkcji. Ponowne użycie kodu redukuje czas prac inżynierskich i minimalizuje możliwość popełnienia błędu przez ludzi.
1. Alokacja trybów operacyjnych
Tryby operacyjne sprzętu w odległych lokalizacjach mogą być trudne w obsłudze, jeśli ich granice nie są wyraźnie zdefiniowane. Czy operator może dokonywać zmian w sprzęcie lokalnie, jeśli zmienne sterujące zostały wprowadzone zdalnie z procedury ogólnej? Czy procedura ta powinna przejść w stan zatrzymania (hold), gdy specyficzny status operacyjny się zmienia? To tylko kilka pytań, które należy przeanalizować podczas integrowania odległego sprzętu. Reguły sprzęgania i zasada współdziałania systemu nadrzędnego i podrzędnego powinny być jasno zdefiniowane, aby uzyskać trwały i jednolity interfejs pomiędzy tymi dwoma systemami.
2. Przestrzeganie standardowych stanów operacyjnych
Standaryzacja stanów operacyjnych pozwala mechanizmowi na obsługiwanie trudnej części wsadu, co stanowi sytuację wyjątkową. Warunki takiej wyjątkowej sytuacji można zdefiniować jako zdarzenie, które występuje poza normalnym czy pożądanym zachowaniem procesu. Obsługa, przetwarzanie i powrót tych typów warunków do normalnych jest kluczowym elementem produkcji wsadowej. Obsługa wyjątków jest nie tylko ważna dla bezpieczeństwa procesu, ale jest także niezbędna dla zachowania jakości produktu oraz kluczowa dla osiągnięcia wysokiego poziomu efektywności operacyjnej. Obsługa wyjątków w programowaniu może stanowić nawet 70% prac związanych z programowaniem i musi być traktowana jako podstawowy cel w procesie projektowania sterowania produkcją wsadową.
3. Definiowanie informacji zwrotnych dotyczących statusu
Informacje zwrotne dotyczące statusu są zasadniczą częścią efektywnych operacji realizowanych między dwoma różnymi systemami. Informacje te powinny być ustrukturyzowane i zdefiniowane także dla trybów, stanów operacyjnych oraz warunków błędu. Reprezentowanie standardowych trybów i stanów powinno być wspólne dla całego sprzętu, jednak warunki błędu powinny być specyficzne dla każdego sprzętu osobno. Specyficzne informacje zwrotne dotyczące błędu systemu podrzędnego lub odległego powinny dostarczać pracownikom działów operacyjnych wizualne wskazania dotyczące warunków bieżących. Stany błędu mogą także być wykorzystane do wykrywania działań zapobiegawczych w celu zwiększenia stopnia wykorzystania sprzętu i poprawy efektywności operacyjnej systemu.
4. Standaryzacja komunikacji
Komunikacja pomiędzy systemami może być zrealizowana w bardzo efektywny sposób poprzez użycie jednolitej, pojedynczej wartości całkowitej. Komunikacja ta może być bardzo uproszczona, wykorzystując pojedyncze słowo dla poleceń dla systemu podrzędnego oraz dostarczając słowa statusu przychodzącego z systemu podrzędnego. Ogólny status poleceń może być wspólny w celu zachowania zgodności z trybem i stanami operacyjnymi. Jednak może się okazać konieczne wpisanie dodatkowych parametrów lub zmiennych systemowych do programowalnego sterownika logicznego (PLC) jako wynik ogólnych ustawień procedur w systemie głównym. Standaryzacja typów komunikacji dla sprzętu odległego lub pochodzącego od firmy innej niż OEM czyni system sterowania łatwiejszym w utrzymaniu i wydłuża czas jego eksploatacji. Opracowanie standardów komunikacyjnych dla odległych interfejsów musi być na tyle ogólne, standardowe, aby umożliwić dopasowanie się do różnych typów aplikacji, ale jednocześnie na tyle uszczegółowione, by możliwe było przekazanie konkretnych, standardowych wartości.
Rozwiązanie: standardy
Integracja systemów zdalnych, odległych lub podrzędnych może być wyzwaniem, jednak standaryzowane interfejsy czynią taki proces znacznie łatwiejszym w zarządzaniu. Dwa z podanych wyżej zaleceń są zdefiniowane wyraźnie w zakresie standardów ISA S88.01. Możliwe jest zdefiniowanie informacji zwrotnych dotyczących statusu oraz zasad pakowania danych komunikacyjnych między systemami w celu objęcia jednolitym systemem rozwiązań firm zewnętrznych. Projekt wspólnego interfejsu promuje podejmowanie wysiłków dla zbudowania spójnej, jednolitej platformy systemowej, co pozwala na łatwe utrzymanie i rozbudowę infrastruktury sprzętu obsługującego cały proces.
Rozwiązania wspólnego interfejsu powinny być udokumentowane w dokumencie projektowym, dostarczanym jako Specyfikacja Wymagań Użytkownika (User Requirement Specification – URS) dostawcom OEM w celu zachowania zgodności ze standardami. Takie podejście zapewni, że programowanie odległego systemu i urządzeń zdalnych będzie zgodne z oczekiwanymi operacjami. Standaryzacja współdziałania systemów w celu objęcia nim warunków i sytuacji wyjątkowych powinna pozwolić na stworzenie takiego systemu sterowania produkcją, który jest łatwiejszy w obsłudze i utrzymaniu, co przyniesie wyższy poziom efektywności operacyjnej.
Robbie Peoples jest menedżerem ds. integracji systemów w firmie Cross Company.
