2 Opis protokołu CAN

Obecnie w automatyce i sterowaniu dostrzega się potrzebę decentralizacji elementów sterowania oraz do tworzenia specjalnych kanałów komunikacyjnych pozwalających zbierać i wysyłać określone informacje. Coraz częściej stosowane są również inteligentne czujnik wysyłające samoczynnie poprzez różne media transmisyjne komunikaty informujące procesor o stanach kontrolowanych obiektów. Tendencje te doprowadziły do opracowania wielu protokołów komunikacyjnych za pośrednictwem jednej lub wielu linii komunikacyjnych takich jak Profibus, P-Net, FIP, LON, Interbus-S (lata 80-te) które mogły by sprawnie łączyć wszystek elementy rozproszonego systemy. Ciągle istniejący jednak problem występowania zakłóceń transmisji zmusił projektantów do stworzenia niezawodnego protokołu komunikacyjnego odpornego na wszelkiego rodzaju błędy. W ten sposób opracowano CAN, którego podstawowym celem użycia jest to, aby w każdej sytuacji podzespoły systemu mogły współpracować ze sobą nawet w przypadku awarii głównego komputera. CAN (Controller Area Network) stał się zaawansowanym szeregowym protokołem komunikacyjnym który sprawnie i niezawodnie wspomaga sterowanie w czasie rzeczywistym oraz pozwala elastycznie konfigurować sieci z różnymi typami mikroprocesorów. Tworzenie komunikatów CAN i ich kontrola jest wykonywana sprzętowo co jest podstawową przewaga nad wieloma innymi tego typu protokołami wcześniej już istniejącymi.

Rozdział ten omawia idei wymiany komunikatów w protokole, jego zastosowaniu w przemyśle samochodowym i w automatyce, sposobie łączenia sterowników w sieć CAN oraz sprzętowej kontroli błędów. Przedstawione zostaną także ramki komunikatów, wraz z opisem znaczenia poszczególnych grup bitów. Szczegóły implementacji protokołu zostaną omówione w dalszej części pracy w oparciu o wykorzystany przez nas procesor 80C592 który obsługuje omawiany protokół.

2.1 Rozwój interfejsu i jego zastosowanie

Protokół CAN powstał dzięki firmie Bosh GmbH która stworzyła go głównie dla celów przemysłu samochodowego, chociaż zastosowania specjalizowanych protokołu do komunikacji w systemach samochodowych nie było przy tym specjalnym odkryciem. Obok CAN-a istniały już protokoły VAN, J1850, ABUS oraz CCD [?]. Trzeba jednak podkreślić, że żaden z nich nie zyskał takiej popularności jak CAN. Począwszy od roku 1985 efektem współpracy Bosh GmbH z firmą Intel było kilka implementacji tego protokołu w mikroprocesorach 82526 a następnie 82527. Produkcję układów rozpoczęła również firma Philips a za nią także inne [?].

Po raz pierwszy komunikację CAN wykorzystano w nowoczesnych samochodach takich jak Mercedes klasy S, BMW, Porshe, w których złożoność funkcji współbieżnego sterowania wymagała wymiany informacji pomiędzy poszczególnymi kontrolerami. Dla przykładu ASC wymaga powiązania zapłonu silnika i sterowania gaźnikiem, aby zmniejszyć moment obrotowy przy zrywaniu przyczepności co w praktyce daje doskonałe rezultaty. Gwałtowny wzrost produkcji samochodowej, oraz coraz większe unowocześnianie produktów spowodowało, że system CAN zaczęto stosować w coraz mniej ekskluzywnych modelach samochodów, a co za tym idzie tańszych. Masowa produkcja układów obsługujących protokół spowodowała spadek ich cen oraz dalsze upowszechnienie systemu w różnych gałęziach przemysłu. Wykupienie licencji na protokół przez amerykańską firmę Intel oraz fakt, że komunikacja jest przystosowana do pracy w trudnym elektrycznie otoczeniu (układ zapłonowy), sprzętowa kontrola błędów oraz możliwość generowania ramki także w sposób sprzętowy były dodatkowymi atutami.

Szczególnie wysoka odporność na zakłócenia oraz zatwierdzenie standardu CAN przez normy międzynarodowe spowodowało, że zaczął on coraz bardziej być wykorzystywany we wszelkiego rodzaju systemach automatyki. Dosyć wysoka prędkość transmisji do 1Mb/s oraz zasięg do 100 metrów sprawiły, że nadaje się on bardzo dobrze także do sterowania procesami w czasie rzeczywistym.

Obecnie zintegrowane urządzenia sterowania zbudowane są na układach takich jak 80C592, 80C167, 80C196CA. Rys 2.1 przedstawia sieć CAN w której może istnieć szereg komputerów nadrzędnych rywalizujących o dostęp do wspólnej magistrali. Każde urządzenie CAN jest podłączone za pomocą dwóch wyprowadzeń z układem dopasowania do magistrali zwanego inaczej sterownikiem linii (bus driver). Układy te zapewniają odpowiednie poziomy napięć w zależności od stosowanego napięcia zasilania. Zamieniają także różnicowy sygnał CAN_H i CAN_L na jednokierunkowe sygnały RXCAN i TXCAN oraz dodatkowo oddzielają układ sterowania od magistrali stanowiąc dodatkowe zabezpieczenie np. przed pojawieniem się na procesorze zbyt wysokiego napięcia. Dlatego też najczęściej montowane są na podstawkach w celu ich łatwiejszej i szybszej wymiany w razie uszkodzenia. Do najczęściej stosowanych układów tego typu należy produkt firmy Philips 82C250 (dokładny opis układów 82C250 i 80C592 w rozdziale 3).

