Sterowanie rozproszone

Sieci umożliwiają zmniejszenie centralizacji. Gdy decentralizujemy proces, powinniśmy dostosować się do wymagań konkretnego zastosowania, uwzględniając specyfikę procesu produkcyjnego lub cyklu życia projektu.

 

Scentralizowane sterowanie w produkcji oraz zbliżonych środowiskach, podobnie jak i inne nowości technologiczne, jest mieczem obosiecznym. Sytuacja przypomina dwugłowe zwierzę z dziecięcych historyjek o doktorze Doolittle – kiedy jedna głowa zwierzęcia chciała iść w jakimś kierunku, ciągnęła za sobą drugą. W tym przypadku pojawia się pytanie, czy projekt powinien kształtować proces, czy też proces powinien decydować o kształcie projektu?

Centralizacja oznacza często jednoosobowy dostęp do całej operacji (lub linii produkcyjnej) lub dostęp dla małej grupy osób z jednego miejsca. Taką całkowitą zależność od jednej bądź kilku jednostek sprzętowych można porównać do włożenia wszystkich posiadanych jajek do koszyka. Jeśli się Państwo na to zdecydują, trzeba uważać na koszyk! (Jak słusznie podsumował tę mądrość Mark Twain). W całkowicie scentralizowanym projekcie, w którym nie ma żadnych zbędnych elementów, jeśli na skutek wyłączenia prądu lub awarii systemu albo innej pada serwer, wyłączają się również wszystkie procesy satelitarne. Ponadto centralizacja może nie zezwalać na szybkie reagowanie na zmieniające się warunki lub różnice sprzętowe pomiędzy urządzeniami pracującymi w różnych miejscach (w rozumieniu stref geograficznych). W rezultacie wielu producentów poszło w innym kierunku, rozdzielając sterowanie „pomiędzy prowincje”.

Ponieważ wostatnich latach mikroprocesory stały się znacznie lepsze i tańsze, firmy wbudowały je w zdalne urządzenia I/O, przyciski, czujniki oraz inne komponenty. Owe „inteligentne części” mogą wykonywać funkcje sterujące w sieci komunikacyjnej blisko procesów, którymi sterują. Ostatnie wynalazki, takie jak udoskonalone interfejsy człowiek-maszyna (HMI – human-machine interface), pozwalają inżynierom na przenoszenie wyświetlaczy typowych dla sterowni na produkcję, ukrytych w podręcznych urządzeniach, takich jak osobisty asystent cyfrowy (personal digital assistant – PDA).

 

Sieci pozwalają na dyskretne sterowanie piksel po pikselu

Lepsze procesory i sieci (przewodowe i bezprzewodowe) umożliwiają realizację projektów wielowarianto-wych. W każdym spośród wielu scenariuszy można przesłać dodatkowe instru-kcje wejściowe i dodatkowe dane wyjściowe w celu rejestracji, analiz, monitoro-wania i serwisu. Zdjęcia udostępnili (od lewej): Invensys, Wago, Motorola.

Źródło: Control Engineering USA

Rys. Ziarnistość lub „granulacja pikselowa” na przykładzie procesu, gdzie pomiary, decyzje i ich wykonanie następują bardzo szybko, w najbliższym sąsiedztwie. Wszystko to w jednym urządzeniu, kości lub module.

 

 Spojrzenie na konkretne zastosowanie

Jednak pytanie pozostaje w dalszym ciągu to samo: Ile mocy decyzyjnej ma punkt centralny, a ile kierownictwo linii produkcyjnej? Gdzie i kiedy potrzebne jest w dalszym ciągu scentralizowane sterowanie? Czy rozproszona inteligencja może skorzystać z jakichkolwiek funkcji, które muszą pozostać scentralizowane? W wynikającym z tego ciągu rozwiązań każde podeście ma swoje zalety i wady. Każde też sprawdza się najlepiej w określonych warunkach. Tylko jak te zastosowania rozgraniczyć?

