Base Driven Protocol

Inżynierowie z firmy RACOM znaleźli rozwiązanie, które od lat było poszukiwane na rynku. Base Driven Protocol, zaprojektowany dla aplikacji TCP/IP (IEC104) oraz dostosowany do sieci kolizyjnych , gdzie zdalne radio nie może być słyszane przez inne radia zdalne i/lub wykorzystywane są oddzielne częstotliwości dla RX / RX. Wszystkie transmitowane pakiety są zarządzane przez lokalną stację bazową i dystrybuowane równomiernie do wszystkich jednostek zdalnych.

Ten protokół jest rezultatem 20 lat doświadczeń RACOM w opracowywaniu protokołów na kanale radiowym w obrębie sieci wąskopasmowych, aby sprostać wymaganiom rynku. Do zakończenia prac nad protokołem potrzeba było dwóch lat pracy naszych najlepszych światowych programistów we współpracy z Uniwersytetem Technicznym w Pradze.

Cechy

• Zaprojektowany do sieci o topologii gwiazdy z możliwością retransmisji,
• Optymizowany dla TCP/IP, szczególnie dla protokołu IEC104,
• Dostosowany do sieci kolizyjnych , gdzie zdalne radio nie może być słyszane przez inne radia zdalne i/lub wykorzystywane są oddzielne częstotliwości dla RX / RX.
• Ponad 90% pojemności kanału jest dostępne dla danych użytkownika
• Cały ruch w sieci jest zarządzany i optymizowany przez stację bazową.
• Brak kolizji w sieci,
• Dostęp do kanału radiowego jest udzielany przez własny algorytm deterministyczny
• Stabilne czasy odpowiedzi z minimalnym odchyleniem,
• Sprawiedliwy podział pojemności kanału pomiędzy wszystkimi jednostkami zdalnymi.
• Stacja bazowa może obsługiwać do 255 stacji zdalnych, w tym do 128 stacji retransmisyjnych,
• Wysoka niezawodność – potwierdzone pakiety unicast na kanale radiowym.

Wstęp do rewolucji

Tyle słowem wstępu od strony marketingu, a jak to wygląda od strony praktycznej? Zanim do tego przejdziemy, trzeba jasno powiedzieć, że w dobie kiedy wszystko jest produkowane bez końca, czyli każda większa zmiana funkcjonalna urządzenia, skutkuje nową wersją sprzętową z kolejnym numerkiem wersji, firma RACOM postępuje wprost przeciwnie, zapewniając stały rozwój swojego produktu. Do tej pory było jedno urządzenie, które pełniło funkcję stacji bazowej, stacji zdalnej, repetera lub wszystkich trzech jednocześnie. Po aktualizacji oprogramowania do nowej wersji 1.6 otrzymujemy dwa, zupełnie nowe urządzenia. Jedno z nich pracuje w trybie FLEXIBLE czyli w tym co znamy, a nowość polega na tym, że aktualnie można dowolnie mieszać modulacje w kanale radiowym. Drugie to Base Driven czyli sterownik sieci radiowej z możliwością retransmisji z całym inwentarzem nowych możliwości.

Flexible