Magistralę CAN stanowi para kabli przewodu skręcanego w celu dodatkowego eliminowania zakłóceń (tzw. skrętka), przy czym do łączenia sterowników można zarówno użyć przewodu ekranowanego jak i nieekranowanego. Na końcach magistrali powinny być umieszczone rezystory o wartościach 120 Ω, przy czym długość przewodów magistrali nie powinna przekroczyć 100 metrów.

Rys 2.1. Przykład sieci CAN

Komunikacja między poszczególnymi kontrolerami jest realizowana przy użyciu szyny CAN. Takie połączenia szeregowe jest polecane w przypadku luźno sprzężonego systemu, gdzie komunikacja nie zachodzi często. W tym przypadku nieelastyczne i drogie specjalne okablowanie nie jest konieczne - system może być modyfikowany w zakresie węzłów sieci bez jego zmiany. Dane pobrane z sieci mogą być odczytane przez kilka sterowników w tym samym czasie. Nie jest konieczne fizyczne adresowanie komunikatu, o tym kto odczytuje komunikat decyduje identyfikator komunikatu. Umożliwia on każdemu węzłowi sieci wykrycie komunikatu i określenie czy ten komunikat jest przeznaczony dla niego.

Cechy charakterystyczne dla protokołu CAN:

• struktura multi-master (każde urządzenie może pracować jako master i slave),

• zautomatyzowany system formowania komunikatów i sterowania komunikacją,

• możliwość podłączenia wielu urządzeń do jednej linii,

• gwarantowany czas dostępu dla komunikatów o wysokim priorytecie,

• długość pola danych w jednym komunikacie od 0 do 8 bajtów,

• duża odporność na zakłócenia i dobrze rozwinięty system obsługi błędów komunikacji,

• prędkość transmisji w zależności od aplikacji i odległości pomiędzy urządzeniami do 1 Mb/s.

Zastosowanie

Typowe aplikacje CAN można spotkać w systemach samochodowych oraz w przemyśle:

• zastosowania samochodowe:

• transmisja za pomocą rozbudowanej instalacji elektrycznej (<125 kbit/s)

• kontrola silnika, skrzyni biegów, gaźnika itp. (do 1 Mbit/s)

• automatyczny system hamowania (ang. Automatic Break System- ABS)

• automatyczny kontroler przyspieszenia (ang. Acceleration Seed Control- ASC)

• system alarmowy

• rozwiązania przemysłowe:

• sieci polowe

• robotyka, sterowanie obrabiarkami numerycznymi

• maszyny rolnicze

• sterowniki i regulatory wielopakietowe (moduł centralny + sterowniki)

aparatura medyczna

2.2 Ramki komunikatów

Ramka CAN, czyli sposób przesyłania danych w protokole, może występować w dwóch odmianach - jako ramka standardowa (standard frame) - CAN2.0A oraz jako ramka rozszerzona (extened frame) - CAN2.0B. Graficzna ilustracja obu przypadków jest przedstawiona poniżej na rysunkach ?? oraz ??. Szczegółowa specyfikacje protokołu opisują normy ISO/OSI mówiące o standardzie ISO 11519-2 (niskie prędkości) i ISO 11898 (wysokie prędkości).

Komunikaty CAN-a

Każdy komunikat CAN-a zawiera pewną liczbę bajtów podzieloną na pola o różnym przeznaczeniu. Ramki standardowa i rozszerzona posiadają ten sam schemat i różnią się oprócz bitów, które pozwalają na automatyczne rozróżnienie ramki standardowej od rozszerzonej, długością identyfikatora. Ma to oczywiście wpływ na ilość unikalnych komunikatów w danej sieci. Dla ramki standardowej jest to zaś dla ramki rozszerzonej komunikatów [?].

a)

b)

Rys. 2.2. Wygląd ramki CAN-a - a) standardowej, b)rozszerzonej

Jak już wspomniano ramki CAN są generowane sprzętowo co oznacza że po wpisaniu informacji na temat konfiguracji do odpowiednich rejestrów układu, który jest przystosowany do wymiany informacji w tym protokole, nie musimy dbać o postać czasową ramki ale na żądanie wysłania danych zostanie ona „wytworzona” przez specjalizowane układy, które oprócz dodania specjalnych bitów, przedstawionych na powyższych rysunkach dodadzą wszystkie niezbędne informacje w tym także słowo CRC. Protokół zapewnia także, że jeśli jedno z urządzeń nie odbierze poprawnie komunikatu na skutek błędu transmisji, dany komunikat będzie powtarzany aż do momentu kiedy wszystkie kontrolery podpięte do sieci otrzymają poprawną informację.

W komunikacji CAN do jednej linii może być podłączone kilka urządzeń wysyłających komunikaty o różnych i niepowtarzalnych dla każdego z nich identyfikatorach. Identyfikator ten służy jednocześnie do określenia priorytetu komunikatu. W wersji 2.0A identyfikator jest 11-bitową liczbą (2048 możliwych komunikatów) a w 2.0B 29-bitową (2²⁹ =536.870.912 możliwych komunikatów). Komunikat posiadający identyfikator o niższej wartości ma wyższy priorytet. Jeżeli dwa lub więcej urządzeń stara się uzyskać dostęp do magistrali, to uzyska go urządzenie nadające komunikat o najwyższym priorytecie. Komunikaty pojawiające się na magistrali odbierane są przez wszystkie kontrolery CAN, lecz nie wszystkie dane muszą docierać do urządzenia współpracującego z kontrolerem. Istnieje możliwość takiego zaprogramowania kontrolera CAN, by przesyłał do urządzenia komunikaty tylko o określonych identyfikatorach. Umożliwia to odciążenie urządzenia od interpretacji nieistotnych dla niego komunikatów (komunikaty nie spełniające warunków akceptacji są ignorowane przez kontroler CAN).

