Sposoby wykrywania błędów

Rys. 4 Przykład wyliczania wieku danych

Jak wspomniano wcześniej, zadaniem CIP Safety nie jest 100% ochrona czy zapobieganie pojawianiu się błędów. Jedną z głównych funkcji obiektów SV jest ich wykrywanie i podejmowanie odpowiedniej akcji. W tabeli 1 wymienione zostało 9 błędów, które muszą być wykrywane przy pomocy jednej, bądź kilku z pięciu metod.

W standardowej sieci DeviceNet wysyłanie danych odbywa się metodą typu broadcast. Oznacza to, że nadawca nie otrzymuje bezpośrednio potwierdzenia odebrania danych. Protokół nakłada na urządzenia typu slave obowiązek przesyłania co określony czas informacji o stanie lub odpowiedź taka udzielana jest na żądnie.

Taki sposób weryfikacji jest niewystarczający do zapewnienia pracy na poziomie SIL 3. W sieci DeviceNet Safety każda informacja jest przesyłana z dołączonym stemplem czasowym. Jest to forma bardzo precyzyjnego licznika pozwalającego odbiorcy określić wiek otrzymanych danych. W przypadku przekroczenia dopuszczalnego czasu mogą być podejmowane dodatkowe działania, jak np. żądanie ponownego transferu lub przełączenie w tryb bezpieczny. Szczegóły takiej komunikacji pokazano na rys. 4.

Rys. 5 Krótka ramka DeviceNet Safety

Po nawiązaniu połączenia następuje synchronizacja zegarów poprzez komendę ping. Wszystkie dalsze komunikaty opierają się na czasie liczonym na bazie offsetów określonych podczas nawiązywania połączenia. Każde przesłanie danych jest łączone z przesłaniem stempla (oznaczone jako Time Stamp na rysunku). Z uwagi na możliwy dryft układów nadawczych i odbiorczych ramka ping jest przesyłana co jakiś czas, aby zapewnić synchronizację zegarów.

Oprócz stempla czasowego do detekcji błędów wykorzystywany może być identyfikator PID (Production IDentifier). Podczas konfiguracji systemu każdy potencjalny nadawca danych (producent) tworzy specjalny numer będący kombinacją numeru seryjnego, numeru połączenia CIP oraz klucza produktu.

Odbiorca podczas analizy danych (poprzez obiekt SV) porównuje identyfikatory i w przypadku niezgodności odrzuca informację i/lub przechodzi w stan bezpieczny. Mechanizm taki jest szczególnie ważny w przypadku układów hybrydowych łączących kilka podsieci, w których może wystąpić błąd złego przekierowania pakietów.

Rozdzielność funkcjonalna, Safety CRC i redundancja

Kolejną cechą omawianego protokołu jest tzw. rozdzielność funkcjonalna. Jest to cecha DeviceNet Safety blokująca tworzenie obiektów SV w urządzeniach, które nie mają charakteru układów bezpieczeństwa. Mechanizm ten pozwala na uniemożliwienie hipotetycznego podszywania się – np. w wyniku błędu – standardowych urządzeń pod elementy typu safety.

Wykrywanie błędów wspomaga również suma kontrolna. Zapewniać ma ona kontrolę integralności i niezmienności danych. Modyfikacja standardowego algorytmu na potrzeby układów bezpieczeństwa pozwoliło na osiągnięcie odstępu Hamminga na poziomie 4. Dzięki temu wszelkie problemy wynikające zarówno z zakłóceń jak i błędów przy fragmentacji mogą zostać szybko wykryte. Dzięki umiejscowieniu Safety CRC wewnątrz obszaru danych w komunikatach osiągnięto niezależność od warstwy łącza dodającej własną, wynikającą z sieci sumę kontrolną.

Aby dodatkowo zwiększyć wartość odstępu powyżej 4, zdecydowano się na redundantny transfer danych i sum kontrolnych. Oznacza to iż w każdym komunikacie przekazywane informacje są dublowane w postaci właściwych danych i ich negacji. Zadaniem obiektu SV jest więc ich wydzielenie, porównanie logiczne i następnie – o ile wynik jest pozytywny – przekazanie do analizy sumy safety CRC.

Przesyłanie danych i nawiązywanie połączeń

Rys. 6 Długa ramka DeviceNet Safety

Przesyłanie danych, w przypadku podstawowej formy protokołu DeviceNet, opiera się o wykorzystanie ramki CAN. W przypadku sieci bezpiecznej wszelkie zmiany w protokole wprowadzone zostały w obszarze danych, co pozwala zachować niezależność od typu łącza i umożliwić współpracę różnych urządzeń.

