CANOpen_teoria

Załącznik C
Temat: „Sieć Przemysłowa CAN.”
Zadanie: „Zdalne moduły wejść/wyjść w sieci CANOpen”
Wstęp teoretyczny do ćwiczenia laboratoryjnego.
1. Historia sieci CAN.
Sieć CAN (ang. Control Area Network) wywodzi się z motoryzacji. Na potrzeby przemysłu
motoryzacyjnego od roku 1983 zaczęto w firmie Robert Bosch GmbH opracowywać nowy interfejs
szeregowy.[2] Rozwiązanie miało zostać zastosowane do sterowania układami pomiarowymi
i wykonawczymi w samochodach, w związku z tym sformułowano następujące trzy wymagania dla jego
parametrów:[1]
•
•
•
duŜa szybkość transmisji danych, umoŜliwiająca szybkie działanie takich układów jak
poduszki powietrzne, system antypoślizgowy ABS (niem. AntiBlockierSystem);
odporność na zakłócenia emitowane w samochodzie przez urządzenia
elektromechaniczne (np. rozrusznik, alternator) oraz elektroniczne (np. zapłon);
elastyczność systemu co do liczby podłączonych modułów.
Pierwszy raz, oficjalnie zaprezentowano nowy standard w lutym 1986 roku na kongresie SAE
(ang. Society of Automotive Engineers) w Detroit, USA. Sześć lat później rozpoczęto seryjną produkcję
samochodu Mercedes-Benz S-Class, pierwszego z magistralą CAN. Obecnie, kaŜdy produkowany
samochód w Europie posiada przynajmniej jedną taką magistralę.[2] PoniewaŜ rozwiązanie pod
względem jakości i warunków technicznych sprawdziło się w samochodach, zainteresowały się nim teŜ
inne gałęzie przemysłu. JuŜ w 1992 roku została zawiązana organizacja CAN in Automation (CiA) która
rozpoczęła pracę nad opracowywaniem warstwy aplikacji protokołu dla potrzeb spoza motoryzacji.
CiA bazowało na protokole wymyślonym pierwotnie przez Philips Medical Systems-CAL (ang. CAN
Application Layer). Dzisiaj, na podstawie specyfikacji Boscha powstały rozwiązania dla przemysłu,
sterowania ruchem drogowym i kolejowym, aparatury medycznej, automatyzacji budynków (szczególnie
wind) oraz systemów przeciwpoŜarowych.
Od 1993 roku najniŜsze warstwy protokołu zostały objęte normą ISO 11898.[2] Obecnie
wykorzystuje się dwie wersje interfejsu: standardową CAN 2.0A (ang. standard CAN) i rozszerzoną
CAN 2.0B (ang. extended CAN), róŜniące się wyłącznie długością pola identyfikatora. Dla standardu A
wynosi ona 11 bitów, a dla B 29 bitów.[1]
Z punktu widzenia uŜytkownika, na sukces CAN poza motoryzacją wpłynęły następujące
czynniki:[5]
• zastosowanie międzynarodowego standardu ISO/OSI;
• wysoka niezawodność w warunkach duŜych zakłóceń;
• moŜliwość pracy w systemach czasu rzeczywistego;
• wysoki stopień bezpieczeństwa danych;
• duŜa przepustowość szyny;
• system otwarty, moŜliwość łatwej rozbudowy;
• niski koszt;
• duŜa baza elementów.
1
2. CAN w modelu ISO/OSI.
Rodzina protokołów sieciowych opartych o CAN, tak jak większość sieci polowych,
w odniesieniu do modelu sieciowego ISO/OSI ma zaimplementowaną jedynie warstwę 1. (Fizyczną,
ang. Physical Layer), 2. (Łącza Danych, ang. Datalink Layer) oraz 7. (Aplikacji, ang. Application Layer).
Rysunek 1. Model referencyjny ISO/OSI.
System CAN opiera się jedynie na dwóch warstwach: fizycznej oraz łącza danych. Opierając się
tylko na tych najniŜszych warstwach moŜliwe jest stworzenie kompletnego systemu przesyłu informacji,
wraz z elementami nadzorującymi i konfiguracyjnymi ale biorąc pod uwagę konkretne wymagania
urządzenia lub obiektu, w którym CAN będzie wykorzystany. System nie jest elastyczny. PoniewaŜ wraz
ze wzrostem popularności tej sieci zainteresowały się nią róŜne, odmienne dziedziny przemysłu i nie
tylko, wystąpiła konieczność dostosowania go do konkretnych grup zastosowań.. W związku z tym
powstało kilkanaście rozwiązań warstwy aplikacyjnej bazującej na systemie Control Area Network.
Umiejscowienie warstwy aplikacyjnej w modelu Referencyjnym ISO/OSI na przykładzie CANOpen
przedstawiono na Rysunku 2.[6]
Rysunek 2. Relacje pomiędzy modelem sieciowym ISO/OSI a rozwiązaniami CAN i CANOpen.
2
3. Magistrala w sieci CAN.
Urządzenia sieci CAN pracują prawie zawsze podłączone do magistrali w topologii liniowej,
choć dopuszcza się takŜe topologie gwiazdy.
CAN jest siecią Multi Master, węzły mogą w tym samym czasie zaŜądać dostępu do magistrali.
Zastosowaną metodą dostępu do łącza jest Carrier Sense Multiple Access with Collision Detection and
Arbitration on Message Priority (CSMA/CD + AMP).
CSMA/CD + AMP (CSMA/ CD + Arbitration on Message Priority).
Carier Sense Multiple Access with Colision Detection, Arbitratrion on Message Priority jest tak
zwaną metodą z nieniszczącym arbitraŜem (ang. non-destructive, bit-wise arbitration) bazującą na
priorytecie wiadomości.
Podczas wykrycia kolizji, z transmisji rezygnują węzły, których wiadomość ma niŜszy priorytet.
ArbitraŜ odbywa się na podstawie identyfikatora nadawanego na początku ramki. W wyniku
nadpisywania recesywnych bitów (logiczne 1) identyfikatora wiadomości przez bity dominujące
(logiczne 0), dla wszystkich nasłuchujących węzłów sieci widoczna będzie jedynie wiadomość
z identyfikatorem o najniŜszej wartości, czyli najwyŜszym priorytecie. JeŜeli którykolwiek z nadawców
stwierdza róŜnice pomiędzy bitem nadawanym a odbieranym, zaprzestaje transmisji – przegrywa proces
arbitraŜu. Dzięki temu w całości zostanie nadana tylko wiadomość o najwyŜszym priorytecie, bez utraty
czasu na wznawianie transmisji po wykryciu kolizji (Rysunek 3). Po stwierdzeniu przez odbiorcę, Ŝe
odebrana ramka jest poprawna, ten nadpisuje stanem dominującym bit potwierdzenia (ACK) aktualnie
przesyłanej ramki. Dzięki temu nadawca ma potwierdzenie, Ŝe dana ramka dotarła do odbiorcy. [10].
Rysunek 3. Nieniszczący arbitraŜ występujący w sieci CAN.
CAN nie specyfikuje dokładnie ani nośnika informacji (sygnał elektryczny, optyczny
lub radiowy), ani rodzaju medium (linia elektryczna symetryczna, linia elektryczna niesymetryczna,
światłowód). Rolę kabla przekazującego sygnały w sieci CAN mogą pełnić przewody metalowe, włókna
światłowodowe lub fale elektromagnetyczne: radiowe lub podczerwone. Kable te róŜnią się znacznie
3
zarówno właściwościami uŜytkowymi, jak i ceną. Warto podkreślić, Ŝe w róŜnych segmentach tej samej
sieci mogą być wykorzystane róŜne rodzaje przewodów.[m]
Najczęściej sygnały CAN przesyłane są symetryczną linią transmisyjną złoŜoną z dwóch
skręconych przewodów (ang. twisted pair). Jest to obecnie najtańszy środek transmisji danych. Dzięki
symetrycznemu obwodowi transmisji zapewniono dobre parametry pracy w warunkach zwiększonych
zakłóceń. W celu uniknięcia odbicia sygnału na obu końcach linii transmisyjnej włącza się impedancję
o wartości około 120Ω. Linia transmisyjna składa się z dwóch przewodów do których są doprowadzone
wyprowadzenia CAN_H (high) oraz CAN_L (low) kaŜdego węzła (Rys. 4).[1]
Rysunek 4. Podłączenie węzłów do magistrali sieci CAN.
W większości przypadków, przy wykorzystaniu skrętki jako medium transmisyjne, poszczególne
poziomy reprezentowane są jak na Rysunku 5.[3]
Rysunek 5. Poziomy napięć na magistrali CAN.
Moduł CAN wykrywa poziom:
•
recesywny, gdy napięcie na linii CAN_H jest nie więcej niŜ o 0.5V wyŜsze niŜ na linii
CAN_L;
•
dominujący, gdy napięcie na linii CAN_H jest co najmniej 0.9V wyŜsze niŜ na linii CAN_L.
Nominalnym napięciem dla poziomu dominującego jest CAN_H = 3.5V oraz CAN_L =
1.5V.[3]
4
4. Struktura ramki danych.
Komunikacja w systemie CAN odbywa się poprzez wysyłanie i odbieranie komunikatów
zawierających dane lub instrukcje. Rozpoczęcie nadawania jest moŜliwe tylko w przypadku,
gdy pretendujący do tego węzeł wykryje na magistrali stan bezczynności (ang. idle). Istnieją cztery grupy
komunikatów:[1]
•
•
•
•
Ramka danych (ang. data frame)
Ramka zdalna (ang. remote frame)
Ramka błędu (ang. error frame)
Ramka przepełnienia (ang. overloaded frame)
Najczęstszym komunikatem w sieci CAN jest ramka danych. Struktura ramki w formacie
CAN 2.0A przedstawiona jest na Rysunku 6.
Rysunek 6. Ramka danych w standardzie CAN2A.
5. Organizacja komunikacji w sieci CAN.
Podstawową cechą sieci CAN, odróŜniającą ją od innych rozwiązań jest adresowanie
wiadomości jej zawartością, a nie adresatem. Identyfikator wiadomości mówi „to jest wiadomość
zawierające dane X”, a nie „to jest wiadomość dla węzła X”. RóŜnica pomiędzy tymi ideami wydaje się
subtelna, ale ma duŜe znaczenie. Wymiana informacji moŜe występować według jednego z dwóch
schematów:[3]
•
komunikacja rozgłoszeniowa (ang. Broadcast Communication);
•
Ŝądania informacji (ang. Remote Request).
Koncepcja komunikacji rozgłoszeniowej polega na tym, iŜ kaŜda stacja moŜe odebrać
wiadomość transmitowaną przez dowolny węzeł (na Rysunku 7 węzeł nr 2) i na podstawie jej
identyfikatora decyduje czy chce lub nie ją przyjąć. Mechanizm filtracji wiadomości musi być
zaimplementowany w kaŜdej stacji. Sposób ten moŜna porównać do informacji drogowych w stacji
radiowej. KaŜdy kierowca ją odbiera, ale w zaleŜności od tego z jakiej drogi ma zamiar skorzystać
decyduje czy jest ona dla niego waŜna czy nie.
5
Rysunek 7. Broadcast Communication w sieci CAN.
Druga metoda komunikacji polega na wysłaniu zapytania zwanego Remote Transmission Request
(RTR). Na Rysunku 8. węzeł nr 1 pyta (1), a odpowiedź posiada węzeł nr 2 (2). Ta sama ramka
z odpowiedzią moŜe być odebrana takŜe przez inne zainteresowane stacje (węzeł nr 3).
Rysunek 8. Komunikacja Remote Request w sieci CAN.
6. Podstawowe cechy warstwy aplikacji CANOpen.
Urządzenia na stanowisku laboratoryjnym są zgodne z protokołem CANOpen, którego niektóre
cechy zostaną bliŜej przedstawione w tym punkcie.
Object Dictionary
CANOpen jest rozwinięciem opracowanej wcześniej przez Philips Medical Systems warstwy
CAL. CAL wyróŜnia 4 róŜne funkcjonalności warstwy aplikacyjnej: CMS (ang. CAN-based Message
Specification), NMT (ang. Network ManagementT), DBT (ang. DistriBuTor), LMT (ang. Layer
ManagemenT). Wszystkie te warstwy określają jak ma być zorganizowana komunikacja, ale nie określją
jednoznacznie zawartości komunikatów. Tutaj z rozwiązaniem przychodzi CANOpen z główną
koncepcja – Device Object Dictionary (OB).
6
CANOpen Object Dictionary jest uporządkowaną grupą obiektów. KaŜdy obiekt posiada swój
16bitowy indeks, oraz dodatkowo 8-bitowy subindeks. Ogólną strukture OD przedstawia Tabela.
Tabela 1. Ogólna struktura CANOpen Object Dictionary.
Index
Object
0000
Zarezerwowany
0000 – 0001F
Static Data Types – standardowe typy danych np. Boolean, Integer16 etc.
0020 – 003F
Complex Data Types – predefiniowane struktury składające się ze standartowych
typów danych
0040 – 005F
Manufacturer Specific Complex Data Types – zakres zarezerwowany dla
specyficznych danych wykorzystywanych przez producenta
0060 – 007F
Device Profile Specific Static Data Types
0080 – 009F
Device Profile Specific Complex Data Types
00A0 – 0FFF
Zarezerwowany dla przyszłych zastosowań
1000 – 1FFF
2000 – 5FFF
6000 – 9FFF
A000 - FFFF
Communication Profile Area – np. Typ urządzenia, rejestr błędów, ilość
obsługiwanych PDO.
Manufacturer Specific Profile Area
Standardized Device Profile Area np. DSP-401 dla modułów wejść/wyjść cyfrowych
i analogowych.
Zarezerwowany dla przyszłych zastosowań
KaŜdy węzeł w sieci posiada swój własny Object Dictionary, który całościowo opisuje wszystkie
jego parametry oraz zachowanie w sieci.
Pełny opis Object Dictionary dla konkretnego typu urządzenia jest dostarczany przez producenta
i znajduje się w Electronic Data Sheet (EDS), który jest plikiem ASCII z rozszerzeniem *.eds.
Na podstawie EDS powstaje opis konkretnego, sparametryzowanego urządzenia w sieci – Device
Configuration File (DCF). DCF posiada taką samą składnie jak EDS, zdefiniowaną w specyfikacji
opracowanej przez CIA – CiA 306 DS V1.3.[2] Pliki te są uŜywane przez MenadŜery sieci CANOpen
w celu łatwej parametryzacji transmisji i urządzeń w sieci.
Mechanizmy komunikacji: PDO i SDO
W sieci wyróŜniamy dwie główne metody komunikacji: Service Data Object oraz Process Data
Object.
Service Data Object pozwalają na dostęp do Object Dictionary urządzeń sieci oraz transmisje
większej niŜ 8 bajtów ilości danych. Mechanizm transmisji z potwierdzeniem odbioru, stąd kaŜde SDO
posiada dwa róŜne identyfikatory (Rys. 9). Typowo SDO jest uŜywany do konfiguracji węzłów sieci.
7
Rysunek 9. Komunikacja z potwierdzeniami – Service Data Object.
Process Data Object, moŜe być opisany jako komunikacja typu Producent – Konsument
(Rysunek 10). Został zoptymalizowany do szybkiej transmisji danych. Jest wykorzystywany do transmisji
danych w czasie rzeczywistym (stany Wejść/Wyjść, wartości analogowych etc.). Nie wymaga
potwierdzenia odbioru, wykorzystuje wyŜsze priorytety wiadomości (COB-ID, CAN-ID).
Struktura zawartości ramki PDO musi być wcześniej zdefiniowana i znana zarówna nadawcy jak
i odbiorcy. Ilość danych w jednym PDO jest ograniczona od 1 do 8 bajtów. Przykładowo, jeden PDO
moŜe transmitować stan maksymalnie 64 wartosci I/O lub czterech 16-bitówych wartości analogowych.
Obiekty PDO, w zaleŜności od konfiguracji, mogą być transmitowane cyklicznie, na Ŝądanie
innego urządzenia lub wyzwalane przez zmianę wartości mapowanej w PDO.
Rysunek 10. Komunikacja bez potwierdzenia - Process Data Object.
Obiekty PDO, w zaleŜności od konfiguracji, mogą być transmitowane cyklicznie, na Ŝądanie
innego urządzenia lub wyzwalane przez zmianę wartości mapowanej w PDO.
Nodeguarding i Heartbeat
W sieci CANOpen istnieją dwa róŜne mechanizmy do wykrywania błędów na poziomie węzłów
sieci: Nodeguarding oraz
Heartbeat. Węzeł jednocześnie moŜe obsługiwać tylko jedną metodę.
CiA zaleca korzystanie z Heartbeat.[2]
W przypadku Nodeguarding kontroler sieci NMT Master moŜe wysłać ramkę RTR z zapytaniem
o stan do kaŜdego węzła NMT Slave. Na tej podstawie, w przypadku uszkodzenia bądź odłączenia
urządzenia od magistrali wprowadzić system w „save state” definiowany przez aplikacje (Rys. 11).[4]
8
Rysunek 7. Mechanizm Nodeguarding
Cykl Heartbeat trwa przez zdefiniowany w obiekcie 1017h jako „producer Heartbeat time” czas.
Konsument Heartbeat, najczęściej NMT-Master (na przykład CANopen manager) na podstawie
wiadomości Heartbeat ocenia czy konkretny węzeł pracuje poprawnie. W obiekcie 1016h, podobnie jak
cykl Heartbeat, konfiguruje się okres w którym Konsument powinien otrzymać co najmniej jedną
wiadomość od producenta, aby nie uznać go za uszkodzony (Rysunek 12).[2]
Rysunek 8. Mechanizm Heartbeat.
9
Literatura:
[1] Waldemar Nawrocki, „Rozproszone Systemy Pomiarowe”. Wydawnictwo Komunikacji i Łączności,
Warszawa, 2006
[2] Oficjalna strona CAN in Automation Alliance, http://www.CAN-CiA.de
[3] „CAN / CANopen / DeviceNet” http://www.softing.com/home/en/industrialautomation/products/index.php?navanchor=3010003
[4] G.Gruhler(Ed.) and Bernd Dreier, "CANopen Imprementation Guidelines", STA Reutlingen, Germany, version
2.3
[5] Andrzej Radowski, “Sieć Miejscowa Controler Area Network”,
http://www.ely.pg.gda.pl/~rkraj/can/
10