Ramki wersji 2.0A i 2.0B różnią się nieco od siebie chociaż zawierają podobne informacje. Sekwencje bitów są podzielone na grupy, w celu wyodrębnienia poszczególnych faz przesyłania protokołu. Znaczenia poszczególnych bitów komunikatu opisane są poniżej:

• Bit Startu - 1 bit - dominujący
  Zaznacza początek informacji. Po czasie jałowym (idle time) opadające zbocze bitu startu jest używane do synchronizacji węzłów sieci.

• Identyfikator - 11 bitów
  Logiczny adres i priorytet komunikatu; niższy komunikat ma wyższy priorytet (0 - najwyższy priorytet)

• RTR bit - 1 bit
  Bit RTR (Remote Transmission Request) w stanie wysokim informuje, że bieżący komunikat jest komunikatem żądania danych (Remote Frame). Ramka takiego komunikatu nie zawiera danych nawet jeśli kod długości danych mówi co innego. Żądanie danych i możliwa odpowiedź to dwa odrębne komunikaty. W ten sposób odpowiedź może być opóźniona o komunikat o wyższym priorytecie

• Pole Sterujące - 6 bitów
  Pierwszy bit jest bitem IDE (Identifier Extension). Jeśli jest on wysyłany jako logiczne 0 to znaczy, że nie będzie więcej bitów identyfikatora (ramka CAN 2.0A). Bit r0 jest zarezerwowany dla przyszłych rozszerzeń protokołu. Następne 4 bity zawierają kod długości pola danych DLC

• Pole danych - 0 do 64 bitów (0 do 8 bajtów)
  Zawiera przesyłane dane. Długość tego pola nie może przekroczyć 8 bajtów

• Pole CRC (Cycling Reduntancy Code) - 16 bitów (włączając CRC Delimiter - recesywny)
  Zawiera sumę kontrolną dla poprzednik bitów komunikatu. Suma kontrolna jest używana tylko do detekcji błędów, a nie jest używana do poprawy błędów. Możliwe jest wykrycie do 6 błędnych bitów komunikatu.

• Pole ACK - 2 bity (włączając ACK Delimiter - recesywny)
  Każdy aktywny węzeł sieci, który odkryje poprawną wiadomość nadpisuje poziom recesywny(ustawiony przez nadawcę) poziomem dominującym. Ten bit jest czytany także przez nadawcę. Jeśli stwierdzi on brak poziomu dominującego generuje błąd braku potwierdzenia. Jeśli nadawca wykryje potwierdzenie odebrania komunikatu nie może być pewny, że komunikat został odebrany przez odpowiednią aplikacje. Może być jedynie pewien, że wiadomość została poprawnie przesłana

• Pole EOF (End Of Frame) - 7 bitów - recesywny
  EOF zaznacza koniec ramki CAN-a. Metoda synchronizacji Bit Stuffing jest naruszona kiedy EOF jest aktywne.

• IFS (Inter Frame Space) - 7 bitów - recesywny

IFS zaznacza długość czasu potrzebną sterownikowi CAN-a na przesłanie poprawnie otrzymanej ramki z bushandler do odpowiedniego miejsca w buforze komunikatów

• Idle >=0bit - wysoki (recesywny)

Magistrala nie jest używana. Każdy węzeł może zacząć nadawać komunikat

Komunikaty rozszerzonego CAN-a różnią się od zwykłych wiadomości na następujących pozycjach:

• SRR (Substitute Remote Request Bit) - 1 bit - wysoki (recesywny)

SRR zastępuje bit RTR w standardowym komunikacie CAN-a.

• IDE - 1 bit - wysoki (recesywny)

W komunikacie rozszerzonego CAN-a bit IDE jest ustawiony na 1i wskazuje, że następują dalsze bity identyfikatora

• Pole sterujące (Control Field) - 6 bitów

Pierwsze dwa bity w tym polu są zarezerwowane. Reszta tego pola i dalsza część komunikatu jest identyczna jak w CAN 2.0A

Możliwe jest używanie komunikatów CAN 2.0A i 2.0B w jednaj sieci, gdyż sterowniki CAN-a zgodne z wersją CAN 2.0B mogą pracować jednocześnie z ramkami standartowymi.

Obok opisanej ramki komunikatu (data frame) , protokół CAN przewiduje również wysyłanie następujących komunikatów:

• wykrycie błędu transmisji (error frame) - jak już wspomniano komunikat ten jest wysyłany automatycznie przez kontroler CAN w przypadku wykrycia błędu. Składa się on z sześciobitowego pola znaczników błędów oraz sześciu bitów znacznika komunikatu błędu. W przypadku, gdy błąd jest sygnalizowany w trakcie transmisji komunikatu danych bądź RTR, transmisja zostaje przerwana i komunikat musi zostać nadany ponownie. (Dokładny opis mechanizmu generacji błędów przedstawiony będzie w dalszej części pracy.)

• przepełnienie łącza (overload frame) - komunikat ten jest generowany gdy odbiornik potrzebuje więcej czasu na odebranie strumienia danych z kontrolera lub gdy kontroler wykryje na magistrali znacznik początku komunikatu w przerwie pomiędzy komunikatami (minimum 3 bity). Komunikat przepełnienia łączy jest bardzo podobny do komunikatu błędu i składa się ze znacznika przepełnienia (6 bitów w stanie dominującym) i sześciobitowego znacznika końca komunikatu,

