W komunikacji CAN nie liczy się tylko zawartość wiadomości, ale też to, jak jest ona ułożona w ramce. Od identyfikatora zależy priorytet, od pola DLC długość danych, a od CRC i ACK to, czy transmisja została uznana za poprawną. Poniżej rozkładam cały format na czynniki pierwsze, pokazuję różnice między klasycznym CAN a CAN FD i wskazuję błędy, które najczęściej psują diagnozę magistrali.
Najkrócej o strukturze wiadomości CAN
- Identyfikator nie jest adresem urządzenia, tylko etykietą i nośnikiem priorytetu.
- W klasycznym CAN dane mieszczą się w 0-8 bajtach, a w CAN FD w do 64 bajtów.
- Standardowa wersja używa 11-bitowego identyfikatora, a rozszerzona 29-bitowego.
- Bit stuffing zmienia rzeczywistą długość transmisji, więc nie wolno liczyć ramek wyłącznie „na oko”.
- ACK potwierdza odbiór na poziomie magistrali, ale nie zastępuje potwierdzenia aplikacyjnego.
- CAN FD dokłada bity, które zmieniają interpretację DLC i pozwalają szybciej przesyłać część danych.
Z czego składa się ramka CAN
Najwygodniej patrzeć na nią jak na zestaw pól, z których każde ma własną funkcję. W praktyce to właśnie układ tych pól decyduje o kolejności nadawania, długości komunikatu i o tym, czy odbiornik uzna transmisję za poprawną.
| Pole | Rola | Co warto zapamiętać |
|---|---|---|
| SOF | Początek transmisji i punkt synchronizacji | Ramka startuje od bitu dominującego, żeby wszystkie węzły „złapały rytm” |
| Arbitration | Identyfikator oraz bity rozróżniające typ ramki | Tu rozstrzyga się priorytet i to, czy mamy format standardowy, czy rozszerzony |
| Control | Informacja o formacie i długości danych | W klasycznym CAN kluczowe są IDE, bity rezerwowe i DLC |
| Data | Właściwy payload | W klasycznym CAN to 0-8 bajtów, a w FD może być ich znacznie więcej |
| CRC | Wykrywanie błędów | To nie dekoracja, tylko podstawowy mechanizm kontroli poprawności |
| ACK | Potwierdzenie odbioru | Co najmniej jeden poprawnie odbierający węzeł powinien zaznaczyć odbiór |
| EOF | Zakończenie ramki | To 7 recessive bits oznaczających koniec transmisji |
| IFS | Odstęp międzyramkowy | Krótka przerwa przed kolejnym komunikatem |
Do końca pola CRC obowiązuje bit stuffing: po pięciu kolejnych bitach tego samego poziomu nadajnik wstawia bit przeciwny. To dlatego dwie ramki o tym samym payloadzie mogą zająć na magistrali różny czas, jeśli ich przebieg bitowy układa się inaczej. Gdy ten szkielet jest jasny, łatwiej przejść do różnicy między formatem standardowym i rozszerzonym.
Standardowa i rozszerzona wersja różnią się głównie identyfikatorem
Ja zwykle zaczynam od pytania, czy 11 bitów wystarczy do jednoznacznego opisania komunikatów w danej sieci. Jeśli tak, standardowy format jest prostszy i krótszy. Jeśli nie, trzeba sięgnąć po wersję rozszerzoną z większą przestrzenią identyfikatorów.
| Cecha | Format standardowy | Format rozszerzony |
|---|---|---|
| Długość identyfikatora | 11 bitów | 29 bitów |
| Pola rozróżniające | IDE i RTR w prostszej postaci | SRR, IDE, RTR oraz dodatkowe bity w arbitrażu |
| Zastosowanie | Mniejsze, prostsze sieci | Sieci z większą liczbą komunikatów lub wymagające szerszego zakresu ID |
| Złożoność dekodowania | Mniejsza | Większa, zwłaszcza przy ręcznej analizie |
W praktyce nie chodzi o to, że jeden format jest „lepszy”. Standardowy bywa wystarczający w prostych układach i łatwiej go debugować. Rozszerzony daje więcej miejsca na identyfikatory, ale wymaga większej dyscypliny przy projektowaniu i dokumentowaniu sygnałów. To prowadzi wprost do arbitrażu, bo właśnie tam identyfikator zaczyna pracować na pełny etat.
Dlaczego identyfikator decyduje o priorytecie
CAN jest sprytny: zamiast klasycznej kolizji ma arbitraż bit po bicie. Niższa wartość identyfikatora oznacza wyższy priorytet, bo dominujące bity „przebijają” bity recessive i wygrywa ten węzeł, którego komunikat ma ważniejszy numer.
Przykład jest prosty. Jeśli dwa sterowniki zaczną nadawać jednocześnie, a jeden wysyła identyfikator 0x080, a drugi 0x100, to wygra 0x080. Dla magistrali nie ma tu chaosu ani zderzenia ramek, tylko deterministyczne ustalenie kolejności. Ja traktuję to jako jedną z najważniejszych cech CAN, bo od razu widać, że dobór ID wpływa nie tylko na opis komunikatu, ale też na zachowanie całego systemu.
- Wiadomości krytyczne czasowo powinny mieć niższy numer ID niż komunikaty mniej pilne.
- Źle ustawiony priorytet może opóźnić alarm, nawet jeśli sam protokół działa poprawnie.
- Arbitraż nie „gubi” danych. Przegrany nadawca po prostu czeka na kolejną szansę.
Jeśli w sieci kolejność priorytetów jest dobrze zaprojektowana, magistrala zachowuje się przewidywalnie nawet pod obciążeniem. Na tej zasadzie opiera się też praktyczny podział typów ramek, który w narzędziach diagnostycznych bywa źródłem nieporozumień.
Jakie typy ramek zobaczysz na magistrali
Najważniejsza jest oczywiście ramka danych, bo to ona niesie właściwy payload. Ale przy diagnozie warto rozumieć również inne typy, bo ich pojawienie się zwykle coś sygnalizuje.
- Ramka danych - przenosi właściwą informację z identyfikatorem i payloadem.
- Ramka zdalna - służy do zażądania danych o tym samym identyfikatorze; nie niesie własnego payloadu.
- Ramka błędu - pojawia się, gdy węzeł wykryje niezgodność, na przykład błąd CRC albo naruszenie reguły bit stuffing.
- Ramka przeciążenia - daje dodatkową przerwę między komunikatami, gdy kontroler potrzebuje chwili oddechu.
- Odstęp międzyramkowy - nie jest payloadem, ale ważną częścią rytmu pracy magistrali.
W nowych systemach ramki zdalne spotyka się rzadziej niż kiedyś, bo wiele projektów woli po prostu cyklicznie nadawać dane. Mimo to w starych instalacjach i w analizie zgodności nadal trzeba wiedzieć, jak je rozpoznać. Jeśli jednak system wykracza poza klasyczne 8 bajtów, wchodzi CAN FD i to on zmienia reguły gry.
Co zmienia CAN FD
CAN FD zachowuje standardowy i rozszerzony format ramki, ale dokłada dodatkowe bity sterujące i znacznie większy payload. Z praktycznego punktu widzenia najważniejsze są trzy rzeczy: interpretacja DLC, możliwość przyspieszenia części transmisji oraz inny mechanizm CRC.
| DLC | Classic CAN | CAN FD |
|---|---|---|
| 0-8 | 0-8 bajtów | 0-8 bajtów |
| 9 | nieużywane w klasycznym znaczeniu | 12 bajtów |
| 10 | nieużywane w klasycznym znaczeniu | 16 bajtów |
| 11 | nieużywane w klasycznym znaczeniu | 20 bajtów |
| 12 | nieużywane w klasycznym znaczeniu | 24 bajty |
| 13 | nieużywane w klasycznym znaczeniu | 32 bajty |
| 14 | nieużywane w klasycznym znaczeniu | 48 bajtów |
| 15 | nieużywane w klasycznym znaczeniu | 64 bajty |
W CAN FD pojawiają się też bity EDL, BRS i ESI. EDL sygnalizuje, że to ramka FD, BRS pozwala przyspieszyć część danych, a ESI pokazuje, czy węzeł działa w stanie error active, czy error passive. CRC też się zmienia: w klasycznym CAN jest 15-bitowy, a w FD używa się 17-bitowego CRC dla 0-16 bajtów i 21-bitowego dla większego payloadu.
W mieszanej sieci trzeba też pilnować zgodności kontrolerów i analizatorów, bo starszy sprzęt może nie obsłużyć ramek FD poprawnie i zamiast czytelnego logu pokaże lawinę błędów. Najwięcej błędów nie wynika z samego protokołu, tylko z jego złej interpretacji w analizatorze.
Najczęstsze błędy przy analizie ramek w praktyce
W diagnostyce CAN te same pomyłki wracają zaskakująco często. Najczęściej nie chodzi o hardware, tylko o błędny odczyt znaczenia pól.
- Mylenie identyfikatora z adresem urządzenia - identyfikator opisuje wiadomość i jej priorytet, nie „numer ECU”.
- Mylenie formatu standardowego z rozszerzonym - 11 i 29 bitów wyglądają podobnie na ekranie, ale znaczą coś innego.
- Ignorowanie bit stuffing - gdy liczysz czas transmisji ręcznie, wynik bez stuffing jest po prostu zbyt optymistyczny.
- Odczytywanie DLC w CAN FD tak jak w Classic CAN - tu najłatwiej o błędną interpretację długości payloadu.
- Zakładanie, że ACK oznacza potwierdzenie aplikacyjne - w rzeczywistości to tylko potwierdzenie na poziomie magistrali.
- Pomijanie ramek bez danych - ramka zdalna nie niesie payloadu, ale nadal jest ważna dla logiki komunikacji.
Jeżeli te pułapki masz z głowy, analiza ruchu staje się dużo szybsza. Zostaje już tylko uporządkowany checklista i spokojne sprawdzanie tego, co naprawdę wpływa na zachowanie sieci.
Co sprawdzałbym najpierw, gdy rozbieram komunikat CAN na części
Ja przy diagnozie zaczynam od prostych pytań, bo one zwykle odsłaniają problem szybciej niż długie śledzenie logu. Najpierw patrzę na format identyfikatora, potem na długość danych, a dopiero później na treść payloadu.
- Czy to format standardowy, czy rozszerzony?
- Czy identyfikator ma właściwy priorytet względem innych komunikatów w sieci?
- Czy DLC zgadza się z oczekiwaną długością danych?
- Czy na magistrali pojawiają się ramki błędu albo nietypowo częste retransmisje?
- Czy analizator pracuje w trybie zgodnym z rzeczywistym typem magistrali, zwłaszcza przy CAN FD?
Gdy rozbierasz taką ramkę na pola, szybciej widać, czy problem leży w projekcie komunikacji, konfiguracji narzędzia, czy w samym nadawaniu. W praktyce wystarcza mi wtedy sprawdzenie formatu identyfikatora, DLC, typu ramki i trybu pracy analizatora, żeby odsiać większość fałszywych tropów. Dzięki temu wiadomość CAN przestaje wyglądać jak ciąg przypadkowych bitów, a zaczyna czytelnie pokazywać, co dzieje się na magistrali.