Tryb ten umożliwia tworzenie sieci o dowolnej topologii i dowolnej ilości urządzeń końcowych. Liczbę pracujących jednostek zdalnych i urządzeń końcowych doń podłączonych definiują takie parametry jak: rozmiar paczki danych, interwał zapytań, żądany czas odpowiedzi/reakcji sieci, szerokość kanału radiowego oraz stosowana modulacja czyli szybkość transmisji danych. W tej sieci typowy repeter (retransmisja) nie występuje, ponieważ każde urządzenie ma możliwość przesyłania danych do serwera SCADA ścieżkami alternatywnymi, które określamy (lub nie) w tablicy routingu. RipEXy w tym trybie wykorzystują autorski protokół anty-kolizyjny, który umożliwia urządzeniom ustalenie dostępu do kanału radiowego w najbardziej efektywny sposób oraz wyboru trasy doręczenia pakietu danych do miejsca przeznaczenia (nie mylić z trasami zapasowymi – Backup routes). Ten tryb pracy ma bardzo wiele zalet ale wymaga drobiazgowego podejścia do projektu, jak i  optymalizacji zapytań systemów SCADA aby nie spowodować zatorów, choć protokół anty-kolizyjny do pewnego stopnia sobie z nimi radzi. W trybie Flexible prócz pull mamy też push czyli możliwość wysyłania danych do serwera po wystąpieniu zdarzenia. Serwer może tylko nasłuchiwać w oczekiwaniu na dane. W tym trybie możliwa jest jednoczesna praca wszystkich interfejsów użytkownika, czyli wszystkie porty ETH i COM mogą jednocześnie wysyłać i odnierać dane w całej sieci! Jest to semi-duplex z podziałem czasu 50/50. Protokół Flexible idealnie nadaje się do zastosowań telemetrycznych, zdalnej kontroli i sterowania oraz systemów SCADA. Nam się udało wykorzystać go również do transmisji VoIP ale o tym innym razem.

Optymizacja zapytań serwerów SCADA, jak życie pokazało, nie idzie w parze w poszanowaniu transmisji wąskopasmowej przez programistów ale też niektóre protokoły komunikacyjne powodują duże zamieszanie w takiej sieci, przez co tworzą się zwyczajne korki, a fachowo kolizje w kanale radiowym. Rozwiązaniem tego problemu, wdług zapewnień producenta jest:

Base Driven Protocol

Dosłownie - Sterownik Bazowy - sieci radiowej. Protokół ten został zaprojektowany od podstaw na potrzeby komunikacji TCP/IP z uwzględnieniem IEC104. Base Driven pozwala na budowę sieci wyłącznie o topologii gwiazdy z możliwością stosowania repeterów, czyli typowej struktury budowanych sieci radiowych. Ilość stacji zdalnych została ograniczona do 255, z możliwością użycia 128 repeterów wewnątrz sieci, ale za repeterem nie możemy stosować kolejnych repeterów. W zamian dostajemy rozwiązanie kilku problemów. Pierwszy, najważniejszy to nowoczesne aplikacje SCADA - czyli problem optymalizacji zapytań, który Base Driven skutecznie rozwiązuje. Drugi, to wzajemna widoczność stacji zdalnych (remote), czyli przerywanie transmisji przez sąsiednie radiomodemy, które pytają o dostępność kanału radiowego. Ten problem nie występuje w protokole Base Driven. Sesje pomiędzy stacją bazową, a zdalną nawiązywane są w trybie bezpośrednim (unicast) z potwierdzeniem doręczenia. W czasie trwania sesji, sąsiednie radiomodemy nie zagłuszają trwającej transmisji. W efekcie zostały wyeliminowane kolizje w kanale radiowym. Radio bazowe steruje komunikacją w całej sieci, przydzielając stacjom zdalnym „czas antenowy” w zależności od zapotrzebowania na transmisję i warunki propagacyjne. Obiekt, który generuje dużą ilość zmiennych, np. 2-3 sterowniki PLC otrzyma więcej czasu niż obiekt, na którym pracuje jeden sterownik, odpowiedzialny np. za sterowanie pompą i kontrolą poziomu zbiornika. W nowym protokole nie znajdziemy mechanizmów używanych w trybie Flexible. Nie ma tu protokołu anty-kolizyjnego i innych mechanizmów z nim powiązanych. Dzięki uproszczonej strukturze sieci, protokoły sterujące zajmują mniej niż 10% pasma, a to oznacza, że dla użytkownika dostępne jest ponad 90% zasobów! W trybie Base Driven dostępem do kanału radiowego zarządza własny algorytm deterministyczny, który pozwala również na jednoczesną pracę wszystkich portów komunikacyjnych w całej sieci. Mamy więc do czynienia z bardzo wyrafinowanym rozwiązaniem.