• żądanie nadesłania danych o określonym identyfikatorze (remote frame) - komunikat ten oparty jest na ramce transmisji danych i różni się od niej brakiem pola danych oraz ustawionym bitem RTR w polu arbitrażu. Komunikat żądania danych może być wykorzystany do inicjowania transmisji w sieci CAN. Ustawiając odpowiedni identyfikator można żądać od innych urządzeń nadesłania potrzebnych danych.

Kodowanie ramki

Segmenty ramki - Bit startu, Pole arbitrażu, Pole Sterujące i sekwencja CRC są kodowane metodą bit stuffing. Kiedykolwiek nadawca wykryje pięć kolejnych bitów o identycznej wartości w nadawanym strumieniu bitów, automatycznie wstawia przeciwny bit do aktualnie wysyłanego. Pozostałe bity ramki danych (CRC delimiter, pole ACK i EOF) maja ustaloną formę i nie są kodowane bit shuffing-iem. Strumień bitów jest kodowany metodą NRZ (Not-Return-to-Zero).

Arbitraż

Cechą charakterystyczną protokołu CAN jest fakt, że nie występuje tutaj numer urządzenia dla którego jest wysyłany komunikat, ale w zamian tego jest wysyłany identyfikator. Dzięki takiemu rozwiązaniu kilka sterowników może odebrać dany komunikat i odpowiednio na niego zareagować. W innych przypadkach należałoby wysłać kilka komunikatów do właściwych urządzeń zmieniając tylko numer kolejnego urządzenia. Dzięki omawianemu zastąpieniu można tak skonfigurować komunikaty, aby identyfikator oznaczał nie numer sterownika ale pewne polecenie. Odbieranie komunikatu polega na sprawdzeniu, czy transmitowany w danym momencie przez dowolne urządzenie podłączone do sieci identyfikator, „zgadza się” z identyfikatorem urządzenia odbierającego (nie oznacza to że identyfikatory te muszą być takie same, gdyż pewne bity mogą być ignorowane poprzez tzw. maskowanie).

