Wzrost interoperacyjności w systemach sterowania

Kompleksowe testy urządzeń sieciowych już nie wystarczają. Wiele problemów związanych z kompatybilnością i interoperacyjnością w sieciowych systemach sterowania pojawia się bowiem w momencie, gdy urządzenia obiektowe komunikująsię z systemami nadrzędnymi. Można temu zaradzić – dlatego warto zwrócić uwagę na ten element komunikacji i integracji.
Dla Fieldbus Foundation, jako firmy odpowiedzialnej za opracowanie i zarządzanie protokołami komunikacji sieciowej do zastosowań przemysłowych, wykorzystywanymi przez wielu producentów i użytkowników końcowych, interoperacyjność i kompatybilność są priorytetem. Interoperacyjność to zdolność urządzeń pochodzących od różnych producentów do funkcjonalnego współdziałania i swobodnej wymiany informacji w ramach systemu sieciowego, przy zachowaniu pełnej swobody w zakresie jego rekonfiguracji i rozbudowy funkcjonalnej. Np. czujnik ciśnienia z firmy A powinien działać w tym samym segmencie sieci obiektowej co inny czujnik z firmy D, przy zachowaniu pełnej funkcjonalności i możliwości integracji z innymi modułami sieciowymi.
Aby to osiągnąć, Fieldbus Foundation, podobnie jak inne organizacje zaangażowane w rozwój standardów komunikacji sieciowej, zajmuje się dokładną specyfikacją procedur komunikacji i wymiany danych. Musi być ona na tyle dokładna i przejrzysta, aby zapewnić pełną współpracę urządzeń różnych producentów, bez eliminacji czy ograniczania ich elastyczności dla użytkowników i integratorów, którzy korzystają z danego standardu komunikacji nawet w specjalizowanych aplikacjach. Taka specyfikacja wymaga zaangażowania wszystkich stron – opracowujących i użytkujących standard.
Na podstawie obserwacji i doświadczeń z działania wdrożonych już systemów sieciowych wynika jednoznacznie, że jednym z największych problemów dotyczących interoperacyjności jest prawidłowa komunikacja nie na poziomie obiektowym – między urządzeniami, węzłami sieci, ale pomiędzy poziomem obiektowym a systemem nadrzędnym wyższego poziomu. Firmy produkujące systemy sterowania, pulpity operatorskie, interfejsy HMI i inne, nie zawsze posługują się jednolitymi standardami, metodami ich komunikowania z modułami obiektowymi. Ten fakt przywołuje wielu członków Fieldbus Foundation, prosząc jednocześnie o znalezienie metod rozwiązania tego typu kwestii – rozszerzenia specyfikacji standardu sieciowego również na te obszary. Testy protokołów i algorytmów prowadzone są już od kilku lat i wciąż trwają.
Dlaczego testy?
Fieldbus Foundation jest jedną z organizacji branży automatyki przemysłowej z ustalonym programem rejestracji, zawierającym opis funkcjonalności i dedykowanych dla nich testów podstawowych elementów standardu sieciowego, krytycznych z punktu widzenia kompatybilności i interoperacyjności. Obowiązkowymi testami objęte są obszary dedykowanych systemów nadrzędnych, urządzeń obiektowych (węzłów) oraz modułów systemowych warstwy fizycznej sieci, takich jak: zasilacze, moduły łączeniowe, okablowanie. Dlatego też użytkownik, biorąc do ręki moduł ze znakiem Foundation Product Registration, może być pewny o jego pełnej interoperacyjności z innymi tak oznaczonymi modułami, ponieważ wszystkie one wcześniej podlegały serii zunifikowanych testów kompatybilności. Bez względu na producenta użytkownik końcowy, wybierając urządzenie sieciowe, ma pewność, że zagwarantuje mu ono odpowiedni poziom funkcjonalności, integracji, również w odniesieniu do współpracy z systemami nadrzędnymi.
W Fieldbus Foundation wypracowano trzy ścieżki testowe dla rejestracji produktów sieciowych: H1 – dla modułów dla sieci H1, HSE – dla sieci HSE (szybki Ethernet) oraz Host Profile – dla systemów nadrzędnych. Ta ostatnia ma szczególne znaczenie dla użytkowników końcowych. Aby zrozumieć dlaczego, najpierw trzeba wiedzieć, czym są systemy nadrzędne w aplikacjach sterowania w przemyśle.
Czym jest system nadrzędny – host?
System nadrzędny to wszystkie elementy wspierające obsługę telegramów Fieldbus Foundation wyżej niż na poziomie obiektowym. Są to np. narzędzia konfiguracyjne, moduły rejestracji zdarzeń, danych, panele alarmowe, interfejsy HMI i inne systemy sterowania/zarządzania. Może na nie składać się jedno lub wiele urządzeń. W systemie nadrzędnym nie jest konieczne istnienie bloków funkcjonalnych, może być on natomiast wyposażony w interfejsy H1, HSE. Może również obsługiwać urządzenia bezpieczeństwa, sterowania i monitoringu. System nadrzędny z interfejsem H1 powinien mieć zaaplikowany zarejestrowany stos protokołu komunikacyjnego Foundation oraz fizyczną warstwę interfejsu. Interfejs HSE wymaga jedynie zarejestrowanego stosu protokołu. Rolę systemu/modułu nadrzędnego mogą pełnić również urządzenia obiektowe, jeżeli mają zaaplikowane funkcjonalności i cechy hosta.
Systemy nadrzędne zawsze stanowiły istotnyelement hierarchii systemowej w sieciowych systemach sterowania, często decydujący o sprawnym ich funkcjonowaniu. Jeżeli zaimplementowany w zakładzie system nadrzędny nie jest certyfikowany i zarejestrowany, może nie spełniać swej roli, uniemożliwiając integrację funkcjonalną z urządzeniami obiektowymi H1 lub HSE.
Opracowanie procedur testowych
Organizacja Fieldbus Foundation prowadzi testy systemów nadrzędnych w zasadzie od początku prac związanych z rozwojem swoich protokołów komunikacyjnych. Procedury te ewoluowały. Poprzednio test interoperacyjności Host Interoperability Support Test (HIST) weryfikował zapisy protokołu bez zapewnienia formalnej rejestracji testowanego produktu. Cała procedura testowa HIST była realizowana przez dostawcę systemu nadrzędnego. Testy okazały się bardzo pomocne i szybko stało się jasne, że kompleksowe testowanie protokołu dla systemów nadrzędnych jest niezbędne. W związku z tym uruchomiono proces przygotowania procedur testowych z gwarancją certyfikacji testowanego produktu – Host Profile Registration Process. W jego ramach Fieldbus Foundation przeprowadza odpowiednie testy funkcjonalne ze specjalizowanymi testami opisu urządzeń i ich plików funkcjonalnych. Profil systemu nadrzędnego musi wspierać wszystkie wymagane cechy protokołu. Jednak nie wszystkie cechy mogą być odpowiednie dla danego systemu nadrzędnego i dlatego niektóre z nich mogą nie być wspierane przez wybrane systemy. Z każdą cechą, funkcją związane są zestawy procedur testowych, uruchamiane po stronie systemu nadrzędnego lub po stronie urządzeń obiektowych integrowanych z systemem nadrzędnym. Cechy te mają charakter ogólny, dlatego też producenci wybierają odpowiednie procedury testowe, ścieżki, niezbędne do weryfikacji określonych funkcji i cech. Systemy nadrzędne, które je spełnią, są automatycznie autoryzowane i certyfikowane znakiem Fieldbus Foundation.
Klasy systemów nadrzędnych
Profil Fieldbus dla systemów nadrzędnych określa minimalny zestaw funkcji zaimplementowanych w systemie nadrzędnym, aby spełnił on wymogi kompatybilności i interoperacyjności ze standardem Foundation Fieldbus w klasie systemów host. System może obejmować jeden lub więcej elementów programowych i sprzętowych, zgodnie ze specyfikacją producenta. Jest pięć klas profili dla systemów nadrzędnych:
Klasa 61 – system nadrzędny zintegrowany; podstawowy, dla systemów bezpośrednio obsługujących procesy, zarządzających komunikacją i konfiguracją aplikacji urządzeń w sieci;
Klasa 62 – system nadrzędny typu Visitor; okresowy, dla systemów bezpośrednio obsługujących procesy, jednak z ograniczonym dostępem do parametrów urządzeń;
Klasa 63 – system nadrzędny typu Bench; podstawowy, dla systemów nieobsługujących bezpośrednio procesów, dedykowany dla procedur konfiguracji i doborunastaw bez komisjonowania urządzeń;
Klasa 64 – podstawowy, dla systemów nieobsługujących bezpośrednio procesów, z ograniczonym dostępem do parametrów skomisjonowanych urządzeń w trybie off-line;
Klasa 71 – system nadrzędny z zaimplementowanymi funkcjami bezpieczeństwa (SIF); podstawowy, dla systemów bezpośrednio obsługujących procesy, z obsługą funkcji bezpieczeństwa.
Każda z klas ma własną charakterystykę, dedykowaną grupę odbiorców i obszarów implementacji. Zintegrowany system nadrzędny jest bardzo istotnym elementem sterowania procesem, z charakterystykami zwykle zarezerwowanymi dla urządzeń obiektowych:

  • ustawianie i zarządzanie warstwą fizyczną sieci dla wszystkich urządzeń wraz z konfiguracją,
  • zarządzanie konfiguracją aplikacji rozproszonych wraz z harmonogramami, automatycznymi kopiami zapasowymi, organizacją bloków, łączeniem obiektów, cykli makr i alarmów,
  • zapewnienie dostępu do wszystkich bloków w zasobach systemu sieciowego, bloków przetwarzania i bloków funkcjonalnych,
  • zarządzanie bazą danych/kopii zapasowych.