Base Driven w praktyce

Nowy protokół komunikacyjny opracowany przez firmę RACOM, został wdrożony w sieci radiowej, należącej do poznańskiej spółki Aquanet S.A. Po modernizacji jednej ze stacji SUW oraz włączeniu jej do sieci IT powstał problem, którego nikt wcześniej nie był w stanie przewidzieć, a mianowicie ilość i częstotliwość przesyłanych danych pomiędzy sterownikami PLC, a serwerem SCADA. Postanowiliśmy więc sprawdzić, czy nowe oprogramowanie urządzeń RipEX będzie tak skuteczne, jak zapewnia producent.

AKPiA

W ramach modernizacji SUW Kamińsko, zainstalowane zostały dwa sterowniki PLC firmy Schneider Electric, odpowiedzialne za automatyzację wszystkich procesów. Pierwszy sterownik odpowiada jest za prace zestawu sieciowego, a drugi za pracą pomp głębinowych włącznie z kontrolą poziomu zbiorników.

Poprzez tor radiowy przesyłane są wszystkie stany 123 wejść, stany wszystkich 53 wyjść, 217 flag oraz 381 rejestrów. Stan wejść pozwala na odczytanie aktualnego stanu pracy urządzeń. Flagi pozwalają na zarządzanie pracą technologiczną i załączaniem/wyłączaniem odpowiednich urządzeń. W rejestrach są przetrzymywane pomiary oraz wartości umożliwiające utrzymywanie odpowiednich ciśnień, poziomów wody, itp. oraz dane archiwalne.

SCADA

Komunikacja pomiędzy wizualizacją przemysłową, a sterownikami PLC odbywa się dwukierunkowo, tzn. na wizualizacji SCADA jest możliwość odczytywania wartości jak i zadawania nowych oraz możliwość zdalnego sterowania wybranymi pompami. Ze sterownikami komunikują się dwa niezależne stanowiska komputerowe z wizualizacją SCADA, w interwałach czasu co 5000ms (podstawowe) i 8000ms (zapasowe).

Implementacja Base Driven

Po aktualizacji oprogramowania do nowej wersji pojawiają się nowe opcje w panelu zarządzania, co widać na poniższym  rysunku. W tym miejscu możemy zdefiniować zakres dostępnych adresów (Protocol adress) oraz dostępnych modulacji (prędkości transmisji danych). Na tym przykładzie, w celu przeprowadzenia testu zostały zdefiniowane wszystkie dostępne modulacje cyfrowe, aby sprawdzić jak bardzo moje decyzje zostaną podważone przez zaawansowany algorytm. Oczywiście do projektanta sieci należy ostatnie słowo.

Poniżej panel konfiguracji stacji zdalnej (remote). Tutaj należy tylko wybrać protokół i tryb pracy, w tym przypadku Base Driven => Remote oraz rodzaj modulacji => QAM. Resztę zostawiamy automatyce.

Autospeed - czyli rozbieżności projektant via algorytm

Na tym linku można swobodnie operować modulacją 16DEQAM bez FEC. Zdecydowałem jednak użyć modulacji D8PSK bez FEC. Pomimo odległości 9km, łącze cechuje się bardzo stabilnym sygnałem (ponad 20dBm zapasu), o bardzo dobrej jakości (DQ >230). Algorytm "wykalkulował" jdnak 16DEQAM z FEC3/4. Można więc powiedzieć, że poszedł tutaj na kompromis.

12:22:55.202387 [RF:phy:Tx] IP 192.168.213.3 > 192.168.213.8: ICMP echo request, length 62
    RLhead:  4860 08a6 9da2 3160 44 ((MC:B1) 10.10.10.1 > 10.10.10.8 DATA: T:8 LN:49 Rp:- nA:y A:68)
    DChead:  00 (|F:-|C:-|E:-|)