Mechanizm dostępu do magistrali w CAN-ie jest zaimplementowany jako nie destruktywny tzn. zwycięzca arbitrażu nie musi rozpoczynać nadawania komunikatu ponownie od początku. Dla uzyskania tej właściwości konieczne jest zdefiniowanie w protokole CAN stanu dominującego (logiczne `0') i recesywnego (logiczna `1'). Bit dominujący nadpisuje bit recesywny tzn. jeśli jednocześnie z dwóch urządzeń zostaną podane na magistralę bity w stanie dominującym i recesywnym to wynikiem będzie bit w stanie dominującym (`0' wypycha `1').

Technika dostępu do szyny multi-master umożliwia automatyczny wybór komunikatu o najwyższym priorytecie (im mniejsza wartość komunikatu tym priorytet jest wyższy). Każde urządzenie monitoruje stan magistrali i zaczyna wysyłać komunikat tylko wtedy gdy magistrala jest wolna. Gdy to nastąpi może się zdarzyć, że dwa lub więcej urządzeń rozpocznie jednocześnie nadawanie, rozpoczynając od dominującego bitu startu. Jeżeli kontroler wykryje, że oprócz niego nadaje inny kontroler, którego komunikat posiada wyższy priorytet, wtedy przerywa nadawanie i czeka do zakończenia transmisji na magistrali. Po zakończeniu transmisji próbuje ponownie nadać komunikat.

Arbitraż pomiędzy komunikatami odbywa się na etapie nadawania identyfikatora komunikatu. Kontroler monitoruje stan na magistrali w trakcie nadawania identyfikatora (każdy jego bit). Jeżeli wykryje, że nadawał bit recesywny, a na magistrali pojawił się bit dominujący, to ustawia wyjście w stan recesywny, by nie zakłócać transmisji komunikatu o wyższym priorytecie.

Na rys. 2.3 został przedstawiony przypadek, gdy jednocześnie rozpoczęły nadawanie trzy kontrolery. Wszystkie komunikaty rozpoczęły się bitem dominującym znacznika początku komunikatu (SOF),a następnie wszystkie rozpoczęły jednakowo od bitu recesywnego na 10 polu identyfikatora (ID.10). Kontroler 1, w trakcie nadawania bitu recesywnego w polu ID.9 identyfikatora komunikatu, wykrył że na magistrali pojawił się bit dominujący i kontroler 1 przerwał nadawanie ustawiając wyjście w stan recesywny. Dalsze nadawanie identyfikatora kontynuują kontrolery 2 i 3. Podobną kolizję przy nadawaniu bitu ID.5 identyfikatora wykrył kontroler 3 i również przerwał nadawanie komunikatu. Jedynie kontroler 2 dokończył nadawanie identyfikatora i całego komunikatu. Kontrolery 1 i 3 były zmuszone do nadania swoich komunikatów ponownie w późniejszym czasie. Jak widać, arbitraż pomiędzy komunikatami w protokole CAN nie powoduje utraty danych ani przerwania komunikacji w przypadku kolizji.

Rys. 2.3. Arbitraż

Jak już zaznaczono wcześniej dostęp do magistrali odbywa się na zasadzie rywalizacji. W przypadku, gdy kilka urządzeń zaczyna nadawać jednocześnie sygnał początku ramki (SOF) to pierwszeństwo dostępu uzyskuje urządzenie o mniejszym identyfikatorze, ma więc ono większy priorytet. Problem ten został rozwiązany w banalny sposób na drodze sprzętowej jak to przedstawia rys. 2.4.

Rys. 2.4. Dostępu sterowników CAN do magistrali

Sygnał CAN_H będzie miał poziom wysoki tylko w przypadku gdy wszystkie sygnały na bazach tranzystorów CAN1, CAN2 i CAN3 (związane z wartością identyfikatora komunikatu) będą nieaktywne. Pojedynczy sygnał na którymkolwiek z nich wymusza niski poziom na magistrali CAN poprzez zwieranie CAN_H do masy.

2.3. Kontrola błędów

Kontroler CAN-a ma kilka mechanizmów detekcji błędów, łącznie z cykliczną kontrolą nadmiarową (CRC), oraz specjalnymi algorytmami dodatkowego kodowania bitów. Kontroler generuje kod CRC dla transmitowanych komunikatów oraz sprawdza CRC dla komunikatów przychodzących. Dodatkowo po pięciu takich samych bitach po stronie nadajnika dodawany jest dodatkowy bit o wartości przeciwnej niż poprzedzające go. Operacja taka (dopełnianie bitami bit stuffing [?]) zapewnia właściwą synchronizację czasową. Wszystkie pola ramki podlegają dopełnianiu za wyjątkiem bitu synchronizacji, CRC, pola potwierdzenia, oraz pola końca ramki. W odbiorniku bity te są automatycznie usuwane.

Odbiorniki odbierające uszkodzone komunikaty podczas transmisji ogłaszają to w ten sposób, że wysyłają komunikat ACK=0 poprzez magistralę CAN, zaś nadajniki odbierają je i automatycznie powtarzają komunikat w którym wykryto błąd. Retransmisja wadliwie otrzymanego komunikatu jest gwarantowana w czasie odpowiadającym przesyłaniu 23-31 bitów od momentu wykrycia błędów.

Jedną z głównych właściwości CAN-a jest to, że wiele błędów powinno być wykrywane i manipulowane przez chip CAN-a. Każdy błąd wykryty przez węzeł sieci będzie natychmiast odnotowany przez resztę sieci. Po komunikacie błędu wszystkie węzły sieci usuwają otrzymane bity. Nadawca, poinformowany o błędzie komunikatu powtarza nadawanie komunikatu kiedy szyna jest znowu wolna. Wszystko to jest kontrolowane przez sterownik CAN-a i nie jest częścią warstwy aplikacji.

Zawiadomienie o wykrytym błędzie jest osiągnięte przez ramkę błędu, która jest kodowana metodą coding violation (prawo bit stuffing nie jest stosowane). Struktura ramki błędu jest pokazana na rys. 2.5.

a)

b)

Rys. 2.5. Ramki błędów a)aktywna b)pasywna

Sekwencja 6 lub więcej dominujących bitów będzie nadpisana na aktualne bity nadawanego komunikatu. Te sześć kolejnych dominujących bitów będzie odebrane przez każdy węzeł sieci i będzie wykryte naruszenie stuff bit. Przy ciągłym lokalnym zakłóceniu sieci, ramka błędu będzie powtarzana przez cały czas. Dla zabezpieczenia przed takim zjawiskiem węzły sieci są odłączane od aktywności krok po kroku. Algorytm ten umożliwia pracę pozostałych węzłów, gdyż uszkodzony węzeł po pewnym czasie wysyła pasywne ramki błędu. Proces błędu podzielony jest na trzy etapy: wykrycia błędu, obsługa błędu i ograniczenia błędu.

Układy CAN wykrywa następujące typy błędów:

• błąd bitowy - poziom na magistrali jest inny od nadawanego przez kontroler,

• błąd dopełniania bitami- więcej niż 5 kolejno odebranych bitów ma te samą wartość. Wykorzystywana jest tzw. metoda synchronizacji zboczy sygnałów bit stuffing polegająca na tym, że po nadaniu 5 bitów o tej samej polaryzacji nadajnik wysyła jeden bit o polaryzacji przeciwnej, który jest następnie automatycznie usuwany z komunikatu przez odbiornik,

• błąd ramki - nie występuje określona wymogami protokołu struktura ramki (np. brak jakiegoś pola ramki komunikatu),

• błąd rozpoznania komunikatu (ACK) - żaden z pozostałych węzłów (kontrolerów) nie potwierdza przyjęcia komunikatu,

• błąd CRC - wysłana wartość sumy kontrolnej CRC nie zgadza się z wartością obliczoną w odbiorniku.

Do rozpoznawania i kontroli błędów przez program służą specjalne rejestry, w których można sprawdzić status ostatnio wysłanego komunikatu oraz dodatkowo odczytać co jest przyczyną błędu. Umieszczane są także liczniki w których zapisywana jest liczba prób wysłania danego komunikatu.

Po wykryciu jednego z błędów, natychmiast jest nadawana ramka błędu. Zawiera ona dwa różne pola. Pierwsze pole jest tworzone przez superpozycję flag błędu dostarczonych przez różne węzły, a drugie jest delimiterem błędu. Węzeł wykrywający błąd sygnalizuje to poprzez nadanie aktywnej ramki błędu. Forma ramki błędu narusza prawo bit stuffing.-u lub niszczy pole bitu wymagające ustalonej formy. W konsekwencji wszystkie inne węzły sieci także wykrywają warunki błędu i podobnie zaczynają nadawać flagi błędu. Więc sekwencja dominujących bitów jest wynikiem superpozycji różnych flag błędów nadawanych przez poszczególne węzły. Całkowita długość sekwencji wynosi od 6 do 12 bitów.

Pasywne flagi błędu są inicjowane przez nadawcę z powodu błędów u odbiorców, kiedy zaczynają się one w polu ramki kodowanym metodą bit stuufing, ponieważ one następnie prowadzą do błędów stuff wykrywanych przez odbiorców. To wymaga jednak, że taka flaga błędu nie rozpoczęła się podczas arbitrażu lub kilka bitów przed końcem CRC (ostatnie bity CRC mogą być wszystkie recesywne) ?????

Delimiter błędu zawiera 8 recesywnych bitów. Po nadaniu flagi błędu każdy węzeł nadaje bit recesywny i sprawdza stan szyny dopóki nie wykryje bitu recesywnego. Następnie zaczyna nadawać dalszych 7 recesywnych bitów. Obsługa błędu odbywa się w następującym porządku:

1. Wykrycie błędu

2. Nadanie ramki błędu.

3. Komunikat zostaje odrzucony przez wszystkie węzły

4. Licznik błędów każdego węzła zostaje zwiększony

5. Nadawana wiadomość zostaje powtórzona

Ograniczenia zakłóceń sieci ramkami błędów

Dla zabezpieczenia przed ciągłym zakłócaniem sieci, przez ramki błędu spowodowane przez lokalne zakłócenie jednego lub grupy węzłów sieci zaimplementowany jest specjalny algorytm do ograniczania skutków tego rodzaju błędu. Każdy sterownik CAN-a ma trzy stany błędu:

1. Błąd aktywny - węzeł w tym stanie bierze normalnie udział w komunikacji i wysyła aktywne flagi błędu po jego wykryciu.

2. Błąd pasywny - Węzeł w tym stanie może normalnie brać udział w komunikacji w sieci i wysyła pasywną flagę błędu, kiedy błąd zostaje wykryty. Po zakończeniu nadawania węzeł taki czeka dodatkowy czas zanim zainicjuje ponowne nadawanie.

3. Szyna wyłączona - jest to stan kiedy węzeł jest odłączony od szyny.

Sterownik CAN automatycznie dokonuje zmiany stanu błędu aktywnego na pasywny (lub na odwrót). Stan trzeci (szyna wyłączona) może być opuszczony tylko za zgoda użytkownika (reset sprzętowy lub programowy). Rysunek ???? przedstawia diagram stanów kontrolera.

Rys. 2.5. Stany błędów kontrolera CAN

O tym w jakim stanie znajdzie się kontroler CAN decyduje liczniki błędów nadawczych (TEC - Transmit Error Counter) oraz licznik błędów odbiorczych (REC - Receive Error Counter). Stany błędów są definiowane przez następujące warunki:

• Błąd aktywny - wartości REC i TEC ≤ 127

• Błąd pasywny - wartość jednego z liczników musi przekroczyć 127 oraz TEC ≤ 255

• Szyna odłączona - TEC > 255

Licznik błędów modyfikowane są zgodnie z następującymi zasadami (podczas transmisji może być stosowana więcej niż jedna zasada):

1. kiedy odbiornik wykryje błąd, licznik REC zwiększa swoja zawartość (wykrycie błędu bitu podczas transmisji aktywnej flagi błędu AEF nie powoduje zwiększenia stanu licznika REC)

2. licznik REC jest zwiększany o osiem (REC=REC+8) gdy odbiornik wykryje pierwszy dominujący bit po wysłaniu flagi błędu

3. kiedy nadajnik wysyła flagę błędu, zwiększany jest licznik błędu nadajnika (TEC = TEC+8).

4. Zwiększenie licznika błędów nadajnika (TEC=TEC+8), gdy nadajnik wykryje błąd bitu podczas wysyłania aktywnej ramki błędu lub flagi przepełnienia.

5. Zwiększenie licznika błędów odbiornika (REC=REC+8), gdy odbiornik wykryje błąd bitu podczas wysyłania aktywnej ramki błędu lub flagi przepełnienia.

6. Każdy węzeł toleruje 7 kolejnych dominujących bitów po nadaniu aktywnej/pasywnej ramki błędu (AEF / PEF) lub flagi przepełnienia (OVF). Po wykryciu 14-go kolejnego bitu dominującego dla AFE i OVF lub po ośmiu dla PEF, nadajnik zwiększa swoja zawartość o osiem (TEC=TEC+8).

7. Po pomyślnym wysłaniu ramki licznik błędów nadajnika zostaje zmniejszony o jeden

8. Po pomyślnym odbiorze ramki licznik błędów odbiornika zostaje zmniejszony o jeden

W poniższych okolicznościach będzie stosowana więcej niż jedna zasada:

Kiedy węzeł A sieci odbierając komunikat wykryje błąd z powodu lokalnego zakłócenia, wysyła flagę błędu. Pozostałe węzły odbierając ramkę od węzła A, wykryją błąd na szóstym bicie flagi błędu (błąd bitu stuff) i natychmiast wyślą swoje flagi błędu. Wykrycie dominujących bitów na końcu wysyłanej flagi przez węzeł A powoduje zwiększenie licznika REC o 9 - wynika to z zasady a) (REC=REC+1) oraz z b) (REC=REC+8). Reszta węzłów sieci zwiększa licznik nadajnika tylko o jeden (nie wykryją one dominującego bitu po swojej fladze błędu). W rezultacie węzeł A osiągnie stan błędu pasywnego jako pierwszy w sieci.

Kiedy któryś z liczników osiągnie wartość 96 (przed osiągnięciem stanu błędu pasywnego), zostaje ustawiony specjalny bit statusu błędu (Error Status) w rejestrze statusowym kontrolera CAN. Kiedy TEC przekroczy limit 255, zostanie ustawiony bit statusu szyny (Bus Status). Normalnie bity statusu błędu i status szyny są tylko informacja o błędach, która jest pokazywana aplikacji. aplikacji.

2.4. Synchronizacja transmisji

Jak wspomniano wcześniej są dwa typy ramek: standardowa i rozszerzona w których liczba bajtów danych może być od 0 do 8. Z tego powodu szybkość transmisji danych (data rate) i czasy opóźnienia zależą od typu ramki i od długości danych. Maksymalny czas opóźnienia komunikatu w normalnych warunkach pracy może być obliczony jedynie dla komunikatu o największym priorytecie i zależy on od czasu trwania komunikatu o największej długości oraz od opóźnienia transmisji (transmission rate). Czasy opóźnienia dla innych komunikatów nie mogą być wyznaczone z powodu mechanizmu dostępu do szyny CAN. Czasy opóźnienia mogą być określone w sposób statystyczny za pomocą odpowiednich symulatorów, analizatorów i emulatorów. W sieci CAN 2.0A czas ten jest obliczany następująco:

1 bit startu + 11 bitów identyfikatora + 1 bit RTR + 6 bitów kontrolnych + 64 bity danych + 15 bitów CRC + 19 (maksymalnie) bitów dodatkowych + 1 bit CRC delimiter +1 bit ACK slot +1 bit ACK delimiter + 7 bitów końca komunikatu EOF + 3 bity IFS = 130 bitów

Maksymalny czas opóźnienia to czas trwania 130 bitów (tj. 130 μs z maksymalna prędkością transmisji 1Mbit/s).

W sieci CAN z rozszerzonymi komunikatami czas opóźnienia obliczany jest następująco:

1 bit startu + 11 bitów identyfikatora + 1 bit SRR + 1 bit IDE + 18 bitów identyfikatora + 1 bit RTR + 6 bitów kontrolnych + 64 bity danych + 15 bitów CRC + 23 (maksymalnie) bity dodatkowe + 1 bit CRC delimiter + 1 bit ACK slot +1 bit ACK delimiter + 7 bitów końca komunikatu EOF + 3 bity IFS = 154 bitów

W rezultacie maksymalny czas opóźnienia komunikatu o najwyższym priorytecie wynosi 154 μs dla prędkości transmisji 1Mbit/s.

DATA RATE określa stosunek bitów danych do całkowitej liczby bitów komunikatu i zależy od typu komunikatu, długości i prędkości transmisji. Poniższa tabela przedstawia wartości DATA RATE dla różnych długości pola danych przy prędkości 1 Mbit/s:

Tab. 2.1. Szybkość transmisji

Długość danych	szybkość transmisji danych - standartowy CAN	szybkość transmisji danych - rozszerzony CAN
0	-	-
1	72.1 kbit/s	61.1 kbit/s
2	144.1 kbit/s	122.1 kbit/s
3	216.2 kbit/s	183.2 kbit/s
4	288.3 kbit/s	244.3 kbit/s
5	360.4 kbit/s	305.3 kbit/s
6	432.4 kbit/s	366.4 kbit/s
7	504.5 kbit/s	427.5 kbit/s
8	576.6 kbit/s	488.5 kbit/s

Czas trwania bitu i synchronizacja

Każdy węzeł sieci CAN taktowany jest przez indywidualny oscylator co stwarza możliwość pojawienia się przesunięcia fazy w różnych modułach. Kontroler CAN wspiera specjalny algorytm synchronizacyjny dla kompensacji przesunięcia fazowego podczas odbierania ramki CAN. Dla zapewnienia właściwe funkcjonowania sieć należy również zadbać o odpowiednie próbkowanie bitów wchodzących w skład komunikatu oraz dobranie odpowiedniej prędkości transmisji. Wszystkie parametry transmisji mogą być programowane indywidualnie a wykonywane są przez logikę Bit Timing (BTL). Zgodnie ze specyfikacją CAN czas trwania bitu można podzielić na trzy segmenty (rys. 2.6. : segment InSync, Time Segment1 (TSEG1) i Time Segment 2 (TSEG2). Segmenty są złożone z określonej (programowalnej) liczby cykli BTL wyznaczonych na podstawie częstotliwości kwarcu i układu skalującego (Baud Rate Prescaler).

Punkt próbkowania jest położony między TSEG1 a TSEG2. Programowalna część segmentu czasowego (Synchronisation Jump Width - SJW) jest używana do resynchronizacji. Dzięki SJW bit może skracany lub wydłużany w celu kompensacji przesunięcia fazowego podczas odbierania ramki komunikatu. Programowalne wartości dla segmentów czasowych są następujące:

Segment czasu	Zakres programowania	Tab 2.2. Programowanie czasu trwania bitu
InSync	1 cykl BTL
SJW1	1 - 4 cyklów BTL
TSEG1	1 - 16 cykli BTL
TSEG2	1 - 8 cykli BTL
SJW2	1- 4 cykle BTL

Czas trwania bitu jest określony przez oscylator kwarcowy (t_Xosc), układ BRP i licznik cykli BTL (suma TSEG1 i TSEG2):

Czas trwania bitu = t_InSync + t_TSEG1 + t_TSEG2

t_InSync = 1 t_BTL

t_TSEG1 = (TSEG1 +1) t_BTL

t_TSEG2 = (TSEG2 +1) t_BTL

t_BTL = (BPR + 1) 2 t_XOSC

TSEG1, TSEG2 i BRP są wartościami programowalnymi, ustawialnymi na odpowiednich rejestrów Bus Timing BTR0, BTR1 (opis rejestrów w rozdziale piątym). Nadawca zawsze będzie wysyłał ramkę CAN z zaprogramowanymi wartościami TSEG1 i TSEG2

Protokół CAN wspiera dwa typy synchronizacji:

• synchronizacja „twarda” - jest osiągana z opadającym zboczem na magistrali dopóki magistrala jest pusta. Pojawienie się na magistrali początku komunikatu restartuje wewnętrzną logikę Bit Timing.

• „miękka” synchronizacja - jest używana do skrócenia lub wydłużenia czasu bitu dopóki jest odbierana ramka CAN.

Pojawienie się zbocza przewidywane jest w czasie trwania cyklu InSync . Jeżeli tak nastąpi, odbiorca generuje segment TSEG1 i próbkuje bit w końcu tego segmentu. Następnie rozpoczyna się segment TSEG2 i po jego zakończeniu ponownie odbiorca oczekuje na następny bit informacji. Jeżeli jednak czas trwania bitu nadawcy jest dłuższy niż czas bitu odbiorcy (nadawca posiada niższą prędkości transmisji), to zbocze zostanie wykryte dopiero w obszarze segmentu SJW1. Wtedy SJW1 zostanie wygenerowany ponownie co wpłynie na wydłużenie rzeczywistej długości trwania bitu odbiornika. Taka sytuacja dotyczy jedynie pierwszego tak przychodzącego bitu - kolejne będą próbkowane z nominalnym czasem bitu zaprogramowanym w danym odbiorniku CAN a następna resynchronizacja wystąpi dopiero przy ponownym pojawieniu się zbocza. Opisaną powyżej sytuację ilustruje rysunek 2.6.

Rys. 2.6. Czas trwania bitu

W przypadku gdy nadawca ma większa prędkość przesyłu (czas trwania bitu nadawcy jest krótszy od oczekiwanego przez odbiorcę), zbocze następnego bitu wykryte będzie w segmencie SJW2. SJW2 zostanie zatrzymany i kontroler CAN zacznie generować dla następnych bitów nominalne segmenty Bit Timing. Defakto czas trwania pierwszego odebranego bitu zostanie skrócony. Tak jak i poprzednio ponowna resynchronizacja nastąpi dopiero przy wykryciu kolejnego zbocza.

Minimalna i maksymalna prędkość transmisji, która może być odebrana i zsynchronizowana przez odbiornik zależy od stosunku długości segmentów synchronizacyjnych do długości czasu trwania bitu, oraz od możliwej liczby bitów bez zboczy dla resynchronizacji. Dzięki możliwości dostrajania wszystkich wspomnianych elementów logik Bit Timing (możliwość programowania czasu trwania poszczególnych segmentów), możemy umieścić punkt próbkowania na właściwej pozycji wewnątrz bitu w zależności od jakości sygnałów na magistrali. Tak więc oscylacje czasowe pomiędzy różnymi węzłami sieci mogą być wyeliminowane przez użycie mechanizmu synchronizacji dopasowującego kontroler CAN do poprawnej pracy w różnych sieciach.

Stanowisko Laboratoryjne

Opis Protokołu CAN

pozostałe

18 bitów

identyfikatora

(EXIDE2)

A

C

K

2 bity

pierwsze

11 bitów

identyfikatora

(EXIDE1)

I

D

E

1 bit

S

R

R

1 bit

Koniec

ramki

r

1

1 bit

E

O

F

7 bitów

Pole

potwierdzenia

Pole CRC

Pole danych

Pole sterujące

Pole arbitrażu

15-to bitowe

słowo CRC

0-8 bajtów

danych

(Data)

DLC

4 bity

r

0

1 bit

R

T

R

1 bit

S

O

F

1 bit

magistrala

kontroler 1

kontroler 2

kontroler 3

1 rezygnuje

3 rezygnuje

recesywny

dominujący

SOF ID10 ID9 ID8 ID7 ID6 ID5 ID4 ID3

8-bitów aktywnych

flaga błędu od

węzła X

0-6 bitów aktywnych

flaga błędu od

węzła Y

8-bitów pasywnych

flaga błędu od

węzła X

0-6 bitów aktywnych

flaga błędu od

węzła Y

8-bitów oznaczających

koniec ramki błędu

8-bitów oznaczających

koniec ramki błędu

Błąd

Pasywny

Odłączenie

od

magistrali

Błąd

Aktywny

stan normalnej pracy

REC<=127

TEC<=127

REC>127 lub TEC>127

TEC<= 255

powrót do

normalnej pracy

TEC>255

CAN_L

R1

R2

R3

Ucc

CAN1

CAN3

CAN2

CAN_H

Punkt próbkowania

Wydłużony czas trwania bitu

Sygnał wejściowy

Nominalny czas

Ponowny SJW1

Magistrala CAN

FIZYCZNY

INTERFEJS

P8xC592

INTERFEJS

APLIKACJI

SJW2

SJW1

TSEG2

TSEG1

InSync

FIZYCZNY

INTERFEJS

PCA 82C200

P8xC552

INTERFEJS

APLIKACJI

FIZYCZNY

INTERFEJS

KONTROLER

MAGISTRALI

CPU

INTERFEJS

APLIKACJI

A

C

K

2 bity

E

O

F

7 bitów

Koniec

ramki

Pole

potwierdzenia

Pole CRC

Pole danych

Pole sterujące

Pole arbitrażu

15-to bitowe

słowo CRC

Dane

0-8 bajtów

(Data)

DLC

4 bity

r

0

1 bit

I

D

E

1 bit

R

T

R

1 bit

11-to bitowy

identyfikator

komunikatu

(IDE)

S

O

F

1 bit

---