Hoci samotný protokol CAN má silnú schopnosť detekcie a opravy chýb, v priemyselnom riadení nie je zástrčkové spojenie pevné, je poškodené prenosové médium alebo je poškodený ovládač zbernice atď., čo zničí spoľahlivú komunikáciu CAN. V aplikačnom systéme, ktorý vyžaduje vysokú spoľahlivosť, tieto chyby, ak nie sú automaticky zistené a neprijmú vhodné opatrenia na ich odstránenie, spôsobia, že systém čiastočne alebo úplne stratí schopnosť komunikovať. Efektívnym spôsobom riešenia tohto problému je použitie redundantnej kontroly komunikácie. To zaisťuje, že hlavné funkcie komunikačného systému fungujú normálne, čím sa zvyšuje spoľahlivosť systému.
1 Hardvérové komponenty systému
MB90F543 je 16-bitový mikrokontrolér s dvomi CAN radičmi od Fujitsu. Systém využíva dve sady zberníc (CAN0, CAN1), z ktorých každá obsahuje nezávislé zbernicové káble, ovládače zberníc a ovládače zberníc, ktoré dokážu realizovať plnú redundanciu fyzických médií, fyzickej vrstvy, vrstvy dátového spojenia a aplikačnej vrstvy. Dve sady zberníc pracujú v režime horúcej zálohy: jeden CAN radič slúži ako predvolený CAN po zapnutí systému (ktorý môže byť nazývaný hlavný CAN); druhý slúži ako pohotovostný CAN systému (ktorý sa nazýva podriadený CAN) a slúži ako redundancia pre hlavný CAN. Keď systém funguje normálne, uvedie sa do prevádzky hlavná zbernica CAN (CAN0). Keď zlyhá hlavná zbernica CAN, spustí sa podriadená zbernica CAN (CAN1). Ak zapnutie{15}}detekuje chybu na hlavnej zbernici CAN, automaticky sa uvedie do prevádzky podriadená zbernica CAN. Týmto spôsobom, keď jedna sada zberníc zlyhá, druhá sada zberníc bude automaticky pokračovať v práci, aby zabezpečila normálnu prevádzku komunikačnej funkcie celého systému, čo výrazne zlepšuje spoľahlivosť systému a realizuje komplexný redundantný dizajn zbernice CAN. Okrem toho je možné podľa potrieb softvéru nastaviť aj redundantný alebo neredundantný režim. Pre neredundantný režim sa používa iba hlavná zbernica CAN.
Bloková schéma architektúry systému
RT je prispôsobovací rezistor ukončenia zbernice, ktorý sa používa na potlačenie rušenia vyžarovania signálu, RT=100Ω alebo 120Ω. Sieť používa ako komunikačné médium tienený krútený párový kábel.
Riadiaca jednotka CAN integruje funkcie fyzickej vrstvy a vrstvy dátového spojenia protokolu CAN a môže dokončiť proces rámcovania dátovej komunikácie, vrátane vypĺňania bitov, kódovania dátových blokov, kontrolného súčtu CRC a rozlišovania priorít.
Regulátor CAN má tieto hlavné vlastnosti:
◇ Vyhovuje protokolom CAN2.0A a CAN2.0B.
◇ Podporuje odosielanie a prijímanie dátových rámcov a vzdialených rámcov.
◇ 16 vyrovnávacích pamätí na odosielanie a prijímanie správ, ktoré podporujú 11-bitové alebo 29{4}}bitové identifikátory a viacúrovňovú štruktúru vyrovnávacej pamäte správ; ◇ Podporuje úplné-porovnávanie bitov, porovnávanie celých bitov a porovnávanie celých bitov.
◇ Podporuje tri metódy výberu identifikácie akceptácie: úplné{0}}porovnanie bitov, úplné{1}} maskovanie bitov a akceptovanie maskovania bitov; ◇ Dva akceptačné identifikačné registre.
◇ Dva akceptačné identifikačné registre podporujú formát štandardného rámca alebo rozšíreného rámca.
◇ Prenosová rýchlosť je programovateľná od 10 Kbps do 1 Mbps.
Ovládač zbernice využíva PCA82C250 ako rozhranie medzi radičom CAN a fyzickou zbernicou, aby sa zlepšila schopnosť diferenciálneho prenosu a príjmu zbernice.
2 Návrh systémového softvéru
2.1 Realizácia funkcie duálneho redundantného riadenia CAN
V systéme duálnej redundancie CAN je v porovnaní s hardvérovou štruktúrou návrh softvéru relatívne zložitejší. Všeobecný komunikačný program zbernice CAN musí obsahovať tri základné časti: program inicializácie CAN, program prenosu CAN a program príjmu CAN. V tomto redundantnom návrhu systémového softvéru sa vyššie uvedené tri časti používajú ako tri najzákladnejšie moduly na volanie iných softvérových modulov systému.
MB90F543 dokáže spracovať 256 druhov zdrojov prerušení a existujú štyri hardvérové prerušenia súvisiace s radičom CAN: CAN0 RX (CAN0 prijíma úplné prerušenie), CAN0 TX /NS (prerušenie CAN0 je dokončené/prerušenie zmeny stavu uzla), CAN1 RX (CAN1 prijíma úplné prerušenie), CAN1 TX/NS (CAN1 zmena stavu odosiela dokončené prerušenie). CAN1 TX /NS (CAN1 prenos dokončený/prerušenie zmeny stavu uzla). V tomto softvérovom dizajne sa používa odosielanie dotazov a prijímanie prerušení. Na spracovanie zmeny stavu uzla sa používa podprogram prerušenia zmeny stavu uzla. Dôvodom je to, že protokol CAN2.0 špecifikuje, že uzol je v jednom z nasledujúcich troch stavov: chyba-aktivovaný stav, chyba-ignorovaný stav a vypnutý{20}}stav zbernice. V sérii MB90500 existuje aj dodatočný varovný stav, ktorý indikuje, že hodnota počítadla chýb vysielania/prijímania presiahla 96 a zmena stavu uzla spôsobí zodpovedajúce prerušenie.
Keďže systém pracuje s duálnou redundanciou CAN v horúcom pohotovostnom režime, oba ovládače CAN musia byť v stave horúceho pohotovostného režimu. Obidva ovládače CAN všetkých uzlov v systéme sú inicializované, aby boli kedykoľvek pripravené na prijímanie správ, ale správy odosiela iba jeden ovládač CAN. Inými slovami, v jednom okamihu je aktívny iba jeden z kanálov CAN, zatiaľ čo druhý počúva (pri normálnej prevádzke) alebo je v poruchovom stave (v prípade poruchy).
Kľúč ku komplexnosti návrhu softvéru duálneho redundantného riadiaceho systému CAN v porovnaní s jedným riadiacim systémom CAN spočíva v detekcii porúch systému CAN a automatickom prepínaní systému CAN. Vďaka použitiu dvoch sád úplne nezávislých prenosových médií, ovládačov zbernice a ovládačov zbernice, môžu byť detekované nezávisle od ich vlastných porúch kanála, ako je skrat- CANH a CANL, odpojenie CANH alebo CANL, skrat CANH a uzemnenie, skrat CANL a napájania-, poškodenie vodiča autobusu atď. Pri skutočnom ladení sa zistí, že ak je CANH, CANL odpojený alebo je na zbernici iba jeden vysielač, spôsobí to zvýšenie počítadla chýb vysielania/prijímania na 128, čo uvedie uzol do ignorovaného chybového stavu; a skrat-skrat medzi CANH a CANL, skrat-medzi CANH a zemou alebo skrat- medzi CANL a napájaním spôsobí zvýšenie počítadla chýb vysielania/prijímania na 256, čím sa uzol dostane do stavu odpojenej zbernice. Preto volaním modulu redundancie CAN v podprograme prerušenia zmeny stavu uzla môžeme dosiahnuť vyššie uvedený účel automatickej detekcie porúch a automatického prepínania systému CAN. Podprogram prerušenia zmeny stavu uzla CAN0 je nasledujúci:
__interrupt void NodeStateTransmitInt0 (void)
{
if (CSR0_NT) /* zmena stavu uzla */
{
CSR0_NT=0; /*Reset príznaku prerušenia */
if ( (CSR0_NS==2 ) (CSR0_NS==3 ) ) /* prerušenie alebo skrat spôsobené */
{
NoWaitFlg=1; /* vzájomne sa vylučujúca vlajka */
Bus0Error() ; /* Bus0Error( ) zastaví CAN0 a spustí redundantný podprogram CAN1 */ { NoWaitFlg=1; /* príznak mutexu */
}
}
ICR00 =3; /* zmeniť prioritu prerušenia na prioritu prerušenia Timer0 */ }
ICR03 =2; /* Zmeňte prioritu prerušenia tak, aby uprednostnila prerušenie časovača 0 */ }
}
Okrem toho v procese komunikácie so zbernicou CAN, keď sa dokončí prenos údajov určitej informačnej vyrovnávacej pamäte, zodpovedajúci bit v registri dokončenia prenosu sa nastaví na 1. V procese dotazovania na prenos posúdením tohto registra môžete vedieť, či je prenos dokončený alebo nie. Ak však odoslanie nie je úspešné, systém bude neustále čakať a spôsobí zlyhanie systému. Softvér tu preto musí nastaviť čakaciu dobu, po ktorej bude systém redundancie CAN vyzvaný, aby zastavil hlavný kanál CAN a povolil podriadený kanál CAN.
Návrh softvéru by mal venovať pozornosť aj problému, ako obnoviť pôvodnú komunikačnú úlohu po dokončení prepínania zálohy CAN. Riešením je pripraviť zoznam príznakov úloh, pohotovostné prepínanie CAN, prečítať tabuľku, aby ste získali pôvodnú úlohu systému, aby ste dosiahli pôvodnú komunikačnú úlohu spoľahlivého prepínania.
2.2 Realizácia funkcie riadenia zbernice
Softvérový návrh tohto systému obsahuje okrem programu na prenos a príjem dát v reálnom čase- aj program na správu komunikácie pre správu každého uzla. Všetky uzly sú rozdelené na hlavné uzly a podriadené uzly. Rozdiel medzi nimi je v tom, že hlavný uzol má funkciu správy zbernice, ktorá mu umožňuje vykonávať online štatistiky uzlov, rozpoznávať offline uzly a prijímať opatrenia na ich riešenie; zatiaľ čo podriadený uzol túto funkciu nemá. Existuje iba jeden hlavný uzol, zatiaľ čo viacero podriadených uzlov je povolených. Program funkcie riadenia zbernice pre hlavný uzol volaný raz za čas, aby sa zistilo, či sú všetky uzly online: ak sú všetky uzly online, zbernica sa považuje za normálnu; v opačnom prípade identifikujte offline uzly a podľa toho s nimi naložte. Myšlienkou návrhu je, že hlavný uzol systému posiela vzdialený rámec všetkým podriadeným uzlom na zbernici v pravidelných intervaloch a každý podriadený uzol ho prijme, vloží svoje vlastné číslo uzla do dátového rámca a odošle ho nadriadenému uzlu a hlavný uzol podľa prijatého čísla uzla offline určí, či došlo k zlyhaniu uzla. V tomto systéme sa číslo uzla (adresa modulu) nastavuje prepínačom DIP na module.
V procese ladenia softvéru, aj keď je hardvérová štruktúra každého uzla rovnaká, kvôli rozdielom v zapojení dosky plošných spojov a rozptylu komponentov sa často stáva, že nie všetky podriadené uzly môžu prijímať informácie odoslané nadriadeným uzlom, alebo nadriadený uzol neprijíma všetky informácie odoslané podriadenými uzlami, tj existuje problém so stratou rámca. Tento problém bol vyriešený softvérovým oneskorením a optimalizáciou prijímacieho programu prerušenia.
3 Vývojové prostredie a aplikácia by mali venovať pozornosť niekoľkým problémom
Softvérový pracovný stôl Softune V3 je integrované vývojové prostredie softvéru pre vývoj programu mikrokontrolérov série Fujitsu FFMC-8L, FFMC-16L/LX a FR, vrátane správy vývoja, ladenia emulátora, mäkkej simulácie a integrovaného vývojového prostredia. Jeho vývojový nástroj obsahuje Softune Workbench, C kompilátor, Assembler, Linker, C Checker, C Analyzer. Softtune V3 podporuje jazyky C aj assembler.
Počas skutočného používania MB90F543 by ste si mali všimnúť nasledujúce problémy.
① Nastavenie registra výberu akceptačných značiek (AMSR). Každá vyrovnávacia pamäť správy môže vybrať jednu metódu označovania akceptovania: úplné porovnanie bitov, úplnú bitovú masku alebo prijatie bitovej masky. Úplné-bitové porovnanie znamená, že ID informácií prijatých uzlom musí byť presne rovnaké ako ID nastavené informačnou vyrovnávacou pamäťou, aby informácie prešli akceptačným identifikátorom. úplné-bitové maskovanie nemusí porovnávať ID informácie, čo možno interpretovať ako bezpodmienečné odovzdanie akceptačného identifikátora; Akceptovanie maskovania bitov -môže špecifikovať bity ID, ktoré sa majú porovnať, a bity ID, ktoré sa majú maskovať, tj čiastočné porovnanie prijatia. V praxi sa táto metóda akceptačného identifikátora používa najčastejšie, preto sú v CAN radiči čipu MB90F543 nastavené dve takéto metódy. nastavenie AMSR poskytuje vývojárovi veľkú flexibilitu pri spracovaní informácií o vyrovnávacej pamäti.
② Nastavenie registra označovania (AMR). Po nastavení AMSR na bit{1}}maskovanú metódu prijatia je potrebné nastaviť AMR tak, aby sa nastavilo, ktoré bity ID sa majú porovnávať a ktoré bity sa majú maskovať. AMR má celkovo štyri bajty a podporuje 29-bitové znaky ID. Je však potrebné poznamenať, že pre 29-bitový znak ID sa používa AM28~AM0; zatiaľ čo pre 11-bitový ID znak sa používa AM28~AM18. preto musí byť používateľ pri nastavovaní AMR opatrný, inak to spôsobí chybu príjmu. Autor tu trpel.
③ Jednou z funkcií ovládača CAN od Fujitsu je, že podporuje používanie viacúrovňových vyrovnávacích pamätí správ. V prípade, keď sa príjem vyskytuje často alebo sa prijíma niekoľko rôznych informačných rámcov ID, je možné, že CPU nemá dostatok času na spracovanie prijatých informácií, takže viaceré informačné vyrovnávacie pamäte môžu byť sformované do viacúrovňovej informačnej vyrovnávacej pamäte, aby sa zabezpečilo, že informácie môžu byť spracované včas a efektívne. Týmto spôsobom je možné odoslať informácie väčšie ako 8 bajtov v 1 rámci. Ďalšou výhodou tohto usporiadania je, že CPU môže čítať informácie určitej informačnej vyrovnávacej pamäte bez toho, aby sa musel obávať, že informácie o vyrovnávacej pamäti budú prepísané a okamžite stratené.
4 Záver
V procese vývoja protokolu aplikačnej vrstvy CAN sa požičajú niektoré mechanizmy špecifikácie DeviceNet, ako napríklad podpora viacerých foriem prenosu údajov (selektívny prechod, polling, zmena stavu atď.); z dôvodu obmedzení mnohých faktorov, ako je vývojový cyklus, je však potrebné zlepšiť a rozšíriť diagnostickú funkciu zariadenia, ako aj interoperabilitu s podobnými produktmi. Duálny redundantný komunikačný systém CAN funguje stabilne v experimentálnej fáze, prenos dát je spoľahlivý, redundantné prepínanie je praktické a spoľahlivosť správy zbernice je dobrá; môže byť aplikovaný na riadiaci systém lokomotívy alebo iné priemyselné riadiace miesta, ktoré vyžadujú vysokú spoľahlivosť.