W sieci DeviceNet Safety wyróżnia się dwa rodzaje komunikatów – krótkie i długie. Pierwszy z nich (patrz rys. 5) pozwala na przesłanie do dwóch bajtów informacji, co jest bardzo przydatne dla prostych urządzeń, takich jak wyłączniki bezpieczeństwa czy zabezpieczenia osłon. Taki rodzaj komunikacji minimalizuje też ruch sieciowy.

Drugi rodzaj komunikatu umożliwia przesyłanie większych ilości danych – aż do 250 bajtów. Warto tutaj zwrócić uwagę, że standard CAN dopuszcza przesyłanie do 8 bajtów w ramce, a więc do przesłania takiej ilości danych konieczna będzie ich fragmentacja. Jest to jednak własność łącza, a więc z punktu widzenia DeviceNet Safety i obiektu SV ciągle operuje się na pojedynczym, długim komunikacie (patrz rys. 6).

Warto zauważyć, że w przypadku danych podlegających redundancji, wydłużeniu ulega zarówno suma kontrolna, jak i właściwe dane. Wydłuża to treść komunikatu, a co za tym idzie czas jego przesyłania, ale zapewnia również bardzo dużą integralność danych.

Ponieważ wykorzystanie wyłącznie komunikatów z danymi jest niewystarczające do poprawnej pracy sieci, stworzono cały szereg dodatkowych form pozwalających na synchronizację, diagnostykę i konfigurację. Wcześniej omówiony został układ obiektów przy połączeniu typu singlecast czyli jeden-do-jednego.

Ciekawsze wydaje się wykorzystanie komunikatów typu multicast, a więc takich, w przypadku których nadawca wysyła informacje do kilku odbiorców jednocześnie. Schemat takiego połączenia przedstawiony został na rys. 7. W ten sposób możliwe jest przesłanie danych do 15 urządzeń. Klient SV tworzy w tym przypadku trzy połączenia – danych, koordynacji czasu i korekty czasu.

Dwa pierwsze są wspólne dla wszystkich odbiorców, natomiast korekta czasu odbywa się, z uwagi na wymogi bezpieczeństwa, indywidualnie dla każdego odbiorcy. Każdemu z powyższych mechanizmów towarzyszy inna, pod względem budowy ramki, forma komunikatu.

Konfiguracja urządzeń

Rys. 7 Schemat obiektowy połączenia typu multicast

Bardzo ważnym elementem pracy sieci jest konfiguracja urządzeń. Obecnie praktycznie wszystkie elementy systemów bezpieczeństwa są wyposażane w układy procesorowe z pamięciami typu Flash, dzięki czemu projektant może wykorzystać szereg narzędzi umożliwiających swobodną konfigurację urządzeń przez sieć.

Przesłanie typowych ustawień czy parametrów nie jest niczym nowym, więc w tym miejscu pokazane zostaną jedynie elementy związane z podniesieniem bezpieczeństwa.

Sieć DeviceNet Safety zapewnia kilka mechanizmów zabezpieczających system przed zmianami konfiguracji:

• Safety Network Number – specjalny numer określający sieć, który jest modyfikacją PID związaną z wersją skanera sieci. Każde urządzenie pracujące ze skanerem przechowuje jego identyfikator w celu sprawdzenia, czy zmiany w konfiguracji prowadzone automatycznie przez program sterownika pochodzą z właściwego skanera.
• Password Protection – zabezpieczenie odpowiadające powyższemu identyfikatorowi, które przeznaczone jest dla operatorów sieci i umożliwia autoryzowanie dostępu.
• Configuration Ownership – możliwość wyeliminowania na poziomie komunikatów nieautoryzowanego dostępu; każde urządzenie (sterownik, karta sieciowa, urządzenie zdalne, itp.) może mieć określone dozwolone źródło zmian w konfiguracji.
• Configuration Locking – możliwość przełączenia sieci w stan blokujący wszelkie zmiany, ale umożliwiający odczyt wszystkich parametrów. Dzięki temu po zakończeniu testów i dopuszczeń systemu do pracy użytkownik ma możliwość podglądu stanu sieci.

Podsumowanie

W przedstawionym przykładzie omówiono przykładowy protokół bezpieczeństwa, który rozszerza wykorzystywany w przemyśle standard komunikacyjny. Chociaż obecny jest on na rynku dopiero od kilku lat, wielu znaczących producentów automatyki ma w swojej ofercie wspierające go urządzenia i systemy.

Niemniej szczególnie ważne jest zrozumienie zasad jego działania przed rozpoczęciem wykorzystywania urządzeń oferujących omawianą funkcjonalność, gdyż z poziomu oprogramowania narzędziowego (które jest najczęściej przedmiotem szkoleń i prezentacji) wielu omawianych elementów protokołu nie widać. Autorzy zachęcają do udziału w różnego typu spotkaniach i szkoleniach jako kontynuację poznawania sieciowych systemów bezpieczeństwa opartych o DeviceNet Safety.

Rafał Tutaj, Zbigniew Piątek