Přenosová kapacita CANu

Často dostáváme otazku, jaká je přenosová kapacita CAN sběrnice. Odpověď však není úplně jednoduchá a rozhodně není taková, že CAN na rychlosti 1Mbit/s přenese 1000000 / 8 = 125 000 bajtů za sekundu. V tomto článku se pokusíme problematiku alespoň částečně objasnit.

Pro vlastní výpočet je třeba zohlednit několik skutečností:

  • jsou použity 11 (standard) nebo 29 (extended) bitové identifikátory CAN zpráv
  • jsou využity všechny datové bajty zprávy
  • jaký je skutečný obsah zprávy

Začneme tím jak vypočítat bitovou délku CAN zprávy. Zde jsou obvykle používány 3 přístupy:

  • bez ohledu na bit stuffing
  • nejhorší možný případ
  • přesný výpočet

Co je to bit stuffing je? Vysílá-li se na sběrnici pět po sobě jdoucích bitu jedné úrovně, je do zprávy navíc vložen bit opačné úrovně. Toto opatření slouží jednak k detekci chyb, ale také ke správnému časovému sesynchronizování přijímačů jednotlivých uzlů. Je-li detekována chyba vládání bitu, je vygenerována chyba. Vše nejlépe vysvětluje následující obrázek (zdroj: Wikipedie):

Z obrázku je patrné, že bitstuffing se používé na nejnižší úrovni, pokud je splněna podmínka 5 stejných bitů. Tedy bez ohledu na to o jaké místo zprávy se jedná (vyjímkou je End of Frame, Interframe, ACK delimiter), nebo recesivní/dominantní úroveň těchto bitů. Je tak zřejmé, že i například CAN zpráva se stejným identifikátorem a stejným počtem datových bajtů se ve skutečnosti může na CANu lišit svou délkou podle skutečných hodnot datových bajtů.

Délka bez bitstuffingu:

Pokud budeme tedy počítat délku bez ohledu na bitstuffing, lze použít vzorce podle typu identifikátoru:

11 bitový: 47 + počet datových bajtů * 8

29 bitový: 67 + počet datových bajtů * 8

Hodnoty 47/67 jsou tak součtem polí zprávy podle následjící tabulky:

 

Base frame format - 11 b

Start-of-frame 1
Identifier (green) 11
Remote transmission request (RTR) (blue) 1
Identifier extension bit (IDE) 1
Reserved bit (r0) 1
Data length code (DLC) (yellow) 4
Data field (red) 0–64 (0-8 bytes)
CRC 15
CRC delimiter 1
ACK slot 1
ACK delimiter 1
End-of-frame (EOF) 7
Interframe 3

Extended frame format - 29 b

Start-of-frame 1
Identifier A (green) 11
Substitute remote request (SRR) 1
Identifier extension bit (IDE) 1
Identifier B (green) 18
Remote transmission request (RTR) (blue) 1
Reserved bits (r1, r0) 2
Data length code (DLC) (yellow) 4
Data field (red) 0–64 (0-8 bytes)
CRC 15
CRC delimiter 1
ACK slot 1
ACK delimiter 1
End-of-frame (EOF) 7
Interframe 3

Nejhorší možný případ:

Pro nejhorší možný příklad (tedy data, ID a ostatní části obsahují sekvence 5 a více stejných bitů), pak přibližne platí:

11 bitový: 55 + počet datových bajtů * 10

29 bitový: 80 + počet datových bajtů * 10

Přesný výpočet:

Tento výpočet musí zohledňovat hodnotu identifikátorů, dat a crc a vypočítat počet vložených (stuff) bitů. Algoritmus výpočtu jde najít například v CAN tools pro Linux zde.

A teď zpět k přenosové kapacitě, nejprve tabulka údajů pro různé zprávy vypočtená pro rychlost 1Mbit/s a 100 procentní zatížení (bus load). Tedy počet zpráv je roven 1 000 000 / bitová délka:

