Jednym z popularniejszych protokołów sieciowych jest Profibus (Process Field Bus), który został opracowany w Niemczech w 1989 roku. Na rynek wprowadziła go firma Siemens, zaś protokół został zestandaryzowany i opisany w normie DIN 19245 w 1991 roku. Podobnie jak i inne przemysłowe protokoły komunikacyjne, Profibus jest zgodny z dwoma normami: IEC 61158 oraz IEC 61784. W pierwszej z nich zebrano wytyczne w zakresie cyfrowej komunikacji danych w sieciach polowych, pomiarowych i sterujących w przemysłowych systemach sterujących, natomiast w drugiej opisano profile dla protokołów komunikacyjnych opartych na normie IEC 61158.
PROFIBUS DP
W standardzie Profibus wyróżnionych zostało kilka profili, w tym: Profibus DP (Decentralized Peripheral) i Profibus PA (Process Automation). Pierwszy znajduje zastosowanie w komunikacji między sterownikami PLC i urządzeniami peryferyjnymi, natomiast drugi zaprojektowano z myślą o sieciach w strefach zagrożonych wybuchem.
Wyróżnia się trzy wersje protokołu Profibus DP: DP-V0, służącą do cyklicznej wymiany danych procesowych oraz diagnostyki sieci, DP-V1 - do komunikacji acyklicznej z rozszerzeniami do na przykład przesyłania alarmów oraz DP-V2, m.in. do izochronicznej wymiany danych procesowych. W warstwie fizycznej wykorzystywany jest interfejs RS-485 lub światłowód. Osiągalne są prędkości transmisji: 9,6; 19,2; 45,45; 93,75; 187,5 kbit/s oraz 0,5; 1,5; 3; 6 i 12 Mb/s. Prędkość transmisji jest jednakowa dla wszystkich urządzeń w sieci i narzuca ją stacja aktywna (master). Maksymalna liczba urządzeń w segmencie sieci, z interfejsem RS485, wynosi 32.
W sieciach Profibus DP wykorzystywana jest technika przekazywania prawa dostępu do sieci między stacjami nadrzędnymi typu master. W ten sposób powstaje logiczna topologia pierścienia. Stacje podrzędne slave nie mają możliwości aktywnego dostępu do medium, tzn. nie mogą wysyłać zapytań, a jedynie odpowiadać na żądania stacji master.
ETHERNET/IP
Protokół EtherNet/IP (Ethernet Industrial Protocol, EIP) został opracowany w 2000 roku przez firmę Rockwell Automation, obecnie zaś jego rozwojem zajmuje się m.in. organizacja ODVA (Open DeviceNet Vendors Association). Opiera się on na protokole CIP (Common Industrial Protocol), który definiuje profile różnych urządzeń przemysłowych. Charakteryzują one ich właściwości i metody komunikowania się.
W EtherNet/IP wyróżniono dwa rodzaje wiadomości. Do pierwszej kategorii zaliczane są dane o znaczeniu niekrytycznym, na przykład diagnostyczne lub konfiguracyjne (Explicit Messages). Do ich transmisji wykorzystywany jest protokół TCP. Dane, które muszą być transmitowane w czasie rzeczywistym (Implicit Messages), są natomiast przesyłane za pośrednictwem protokołu UDP.
Priorytetyzacja Quality of Service gwarantuje, że pakiety drugiego typu będą miały wyższy priorytet. Ethernet/IP korzysta również z protokołu CIPsync, który zapewnia synchronizację zegarów czasu rzeczywistego w rozproszonych systemach. Taka możliwość jest wymagana w systemach, które koordynują działanie kilku podsystemów. Przykładem są wieloosiowe systemy sterowania ruchem.
CIPSync bazuje na protokole PTP (Precision Time Protocol) opisanym w normie IEEE 1588. PTP jest protokołem typu master-slave. Tym pierwszym jest najdokładniejszy zegar w sieci, z którym synchronizowane są pozostałe zegary typu slave. Proces synchronizacji jest podzielony na dwa etapy. W pierwszym - korekcji offsetu - wyrównuje się różnicę pomiędzy czasem zegara master i pozostałymi. W tym celu master wysyła do wszystkich zegarów slave wiadomość synchronizującą, która zawiera swój przewidywany czas wysłania. Równocześnie czas ten jest mierzony, zaś wynik pomiaru jest przesyłany w kolejnej wiadomości.
W węzłach slave czas odbioru obu tych wiadomości jest precyzyjnie mierzony. Różnica między tą wartością a danymi z wiadomości od mastera służy do korekcji czasu w poszczególnych zegarach slave. Jeżeli nie występują opóźnienia na linii transmisyjnej, zegary mastera oraz pozostałe są zsynchronizowane. To ewentualne opóźnienie jest wyznaczane w drugiej fazie synchronizacji poprzez pomiar czasu propagacji pakietu. Wartość ta jest w zegarach podrzędnych używana do ustawienia dokładnego czasu.
PROFINET
Profinet został opracowany przez firmę Siemens wspólnie z organizacją PNO (Profibus User Organization). Występuje w kilku wersjach przeznaczonych do realizacji zadań, które różnią się wymaganiami czasowymi transmisji. Ponadto każda z odmian Profinetu jest zaliczana do innej kategorii w zależności od tego, w jakim stopniu jest zgodna ze standardem Ethernet TCP/IP.
Wersja podstawowa powinna być używana do przesyłu danych, które są czasowo niekrytyczne, na przykład parametrów konfiguracyjnych i do wymiany informacji między systemami automatyki a tymi wyższego poziomu, na przykład MES czy ERP. W tym celu wykorzystuje się kanał TCP/UDP i IP i nie są wymagane żadne modyfikacje sprzętowe.
Do przesyłu danych krytycznych czasowo trzeba używać Profinetu w wersji real time. Nie wymaga ona korzystania z dodatkowych rozwiązań sprzętowych, lecz wprowadza zmiany w standardowej ramce ethernetowej. W tym wypadku dane o największym znaczeniu są przesyłane w pierwszej kolejności (priorytetyzacja VLAN), zaś dane konfiguracyjne i diagnostyczne za pośrednictwem UDP/IP.
W aplikacjach, które wymagają synchronizacji czasowej, na przykład w sterowaniu numerycznym, używany jest Profinet w trybie transmisji izochronicznej (Isochronous Real Time). Wykorzystuje się w nim oddzielne kanały do komunikacji real time oraz standardowej TCP/UDP, natomiast synchronizację uzyskuje, stosując specjalne switche wyposażone w układy ASIC.
ETHERCAT
EtherCAT (Ethernet for Control Automation Technology) został opracowany przez firmę Beckhoff Automation, natomiast obecnie w jego rozwój i popularyzację jest także zaangażowana organizacja ETG (EtherCAT Technology Group). Komunikacja w sieci zorganizowana jest według modelu master-slave z dodatkowym mechanizmem przetwarzania ramki w locie.
Polega on na tym, że węzeł nadrzędny wysyła jedną ramkę ethernetową, w której umieszczane są wiadomości przeznaczone dla wszystkich węzłów podrzędnych, a nie tylko dla jednego odbiorcy. Ramka dociera po kolei do wszystkich stacji w sieci. Każda z nich najpierw sprawdza, czy w ramce znajdują się dane, których jest odbiorcą. Jeżeli tak, to odczytuje odpowiedni fragment, a następnie dodaje swoją odpowiedź - na przykład potwierdzającą odbiór wiadomości. Ramka jest wówczas przesyłana dalej, a kiedy dotrze do ostatniego węzła, zostaje zawrócona.
Sieci EtherCAT pracują zatem w logicznej topologii pierścienia. Dzięki temu, że w ramce przenoszone są dane do i od wielu węzłów sieci jednocześnie, zostaje rozwiązany problem nieprzystosowania Ethernetu do transmisji małych pakietów danych. W standardowej ramce ethernetowej dane kontrolne mogą bowiem zajmować więcej miejsca niż zasadnicza informacja.
Najkrótsza ramka ethernetowa ma rozmiar 84 bajtów. Jeżeli przykładowo urządzenie okresowo przesyła 4 bajty danych, to wykorzystuje ją w niespełna 5%, podczas gdy w EtherCAT nawet w ponad 90%. W sieciach przemysłowych ma to ogromne znaczenie, gdyż za ich pośrednictwem najczęściej przesyłane są właśnie małe ilości informacji - na przykład wyniki pomiarów albo instrukcje sterujące.
MODBUS
Protokół Modbus został opracowany przez firmę Modicon w 1979 roku, jest to zatem jeden z najdłużej użytkowanych protokołów komunikacji przemysłowej. Obecnie za jego promocję i rozwój odpowiada Modbus Organization.
Bazuje on na modelu komunikacji master-slave. Węzeł nadrzędny, aby połączyć się z węzłem podrzędnym wysyła komunikat składający się z: adresu odbiorcy, treści wiadomości oraz sumy kontrolnej, której sprawdzenie pozwala wykryć ewentualne błędy transmisji. Komunikat jest widoczny dla wszystkich węzłów sieci, jednak odbiera go, interpretuje i odpowiada na niego wyłącznie węzeł o wskazanym adresie sieciowym. Węzły slave nie mogą inicjować transmisji, jedynie odpowiadają na zapytania węzłów master.
Wyróżnia się trzy typy protokołu Modbus: ASCII, RTU oraz TCP. Nie różnią się one formatem wiadomości, lecz jedynie sposobem ich kodowania na potrzeby transmisji. W Modbus-ASCII wykorzystywany jest zapis szesnastkowy, przez co komunikacja w tym trybie jest najmniej efektywna ze wszystkich wymienionych. W Modbus-RTU dane komunikatu są zapisywane w kodzie binarnym, zaś w trzeciej wersji protokołu do przesyłu wiadomości w formacie Modbus wykorzystuje się protokół TCP/IP i sieć Ethernet.
Gorący temat: Czym są sieci TSN?Od pewnego czasu tematem cieszącym się dużym zainteresowaniem są sieci TSN (Time Sensitive Networks). Nie powinno to dziwić szczególnie w związku z przewidywanym rozwojem Przemysłu 4.0, bowiem sieci TSN mają umożliwić połączenie wszystkich systemów w zakładzie, od tych na poziomie sterowania po informatyczne na poziomie zarządzania pracą całego przedsiębiorstwa, w ramach ujednoliconej sieci, z możliwością realizacji transmisji w precyzyjnie ustalonych ramach czasowych. Na wstępie warto wyjaśnić, że TSN prawdopodobnie nie zostaną zdefiniowane jako jeden standard, a raczej będzie to rodzina specyfikacji, z których każda będzie się odnosiła do innego aspektu albo wymogu deterministycznej i niezawodnej transmisji. Prace nad niektórymi z nich trwają dłużej niż nad innymi, więc są w różnym stopniu zaawansowania - część została upubliczniona, niektóre są na ukończeniu, a nad pozostałymi prace dopiero rozpoczęto. Przegląd standardów sieci TSN Jeżeli chodzi o te już opublikowane, to w tej grupie znajdują się specyfikacje, które charakteryzują podstawowe aspekty działania sieci TSN. Jest to m.in. synchronizacja urządzeń w sieci w oparciu o wspólną podstawę czasu według IEEE 802.1AS-2011 albo IEEE 1588. Drugim jest ograniczenie opóźnień oraz jitteru sygnałów. Uzyskuje się je różnymi metodami, które zostały opisane w następujących normach: IEEE 802.1Qbv-2015 (technika scheduled traffic), IEEE 802.1Qbu-2016 i IEEE 802.3br-2016 (metoda frame preemption) oraz IEEE 802.1Qav-2009. Nad innymi sposobami zarządzania ruchem sieciowym w sieciach TSN wciąż trwają prace. Techniki, które mają poprawić ich niezawodność, opisano natomiast w IEEE 802.1Qci-2017 (Per-Stream Filtering and Policing) oraz IEEE 802.1CB (Frame Replication and Elimination for Reliability). Zarządzanie ruchem Ważnym dokumentem, który nie jest jeszcze gotowy, jest IEEE P802.1Qcc. Opisano w nim różne schematy zarządzania siecią, w tym: w pełni scentralizowany, zdecentralizowany oraz częściowo scentralizowany. Ten pierwszy zakłada istnienie głównego menedżera sieci. Będzie on znał właściwości urządzeń w sieci, zależności pomiędzy nimi oraz wymogi odnośnie do przebiegu transmisji. Uwzględniając to i dodatkowo specyfikę aplikacji, będzie zarządzał ruchem sieciowym w taki sposób, aby segmenty sieci oparte na różnych protokołach komunikacyjnych, wymagające albo nie transmisji w czasie rzeczywistym, jak najefektywniej w stosunku do swoich potrzeb wykorzystywały jej zasoby. Podsumowanie Pierwsze próby stworzenia sieci TSN były podejmowane w latach 80. zeszłego wieku, jednak bez powodzenia, na co złożył się szereg czynników, w tym przede wszystkim brak w tamtym czasie możliwości technicznych zorganizowania komunikacji na takim poziomie skomplikowania. Dzięki nim jednak przez lata udało się doprecyzować wymogi stawiane sieciom TSN, zaś obecny poziom techniki stopniowo pozwala je realizować. Choć są one wciąż w powijakach, wymienione wcześniej ukończone specyfikacje dają już solidne podstawy do podejmowania prób ich wdrażania. Idealnie byłoby, gdyby przyjęły się w jakimś zastosowaniu na masową skalę, na przykład w samochodach, przyspieszyłoby to bowiem z pewnością ich rozwój i zmniejszyło koszty ich implementacji. |