„Uniwersalny Konwerter Protokołów„

„Uniwersalny
Konwerter
Protokołów„
Autor
Robert Szolc
Promotor
dr inż. Tomasz Szczygieł
„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
„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
„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
„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
„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
„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
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
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
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
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
Trochę o konwertowanych
protokołach…
12
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
Mechanizm kapsułkowania
- warstwa aplikacji generuje
MODBUS/RTU
- usunięcie CRC16
- warstwa transportu segment TCP
- warstwa sieci - datagram IP
- warstwa łącza danych ramka
14
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
Wady enkapsulacji
Narzut czasowy związany z konwersją ramki sieci
Modbus (ramka Modbus / RTU o długości 4 - 256 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
„Uniwersalny Konwerter
Protokołów„
Dziękuję za uwagę.
17