Mechanizmy komunikacyjne w sieciach DeviceNet i CanOpen
| TechnikaPrzyglądając się aktualnej ofercie systemów sieciowych nie trudno dojść do wniosku, że jest ich bardzo wiele. Po okresie, kiedy każdy producent chciał mieć swój własny protokół, zaczęły krystalizować się pewne standardy ale problem ich wielości pozostał. W artykule przedstawiono metody budowy bramek łączących sieci o różnych standardach.
Problem dużej liczby standardów sieciowych jest szczególnie widoczny z poziomu urządzeń. Z jednej strony stosowanie różnych typów sieci zapewnia większą niezawodność systemu, umożliwia zdalną konfigurację i diagnostykę oraz zapewnia szybkość i stabilność działania. Z drugiej strony, użytkownik końcowy zwłaszcza średnich i dużych instalacji otrzymując kilka rodzajów połączeń może mieć problemy z przepływem danych pomiędzy nimi. Powstaje pytanie, czy wymiana informacji pomiędzy sieciami jest konieczna i czy nie wystarczy połączenie "obiektowe", a więc poprzez zwykłe wejścia i wyjścia. Otóż w bardzo prostych i w pełni niezwiązanych systemach tak jest, ale w przypadku bardziej złożonego systemu oraz przy większej ilości przesyłanych danych potrzeba już innych rozwiązań. Jest tak tym bardziej, że od kilku lat obserwowany jest znaczny wzrost wdrożeń systemów klasy ERP dla których jedną z podstawowych przetwarzanych danych jest stan procesu produkcyjnego.
DeviceNet i CanOpen
Stworzenie odpowiedniego urządzenia łączącego sieci (gateways) wymaga znajomości standardów komunikacyjnych, które będą wykorzystywane. Zarówno sieci DeviceNet, jak i CanOpen zostały oparte o technologię producent-konsument PK (producer/consumer). Główną ideą modelu PK jest przesyłanie danych przy użyciu mechanizmu multicast, który pozwala na odbieranie przez wiele węzłów tych samych danych, w tym samym czasie od jednego nadawcy (producenta). Każda ramka przesyłana przez sieć jest wyposażana w pole identyfikatora pozwalające urządzeniom odbierającym na stwierdzenie, czy dana informacja jest dla nich istotna, czy należy ją zignorować. Pozwala to na osiągnięcie dużej efektywności transmisji przy niskiej częstotliwości nadawania, a co za tym idzie również i przy niższych kosztach.
Podczas normalnej pracy obydwu sieci przesyłane są dwa typy informacji: dane o stanie wejść/wyjść (I/O messages, informacje z obiektów PDO) oraz dane o charakterze ogólnym, konfiguracyjnym i statusowym (explicit messages, informacje z obiektów SDO).
Przesyłanie danych konfiguracyjnych zachodzi na żądanie i wygląda podobnie w różnych systemach. Duże grupy danych są dzielone na części i przesyłane w chwilach małego obciążenia sieci. Znacznie trudniejsze do przesłania z uwagi na swój charakter są dane krytyczne. Ich wymiana wymaga określenia odpowiednich modeli, gwarantujących uzyskanie wysokiej efektywności. W przypadku DeviceNet oraz CanOpen istnieją trzy mechanizmy transferu tego typu danych.
|
Podstawowe typy danych przesyłanych w sieci DeviceNet i CanOpen Wiadomości I/O PDO:
Wiadomości SDO:
|
Transfer danych krytycznych
Pierwszym z mechanizmów przesyłu danych jest tzw. zmiana stanu (change of state – COS, event triggered PDO TM). Ideą COS jest wykorzystywanie łącza jedynie wtedy, gdy stan urządzenia uległ zmianie. Oznacza to, że wszystkie węzły pracujące w trybie COS dokonują sprawdzania, czy dane przeznaczone do przesłania zmieniły swoją wartość i jeśli tak jest, przystępują do testowania stanu sieci, a następnie nadawania (patrz rys. 1). Komunikat (1) jest generowany w sytuacjach, w których skaner modyfikuje sterowanie procesem, zaś sytuacja (2) ma miejsce wtedy, gdy stan procesu uległ zmianie. Warto tutaj zwrócić uwagę na fakt, że typowa transmisja COS odbywa się tylko w jedną stronę i ma charakter multicast. W przypadkach przesyłania szczególnie istotnych danych zachodzi połączenie (3), w którym odebranie komunikatu jest potwierdzane.
Powstaje pytanie jak odróżnić sytuację, w której brak kolejnych danych wynika z ich niezmienności od stanu, w którym urządzenie lub połączenie kablowe zostało uszkodzone i jakakolwiek transmisja nie jest w ogóle możliwa. Aby skaner mógł dokonać analizy stanu węzłów typu COS, wprowadzony został mechanizm cyklicznego przesyłania informacji statusowej (4), nazywany device hartbeat lub timer triggered PDO mode. Jest to metoda opcjonalna i stosuje się ją w przypadku urządzeń, których awaria jest trudna do wykrycia dla obsługi technicznej.
Drugim sposobem przesyłu danych jest tzw. strobowanie bitowe (bit strobe – BS, sync triggered PDO TM). Mechanizm BS stworzony został przede wszystkim do obsługi prostej sensoryki i nieskomplikowanych układów wykonawczych. Urządzenia takie z racji swojej konstrukcji cechują się niewielkimi rozmiarami, co uniemożliwia zastosowanie w nich rozwiniętych układów procesorowych. Ideę komunikacji z wykorzystaniem strobowania bitowego przedstawia rys. 2.
Moduł skanera wysyła w sieć komunikat (1). Zgodnie z modelem producent-konsument dane te mogą zostać odebrane przez wszystkie urządzenia w sieci. W ramce tego komunikatu w przypadku DeviceNet znajdują się 64 bity (8 bajtów czyli maksymalna ilość informacji w jednej ramce), z których każdy reprezentuje jeden węzeł. Jeśli pole zawiera „1”, a węzeł pracuje w trybie BS, to wysyła on do skanera komunikat (2) zawierający aktualny stan urządzenia. Ustawienie wartości „0” jest równoznaczne z brakiem żądania odpowiedzi od danego urządzenia. W sieci CanOpen ramka strobująca SYNC message nie zawiera danych, a jej identyfikator jest sygnałem dla urządzeń o żądaniu przesłania swojego stanu. Mechanizm ten ma pewne cechy klasycznego odpytywania, jest jednak znacznie efektywniejszy z uwagi na charakter przesyłania (1), jakim jest broadcast. Znajduje on zastosowanie przede wszystkim przy współpracy z urządzeniami sensorycznymi, takimi jak czujniki krańcowe, pojemnościowe i indukcyjne sensory obecności, czy też fotowyłączniki, które obok swojego stanu przesyłają swój status ograniczony zazwyczaj do kilku bitów. Typowo całość informacji zwracanej przez urządzenie w postaci (2) ma długość jednego bajtu. Pozwala to na osiągnięcie dosyć znacznych prędkości przekazywania informacji, co jest szczególnie istotne w procesach transportowych, pakowania i masowej produkcji. Obecnie na rynku znajduje się wiele prostych czujników, wyposażonych w taki interfejs.
Trzecią metodą przesyłu danych krytycznych jest cykliczne odpytywanie (polling – PO, remotely requested PDO TM). Komunikacja z wykorzystaniem mechanizmu PO jest realizacją standardowej idei wymiany informacji w sieciach poziomu urządzeń. Przekazywanie danych jest realizowane przez cykliczne łączenie się z każdym urządzeniem, co szczegółowo wyjaśnia rys. 3.
Podczas konfiguracji sieci w skanerze jest budowana lista urządzeń, według której następuje odpytywanie. W omawianym przykładzie listę tworzą adaptery: ADN1 (pozycja (1) na liście), ADN2 (2) oraz ADN3 (3). Rozpoczynając od pozycji (1) skaner wysyła komunikat (1) zawierający informacje przeznaczone dla ADN1 lub adres żądanych danych w ADN1. W odpowiedzi (2) ADN1 przesyła odpowiednio potwierdzenie przyjęcia informacji lub dane wymagane przez skaner. Po zakończeniu połączenia z urządzeniem (1) skaner łączy się z kolejnym adapterem na liście. Proces ten jest realizowany cyklicznie, przy czym dla każdego węzła można określić indywidualny czas odpytywania. Lista w skanerze ma więc charakter dynamiczny, zależny od rodzaju sterowanego procesu i wykorzystanych urządzeń. Mechanizm PO jest najczęściej stosowany przy zbieraniu danych analogowych takich jak temperatura, ciśnienie czy przepływy, których okres zmienności jest wprawdzie zróżnicowany, ale w miarę stały i łatwy do określenia.
Konstrukcja bramek sieciowych
Dostawcy urządzeń, których zadaniem jest sprzęganie różnych systemów sieciowych, stają zazwyczaj przed dwoma fundamentalnymi problemami. Pierwszym z nich jest niezgodność mediów, czyli różnice wynikające z zastosowania innych fizycznych połączeń oraz sterowania dostępem do łącza. Drugim problemem jest niezgodność protokołów będąca efektem stosowania różnych modeli sieciowych.
Pierwsza kwestia jest zazwyczaj rozwiązywana jedno- lub dwuetapowo. W przypadku sieci opartych o standard inny niż RS-485, a więc takich systemów jak Interbus-S, ASI czy Profibus, istnieją dostawcy układów scalonych oferujący gotowe układy, które pozwalają zarówno na obsługę łącza fizycznego, jak i na realizację funkcji sterowania łączem. Jest to szczególnie istotne, gdy ze względu na szybkość działania takiego urządzenia. Warto zwrócić uwagę, że przy systemach pracujących z prędkościami powyżej 19200 b/s wariant, w którym sterowanie dostępem odbywa się w sposób sprzętowy, jest wręcz standardem.
Zastosowanie układu z rys. 4. wymaga od konstruktora zbudowania własnego modelu danych, zapewnienie jego obsługi i wymiany informacji z Anybus-IC. Zwalnia ono jednak z konieczności obsługi podstawowych zadań systemowych takich, jak konstrukcja ramek, kontrolowanie sposobu ich wysłania i odbierania oraz z obsługi samego procesu nadawania i detekcji kolizji. Jest to nieoceniona pomoc w przypadku łączenia sieci DeviceNet i Profibus-DP. Z jednej strony podłączony jest interfejs o przepustowości 500 kb/s z dostępem nasłuchowym CSMA z arbitrażem NBA, z drugiej zaś łącze o przepustowości 12 Mb/s i dostępem tokenowo-M/S. Stosując taki układ do rozwiązania pozostaje jedynie problem mapowania danych i konstrukcja odpowiednich obiektów widzianych w każdej sieci. Takiego komfortu nie ma w przypadku połączeń wykorzystujących jako medium standard RS-485. Tu zasadniczo dostępne są układy magistralowe (sterowniki portów), zaś cała obsługa tj. tworzenie ramek i koordynacja ruchu spoczywają na dostawcy urządzenia. Realizując np. obsługę sieci Modbus konieczne jest pełne określenie zasad ruchu odpowiednie konstruowanie ramek i zapewnienie odpowiednich odstępów międzyramkowych. W przypadku połączeń powolnych jest to oczywiście łatwe do zrealizowania, ale przy przepustowościach 38,4 lub 57,6 kb/s znacznie efektywniejsze są rozwiązania sprzętowe.
Niezgodność protokołów
Drugi problem - niezgodność protokołów - wydaje się być trudniejszym do rozwiązania. Istnieją tutaj dwa sposoby podejścia. Pierwszym z nich jest dynamiczne przekładanie danych pomiędzy ramkami obydwu sieci, drugim – taka konstrukcja bazy danych, aby była ona widziana jako zespół odpowiednich obiektów każdej sieci.
Wariant z dynamicznym tłumaczeniem protokołów sprawdza się jedynie w przypadku systemów z odpytywaniem, z jednoznacznie określoną stacją zarządzającą. W systemach tych możemy określić następujące warianty pracy: master-master, master-slave, slave-slave. Pamiętając, że bramka ma tylko zamieniać ramki, wykorzystanie każdego z powyższych trybów wiąże się z pewnymi trudnościami aplikacyjnymi. Przypadek master-master wymaga korelacji odpytywania po obydwu stronach oraz eliminuje inne stacje master, co zubaża całość aplikacji. Dodatkowo dochodzi problem składowania danych. W wariancie slave-slave występuje ponownie problem korelacji, ale jest on znacznie głębszy. Poprawne działanie takiej bramki wymaga synchronizacji dwóch stacji master w niezależnych sieciach. W praktyce jest to bardzo trudne do zrealizowania. Tryb pracy master-slave jest najczęściej spotykany, gdyż urządzenia podrzędne obsługiwane są przez niezależne stacje kontrolujące, a odebranie zapytania generuje wysłanie żądania po stronie master. Problemem pozostaje wciąż kwestia szybkiej konwersji.
Przykładowa realizacja
W efekcie dotychczasowych rozważań można ustalić, że aby zrealizować konwerter pozwalający na wykorzystanie wszystkich właściwości łączonych sieci oraz podziału danych na istotne i konfiguracyjne konieczna jest implementacja bazy danych jako jądra bramki. Konwerter przedstawiony na rys. 5. wyposażony został w pewną formę bazy danych. Jest to zespół tablic, których przeznaczenie oraz funkcjonalność są zależne od rodzaju sieci. Jeśli określi się charakter jednej strony interfejsu slave w DeviceNet, jednocześnie zdefiniowany zostaje rodzaj współpracy z siecią (change-of-state, polling, bit strobe). Istnieje także możliwość dzielenia danych na ważne (implicit) oraz drugoplanowe (explicit). Z drugiej strony można wykorzystać port master dla magistrali ASI. Będzie on cyklicznie odpytywał całą sieć i wypełniał tablicę buforową. W przypadku zmian wartości, zadziała mechanizm COS i bramka wyśle w sieć DeviceNet odpowiednią informację. Jeśli otrzyma nowe dane od urządzenia końcowego, zostaną one wpisane do tablicy buforowej i zostaną przesłane do odpowiednich stacji ASI Slave. Mechanizm ten cechuje się wysoką stabilnością i co najważniejsze niezależnością funkcjonalną obydwu procesów. Wymiana przez wspólną pamięć pozwala zarówno zachować pełne właściwości łączonych systemów, jak i nie zmniejszać ich efektywności. Warto zwrócić uwagę na obecność obszaru local data, którego zadaniem jest przechowywanie nie tylko informacji konfiguracyjnych ale także danych statusowych i diagnostycznych. Pozwala to na osiągnięcie sprzęgu nie tylko w zakresie danych, ale i bezpieczeństwa systemu.
Podsumowanie
Jeszcze kilka lat temu wystarczyło zainstalowanie odpowiednio dużego komputera wyposażenie go w szereg kart sieciowych, dodanie odpowiedniej wizualizacji, aby uzyskać gotowy sprzęg interfejsów. Jednakże celem było jedynie doprowadzenie informacji do lokalnej stacji operatorskiej.
Dzisiejsze wymagania są znacznie większe. Projektant musi zapewnić szereg połączeń na wszystkich trzech poziomach sieciowych spotykanych w przemyśle, przy czym nie chodzi o zebranie danych w dowolnym czasie. System ma pozwalać na pracę w czasie rzeczywistym, bez tworzenia tzw. wąskich gardeł, a jednocześnie ma być bezpieczny. Aby spełnić powyższe warunki i jednocześnie wykorzystać zalety takich magistrali jak CanOpen, konieczne jest obecnie zastosowanie inteligentnej bramki z wbudowaną bazą danych.
Rafał Tutaj