Według Sama Herba, dyrektora platformy automatyzacji firmy Invensys Foxboro, producenci muszą brać pod uwagę liczbę wymaganych pętli sterowania, złożoność procesu, potrzebę modernizacji i optymalizacji procesu, koszt przestojów i wynikającą z niego potrzebę nadmiarowości oraz względy bezpieczeństwa. Duże, rozbudowane aplikacje zawierające wyrafinowane zabezpieczenia, tolerancję błędów lub zaawansowane strategie sterowania, zyskują na scentralizowanym sterowaniu. Ponadto ułatwia on atestację i dokumentowanie procesu zgodnie z przepisami, co sprawdza się idealnie w przemyśle farmaceutycznym i w nadzorowaniu emisji zanieczyszczeń.

Równocześnie scentralizowane sterowanie wymaga gigantycznych szerokości pasm komunikacyjnych do transmitowania parametrów procesu oraz innych danych i dostarczania ich do punktu sterowania. Jest też narażone na nieuchronne opóźnienie pomiędzy generowaniem danych w punktach źródłowych a reakcją (na nie) systemu. Tracy Lenz, starszy inżynier produktu pracujący dla Wago Corp., zauważa, że inżynierowie muszą precyzyjnie obliczać spodziewany ruch danych w sieci transmisyjnej i tak projektować magistralę fieldbus, żeby była w stanie go obsłużyć. Rozproszone, zdecentralizowane przetwarzanie pozwala na lokalne monitorowanie wejść i przetworników. Zdecentralizowany sterownik może reagować zdecydowanie prędzej na szybkie wejścia (high-speed inputs) niż jego scentralizowany odpowiednik, komunikujący się z procesorem głównym tylko po to, żeby zgłosić wykonanie podprogramu obsługi.

Rozważmy na przykład wewnętrzny test, wykonywany po załączeniu (power-on selftest) typowego systemu sterującego. Jeśli wykonuje się go bezpośrednio na jednostce centralnej, to instrukcje testowe, pomiary oraz sygnały odpowiedzi muszą przechodzić przez sieć, co może zablokować test albo spowodować konflikty przy jednoczesnych próbach dostępu do magistrali i inne błędy. Wbudowany, lokalny test wewnętrzny wykonuje to samo zadanie znacznie szybciej i łatwiej. Jednobitowa instrukcja z lokalizacji centralnej wyzwala test (który może być również uruchamiany lokalnie w pewnych warunkach granicznych), a jedyną wymaganą reakcją jest jednobitowy sygnał odpowiedzi „przeszło/nie przeszło”. Oczywiście dla większej użyteczności w przypadku błędu test wewnętrzny może zwrócić kod błędu umożliwiający wykrywanie i usuwanie usterek w systemie sterowania, ale nawet przesyłanie takich kodów powoduje jedynie drobne zagęszczenie przesyłu danych koniecznego w przypadku scentralizowanego systemu.

 

Tolerancja przerwań

Lenz sugeruje, że decentralizacja pozwala również na zaprogramowaną reakcję na awarię głównego procesora lub komunikacji sieciowej. Niektóre procesy, na przykład w produkcji farmaceutycznej, nie mogą tolerować przerwań. W zależności od warunków zdecentralizowana architektura może kontynuować proces bez zakłóceń, zainicjować sekwencyjne wyłączanie lub wykonać całkowite, ale kontrolowane zatrzymanie.

Producenci mogą stosować decentralizację również do starszych systemów, bez wymieniania istniejącego sprzętu i oprogramowania, co może znacznie obniżyć koszty. Lenz opisuje układ wielokrotnego przetwarzania wsadowego, w którym główny interfejs człowiek-maszyna (HMI) ładuje instrukcje (download) do zdecentralizowanego sterownika, który lokalnie wykonuje wsadowo sterowanie produkcją, równocześnie raportując dane do sieci. W tym przypadku główny sterownik służy jedynie jako interfejs do globalnej sieci. Lokalny węzeł komunikuje się z głównym sterownikiem przez sieć, oszczędzając na wymianie istniejącej infrastruktury.

