Automatyka ekstremalna

Produkcja ropy i gazu
Konieczność pracy w ekstremalnych warunkach stanowi źródło zmian infrastruktury sieciowej i standardów dla morskich systemów automatyki. Zaawansowane komponenty automatyki dennej i powierzchniowej powinny komunikować się ze sobą.
Globalne zapotrzebowanie na energię produkowaną z weglowodorów jest motorem napędzającym produkcję ropy i gazu, szczególnie w nowych przybrzeżnych platformach wydobywczych. Głębokowodna i ultragłębokowodna produkcja ropy i gazu rozpoczęła się we wczesnych latach 90.,osiągając wydobycie dzienne na poziomie 1,5 mln baryłek w 2000 r., a obecnie przekraczając równoważnik 7,2 mln baryłek.
Zwiększenie znaczenia głębokomorskiego wydobycia węglowodorów wpłynęło bezpośrednio na wymagania stawiane systemom automatyki przybrzeżnych platform i statków. Wymagania te najczęściej mają wpływ na sposób wykorzystania różnych systemów automatyki do zwiększenia podwodnej produkcji, a zwłaszcza mają wpływ na sposób komunikacji między systemami.
Wiele platform automatyki
Głębokomorska platforma wydobywcza składa się zwykle z wielu różnych systemów automatyki:
Nadrzędnego systemu DCS, który nadzoruje proces oddzielania i stabilizacji produkcji płynów, przez oddzielanie ropy naftowej od wody i gazu. Woda jest z powrotem wtłaczana, natomiast gaz jest wykorzystywany na potrzeby własne, transportowany na brzeg za pomocą rurociągu, ponownie wtryskiwany lub spalany. W zależności od typu platformy ustabilizowana ropa (z obniżonym ciśnieniem pary) może być magazynowana, a następnie transportowana tankowcem lub przesyłana rurociągiem do innej lokalizacji. Zadaniem systemu DCS jest również udostępnianie interfejsu człowiek-maszyna (HMI), który zapewnia zarządzanie całym statkiem.
Nadrzędnego (lub morskiego) systemu sterowania (MCS), który obsługuje podmorską głowicę do odwiertów, zawory, wtryskiwacze chemiczne i inne podwodne oprzyrządowanie. Zwykle jest podzielony na dwie części: mokre sterowanie, którego komponenty znajdują się pod wodą oraz suche sterowanie, znajdujące się na statku.
Systemów kadłubowych, stanowiących zbiór różnych funkcji związanych z obsługąbalastów, zbiorników itp.
Systemów hotelowych, zarządzających układami potrzebnymi załodze – klimatyzacją, wodą, ściekami, przygotowaniem jedzenia, komunikacją i rozrywką.
Na podstawie obserwacji ewolucji interfejsu komunikacyjnego systemów MCS i DCS można zobaczyć, co zmienia się w systemach automatyki przybrzeżnej i jak na potencjalne wyzwania przygotowana jest załoga.
Rola czynników decydujących o bezpieczeństwie procesów nieustannie rośnie. To wzmaga potrzebę zwiększonej liczby zabezpieczeń i dodatkowego monitorowania podmorskich głowic do odwiertów, zaworów i innych komponentów. Wraz z technologią i metodami wydobywczymi zmieniły się również inne kwestie. Na przykład większe i bardziej złożone pola wymagają znacznie większej liczby podmorskich czujników, sterowników i aktuatorów. Zarówno podmorskie technologie, jak i koszt wydobycia poprawiają się, dlatego często lepiej wykonywać podstawowe operacje, takie jak stabilizowanie, ponowny wtrysk wody i gazu bezpośrednio na dnie, zamiast przesyłać ciecz na powierzchnię w celu przetworzenia, a następnie znów wtłaczać w dno. Zmiany te oznaczają, że potrzebne są bardziej wyszukane strategie sterowania.
Inną zmianę stanowią podmorskie konstrukcje rurowe (ang. tieback) coraz częściej wykorzystywane do przedłużenia życia istniejących platform produkcyjnych. Zamiast stawiać platformę nad nowym zasobem, za pomocą odpowiednich rur łączy się nowe pole z istniejącą, mającą wolne moce przerobowe platformą. Takie rozwiązanie wymaga rozproszenia sieci sterowania na setki kilometrów i kontroli wielofazowych systemów pompujących.
Redukcja kosztów i ryzyka pozostaje bardzo istotną kwestią. Systemy automatyki i ich interfejsy niemal zawsze stanowią krytyczne elementy systemu, dlatego redukcja ryzyka przez standaryzację i zaawansowane techniki programistyczne, takie jak programowanie obiektowe, stanowią klucz. Dodatkowo, ponieważ systemy MCS i DCS pochodzą zwykle od różnych dostawców, bardzo istotny jest jasny podział odpowiedzialności.
Ostatecznie korzystanie z wielu dostawców wymusza powołanie odpowiedniej organizacjiwspierającej open source, której zadaniem będzie zapewnienie kompatybilności i długoterminowej dostępności urządzeń. Królestwo chronionych protokołów komunikacyjnych to już przeszłość. Użytkownicy przemysłowi żądają protokołów mających duże wsparcie wśród przemysłowych dostawców i odpowiednią liczbę gotowych do zakupu urządzeń.
Mając na uwadze te czynniki, łatwo zauważyć, jak potrzeba ustawicznej poprawy bezpieczeństwa i rosnąca złożoność podmorskiego wydobycia węglowodorów pociąga za sobą konieczność pewnej, szybkiej, otwartej i łatwej w utrzymaniu komunikacji między systemami dennymi i powierzchniowymi. Dwa protokoły komunikacyjne spełniają te wymagania.
Do tej pory standardowym protokołem komunikacyjnym między systemami MCS i DSC był Modbus, opracowany w latach 70. XX w. jako standard komunikacji między sterownikami programowalnymi. Jest to pewnego rodzaju narzędzie do mapowania rejestrów, z ograniczoną możliwością swobodnej wymiany danych. Protokół nie ma zdolności zarządzania obiektami, dlatego typami danych i synchronizacją muszą zajmować się programiści MCS i DCS. Protokół bazuje na wymianie danych typu master-slave, przez co raportowanie o sytuacjach nadzwyczajnych jest bardzo ograniczone. Dodatkowym ograniczeniem jest maksymalna liczba urządzeń wynosząca 247. Podstawowy protokół doczekał się wielu odmian, takich jak Modbus TCP/IP, Modbus over TCP/IP, Modbus Plus, Enron Modbus – wszystkie o innej strukturze i wymaganiach.
Te ograniczenia zmusiły przedsiębiorstwa naftowe, dostawców komponentów podmorskich i komponentów automatyki do poszukiwania lepszych metod komunikacji między systemami MCS i DCS. Na horyzoncie widać dwóch kandydatów, którzy mogą zdetronizować Modbus: EtherNet/IP oraz OPC-UA. Przemysłowy protokół ethernetowy (EtherNet/IP) został opracowany przez Rockwell Automation, ale jest w tej chwili zarządzany przez organizację ODVA (Open DeviceNet Vendors Association). OPC-UA (OPC Unified Architecture) jest zarządzany przez OPC Foundation.
EtherNet/IP
EtherNet/IP został opracowany pod koniec lat 90. przez Rockwell Automation i był implementacją protokołu CIP (Common Industrial Protocol) w sieci TCP/IP. W tym sensie jest podobny do DeviceNet i ControlNet, które implementują CIP w pojazdach i dedykowanych sieciach. Wszystkie trzy protokoły są teraz zarządzane przez ODVA.
EtherNet/IP wykorzystuje datagramy UDP do transmisji podstawowych danych I/O i jawne komunikaty TCP z parametrami, wartościami zadanymi itd. Oferuje również wsparcie dla komunikatów krytycznych. Chociaż struktura datagramów zapewnia stosunkowo prostą wymianę danych I/O, inne czynności wymagają bardziej zaawansowanego kodowania.
Plusem jest warstwa bezpieczeństwa CIP, która ma certyfikat SIL3 określony w standardzie IEC 61508.
EtherNet/IP jest szeroko rozpowszechniony w najniższych warstwach hierarchii automatyki, gdzie współpracuje lub stanowi warstwę polową. Był także wykorzystywany w bezpośredniej komunikacji peer-to-peer między warstwą polową a sterowaniem, ale nie został powszechnie zaakceptowany jako interfejs peer-to-peer na poziomie operacyjnym.
OPC-UA
OPC-UA został przedstawiony w 2006 r. jako rozwiązanie ograniczeń poprzednich wersji OPC. Z najważniejszych zmian wymienić można wsparcie dla wielu platform (ANSI C, Java, .Net, a także dla oryginalnego Microsoft Windows), wbudowany model informacyjny z możliwością programowania obiektowego, zdolność do obsługi dwustronnych przerwań umożliwiających przesyłanie komunikatów krytycznych i monitorowanie stanu oraz wsparcie systemów wielkiej skali. Wspierane są dwa poziomy protokołów: szybki protokół binarny odpowiedni dla urządzeń wbudowanych oraz protokół usług sieciowych do ogólnego stosowania. Model informacyjny izoluje protokół od aplikacji użytkownika, a certyfikat współdziałania można uzyskać od OPC Foundation.
Minusem jest fakt, że chociaż OPC-UA wspiera redundancję, w ramach protokołu brakuje wsparcia dla SIL. Wymaga również większych zasobów niż EtherNet/IP.
W ostatnich miesiącach OPC-UA zyskało poparcie największych graczy na rynku automatyki, włączając firmy ABB, Yokogawa, a nawet Rockwell, który ogłosił plan wsparcia i implementacji OPC-UA na poziomie biznesowym i operacyjnym. Invensys i Siemens idą jeszcze dalej, wskazując na plany wykorzystania wbudowanej technologii OPC-UA do rozbudowy protokołów warstwy polowej i sterowania.
Podsumowując, wspierany przez ODVA protokół EtherNet/IP sprawdza się w najniższych warstwach sterowania, ale nie zyskał popularności w warstwach wyższych. Nie posiada solidnych, łatwych w użyciu narzędzi programistycznych, ale istnieje wersja z certyfikatem SIL3.
Z drugiej strony OPC-UA z OPC Foundation został zaakceptowany jako protokół dla wyższych warstw komunikacyjnych przedsiębiorstw, a ostatnio zaproponowano wykorzystanie go jako spoiwo warstwy polowej i zarządzania. Co więcej, w pełni wspiera programowanie obiektowe i ma program uzyskiwania certyfikatów współdziałania.
John M. Gilmore, dyrektor rozwiązań dla przemysłu wydobycia ropy naftowej i gazu w Invensys Operations Management
Opracował Łukasz Urbański, Zachodniopomorski Uniwersytet Technologiczny w Szczecinie
CE