Č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:
|
|
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)