Wczesne systemy sterujące charakteryzowały się głownie zależnością nadrzędny/podległy (master/slave), jak przypomina Gary Marrs, inżynier aplikacji z Lantronix Inc. Centralny sterownik z logiką programowalną (Programmable Logic Controller) lub inny sterownik wykonywał programy i zarządzał wszystkimi punktami I/O oraz komunikacją przez zdalne węzły. Marrs wskazuje trzy główne wady takiego
podejścia:

  • Zdalna komunikacja była bardzo mało wydajna. Jednostka nadrzędna (master) wysyłała polecenia do każdego zdalnego węzła podrzędnego i żądała odpowiedzi. Jeśli jeden z węzłów podrzędnych (slave) musiał się skomunikować z innym węzłem podrzędnym, komunikacja przechodziła przez jednostkę nadrzędną poprzez konfigurację „gwiazdy”. Długie czasy generowania poleceń i reakcji ograniczały zastosowania wymagające czasu rzeczywistego. Mimo że obecne sieci są znacznie szybsze, gęstość danych przechodzących przez nie zwiększa się przynajmniej równie szybko.
  • Scentralizowany system cierpiał z racji nietolerowania błędów. Konieczna konserwacja oraz nieplanowane przestoje pochłaniały czas i zasoby finansowe.
  • Niektóre scentralizowane systemy mogą być kosztowne w utrzymaniu. Inżynierowie projektowali scentralizowane systemy tak, aby pomieścić jak najwięcej funkcji sterujących i I/O. Podpinali każdy czujnik, silnik, przełącznik i układ wykonawczy do sterowni, co skutkowało wysokimi kosztami instalacji. Pojawiały się więc trudności z wykrywaniem i usuwaniem usterek w gigantycznych „gniazdach szczurów”, pełnych kabli i nieregularnie występujących problemów z zakłóceniami elektromagnetycznymi.

Sterowanie rozproszone rozwiązuje te problemy. Architektury sieci o węzłach równorzędnych zapewniają łatwą lokalizację sterowników oraz ich punktów I/O, jako że znajdują się one w pobliżu urządzeń, którymi sterują. System może przetwarzać pętle sterowania czasu rzeczywistego lokalnie, bez obciążania koncentratora, komunikując się bezpośrednio z innymi sterownikami (węzłami równorzędnymi) w celu wysyłania lub otrzymywania danych. Jeśli jeden sterownik odmówi posłuszeństwa, reszta systemu może dalej funkcjonować.

Według Marrsa pecetowa rewolucja pomogła rozwinąć sterowanie rozproszone. Przed pecetami większość sprzedawców PLC oraz systemów sterowania rozproszonego (distributed-control system – DCS) wybierało związane z nimi protokoły, by przywiązać użytkowników do swoich produktów. Otwarte architektury pecetów pomogły w promowaniu standaryzacji i przyczyniły się do ułatwienia obsługii obniżki kosztów.

Ograniczeniem utrudniającym rozpowszechnianie się prawdziwego sterowania zdecentralizowanego jest brak jednego standardu sieciowego. Na szczęście sytuacja ulega poprawie. Standardy takie jak OLE oferują świetne narzędzia wspomagające współpracę. Również serwery sieciowe umożliwiają pozyskiwanie danych i informacji z Internetu, bezpośrednio na każdym komputerze wyposażonyn w przeglądarkę. Protokoły XML i Simple Object Access Protocol (SOAP) pozwalają na udostępnianie danych w środowisku rozproszonym.

 

„Do Ethernetu, czy też nie do Ethernetu”

Parafrazując poetę, wielu spyta w pewnym momencie: „Do Ethernetu, czy też nie do Ethernetu”?

Odnośnie do niestandardowych protokołów przemysłowych, wielu producentów zwraca się w kierunku architektur zbudowanych wokół Ethernetu. Szczególnie nowsze wersje standardu pozwalają na większe prędkości komunikacyjne. Lenz z firmy Wago wskazuje, że większość budynków przemysłowych już jest przygotowana do podłączenia sieci Ethernet. Łączenie rozproszonych sterowników przez sieć opartą na Ethernecie eliminuje konieczność specjalnego okablowywania dla magistrali fieldbus. Połączenia mogą rozciągać się na wielką skalę w obrębie jednego budynku lub sięgać do innych budynków, przy zapewnieniu ciągłej komunikacji z głównym sterownikiem. Jeśli przez Ethernet przechodzi zbyt duże obciążenie, powodując przeciążenie, zdecentralizowane sterowniki w dalszym ciągu funkcjonują.

