Uniwersalny Konwerter Protokołów

Transkrypt

1 Uniwersalny Konwerter Protokołów Autor Robert Szolc Promotor dr inż. Tomasz Szczygieł

2 Uniwersalny Konwerter Protokołów Szybki rozwój technologii jaki obserwujemy w ostatnich latach, spowodował że systemy sterowania i wizualizacji gwałtownie zwiększają zapotrzebowanie na ilość danych, jakie należy przesłać siecią przemysłową. Wzrost ilości danych związany jest ze zwiększeniem zapotrzebowania na informacje diagnostyczne, niezbędne do kontroli poprawności pracy urządzeń wykonawczych (np. temperatur uzwojeń i łożysk silników, ostrzeżeń o niestabilnej pracy danego urządzenia, itd.). 2

3 Uniwersalny Konwerter Protokołów Okazuje się, że przy rozbudowie systemu sterowania czy wizualizacji często dochodzimy do granic możliwości zastosowanej taniej sieci przemysłowej. W celach obniżenia kosztów często stosuje się rozwiązania łączące kilka typów sieci. Jednak aby dokonać takiego zabiegu potrzebne są dedykowane sprzętowe bądź software owe konwertery protokołów transmisji. 3

4 Uniwersalny Konwerter Protokołów 1. Podstawowe wymagania stawiane konwerterowi protokołów transmisji: aplikacja software owa uruchamiana jako proces systemowy umożliwiająca automatyczną detekcję protokołu transmisji uniwersalność - konwersja najpopularniejszych protokołów 4

5 Uniwersalny Konwerter Protokołów 1. Podstawowe wymagania stawiane konwerterowi protokołów transmisji cd.: aplikacja posiadająca właściwości sniffera umożliwiająca przechwytywanie pakietów danych 5

6 Uniwersalny Konwerter Protokołów 1. Podstawowe wymagania stawiane konwerterowi protokołów transmisji c.d.: zapewenienie gwarantowanego czasu dostępu do systemu komunikacyjnego możliwość wysyłania poleceń i odpytywania urządzeń znajdujących się w sieci 6

7 Uniwersalny Konwerter Protokołów 2. Problemy które należy rozwiązać: znaleźć sposób na automatyczne wykrywanie protokołu w sieci w który zostanie wpięty konwerter wykrywanie urządzeń pracujących w sieci 7

8 Przykład konwersji protokołów Konwersja dokonywana dla 2 urządzeń połączonych za pomocą łącza RS 232 i RJ45. Komunikacja opiera się na bazie protokołu Modbus / RTU, a po stronie sieci Ethernet mamy do czynienia z mechanizmami protokołu TCP/IP. Mechanizm konwersji opierać się będzie na bazie kapsułkowania ramek transmitowanych w sieciach przemysłowych poprzez protokół TCP / IP. 8

9 Trochę o konwertowanych protokołach Modbus / RTU Urządzenie podłączone do Modbus RTU komunikują się za pomocą łącza szeregowego RS-232 lub RS-485. Wydzielona stacja Master posługując się listą wymian cyklicznych i wyzwalanych odpytuje kolejno poszczególnych abonentów sieci. Ramka w trybie RTU 9

10 Trochę o konwertowanych protokołach Sieć ta pracuje z niewielkimi szybkościami transmisji danych (typowe: 9.6 Kb/s, 19.2 Kb/s) na ograniczonym dystansie wynikającym z typu zastosowanego łącza komunikacyjnego (RS-232, RS-422, RS-485, Modem). Dystrybucja uprawnień do nadawania realizowana przez stację Master gwarantuje zdeterminowany dostęp do medium. Szerokie zastosowanie w aplikacjach przemysłowych o niskich wymaganiach dotyczących szybkości i częstości transmisji danych, w szczególności w systemach z wydzielonym centrum, do którego przesyłane są dane z urządzeń peryferyjnych. 10

11 Trochę o konwertowanych protokołach TCP organizuje dwukierunkową współpracę między warstwą IP, a warstwami wyższymi, uwzględniając przy tym wszystkie aspekty priorytetów i bezpieczeństwa. Musi prawidłowo obsłużyć niespodziewane zakończenie aplikacji, do której właśnie wędruje datagram, musi również bezpiecznie izolować warstwy wyższe - w szczególności aplikacje użytkownika - od skutków awarii w warstwie protokołu IP Rozpatrując TCP z punktu widzenia funkcjonalności można potraktować jego pracę jako ustanowienie kanału wirtualnego realizującego komunikację między "końcówkami" - tak wygląda to z punktu widzenia aplikacji użytkownika. 11

12 Trochę o konwertowanych protokołach 12

13 Trochę o konwertowanych protokołach Aby zagwarantować, że dane przesyłane z jednej maszyny do drugiej nie są ani tracone, ani duplikowane używa się podstawowej metody znanej jako pozytywne potwierdzanie z retransmisją. Metoda ta wymaga, aby odbiorca komunikował się z nadawcą, wysyłając mu w momencie otrzymania danych komunikat potwierdzenia (ACK). Nadawca zapisuje sobie informację o każdym wysłanym pakiecie i przed wysłaniem następnego czeka na potwierdzenie. Oprócz tego nadawca uruchamia zegar w momencie wysyłania pakietu i wysyła ten pakiet ponownie, gdy minie odpowiedni czas, a potwierdzenie nie nadejdzie 13

14 Mechanizm kapsułkowania - warstwa aplikacji generuje MODBUS/RTU - usunięcie CRC16 - warstwa transportu - segment TCP - warstwa sieci - datagram IP - warstwa łącza danych - ramka 14

15 Mechanizm kapsułkowania Warstwa aplikacji oprogramowanie obsługujące protokół MODBUS generuje ramki Kapsułkowanie w segmencie TCP po usunięciu sumy CRC Segmenty TCP, zgodnie z warstwową budową stosu protokołów TCP/IP, kapsułkowane są na poziomie Intersieci w datagramy IP. Datagramy IP na poziomie interfejsu sieciowego kapsułkowane są w ramki sieci Ethernet. Warstwa sprzętu zapewnia dostarczenie ramki do adresata. Oprogramowanie komunikacyjne po stronie odbiorcy realizuje odwrotną procedurę. 15

16 Wady enkapsulacji Narzut czasowy związany z konwersją ramki sieci Modbus (ramka Modbus / RTU o długości B po przejściu do warstwy fizycznej może mieć długość 372 B ) Niemożność wykorzystania w szeregu zastosowań typu hard real-time w zależności od architektury systemu (determinizm czasowy) Brak mechanizmów zapewniających bezpieczeństwo sieci na poziomie właściwym dla urządzeń automatyki w sieciach rozległych 16

17 Uniwersalny Konwerter Protokołów Dziękuję za uwagę. 17