Z zaimplementowanego w zakładzie przemysłowym zintegrowanego systemu nadrzędnego korzysta wiele osób. Inżynierowie sterowania procesowego używają go do konfiguracji i analiz, operatorzy korzystają z obsługiwanych przez niego paneli HMI, a kadra zarządzająca – do zarządzania zasobami przedsiębiorstwa w poszczególnych aplikacjach (za pośrednictwem różnych jego elementów).
Systemy klasy 62 mogą mieć dostęp na zasadzie zapisu/odczytu do zasobów systemowych oraz bloków przetwarzania. Dla bloków funkcjonalnych w systemie możliwy jest zwykle jedynie odczyt ich nastaw, danych. Systemy tej klasy nie umożliwiają zarządzania warstwą fizyczną, konfigurowania sieci oraz aplikacji rozproszonych. Zazwyczaj służą jedynie do bezpośredniej obsługi urządzeń, z okresowym dostępem do sieci lub mają formę aplikacji rezydujących na określonych, specjalizowanych urządzeniach obiektowych – np. jako narzędzia diagnostyki zaworów.
Systemy klasy 63 pozwalają na konfigurowanie sieci i podobnie jak systemy klasy 64 pozwalają na pracę bez bezpośredniego dostępu do sieci i obsługiwanych procesów. Dzięki nim możliwe jest też konfigurowanie aplikacji rozproszonych, harmonogramów, kopii zapasowych, alarmów. Z systemów tej kasy korzystają głównie osoby z kadr zarządzania oraz obsługi oprzyrządowania. Systemy klasy 63 wykorzystuje się głównie do wprowadzania wstępnych nastaw parametrów dla nowych urządzeń, serwisowania urządzeń już będących w systemie sieciowym oraz przy wymianie urządzeń na nowe. Mogą one okazać się również pomocne przy kasowaniu nastaw urządzenia wyłączonego z sieci, w celu ponownego jego zaprogramowania i użycia w innej aplikacji.
Systemy klasy 64 oferują dostęp do wcześniej skomisjonowanych urządzeń sieciowych. W zasadzie ich specyfikacja jest identyczna jak systemów klasy 62, z jednym wyjątkiem: konfiguracji adresów urządzeń. Korzysta z nich personel zarządzania i nadzoru oprzyrządowania.
Klasa 71 obejmuje systemy nadrzędne dedykowane do obsługi funkcji bezpieczeństwa. Podobnie jak dla klasycznych systemów zintegrowanych (klasa 61), bazuje się w nich na adresowaniu dla standardów H1, z bezpośrednim dostępem do sieci i obsługiwanych procesów. Możliwe jest za ich pośrednictwem zarządzanie warstwą fizyczną wszystkich urządzeń sieciowych, wraz z ustawieniem i zarządzaniem konfiguracją sieci i aplikacji rozproszonych oraz realizacja wszystkich innych funkcjonalności charakterystycznych dla klasy 61. Różnicą jest wprowadzenie obsługi funkcji bezpieczeństwa, z pełnym dostępem do wszystkich bloków i profili bezpieczeństwa. Klasa 71 to pełne wsparcie protokołów dla funkcji bezpieczeństwa SIF Foundation Fieldbus, zarządzanie ich konfiguracją oraz możliwość załączania/wyłączania urządzeń bezpieczeństwa.
Obowiązkowe, opcjonalne, zabronione
Struktury testów dla systemów nadrzędnych składają się z różnych procedur dla różnego typu funkcjonalności systemów, zależnie od ich klasy. Niektóre z nich zaliczają się do grupy obowiązkowych, inne do opcjonalnych, a niektóre do zabronionych. Dla każdej z klas procedury są odpowiednio przyporządkowane, zależnie od wymogów. Aby system mógł uzyskać certyfikat zakwalifikowania do danej klasy, musi przejść procedury zapisane dla niej jako obowiązkowe. Procedury opcjonalne mogą być spełnione, ale nie są konieczne dla uzyskania certyfikatu zgodności i interoperacyjności. Jeżeli jednak związane z nimi funkcjonalności są zaaplikowane w systemie i testy dają pozytywny wynik, stanowią one wartość dodaną danego systemu w swojej klasie. Procedury i funkcjonalności zabronione wyznacza się w celu ograniczenia możliwości przeprowadzenia w systemie niezamierzonych, niedopuszczalnych dla danej klasy czynności, funkcji. Jeżeli w trakcie testów okaże się, że badany system wykazuje znamiona choćby jednej z zabronionych procedur dla danej klasy, nie może być do niej zakwalifikowany.
Implementacja etapowa
Przy analizie procedur testowych dla systemów nadrzędnych kolejnych klas pojawiają się oznaczenia literowe „a” i „b” (np. certyfikat zgodności z profilem 61a lub 61b). Litery oznaczają różne wersje profili: „a” to profil pierwotny, powstały w pierwszym etapie opracowywania procedur testowych, dla najbardziej podstawowych funkcjonalności charakterystycznych dla danej klasy; „b” to efekt dalszych prac nad rozwojem klasy, jej obowiązkowych funkcjonalności i pozwiązanych procedur testowych. W organizacji Foundation Fieldbus od 2010 r. wszystkie testowane systemy nadrzędne muszą przejść procedury testowe wersji „b”. Systemy, które wcześniej uzyskały certyfikację i klasyfikację do określonej klasy według procedur wersji „a”, zachowują ją, jednak dla nowych systemów testy nie są już prowadzone według tej wersji.
Rezultaty
Od wprowadzenia w 2007 r. profili certyfikacyjnych dla systemów nadrzędnych, Fieldbus Foundation udzieliła 12 tego typu certyfikacji/rejestracji. Większość z tych systemów i urządzeń testowana była w oparciu o starsze wersje profili. Większość z nich została później dodana do nowych specyfikacji protokołu sieciowego. Pozytywne reakcje użytkowników były następstwem znacznie lepszego dopasowania, prostszej i szybszej integracji, niemal na zasadzie plug-and-play.
Perspektywa rozwoju profili w przyszłości wydaje się nieunikniona. Stąd konieczność poszerzenia spektrum wszystkich grup funkcjonalności, w szczególności zaś obowiązkowych dla danych klas systemów nadrzędnych.
Opracował dr inż. Andrzej Ożadowicz, AGH Kraków
CE