MC:B1 - oznacza 16DQAM z FEC3/4, natomiast parametr T pokazuje numer kanału.

Kolejny link, choć tylko (aż) 7km, za to w bardzo trudnych warunkach (miasto, puszcza, dwa wzgórza po drodze, obie strony w zagłębieniu terenu). Tutaj na podstawie testów i długiej obserwacji zdecydowałem użyć modulacji π/4-DQPSK z FEC3/4, która oferuje przepustowość 15.62kbps przy granicznej czułości odbiornika -109dBm. Wybór ten stanowił swego rodzaju kompromis, który ostatecznie się sprawdził. Średni poziom syganłu oscyluje w okolicy -100dBm, a w czasie testu było -96dBm. Łącze radiowe ma więc połowę wymaganego zapasu, lecz w groszych warunkach już pracować nie będzie. Za to cechuje się wysoką jakością połączenia, paremetr DQ >200. Algorytm jednak podważył moją decyzję i zastosował modulację DPSK, więc mniej złożoną i bez FEC. Modulacja DPSK pozwala na transfer danych z prędkością 10.42kbps. Algorytm najwyraźniej obliczył, że dodatkowe dane do odbudowy ewentualnie uszkodzonych ramek, czyli FEC, są zbędne, za to mniej złożona modulacja będzie zachowywać się jeszcze stabilniej.

12:22:39.583019 [RF:phy:Tx] IP 192.168.12.158 > 192.168.213.34: ICMP destination unreachable, length 85
    RLhead:  4860 20a6 9da2 ce60 43 ((MC:80) 10.10.10.1 > 10.10.10.32 DATA: T:32 LN:206 Rp:- nA:y A:67)
    DChead:  10 (|F:-|C:l|E:-|)

MC:80 - oznacza DPSK, a wartość T wskazuje na kanał 32.

Z powyższego wynika, że nowy algorytm deterministyczny, odpowiedzialny za dostęp do kanału radiowego, potrafi ocenić jakość połączenia radiowego i dopasować najbardziej efektywną modulację czyli szybkość transmisji danych, indywidualnie dla każdej stacji zdalnej.

Informację o stosowanej modulacji możemy odczytać, w menu Monitoring /zakładka Diagnostic

TX Modulation and Coding

[7..4] Modulation Select Nibble

0x0 = 2-CPFSK (default)
0x1 = 4-CPFSK
0x8 = DPSK
0x9 = pi/4-DQPSK
0xA = 8DPSK
0xB = 16-DEQAM

[3..0] Coding Select Nibble
0x0 = coding Off (default)
0x1 = FEC ¾

Aktualnie STATUS radiomodemu pokazuje ostatnią modulację, jaka była używana w trybie Flexible. Zostanie to poprawione w kolejnej wersji oprogramowania. Aby ustalić typ emisji, czyli użytej modulacji, można połączyć się zdalnie z radiem i podejrzeć wartość pola Protocol Address. Na poniższym rysunku widnieje wartość 32, co w naszym przykładzie oznacza modulację DPSK bez FEC, ponieważ radio bazowe przydziela tą modulację w zakresie adresów 31-35 (wyżej > Konfiguracja sieci).

Protocol address to indywidualny numer radiomodemu, który pracuje pod kontrolą prtotokołu Base Driven.

Dostępność i efektywność kanału radiowego

Teraz przyjrzymy się Base Driven od strony efektywności transmisji i dostępu do kanału radiowego. Główny problemem w tej częsci sieci, to "przeładowanie" portu Ethernet w radiomodemie. Radio nie jest w stanie „upchnąć” otrzymanych danych danych w kanale radiowym.