Typ CAN bus identifikator Počet datových bajtů Hodnota všech datových bajtů Bitová délka Počet zpráv za sekundu Počet datových bajtů za sekundu
11 0 0 - 53 18867 0
29 0 0 - 74 13513 0
11 0 4 0 89 11235 44940
29 0 4 0 112 8928 35712
11 0 8 0 127 7874 62992
29 0 8 0 150 6666 53328
11 0 8 170(AAh)* 115 8695 69560
29 0 8 170(AAh)* 137 7299 58392
11 555h * 8 170(AAh)* 112 8928 71424
29 555h+15555h * (0x15555555) 8 170(AAh)* 131 7633 61064
* Hodnota 55h nebo AAh je střídání 0 a 1, tím je zajištěno, že v tomto případě se nepoužije bit stuffing.

Co z tabulky plyne? Například pro 11 bitový identifikátor a 8 datových bajtů je rozmezí množství přenesených dat 62992 až 71424 b/s. Pro 29 bitový pak 53328-61064 b/s. Bereme li v potaz nejlepší případ 71427 bajtů, pak pro horší případy klesá přenosová kapacita takto:

Typ identifikátoru Bitstuffing Množství přenesených dat Kapacita přenosu vůči maximu
11 Žádný 71427 100%
11 Maximální 62992 88%
29 Žádný 61064 85%
29 Maximální 53328 74%

Téměř žádný vyšší protokol nepoužívá RTR zprávy. Místo toho jsou často požadovaná data přenášena v datové části (SAE1939, PGN požadovaných dat je v datové části), přitom RTR zpráva se stejným ID (nebo alespoň PGN) je mnohem efektivnější. Pokud si budete navrhovat svůj protokol, zkuste RTR zpráv využít.

Pokud vezmeme v ůvahu extrémní případ, kdy komunikační protokol používá dotaz s 29 bitovým dentifikátorem, to jaká data jsou požadována je uvedeno v datové části k čemuž je využito  4 datových bajtů a odpověď bude obsahovat 8 datových bajtů, je maximální přenosová kapacita s maximálním bitstuffingem vypočtena jako: 112 bitů dotaz + 150 bitů odpověd = 262, tedy teoreticky 3816 párů dotaz - odpověď. Při použití RTR bitu je maximum vypočteno jako 74 bitů RTR dotaz + 150 bitů odpověd = 224, tedy teoreticky 4464 párů dotaz - odpověď. Tedy přibližně o 17 procent více.

Stejně tak je otázka, zda je třeba použít 29 bitové identifikátory. Pokud nejste vázáni použitým protokolem,  je kapacita přenesených dat u 11 bitových identifikátorů o přibližně 18 procent větší.

Častou chybou je u CAN open protokolu čtení dat pomocí SDO zpráv. Tato zpráva však nese maximálně 4 datové bajty (single). Plně namapovaná PDO zpráva může obsahovat 8 bajtů, navíc její generování může node provádět automaticky (nebo na SYNC), ušetří se tak celá další zpráva na požadavek na čtení SDO.

Například pro čtení 3 SDO, kdy chceme číst celkem 8 datových bajtů z jednoho nodu (2x16 bitová hodnota, 1x32 bitová hodnota) potřeujeme 3 zprávy s žádostí o čtení SDO a zpět obdržíme 3 zprávy s odpovědí. Místo toho je možné namapovat PDO, nastavit automatické odesílání. Pak zatěžujeme CAN sběrnici 6x méně. Pro menší hodnoty dat (třeba 8 bitové) je poměr ještě menší.

Podobě je často k vidění používání  délky dat vždy nastavené na 8 datových bajtů a to bez ohledu na to, kolik bajtů je skutečně použito. Například u OBD dotazů na data, kdy jsou použity v dotazu 3-4 datové bajty, jsou odesílána i zbylé datové bajty (obvykle s hodnotou 55h).

Závěrem tak lze říci, že skutečná přenosová kapacita CAN sběrnice je dána zejména tím:

  • jaký je použit komunikační protokol a s jakou délkou identifikátoru
  • jak jsou dodržovány skutečné délky dat
  • zda jsou v maximální míře používány zprávy s 8 datovými bajty a ty jsou všechny využity
  • jak jsou efektivně využívány možnosti protokolu (např. SDO vs PDO)