Ponadto Ethernet dodaje kolejny wymiar do równania. Systemy radiowe o dużej mocy mogą przesyłać dane z głównego sterownika do urządzeń lokalnych, tak jak w przypadku miejskiej pompowni wody czy wodociągów. Wdrożenie standardu IEEE NR 802.11 zapewnia szybkie i łatwe łączenie bezprzewodowe, a podręczne interfejsy PDA pozwalają inżynierom podłączać się do systemów bezpośrednio, nawet wprost z hali. Oprogramowanie interfejsu człowiek-maszyna (HMI) można skopiować na PDA, aby uzyskać dostęp do systemu sterowania. Na przykład przy automatycznym sterowaniu budynkami kierownik może sprawdzić status świateł na dowolnym piętrze lub zmienić temperaturę czy inne warunki środowiskowe właśnie za pomocą tych zwyczajnych narzędzi wielkości dłoni.

Ethernet to dzisiaj „gorący” temat, poruszany już we wcześniejszych artykułach, ale nie należy go uznawać za najlepsze czy jedyne rozwiązanie dla sieci przemysłowych. Doug McEldowney, dyrektor firmy Netlinx, będącej oddziałem Rockwell Automation, mówi, że „naginanie” komunikacji ethernetowej do celów produkcyjnych może nie przynieść najlepszych rezultatów.

Architektury sieci przemysłowych, takich jak Device-Net, Interbus i Profibus, w szczególny sposób ukierunkowane są na zastosowania przemysłowe i z tego powodu mogą być lepsze. McEldowney sugeruje również, że wrażenie, jakie odnoszą dyrektorzy, jakoby Ethernet był tańszy od innych rozwiązań, może wynikać z niezrozumienia czego potrzeba, aby system działał. Ethernet wymaga przełączników jako aktywnych komponentów. Chociaż ich ustawienie nie jest trudne, architektura oparta na tych przełącznikach jest nieco inna niż ta, którą większość dyrektorów zna z wdrażania Ethernetu w środowisku biurowym. Z drugiej strony wiele architektur sieciowych, projektowanych specjalnie na potrzeby zakładów produkcyjnych, umożliwia prostszą instalację o znacznie większej elastyczności. Również większość Ethernetu posługuje się topologią drzewa/gwiazdy (tree/star topology) do komunikacji między dwiema stacjami. I znowu, choć sprawdza się to w zastosowaniach biurowych, podejście takie może spowalniać operacje na terenie fabryki. Topologia magistrali pozostałych rozwiązań może być bardziej wydajna.

Dyrektor zauważa, że Ethernet, podobnie jak inne sieci przemysłowe, różni się protokołami. Na tej samej zasadzie sądzi, że udoskonalenia Ethernetu rozszerzą jego zastosowanie i możliwość adaptacji do dodatkowych aplikacji. Na przykład standard IEEE 1588 Time Sync Protocol pozwoli na bardziej precyzyjne zsynchronizowanie Ethernetu z odległymi węzłami. Taka synchronizacja umożliwi dalsze rozproszenie aplikacji, a równocześnie zachowanie ścisłej integracji w sieci pomiędzy jednostką centralną a produkcją.

 

Co dalej?

Wiele osób sądzi, że trend decentralizacji będzie kontynuowany z niesłabnącą siłą, aż do czasu, gdy małe, autonomiczne, inteligentne węzły nie zaczną współpracować bez pośrednictwa sieci. Kolektywnie stanowić będą „system sterowania” z jednostką nadrzędną, monitorującą cały proces. Jeśli tak ma wyglądać przyszłość, to jeszcze nas tam nie ma. Mamy wiele do zrobienia i możemy tworzyć bardziej efektywne procesy na różne sposoby. Rozwój techniki wciąż ku temu skłania.

Invensys Foxboro – www.foxboro.com
Lantronix Inc.www.lantronix.com
Rockwell Automation – www.rockwellautomation.pl
Wago Corpwww.wago.com