Rozważane były tutaj dwie możliwości, w celu rozwiązania problemu: optymalizacja zapytań serwera SCADA lub poszerzenie odstępu międzykanałowego o kolejne 12,5kHz czyli do 25kHz, co się wiąże z dodatkową procedurą i kosztami. W tym miejscu 25kHz rozwiązało by problem na tyle sprawnie, że zostałoby jeszcze "pasma" na zdalną aktualizację oprogramowania samych sterowników PLC, co potwierdziły testy. Wybrana została trzecia opcja, czyli: dopasowanie konfiguracji radiomodemów do specyfiki tranmisji danych/pracy urządzeń. Pomimo uzyskania stabilnej łączności, nadal istniało pewne zagrożenie, o czym nieco dalej.

Poniżej staystyka pakietów TX/RX. Radiomodemy pracują tutaj jeszcze na oprogramowaniu 1.5.7.0.

Duplikatów praktycznie nie było. W trybie Flexible (Router) przy tym obciążeniu i kanale o przepustowości około 15kbps mamy sporo powtórzeń (Repeats). Błąd danych (Data terror) też praktycznie nie występuje, ponieważ link radiowy jest stabilny.

Podsumowując te trzy dni otrzymujemy:

TX/RX: 154 832 103 bajtów czyli ~148MB /3 = 49,3MB na dobę bez pakietów kontrolnych w kanale radiowym.

Po zmianie oprogramowania sytuacja wygląda nieco inaczej.

TX/RX: 120380777 co daje łącznie ~ 115MB /3 = 38,3MB na dobę bez pakietów kontrolnych.

Rejected - usuniete ramki z bufora TX po upływie czasu / zbyt duża ilość przychodzących danych względem pojemości kanału radiowego
Lost - utraty przesyłanej ramki (% = 100 x zaginione ramki / wszystkie przesłane ramki)
Data error - kolizje, błędne nagłówki/ramki, odrzucone pakiety z sieci ETH, słaby sygnał
Repeats - próby powtórnej transmisji ramki

Podsumowanie

Tabela przedstawia dane uśrednione z radia bazowego w ujęciu dobowym bez pakietów kontrolnych.

Wartość Data error/Lost oraz Rejected w przypadku tego łącza nie ma znaczenia. Skuteczność Base Driven obrazuje ilość powtórek transmisji (repeates). Z jednej strony radio próbuje dostarczyć dane, a z drugiej otrzymuje ciągle żądanie nowych. To jest jedna z przyczyn, która obniża efektywność kanału radiowego, czyli kolizje wywołane zbyt dużym ruchem. Ilosć przesłanych danych do radia bazowego przez radio zdalne zmniejszyła się tutaj o 22%, co być może związane jest ze zmianą modulacji i wyłączeniem FEC. Forward Error Corection do spółki z protokołem anty-kolizyjnym zabiera część pasma na "własny użytek", a być może ze zmianą sposobu komunikacji radia bazowego, ze stacją zdalną. Aby to dokładnie ustalić potrzebny jest szerszy zakres danych wejściowych, na co zwrócę szczególną uwagę przy kolejnym wdrożeniu BDP.

Oba te łącza radiowe z punktu wiedzenia SCADY działają perfekcyjnie! Skąd więc pomysł na "25kHz" oraz opis przypadku wdrożenia nowego protokołu komunikacyjnego w sieci RipEX? Rzecz w tym, że w tej jednej lokalizacji możliwości protokołu Flexible zostały wykorzystane w pełni. Wystarczy wysłać z jakiegokolwiek komputera pracującego w sieci dodatkowe pakiety, np. ICMP do zdalnego radia lub sterownika za nim aby wywołać awarię łącza, co będzie natychmiast zasygnalizowane przez system SCADA jako błąd komunikacji. Taką sytuację może spowodować w dowolnej chwli np. informatyk, który będzie sprawdzał funkcjonowanie urządzeń pracujących w sieci, kiedy trafi na "coś za radiem". W tym przypadku mamy do czynienia z siecią hybrydową, na którą składają się światłowody, radiolinie mikrofalowe i wąskopasmowe łącza radiowe w paśmie 450Mhz, co razem tworzy rozległą sieć  WAN. Przy tak rozbudowanej infrastrukturze nie każdy ma świadomość jaką drogę do celu pokonują pakiety IP.

