Även om CAN-protokollet i sig har en stark feldetekterings- och korrigeringsförmåga, på den industriella kontrollplatsen, är kontaktanslutningen inte stabil, överföringsmediet är skadat eller busdrivrutinen är skadad, etc. kommer att förstöra den tillförlitliga kommunikationen av CAN. I applikationssystemet som kräver hög tillförlitlighet kommer dessa fel, om de inte upptäcks automatiskt och vidtar lämpliga åtgärder för att övervinna, att systemet delvis eller till och med helt förlorar förmågan att kommunicera. Ett effektivt sätt att lösa detta problem är att använda redundant kommunikationskontroll. Detta säkerställer att kommunikationssystemets huvudfunktioner fungerar normalt, vilket förbättrar systemets tillförlitlighet.
1 Systemets maskinvarukomponenter
MB90F543 är en 16-bitars mikrokontroller med två CAN-kontroller från Fujitsu. Systemet använder två uppsättningar bussar (CAN0, CAN1), som var och en innehåller oberoende busskablar, busdrivrutiner och bussstyrenheter, som kan realisera full redundans av fysisk media, fysiskt lager, datalänklager och applikationslager. De två uppsättningarna bussar arbetar i ett hot backup-läge: en CAN-styrenhet fungerar som standard-CAN efter att systemet slås på (vilket kan kallas master-CAN); den andra fungerar som systemets standby-CAN (som kallas slav-CAN) och fungerar som en redundans för master-CAN. När systemet fungerar normalt sätts master CAN-bussen (CAN0) i drift. När master-CAN-bussen misslyckas, går slav-CAN-bussen (CAN1) i drift. Om ström{15}}upptäcker ett fel i master CAN-bussen sätts slav-CAN-bussen automatiskt i drift. På detta sätt, när en uppsättning bussar misslyckas, kommer den andra uppsättningen bussar automatiskt att fortsätta att arbeta för att säkerställa normal drift av kommunikationsfunktionen för hela systemet, vilket avsevärt förbättrar systemets tillförlitlighet och realiserar den omfattande redundansdesignen för CAN-bussen. Dessutom kan, beroende på programvarans behov, även ställas in för att ta redundant eller icke-redundant läge. För det icke-redundanta läget används endast CAN-huvudbussen.
Blockdiagram för systemarkitektur
RT är busstermineringsmatchningsmotståndet, som används för att undertrycka signalemissionsstörningar, RT=100Ω eller 120Ω. Nätverket använder skärmad partvinnad kabel som kommunikationsmedium.
CAN-styrenheten integrerar det fysiska lagret och datalänkslagerfunktionerna i CAN-protokollet och kan slutföra inramningsprocessen för datakommunikation, inklusive bitutfyllnad, datablockkodning, CRC-kontrollsumma och prioritetsdiskriminering.
CAN-styrenheten har följande huvudfunktioner:
◇ Överensstämmer med CAN2.0A- och CAN2.0B-protokollen.
◇ Stöder sändning och mottagning av dataramar och fjärrbilder.
◇ 16 skicka/ta emot meddelandebuffertar som stöder 11-bitars eller 29-bitars identifierare och fler-meddelandebuffertstruktur; ◇ Stöder full-bitsjämförelse, helbitsjämförelse och helbitsjämförelse.
◇ Stöder tre metoder för val av acceptansidentifiering: full-bitjämförelse, full-bitmaskering och bitmaskeringsacceptans; ◇ Två register för acceptansidentifiering.
◇ Två acceptansidentifieringsregister stöder standardformat eller utökat ramformat.
◇ Baudhastigheten är programmerbar från 10Kbps till 1Mbps.
Bussdrivrutinen använder PCA82C250 som gränssnittet mellan CAN-styrenheten och den fysiska bussen för att förbättra bussens differentiella överförings- och mottagningsförmåga.
2 Design av systemprogramvara
2.1 Realisering av dubbel CAN redundant styrfunktion
I det dubbla CAN-redundanssystemet, jämfört med hårdvarustrukturen, är mjukvarudesignen relativt mer komplex. Det allmänna CAN-buss-kommunikationsprogrammet måste innehålla tre grundläggande delar: CAN-initieringsprogram, CAN-sändningsprogram och CAN-mottagningsprogram. I denna redundanta systemprogramvarudesign används ovanstående tre delar som de tre mest grundläggande modulerna för andra programvarumoduler i systemet att anropa.
MB90F543 kan hantera 256 typer av avbrottskällor, och det finns fyra hårdvaruavbrott relaterade till CAN-styrenheten: CAN0 RX (CAN0 tar emot fullständigt avbrott), CAN0 TX /NS (CAN0 skicka komplett/nodtillståndsändringsavbrott), CAN1 RX (CAN1 tar emot fullständigt avbrott), CAN1 sändning komplett /noCAN sändning komplett/nej). CAN1 TX /NS (CAN1 sändning komplett/nodstatusändringsavbrott). I denna mjukvarudesign används förfrågningssändning och avbrottsmottagning. Subrutinen för avbrott i nodtillståndsändring används för bearbetning av nodtillståndsändring. Detta beror på att CAN2.0-protokollet anger att noden är i ett av följande tre tillstånd: fel-aktiverat tillstånd, fel-ignorerat tillstånd och av-busstillstånd. I MB90500-serien finns det också ett extra varningstillstånd, som indikerar att värdet på sändnings/mottagningsfelräknaren har överskridit 96, och en förändring i nodtillståndet kommer att orsaka ett motsvarande avbrott.
Eftersom systemet arbetar med dubbel CAN-redundans hot standby, måste båda CAN-styrenheterna vara i hot standby-läge. Båda CAN-styrenheterna för alla noder i systemet är initierade för att vara redo att ta emot meddelanden när som helst, men en och endast en CAN-styrenhet skickar meddelanden. Med andra ord, vid en tidpunkt är en och endast en av CAN-kanalerna aktiv, medan den andra lyssnar (i normal drift) eller i ett feltillstånd (vid ett fel).
Nyckeln till komplexiteten i mjukvarudesignen för ett dubbelt CAN-redundant styrsystem jämfört med ett enda CAN-styrsystem ligger i CAN-systemets feldetektering och automatisk omkoppling av CAN-systemet. På grund av användningen av två uppsättningar av helt oberoende överföringsmedier, busdrivrutiner och bussstyrenheter, så att de kan upptäckas oberoende av sina egna kanalfel, såsom CANH och CANL kortslutning, CANH eller CANL frånkoppling, CANH och jord kortslutning, CANL och strömkortslutning-, och så på busdrivrutin skador. I själva felsökningen finner man att om CANH, CANL kopplas bort eller det bara finns en sändare på bussen, kommer det att få sändnings/mottagningsfelräknaren att öka till 128, vilket försätter noden i det ignorerade feltillståndet; och en kortslutning- mellan CANH och CANL, en kortslutning- mellan CANH och jord, eller en kortslutning- mellan CANL och strömförsörjningen kommer att göra att sändnings-/mottagningsfelräknaren ökar till 256, vilket försätter noden i tillståndet frånkopplad buss. Därför kan vi, genom att anropa CAN-redundansmodulen i subrutinen för nodtillståndsändringsavbrott, uppnå ovanstående syfte med automatisk feldetektering och automatisk omkoppling av CAN-systemet. CAN0-nodtillståndsändringsavbrottssubrutinen är som följer:
__avbrott void NodeStateTransmitInt0 (void)
{
if (CSR0_NT) /* nodtillståndsändring */
{
CSR0_NT=0; /*Avbrottsflaggan återställd */
if ( (CSR0_NS==2 ) (CSR0_NS==3 ) ) /* avbrott eller kortslutning orsakat */
{
NoWaitFlg=1; /* en ömsesidigt uteslutande flagga */
Bus0Error( ) ; /* Bus0Error( ) stoppar CAN0 och startar den redundanta CAN1-subrutinen */ { NoWaitFlg=1; /* en mutex-flagga */
}
}
ICR00 =3; /* ändra avbrottsprioritet till Timer0 avbrottsprioritet */ }
ICR03 =2; /* Ändra avbrottsprioritet för att prioritera timer 0 avbrott */ }
}
Dessutom, i CAN-busskommunikationsprocessen, när dataöverföringen av en viss informationsbuffert är slutförd, kommer motsvarande bit i överföringsavslutanderegistret att ställas in på 1. I processen med att fråga överföringen, genom att bedöma detta register, kan du veta om överföringen är slutförd eller inte. Men om sändningen inte lyckas kommer det att få systemet att vänta hela tiden och få systemet att krascha. Därför måste programvaran ställa in en vänteperiod här, efter vilken CAN-redundanssystemet kommer att anropas för att stoppa master-CAN-kanalen och aktivera slav-CAN-kanalen.
Programvarudesignen bör också vara uppmärksam på problemet med hur man återställer den ursprungliga kommunikationsuppgiften efter att backup-CAN-växlingen är klar. Lösningen är att förbereda en lista över uppgiftsflaggor, standby CAN-växling, läs tabellen för att få systemets ursprungliga uppgift, för att uppnå den ursprungliga kommunikationsuppgiften med tillförlitlig växling.
2.2 Förverkligande av bussledningsfunktion
I mjukvarudesignen för detta system, förutom realtidsdatakommunikationsprogrammet för dataöverföring och mottagning, inkluderar det även kommunikationshanteringsprogrammet för hanteringen av varje nod. Alla noder är uppdelade i masternoder och slavnoder. Skillnaden mellan dem är att masternoden har en busshanteringsfunktion, som gör att den kan utföra nodstatistik online, känna igen offlinenoder och vidta åtgärder för att hantera dem; medan slavnoden inte har denna funktion. Det finns bara en masternod, medan flera slavnoder är tillåtna. Busshanteringsfunktionsprogram för masternoden anropas då och då, för att avgöra om alla noder är online: om alla noder är online anses bussen vara normal; annars, identifiera offline-noder och hantera det därefter. Designidén är att systemmasternoden skickar en fjärrram till alla slavnoder på bussen med jämna mellanrum, och varje slavnod tar emot det, lägger sitt eget nodnummer i en dataram och skickar det till masternoden, och masternoden avgör om det finns ett nodfel offline enligt nodnumret den tar emot. I detta system ställs nodnumret (moduladressen) in av en DIP-switch på modulen.
I processen med mjukvarufelsökning, även om hårdvarustrukturen för varje nod är densamma, på grund av skillnaderna i kretskortledningar och komponentspridning, är det ofta så att inte alla slavnoder kan ta emot informationen som skickas av masternoden, eller så tar masternoden inte emot all information som skickas av slavnoderna, dvs det finns ett problem med ramförlust. Detta problem har lösts genom mjukvarufördröjning och optimering av mottagningsavbrottsprogram.
3 Utvecklingsmiljö och applikation bör uppmärksamma flera frågor
Softune V3 mjukvaruarbetsbänk är en integrerad mjukvaruutvecklingsmiljö för Fujitsu FFMC-8L, FFMC-16L/LX och FR-seriens mikrokontrollerprogramutveckling, inklusive utvecklingshantering, emulatorfelsökning, mjuk simulering och en integrerad utvecklingsmiljö. Dess utvecklingsverktygssats inkluderar Softune Workbench, C-kompilator, Assembler, Linker, C Checker, C Analyzer. Softune V3 stöder både C- och assemblerspråk.
Under den faktiska användningen av MB90F543 bör följande problem noteras.
① Inställningen av Acceptance Mark Selection Register (AMSR). Varje meddelandebuffert kan välja en acceptansmarkeringsmetod: helbitsjämförelse, helbitmask eller bitmaskacceptans. Full-bitjämförelse innebär att ID:t för informationen som tas emot av noden måste vara exakt samma som ID:t som ställs in av informationsbufferten för att informationen ska passera acceptansidentifieraren; hel-bitsmaskering behöver inte jämföra informationens ID, vilket kan tolkas som den ovillkorliga överföringen av acceptansidentifieraren; bit-maskeringsacceptans kan specificera ID-bitarna som ska jämföras och ID-bitarna som ska maskeras, dvs delvis jämföra acceptansen. I praktiken används denna acceptansidentifieringsmetod oftast, så två sådana metoder ställs in i CAN-styrenheten på MB90F543-chipet. inställningen av AMSR ger stor flexibilitet för utvecklaren att bearbeta buffertinformationen.
② Acceptance Marking Register (AMR) inställning. Efter att AMSR har ställts in på metoden för bit-maskerad acceptans, måste AMR ställas in för att ställa in vilka bitar av ID:t som ska jämföras och vilka bitar som ska maskeras. AMR har totalt fyra byte och stöder 29-bitars ID-tecken. Det är dock värt att notera att för 29-bitars ID-tecknet används AM28~AM0; medan för 11-bitars ID-tecknet används AM28~AM18. därför måste användaren vara försiktig när du ställer in AMR, annars kommer det att resultera i mottagningsfel. Författaren har lidit här.
③ En av funktionerna hos Fujitsus CAN-styrenhet är att den stöder användningen av meddelandebuffertar på flera nivåer. I de fall där mottagning sker ofta, eller flera olika ID-informationsramar tas emot, är det möjligt att CPU:n inte har tillräckligt med tid för att bearbeta den mottagna informationen, så flera informationsbuffertar kan formas till en informationsbuffert på flera nivåer för att säkerställa att informationen kan bearbetas på ett snabbt och effektivt sätt. På detta sätt kan information större än 8 byte skickas i en ram. En annan fördel med detta arrangemang är att CPU:n kan läsa informationen från en viss informationsbuffert utan att behöva oroa sig för att buffertinformationen skrivs om och går förlorad omedelbart.
4 Slutsats
I utvecklingsprocessen för CAN-applikationslagerprotokollet lånas vissa mekanismer för DeviceNet-specifikationen, som att stödja flera former av dataöverföring (selektiv pass, polling, tillståndsändring, etc.); Men på grund av begränsningarna av många faktorer, såsom utvecklingscykeln, behöver enhetens diagnostiska funktion såväl som interoperabiliteten med liknande produkter förbättras och utökas. Det dubbla CAN-redundanta kommunikationssystemet fungerar stabilt i experimentstadiet, dataöverföringen är tillförlitlig, redundansväxlingen är praktisk och tillförlitligheten hos busshanteringen är god; den kan appliceras på lokstyrsystemet eller andra industriella styrplatser som kräver hög tillförlitlighet.