CAN FD - stručný úvod

K čemu CAN FD ?

Rostoucí nároky na počet uzlů, rychlost přenosu a obrátku cyklů vedou k úzkým místům, která jsou na klasickém CANu neřešitelná, protože 1 Mbps a 8 bajtů užitečných dat. Bitrate závisí na nejdelší vzdálenosti v síti a nízký počet bajtů užitečných dat v každé zprávě je nedostatečný pro analogová a další data.

V každodenním nasazení jsou tato omezení často obcházena pomocí kompromisů: rozdělením systému do více síťových segmentů pro dílčí funkce, nebo vytvářením paralelních sítí. Tato řešení z nouze víceméně dokládají, že stávající technologie narazila na hranice svých možností, což často vede k řešením která jsou složitá a drahá ve smyslu konfigurace, zprovoznění a údržby.

V zásadě by připadalo v úvahu, přejít na výkonné technologie průmyslového ethernetu. Zásadními překážkami jsou

• vysoká počáteční investice spojená s přechodem na novou technologii
• změna datových struktur
• změna myšlení ve věcech konfigurace sítě/sběrnice
• to vše v oblasti, kde v mnoha subsystémech existují real-time nároky na latence a rychlost odezvy- změna nástrojů pro vývoj, uvádění do provozu a údržbu

Všechny tyto faktory odrazují "uživatele" (integrátory) od úplné konverze.

Dalším motivem je snaha, využít smysluplně stávající know-how.

A přesně tady má CAN FD své místo: CAN FD (CAN with Flexible Data rate), uvedený firmou Bosch v r.2012, je rozšířenou verzí důvěrně známého "klasického" CANu uvedeného firmou Bosch v roce 1986 (CAN 2.0 je z r.1991).

CAN FD výrazně zvyšuje využitelnou přenosovou rychlost a objem užitečných dat v jednotlivé zprávě. Na druhé straně zůstaly zachovány prověřené a oblíbené principy CANu: letmé řešení priority ("arbitration") podle message ID's, odesílání zpráv spouštěné událostmi a potvrzování přijetí pomocí ACK bitu.

Vylepšená rychlost přenosu

Potvrzování zpráv příjemcem (ACK), použité v klasickém CANu, přináší řadu výhod, plynoucích z principu, že se potvrzení odehraje přímo uvnitř přenášené zprávy. Případná chyba přenosu je rychle detekována a přenos lze extrémně rychle zopakovat.

Letmé rozhodnutí o prioritě nad identifikátorem zprávy ("arbitration") má pro řídící aplikace také své výhody - kouzelná je kombinace "samozřejmého" vyřešení kolizí zároveň s krátkými latencemi a priorizací pro důležité zprávy, bez ohledu na okamžitou zátěž sběrnice.

Smutnou stránkou tohoto řešení je, že v okamžiku vzorkování musí napříč celou sběrnicí platit tentýž logický stav, nemá-li docházet k chybám. Jinými slovy, časový interval odpovídající jednomu bitu musí postačit pro šíření signálu mezi dvěma navzájem nejvzdálenějšími uzly na sběrnici (včetně aktivace transceiveru). Proto délka trvání jednoho bitu a potažmo bitrate je omezen nejdelší vzdáleností v síti. Při 40 metrech je možná rychlost až 1 Mbps, na vzdálenost 250 m už jen 250 kbps.

Aby bylo možno významně zvýšit přenosovou rychlost beze změny základní technologie, CAN FD pracuje střídavě na dvou různých rychlostech:

• "Dohadovací" rychlost (arbitration rate), na které běží řídící sekvence (arbitration, typ zprávy, detekce konce a ACK) je omezená rychlostí šíření signálu a nejdelší vzdáleností v síti.
•  druhá (vyšší) rychlost se volitelně používá pro užitečná data a pro "zabezpečení" (kontrolní součet). V tomto okamžiku totiž na sběrnici zbyl už jenom jeden odesílající uzel (jenž "vyhrál rozhoz") což znamená, že okamžitá zpětná vazba uvnitř jednotlivého bitu není zapotřebí. Maximální možná rychlost je proto závislá pouze na vlastnostech přenosového média, nikoli na rychlosti šíření.

CAN FD je momentálně prakticky použitelný v ostrém provozu na rychlostech až 8 Mbps. Norma dovoluje až 15 Mbps. Tato rychlost byla také úspěšně otestována v různých ověřovacích sestavách.

Pozn.překl.: zdá se, že "vysoká" rychlost se často volí jako osminásobek "základní" rychlosti. Možná ale nejde o striktní pravidlo.