Po migracji do Base Driven problem został wyeliminowany. Łącze radiowe nie ulega przeciążeniu. Dodatkowe zapytania wysyłane do urządzeń pracujących w zdalnej sieci nie powodują "zrywania transmisji". Dzięki temu, można podłączyć jeszcze jeden sterownik na obiekcie lub swobodnie prowadzić zdalne prace serwisowe bez wpływu na stabilność połączenia.

Aby to zweryfikować, otworzyłem 3 dodatkowe sesje ICMP do trzech różnych urządzeń w testowanej stacji. Połączenie nadal pracuje stabilnie, a to już 6ta sesja obsługiowana jednocześnie przez radio! Dodałem więc kolejną - panel zarządzania WWW jednego z urządzeń. Zaowocowało to sporadycznymi time out ale odchylenia były w normie. Po godzinie stałego "przeciążenia łącza", zapytałem informatyków o ewentualne problemy. SCADA w tym czasie nie zgłosiła błędów w komunikacji, co potwierdziła centrala słowami "...łącze pracuje stabilnie i wszytko działa jak należy, jest sygnalizacja zdarzeń, itd". Duży sukces, wielkie zaskoczenie! Wcześniej jakakolwiek moja ingerencja w ten kanał radiowy czyli praca zdalna na radiu, skutkowała telefonem telefonem treści ...mamy problem z łącznością, czy Pan coś robi?

Podsumujmy: 6 sesji z trzech różnych serwerów, w tym NTP co 4sek (4ty serwer) i praca z panelem administracyjnym WWW (duże obciążenie), czyli w porywach 8 sesji TCP/IP. Po godzinie otrzymujemy: 9% strat na 12549 zapytań ICMP, średni czas odpowiedzi 1618ms! Szybkość transmisji w tym kanale radiowym 10.42kbps.

Wdrożenie BDP zakończono pozytywnie dnia 17 listopada 2016r.

Konkluzja

Z mojej strony, jako opiekuna sieci radiowej w Aquanet SA, problem został rozwiązany. Bez ponoszenia dodatkowych kosztów, spółka dysponujue stabilnym łączem radiowym o 100% dostępności z możliwością dalszej rozbudowy.

RACOM tym samym po raz kolejny umocnił swoją pozycję lidera na rynku. Aby zaprojektować i wdrożyć takie rozwiązania potrzeba oprócz ogromnych środków, zaangażowania i wieloletniego doświadczenia. Take projekty są w stanie zrealizować zespoły, które specjalizują się wyłącznie w jednej dziedzinie - w tym przypadku jest to transmisja danych w wąskopasmowych sieciach radiowych.

Sieć RipEX o której tu mówimy, ma prawie dwa lata, a była już modyfikowana 2 razy. Pierwsza zmiana to wprowadzenie multispeed, czyli dopasowanie prędkości transmisji do warunków propagacyjnych aby zwiększyć jej wydajność. Druga zmiana, to migracja do Base Driven Protocol - czyli dopasowanie radiowej transmisji danych do nowoczesnych systemów SCADA.

Opracowanie:
Krzysztof Karcz - Opiekun Sieci Radiowej RipEX w Aquanet S.A.

Pomoc i współpraca:
Mateusz Mikorczyk - Programista PLC oraz SCADA w firmie ELCON.

Jest to pierwsza w Poslce implementacja Base Driven w sieciach radiowych, zbudowanych przy użyciu radiomodemów RipEX. Publikacja będzie stale aktualizowana, wraz z włączaniem do ruchu kolejnych obiektów.