|
CANopen – vyšší komunikační protokol pro vestavné sítě
CANopen je vyšší komunikační protokol vytvořený na základě sběrnice CAN (Controller Area Network). Byl vyvinut jako široce konfigurovatelný standardní protokol pro vestavné řídicí sítě pro stroje a zařízení s řízenými pohyblivými částmi, jako jsou např. manipulátory. V současné době je využíván v mnoha rozličných odvětvích v průmyslu, v lékařské technice, automobilech, námořních systémech, ve veřejné dopravě, při automatizaci ve stavebnictví atd. Článek představuje základní protokoly, služby a komunikační objekty definované v protokolu CANopen.
Specifikace CANopen
Původně byl protokol CANopen vyvíjen v rámci projektu Esprit pod záštitou firmy Bosch. V roce 1995 byla specifikace v protokolu CANopen předána organizaci CiA (CAN in Automation). To je sdružení výrobců a uživatelů sběrnice CAN. Protokol CANopen vychází z původního protokolu CAL (CAN Application Layer) a jeho specifikace CiA DS 301 verze 4.01 byla přijata jako norma EN 50325-4. Specifikace protokolu CANopen zahrnují aplikační vrstvu a komunikační profil (specifikace CiA DS 01), rámcový předpis pro programovatelná zařízení (CiA DSP 302), požadavky na propojovací vodiče a konektory (CiA DRP 303-1) a reprezentaci jednotek soustavy SI (Syst) včetně jejich předpon (CiA DRP 303-2). Fyzická vrstva sítě CANopen je realizována současně z řadičů (ISO 11898-1) a budičů (ISO 11898-2) sběrnice CAN. Tato implementace se často označuje jako vysokorychlostní (high-speed) CAN. Aplikační vrstva a komunikační profily sběrnice jsou realizovány programově.
Protokol CANopen umožňuje vývojáři vyhnout se řešení problémů specifických pro CAN, jako je např. správné časování zpráv. Dosahuje se toho zavedením standardních komunikačních objektů: PDO (Proces Data Objects) pro časově kritická (real-time) data, SDO (Service Data Objects) pro konfigurační zprávy a dalších pro speciální funkce (časování, synchronizaci a mimořádné situace) a pro síťové služby (nové spuštění zařízení, správu sítě a chybové zprávy).
Slovník objektů
Aplikační vrstva a komunikační profil (EN 50325-4) v síti CANopen podporují přímý přístup k parametrům zařízení zapojených v síti a přenos časově kritických technologických dat. Síťové služby protokolu CANopen zjednodušují návrh systému řízení a jeho integrování a diagnostiku. Každý decentralizovaný systém řízení vyžaduje odlišné komunikační služby a protokoly. Protokol CANopen je všechny definuje, a to spolu s nezbytnými komunikačními objekty obsahujícími veškeré informace o vlastnostech a funkčních schopnostech jednotlivých zařízení. Komunikační objekty jsou zařazeny v tzv. slovníku objektů (Object Dictionary) uloženém v zařízení, které je součástí sítě, a sloužícím jako rozhraní mezi samotným zařízením a aplikačním programem. Všechny komunikační objekty příslušné určitému zařízení (údaje specifické pro aplikaci a konfigurační parametry) jsou ve slovníku objektů popsány předepsaným způsobem v pevně stanoveném formátu. Každý komunikační objekt je dostupný prostřednictvím šestnáctibitového indexu, v případě objektů typu polí a záznamů (objektů složených s několika dalších objektů) doplněného osmibitovým subindexem.
Všechny komunikační objekty přítomné ve všech zařízeních v síti CANopen jsou pod týmiž indexy uloženy ve slovníku objektů. Totéž platí i pro všechny komunikační objekty tvořící tzv. standardní profil zařízení.
Slovník objektů obsahuje také rezervované indexy určené k umístění specifických informací poskytovaných jednotlivými výrobci daného typu zařízení.
Objekty pro technologická data
Komunikační objekty nesoucí technologická data (Proces Data Objects – PDO) jsou přenášeny v jedné CAN zprávě s využitím všech jejích osmi bajtů v poli dat. Každý PDO musí mít unikátní identifikátor CAN a může být vysílán pouze jediným uzlem sítě, přičemž přijat může být libovolným počtem zařízení. Jde tedy o způsob komunikace známý jako původce/spotřebitel (producer/consumer). Vyslání zprávy s PDO může být inicializováno vnitřní událostí, vnitřním časovačem, požadavky vznesenými jinými zařízeními v síti nebo přijetím synchronizační zprávy (Sync Message – SYNC) – viz obr. 1:
událost nebo časovač: zprávu generuje událost (specifikovaná v profilu zařízení) nebo je zpráva generována periodicky na základě signálu z časovače, a to i když se žádná událost nevyskytne,
požadavek zařízení: jiné zařízení v síti vyvolá vyslání asynchronní zprávy vysláním svého požadavku v podobě zprávy RTR (Remote Transmission Request),
synchronně vysílané zprávy: aby bylo možné synchronizovat vzorkování vstupních veličin ve všech uzlech sítě, je třeba generovat synchronizační zprávu, od níž se odvíjí vysílání příslušných PDO realizované v cyklickém nebo acyklickém režimu.
V cyklickém režimu vysílání PDO zařízení čeká na příchod synchronizační zprávy a poté vyšle na sběrnici jako PDO naměřené hodnoty technologických veličin (obr. 2). V acyklickém režimu je k synchronnímu vyslání PDO nutná jeho inicializace událostí definovanou v závislosti na dané aplikaci, přičemž k vlastnímu vyslání na sběrnici dojde teprve s příchodem nejbližší další synchronizační zprávy. Následné synchronizační zprávy procházejí nepovšimnuty až do okamžiku, než se vyskytne další událost.
Ve slovníku objektů je pro jednotlivé objekty typu PDO uvedeno také implicitní přiřazení tzv. aplikačních objektů (objekt spjatý s konkrétní aplikací) a podporovaný režim přenosu. Aby byla zaručena definovaná (a krátká) doba odezvy systému, musí být zprávám obsahujícím PDO přiřazeny identifikátory CAN s velkou prioritou. Přenos zpráv s PDO není potvrzován (avšak sběrnice CAN zaručuje, že žádné zařízení takovou zprávu nepřijme chybně – pozn. překl.). Slovník objektů obsahuje také tzv. PDO Mapping Object – objekt definující přiřazení aplikačních objektů do příslušných zpráv PDO. Protože jedna zpráva PDO může přenášet data z několika aplikačních objektů, je ve slovníku objektů obsažena informace o tom, jak za sebou v PDO jednotlivé aplikační objekty následují a jaká je jejich délka v bitech. Pokud zařízení podporuje proměnnou skladbu PDO, musí být schopno tuto podporu poskytnout ve svém pracovním režimu předcházejícím vlastnímu provozu zařízení (tzv. předprovozní stav). Je-li podporováno dynamické přiřazování aplikačních objektů k PDO, zodpovídá za konzistenci dat klient SDO (viz dále).
Objekty pro servisní data
Objekty nesoucí servisní data (Service Data Object – SDO) neboli servisní objekty (SDO) umožňují číst a zapisovat jednotlivé položky slovníku objektů (obr. 3). Protokol pro přenos SDO dovoluje přenášet objekty libovolné délky (je-li objekt delší než čtyři bajty, je rozdělen do několika zpráv CAN zvaných segmenty, popř. skupin zpráv CAN zvaných bloky – pozn. překl.). První bajt prvního segmentu obsahuje bity nezbytné pro komunikaci a ošetření chyb rámce SDO. Následující tři bajty obsahují index a subindex položky slovníku objektů, která je čtena nebo zapisována. Zbývající čtyři bajty jsou k dispozici pro přenos uživatelských dat. Druhý a další segmenty (zprávy CAN se stejným identifikátorem CAN) obsahují bajt řídící komunikaci, následovaný až sedmi bajty uživatelských dat. Příjemce segmentu nebo bloku segmentů musí jeho příjem signalizovat odpovědí, takže komunikace SDO je potvrzovaná, typu peer-to-peer (klient/server). (Podle použitého typu protokolu se rozlišuje komunikace SDO zrychlená – expedited, segmentovaná – segmented a bloková – block, kde každá je vhodná pro jinou délku přenášených objektů – pozn. překl.)
Objekty pro správu sítě
Mezi objekty obstarávajícími správu sítě (Network Management Objects) patří Boot-up Object, Node/Life-guarding Object, Heardbeat Object a NMT (Network Management) Object (názvy jsou ponechány v originálním znění, neboť dosud nemají vžité české ekvivalenty – pozn. překl.).
Objekty Boot-up, Node/Life-guarding a Heardbeat jsou tvořeny vždy jedinou zprávou CAN obsahující jeden bajt dat.
Jedinou zprávou CAN je reprezentován i NMT Object, tentokrát ovšem obsahující dva bajty dat. Její identifikátor je 0, což znamená největší prioritu v síti CAN. První datový bajt této zprávy obsahuje příkaz a druhý adresu zařízení, kterého se příkaz týká (je-li adresa 0, je příkaz určen všem zařízením v síti). NMT Object vyslaný řídicím zařízením v síti (NMT master, správce sítě nastaví uzly (zařízení) v síti do požadovaného stavu (obr. 4). Stavový model zařízení komunikujících podle protokolu CANopen obsahuje tyto stavy: inicializace (Initialization), předprovozní (Pre-operational), v chodu (Operational) a zastaveno (Stopped). Každé zařízení je po zapnutí ve stavu Initialization, ze kterého automaticky přechází do stavu Pre-operational. V tomto stavu je již možné přenášet SDO. Jakmile správce sítě přepne vysláním objektu NMT dané zařízení do stavu Operational, může toto začít vysílat zprávy PDO. Ve stavu Stopped není možná jiná komunikace než přenos zpráv typu MNT Object.
Aby bylo možné inicializovat buď uzel jako celek, nebo pouze některé jeho funkce, má stav inicializace tři dílčí tzv. podstavy. Těmi jsou inicializace aplikace (Reset_Application), inicializace komunikace (Reset_Communication) a inicializace zařízení (Initialization Status).
|
|
|
Co je CANopen?
CANopen je otevřený komunikační protokol určený pro průmyslovou sběrnici CAN (Controller Area Network). Komunikace probíhá na bázi přenášení tzv. objektů. Objekt je základní jednotka přenášející data mezi zařízeními komunikujícími podle protokolu CANopen. Podle svého určení se objekty dělí do skupin, z nichž nejdůležitější jsou:
technologické objekty, tzv. PDO (Process Data Objects), které nesou informace o technologických veličinách (teplota, otáčky, napětí apod.), jejich délka je osm bajtů a mají v síti velkou prioritu,
servisní objekty, tzv. SDO (Service Data Objects), které nesou servisní nebo konfigurační údaje (počet I/O, konstanty PID regulátoru, měřicí rozsah snímače apod.), jejich délka může být libovolně velká a mají v síti malou prioritu,
objekty pro správu sítě, tzv. objekty NMT (Network Management), které slouží ke konfigurování a řízení provozu sítě s protokolem CANopen (hlášení stavu zařízení, povel k novému spuštění zařízení apod.) a mají v síti největší prioritu.
Komunikace při přenosu SDO a objektů NMT probíhá vždy způsobem master-slave, kdy existuje pouze jedno řídicí zařízení (master) a až 127 (pod)řízených zařízení (slave). Na rozdíl od toho se PDO přenášejí způsobem zvaným broadcast, takže každé zařízení zapojené v síti s protokolem CANopen má přístup ke všem hodnotám technologických veličin vyslaným na sběrnici.
Důležitou součástí každého zařízení komunikujícího podle protokolu CANopen je tzv. slovník objektů (Object Dictionary – OD), který uchovává aktuální hodnoty všech objektů, jež zařízení může prostřednictvím SDO či PDO vysílat nebo přijímat. Objekty jsou uchovávány v dvojúrovňovém poli a přístupné při použití páru index:sub-index (např. 6200:01).
Struktura a obsah slovníku objektů příslušného danému zařízení jsou obvykle specifikovány v tzv. souboru EDS (Electronic Data Sheet). Jedná se o textový soubor podobný souboru Windows INI.
Zařízení používající ke komunikaci protokol CANopen se rozdělují do různých profilů. Profil je soubor objektů povinně podporovaných ve slovníku objektů, včetně hodnot indexů a sub-indexů, na kterých jsou uloženy. Tato vlastnost zaručuje, že zařízení téhož profilu mohou bez problémů spolupracovat v jedné síti, protože jsou v nich předem definovány odpovídající objekty. Kompatibilní profily rovněž zaručují, že nedochází ke kolizi používaných identifikátorů zpráv CAN.
(fv)
|
|
V dílčím stavu Reset_Application se nastaví na implicitní hodnoty parametry určené výrobcem a standardní parametry pro zařízení dané třídy. Při Reset_Communication se na výchozí hodnoty, tzv. po zapnutí, nastavují všechny parametry komunikace. Do třetího dílčího stavu – Initialization Status – přechází zařízení automaticky po zapnutí nebo inicializaci komunikace nebo aplikace. (Jde o poslední stav před přechodem do předprovozního stavu – pozn. překl.) Při zapnutí zařízení se všechny jeho parametry nastavují na naposled uložené hodnoty.
Po ukončení inicializace vyšle zařízení zprávu Boot-up Object, kterou řídicímu zařízení sítě oznamuje, že přešlo do předprovozního stavu. Takto se postupuje nejen po zapnutí zařízení, ale i po náhodném výpadku napájení během jeho chodu. Správce sítě se tak dozví, že zařízení bylo přechodně mimo provoz, a může ověřit, zda během této doby nebyla ztracena žádná zpráva. Zpráva nesoucí Boot-up Object má stejný identifikátor jako zprávy nesoucí Node/Life-guarding Object nebo Heardbeat Object, na rozdíl od nich však neobsahuje žádná data.
Funkce reprezentované objekty Heardbeat Object a Node/Life-guarding Object slouží pro odhalování chyb a pro signalizaci přítomnosti a stavu jednotlivých zařízení v síti.
Heardbeat je periodická zpráva, kterou zařízení o sobě sděluje jednomu nebo několika ostatním uzlům sítě, že je v činnosti a správně funguje.
V případě zprávy Node-guarding vysílá správce sítě periodicky dotaz podřízeným zařízením s cílem zjistit, zda jsou aktivní. Podřízené zařízení odpovídá zprávou, která obsahuje informaci o jeho stavu a doplňkový bit měnící svoji hodnotu při každém dotazu. Doplňkový bit umožňuje zjistit, zda došlá odpověď je odpovědí na aktuální dotaz.
Pokud jde o funkci Life-guarding, jsou to naopak podřízená zařízení, která kontrolují činnost řídicího zařízení – správce sítě. Využívají se dotazy, které správce zasílá s cílem zjistit stav podřízených zařízení. Jestliže podřízené zařízení neobdrží tento dotaz do plynutí určené doby, oznámí tuto okolnost aplikačnímu programu, který na ni může zareagovat. V každém zařízení pro síť CANopen musí být implementována buď funkce Heardbeat, nebo Node/Life-guarding. V současné době se pro její větší pružnost doporučuje spíše funkce Heardbeat.
Synchronizace, mimořádné situace a časové značky
Jak již bylo uvedeno, definuje protokol CANopen také zvláštní objekty pro synchronizaci, indikaci mimořádných situací a časové značky.
Základní taktování sítě zajišťuje SYNC Object (objekt SYNC), periodicky vysílaný jedním ze zařízení. Perioda vysílání této zprávy je definována ve slovníku objektů (Communication Cycle Period Object) a může být nastavována konfiguračním nástrojem při uvádění zařízení do provozu. Při vysílání objektu SYNC může dojít k jeho zpoždění v důsledku přítomnosti jiných objektů s identifikátory s větší prioritou v síti. Objekt SYNC se skládá z jedné zprávy CAN s identifikátorem 128.
Mimořádnou situaci, jako je např. kritická chyba zařízení, signalizuje zpráva typu nouzový objekt (Emergency Object). Ta je tudíž vhodná pro signalizaci rozličných chyb a jejich sdělování ostatním zařízením. Jde o zprávu, která smí být zařízením vyslána pouze jednou za celou dobu výskytu téže chyby. Není potvrzována, takže není rozhodující, kolik zařízení ji přijme. Rovněž reakce na takovou zprávu je závislá na aplikaci. Protokol CANopen definuje chybové kódy, které mohou být vysílány v nouzových objektech. Nouzový objekt se skládá vždy z jedné CAN zprávy s osmi bajty dat.
Časová značka (Time Stamp Object) je objekt poskytující zařízením informaci o aktuálním datu a aktuálním čase. Časové značky jsou vysílány jedním ze zařízení a neodpovídá se na ně. Tvoří je jedna zpráva CAN s identifikátorem 256 a polem dat dlouhým šest bajtů.
Přiřazování identifikátorů CAN
CAN je sběrnice přenášející komunikační objekty (CAN Communication Object – COB) neboli zprávy. Každému komunikačnímu objektu je přiřazen jeden nebo více identifikátorů, které implicitně definují jeho prioritu na sběrnici. Z toho vyplývá, že přiřazení identifikátorů jednotlivým komunikačním objektům je jednou ze zásadních otázek při návrhu systému. K usnadnění návrhu jednoduchých sítí definuje protokol CANopen výchozí hodnoty identifikátorů pro všechny povinné objekty. Tyto hodnoty se inicializují v předprovoznín stavu sítě, a je-li to nutné, lze je dále dynamicky modifikovat.
Zařízení spolupracující podle protokolu CANopen smějí používat jen identifikátory odpovídající komunikačním objektům podporovaným protokolem. Implicitní schéma přiřazení identifikátorů má funkční část, určující prioritu objektu, a část označenou jako module-ID, která umožňuje rozlišovat mezi dvěma zařízeními plnícími stejnou funkci.
| Názvosloví: |
| komunikační objekt – zpráva přenášená po sběrnici CAN |
| NMT master – správce sítě CANopen |
| komunikační profil – soubor objektů definovaných podle standardu CANopen, nutný pro zapojení zařízení do sítě CANopen |
| Object Dictionary – slovník objektů: slovník obsahující informaci o všech technologických, komunikačních a konfiguračních parametrech zařízení v podobě hodnot pojmenovaných objektů; podporované objekty jsou uvedeny v profilu zařízení |
| Device profile – profil zařízení: specifikace zařazující zřízení do skupiny zařízení s podobnými nadstandardními funkčními schopnostmi; pro tato zařízení jsou definovány další nadstandardní komunikační objekty, které musí poskytovat, chtějí-li spadat do daného profilu |
| Specific Device Profile – speciální profil zařízení: rozšíření souboru objektů poskytovaných zařízení o další specializované objekty (viz profil zařízení) |
| Standard Device Profile – standardní profil zařízení: definuje funkce společné všem zařízením komunikujícím prostřednictvím protokolu CANopen |
Standardní schéma přiřazení identifikátorů odpovídá předem nastavené konfiguraci struktury master/slave a umožňuje komunikaci peer-to-peer mezi jedním řídicím zařízením (master) a až 127 podřízenými zařízeními (slave). Současně také podporuje vysílání nepotvrzovaných objektů (NMT Object, SYNC Object, Time-Stamp Object) z jednoho zdroje většímu počtu adresátů (metoda broadcastKaždé podřízené zařízení má standardně definovánu vlastní sadu komunikačních objektů, která se se skládá z jednoho objektu typu Emergency Object, jednoho objektu typu SDO, až čtyř objektů RPDO (Received PDO – přijímaná technologická data),). až čtyř objektů TPDO (Transmitted PDO – vysílaná technologická data) a jednoho objektu pro hlášení chyb (Error Control Object). Jestliže to návrh systému vyžaduje, lze konfigurovat i přiřazení všech uvedených identifikátorů odpovídajícím objektům.
Profily pro zařízení, rozhraní a aplikace
Standardní profily (Specific Device Profiles), vytvořené členy sdružení CiA pro různá zařízení, rozhraní a aplikace, usnadňují práci návrhářům systémů a zjednodušují včleňování zařízení do sítí CANopen. Zařízení, podpůrné nástroje a implementace protokolů jsou v současné době dobře dostupné za rozumné ceny. Pro vývojáře je také velmi důležitá a užitečná možnost opakovaného používání aplikačního softwaru. Z uvedených skutečností vyplývá zřejmý požadavek, aby propojená zařízení mohla nejen vzájemně komunikovat, ale aby byla schopna i navzájem bez problémů spolupracovat. Protokol CANopen je natolik flexibilní a otevřený, že podporuje jak zvláštní funkce zařízení dané výrobcem, tak funkce společné všem zařízením, jak je specifikují standardní profily zařízení.
Standard protokolu CANopen a doporučené profily zařízení jsou dostupné na ústředí CiA (lze je nalézt na internetové adrese http://www.can-cia.org).
Holger Zeltwanger,
CAN in Automation
(Z anglického originálu Zeltwanger, H.: CANopen, higher layer protocol for embedded networks, CAN in Automation 2004, přeložil Ing. František Vacek.)
|