Obr.1: v tomto příkladu jsou přenášena konfigurační data o celkové délce 42 Bajtů. To by v klasickém CANu znamenalo implementovat transportní protokol, který by si zabral řekněme 1 datový bajt v každé zprávě pro řízení "streamu", tzn. 7 bajtů by zbylo pro užitečná data, tzn. přenos by vyžadoval asi 6 zpráv, pokud pomineme potřebu dalších bajtů pro další řídící funkce.

Srovnejte s jedinou zprávou CAN FD, obsahující 48 bajtů užitečných dat. Díky vyšší rychlosti přenosu je zpráva CAN FD přenesena v citelně kratším časovém intervalu, než řetízek 6 zpráv klasického CANu. Nemluvě o zjednodušení "režie" přenosu.

Zmíněné dvě bitové rychlosti se konfigurují v CAN FD řadiči navzájem nezávisle, pomocí dvou časovacích registrů. Přepínání mezi těmito dvěma rychlostmi se děje pomocí dvou řídících bitů v protokolu. První bit, dosud rezervovaný, dostal za úkol signalizovat "dlouhá data" (EDL = Extended Data Length), konkrétně jeho recesivní úroveň signalizuje zprávu CAN FD. Vlastní přepnutí rychlosti je realizováno nově přidaným bitem zvaným BRS (Bit Rate Switch). Právě v jeho "slotu", v okamžiku sejmutí vzorku, dojde k přepnutí na vyšší bitrate. Přepnutí zpět na základní rychlost se provede ve chvíli, kdy je navzorkován CRC restriction bit.

Delší užitečná data

Řídící data jsou nadále přenášena základní=nízkou rychlostí, což reálný přínos CAN FD trochu omezuje. Ale užitečná data mohou být nyní dlouhá až 64 Bajtů a lze je přenést buď základní rychlostí (zpráva je pak násobně delší v čase) nebo zvýšenou rychlostí - v tom případě může být zpráva nesoucí 64 B užitečných dat i kratší v čase, než zpráva s 8 B užitečných dat na základním baudu.

Klasický CAN podporuje nanejvýš 8 B užitečných dat v jedné zprávě, což mnoha aplikacím nedostačuje - např. při přenosu analogových vzorků ve vysokém rozlišení nebo ovládání více-osého robota s jeho různými enkodérovými hodnotami a povely pro pohon. K tomu je třeba připočíst další režijní data, což dosud citelně zhoršovalo efektivitu, pokud bylo třeba pracovat s 8 Bajty na jednu zprávu.

CAN FD nyní umožňuje přenést až 64 Bajtů užitečných dat v jedné zprávě. Takže se do jedné zprávy vejdou větší bloky dat. Zejména pokud jde o procesní data, je výhodou, že i poměrně složitá zařízení lze nyní kompletně povelovat jedinou procesní zprávou. Pokud se týče režijních dat, snížila se potřeba zavádět speciální transportní protokoly, a jediná zpráva CAN FD často stačí na konfigurační data apod.

Obrázek 2: v tomto obrázku naleznete CANové zprávy z obr.1 v řadě za sebou na časové ose. Pro klasický CAN je zde uvažována bitová rychlost 250 kbps. Pokud uvažujeme zprávy s 8 Bajty užitečných dat (1 bajt pro transportní protokol a 7 bajtů skutečně užitečných dat) a maximální možný počet "vycpávkových" bitů, pak klasická CANová zpráva vyžaduje cca 500 us času na sběrnici. Pokud bude odesílající uzel schopen odeslat všech šest zpráv těsně za sebou bez pomlk, bude sběrnice plně vytížena po dobu 3 ms. Za tu dobu přenese 42 bajtů skutečně užitečných dat.

Pro srovnání, zpráva CAN FD nesoucí 48 bajtů uživatelských dat, na základní rychlosti 250 kbps a datové rychlosti 2 Mbps, obsadí sběrnici na dobu přibližně 365 us - rovněž s maximálním počtem "vycpávkových" bitů. Tato citelně vyšší rychlost přenosu zkracuje latence a reakční doby, což se projeví lepší real-time odezvou celého systému. Vedle rychlejšího přenosu dat je vedlejším efektem také zjednodušení správy/konfigurace datového modelu.

Pozn.překl.: stuffing bits ("vycpávkové bity") jsme zde neprobírali - jedná se o způsob, jak předcházet příliš dlouhé sekvenci bitů o shodné logické úrovni. Prostě když je potřeba, vsune se bit o opačné log.úrovni, čímž se zpráva prodlouží o jeden tik hodin. Jenom další malá komplikace ve formátu rámců. Asi nemá smysl to zde podrobněji rozebírat, zájemci nechť se obrátí na primární zdroje informací.

Aby se zamezilo zbytečnému bobtnání řídících dat v CAN rámci, kóduje CAN FD délku užitečných dat nadále pouze čtyřmi bity DLC (stejně jako klasický CAN). V platnosti zůstaly přímé hodnoty 0 až 8. Dosud nevyužívané hodnoty 9 až 15 (1001 až 1111 binárně) jsou nyní použity jako kódy, zastupující "prodloužené" délky užitečných dat: 12, 16, 24, 32, 48 a 64 bajtů. Jiné délky dat mimo tento výčet nejsou možné, tzn. je třeba použít nejblíže vyšší délku a část prostoru zůstane nevyužita.

Vysoká rychlost přenosu užitečných dat, zkrácený "cyklus datové výměny", nárůst "efektivní" přenosové kapacity... S jistou mírou odvážného PR eskamotérství lze argumentovat, že CAN FD se základní rychlostí 500 kbps a datovou rychlostí 4 Mbps se efektivně chová cca jako základní CAN taktovaný 5 Mbps. Tato argumentační hříčka zjevně naráží na nepříliš dobrou efektivitu (vysoké procento režie) základního CANu ve srovnání s CAN FD.

(Pozn.překl.: originál je formulován dost jinak. Překlad je trochu více vysvětlující a odpovídá realitě.)

Real-time schopnosti

Sloučení více nezávislých datových paketů do jediného rámce znamená citelné zjednodušení správy datového přenosu, protože v optimálním případě zcela odpadne dodatečná drahá režie na udržování přehledu o pořadí a úplnosti přenosu. Vyšší "datová" rychlost CAN FD ve srovnání s klasickým CANem umožňuje přenos osminásobného objemu užitečných dat (64 Bajtů) ve zhruba stejném čase, kolik potřebuje klasický CAN pro přenos svých 8 Bajtů. Nahlíženo z druhého konce, přenést 64 Bajtů trvá na CAN FD osminu času (nebo i méně, uvažujeme-li dodatečnou režii transportu na klasickém CANu). Prioritní data mohou téci rychleji, latence jsou kratší, zlepšuje se real-time odezva.

Bezpečnost dat - odolnost proti chybám přenosu

Integrita přenosu je důležité téma. I přes větší "datovou" délku rámců oproti klasickému CANu vykazuje CAN FD shodnou míru odolnosti proti náhodně umístěným chybám. Je to díky použití delšího CRC kódu a úpravě algoritmů. V závislosti na délce přenášených užitečnýých dat se použije

jeden ze tří různých CRC algoritmů: původní CRC vzorec pro zprávy do 8 Bajtů užitečných dat, nebo dva pokročilejší algoritmy pro data do 16 bajtů resp. více než 16 Bajtů. Volba algoritmu v CANovém řadiči probíhá čistě na základě DLC (délky užitečných dat ve zpracovávané zprávě).

Jako další opatření pro lepší integritu dat byla rozšířena logika "vycpávkových bitů": CRC v rámcích CAN FD nyní vždy začíná vycpávkovým bitem, po dalších 5 bitech je vložen další vycpávkový bit. A v rozporu s "vycpávkovým pravidlem" klasického CANu je tento bit vložen vždy, nezávisle na hodnotách předchozích bitů (je pevně umístěný). Logická hodnota těchto dodatečných vycpávkových bitů je vždy opačná k bitu těsně předcházejícímu.

Zpětná kompatibilita

Obvyklou nevýhodou při přechodu od CANu na jiný komunikační systém je častý požadavek na přechod razantní a úplný. Všechny účastnické uzly musí být převedeny na nový systém, např. EtherCAT. Alternativně může být kontrolér stroje rozšířen o heterogenní podporu více různých sběrnicových technologií. Obě cesty mají své výhody a nevýhody. V případě CAN FD je k dispozici třetí "měkčí" varianta: protože řadiče CAN FD jsou použitelné i v roli uzlů klasického CANu, je možné upgrade jednotlivých uzlů na CAN FD provést postupně. Teprve v momentě, kdy všechny uzly na sběrnici umí CAN FD, lze přepnout režim na CAN FD a využít jeho výhod. Tento přístup je výhodný pro zakázkově integrované řídící systémy, kde některé uzly schopné pouze klasického CANu nejsou snadno nahraditelné modernější variantou, protože se jedná o zakázkový hardware / výsledek interního vývoje.