Designløsning og applikasjonsanalyse av dual CAN redundant kommunikasjonssystem

Jun 23, 2025 Legg igjen en beskjed

Selv om CAN-protokollen i seg selv har en sterk feildeteksjons- og korrigeringsevne, vil på det industrielle kontrollstedet, pluggforbindelsen ikke er solid, overføringsmediet er skadet eller bussdriveren er skadet, etc. vil ødelegge den pålitelige kommunikasjonen til CAN. I applikasjonssystemet som krever høy pålitelighet, vil disse feilene, hvis de ikke oppdages automatisk og iverksette passende tiltak for å overvinne, gjøre at systemet delvis eller helt mister evnen til å kommunisere. En effektiv måte å løse dette problemet på er å bruke redundant kommunikasjonskontroll. Dette sikrer at hovedfunksjonene til kommunikasjonssystemet fungerer normalt, og forbedrer dermed systemets pålitelighet.

 

1 Systemmaskinvarekomponenter

MB90F543 er en 16-bits mikrokontroller med to CAN-kontrollere fra Fujitsu. Systemet bruker to sett med busser (CAN0, CAN1), som hver inneholder uavhengige busskabler, bussdrivere og busskontrollere, som kan realisere full redundans av fysiske medier, fysisk lag, datalinklag og applikasjonslag. De to settene med busser opererer i en varm backup-modus: en CAN-kontroller fungerer som standard CAN etter at systemet er slått på (som kan kalles master CAN); den andre fungerer som systemets standby-CAN (som kalles slave-CAN) og fungerer som en redundans for master-CAN. Når systemet fungerer normalt, settes master CAN-bussen (CAN0) i drift. Når master-CAN-bussen svikter, går slave-CAN-bussen (CAN1) i drift. Hvis oppstart{15}} oppdager en feil i master-CAN-bussen, settes slave-CAN-bussen automatisk i drift. På denne måten, når ett sett med busser svikter, vil det andre settet med busser automatisk fortsette å jobbe for å sikre normal drift av kommunikasjonsfunksjonen til hele systemet, noe som i stor grad forbedrer systemets pålitelighet og realiserer den omfattende redundansdesignen til CAN-bussen. I tillegg, i henhold til behovene til programvaren kan også settes til å ta redundant eller ikke-redundant modus. For den ikke-redundante modusen brukes kun CAN-hovedbussen.

info-1-1                               Systemarkitektur-blokkdiagram

 

RT er busstermineringsmotstanden som brukes til å undertrykke signalemisjonsinterferens, RT=100Ω eller 120Ω. Nettverket bruker skjermet tvunnet parkabel som kommunikasjonsmedium.


CAN-kontrolleren integrerer de fysiske lag- og datalinklagfunksjonene til CAN-protokollen, og kan fullføre rammeprosessen for datakommunikasjon, inkludert bitpadding, datablokkkoding, CRC-sjekksum og prioritetsdiskriminering.


CAN-kontrolleren har følgende hovedfunksjoner:

◇ Samsvarer med CAN2.0A- og CAN2.0B-protokollene.

◇ Støtter sending og mottak av datarammer og eksterne rammer.

◇ 16 sende/motta meldingsbuffere, som støtter 11-bit eller 29-bit identifikatorer og fler-meldingsbufferstruktur; ◇ Støtter full-bit-sammenligning, full-bit-sammenligning og full-bit-sammenligning.

◇ Støtter tre metoder for valg av akseptidentifikasjon: full-bitsammenligning, full-bitmaskering og bitmaskeringsgodkjenning; ◇ To akseptidentifikasjonsregistre.

◇ To akseptidentifikasjonsregistre støtter standardramme eller utvidet rammeformat.

◇ Baudhastigheten er programmerbar fra 10Kbps til 1Mbps.


Bussdriveren bruker PCA82C250 som grensesnittet mellom CAN-kontrolleren og den fysiske bussen for å forbedre differensialoverførings- og mottaksevnen til bussen.

info-1-1

 

2 Systemprogramvaredesign

 

2.1 Realisering av dual CAN redundant kontrollfunksjon

 

I det doble CAN-redundanssystemet, sammenlignet med maskinvarestrukturen, er programvaredesignet relativt mer komplekst. Det generelle CAN-buss-kommunikasjonsprogrammet må inneholde tre grunnleggende deler: CAN-initieringsprogram, CAN-overføringsprogram og CAN-mottaksprogram. I denne redundante systemprogramvaredesignen brukes de tre delene ovenfor som de tre mest grunnleggende modulene for andre programvaremoduler i systemet å kalle.


MB90F543 kan håndtere 256 typer avbruddskilder, og det er fire maskinvareavbrudd relatert til CAN-kontrolleren: CAN0 RX (CAN0 mottar fullstendig avbrudd), CAN0 TX /NS (CAN0 send komplett/nodetilstandsendringsavbrudd), CAN1 RX (CAN1 mottar fullstendig avbrudd), CAN1 sending fullført/noCAN sending full/noCAN. CAN1 TX /NS (CAN1 sending fullført/node status endring avbrudd). I denne programvaredesignen brukes spørringssending og avbruddsmottak. Subrutinen for endring av nodetilstandsavbrudd brukes til å behandle nodetilstandsendring. Dette er fordi CAN2.0-protokollen spesifiserer at noden er i en av følgende tre tilstander: feil-aktivert tilstand, feil-ignorert tilstand og av-busstilstand. I MB90500-serien er det også en ekstra advarselstilstand, som indikerer at verdien på sender/mottaksfeiltelleren har overskredet 96, og en endring i nodetilstanden vil forårsake et tilsvarende avbrudd.


Siden systemet opererer med dobbel CAN-redundans hot-standby, må begge CAN-kontrollerne være i varm standby-tilstand. Begge CAN-kontrollerne for alle noder i systemet er initialisert for å være klare til å motta meldinger når som helst, men én og bare én CAN-kontroller sender meldinger. Med andre ord, på et tidspunkt er én og kun én av CAN-kanalene aktiv, mens den andre lytter (i normal drift) eller i en feiltilstand (ved feil).


Nøkkelen til kompleksiteten til programvaredesignet til et dobbelt CAN-redundant kontrollsystem sammenlignet med et enkelt CAN-kontrollsystem ligger i CAN-systemets feildeteksjon og automatisk svitsjing av CAN-systemet. På grunn av bruken av to sett med helt uavhengige overføringsmedier, bussdrivere og busskontrollere, slik at de kan oppdages uavhengig av deres egne kanalfeil, slik som CANH og CANL kort-kortslutning, CANH eller CANL frakobling, CANH og jordkort-kortslutning, CANL og strømkortslutning-, og så videre bussdriverskade. I selve feilsøkingen finner man at dersom CANH, CANL er frakoblet eller det bare er en sender på bussen, vil det føre til at sender/mottaksfeiltelleren øker til 128, noe som setter noden i ignorert feiltilstand; og en kort-slutning mellom CANH og CANL, en kortslutning- mellom CANH og jord, eller en kortslutning- mellom CANL og strømforsyningen vil føre til at sender/mottaksfeiltelleren øker til 256, noe som setter noden i bussen Frakoblet tilstand. Derfor, ved å kalle CAN-redundansmodulen i subrutinen for endring av nodetilstand, kan vi oppnå formålet ovenfor med automatisk feildeteksjon og automatisk veksling av CAN-systemet.

 

__avbrudd void NodeStateTransmitInt0 (ugyldig)

{

if (CSR0_NT) /* endre nodetilstand */

{

CSR0_NT=0; /*Tilbakestilling av avbruddsflagg */

if ( (CSR0_NS==2 ) (CSR0_NS==3 ) ) /* avbrudd eller kortslutning forårsaket */

{

NoWaitFlg=1; /* et gjensidig utelukkende flagg */

Bus0Error( ) ; /* Bus0Error( ) stopper CAN0 og starter den redundante CAN1-subrutinen */ { NoWaitFlg=1; /* et mutex-flagg */

}

}

ICR00 =3; /* endre avbruddsprioritet til Timer0 avbruddsprioritet */ }

ICR03 =2; /* Endre avbruddsprioritet for å prioritere timer 0 avbrudd */ }

}

 

I tillegg, i CAN-buss kommunikasjonsprosessen, når dataoverføringen til en viss informasjonsbuffer er fullført, vil den tilsvarende biten i overføringsfullføringsregisteret settes til 1. I prosessen med å spørre overføringen, ved å bedømme dette registeret, kan du vite om overføringen er fullført eller ikke. Men hvis sendingen ikke lykkes, vil det få systemet til å vente hele tiden og føre til at systemet krasjer. Derfor må programvaren angi en venteperiode her, utover denne vil CAN-redundanssystemet bli kalt opp for å stoppe master-CAN-kanalen og aktivere slave-CAN-kanalen.


Programvaredesignet bør også ta hensyn til problemet med hvordan du gjenoppretter den opprinnelige kommunikasjonsoppgaven etter at sikkerhetskopieringen av CAN-bytte er fullført. Løsningen er å utarbeide en liste over oppgaveflagg, standby CAN-svitsjing, lese tabellen for å få den opprinnelige oppgaven til systemet, for å oppnå den opprinnelige kommunikasjonsoppgaven med pålitelig veksling.


2.2 Realisering av bussstyringsfunksjon


I programvaredesignet til dette systemet inkluderer det i tillegg til sanntidsdatakommunikasjonsprogrammet for dataoverføring og mottak, også kommunikasjonsadministrasjonsprogrammet for administrering av hver node. Alle noder er delt inn i masternoder og slavenoder. Forskjellen mellom dem er at masternoden har en bussadministrasjonsfunksjon, som lar den utføre online nodestatistikk, gjenkjenne offline noder og iverksette tiltak for å håndtere dem; mens slavenoden ikke har denne funksjonen. Det er bare én masternode, mens flere slavenoder er tillatt. Bussadministrasjonsfunksjonsprogram for masternoden kalles av og til for å finne ut om alle nodene er online: hvis alle nodene er online, anses bussen som normal; ellers, identifiser frakoblede noder, og håndtere det deretter. Designideen er at systemmasternoden sender en ekstern ramme til alle slavenodene på bussen med jevne mellomrom, og hver slavenode mottar det, legger sitt eget nodenummer i en dataramme og sender det til masternoden, og masternoden bestemmer om det er en nodefeil offline i henhold til nodenummeret den mottar. I dette systemet settes nodenummeret (moduladressen) av en DIP-bryter på modulen.

 

I prosessen med programvarefeilsøking, selv om maskinvarestrukturen til hver node er den samme, på grunn av forskjellene i kretskortkabling og komponentspredning, er det ofte slik at ikke alle slavenoder kan motta informasjonen sendt av masternoden, eller masternoden mottar ikke all informasjonen sendt av slavenodene, dvs. det er et problem med rammetap. Dette problemet har blitt løst ved programvareforsinkelse og optimalisering av mottaksavbruddsprogram.


3 Utviklingsmiljø og applikasjon bør ta hensyn til flere problemstillinger


Softune V3 software workbench er et integrert programvareutviklingsmiljø for Fujitsu FFMC-8L, FFMC-16L/LX og FR-seriens mikrokontrollerprogramutvikling, inkludert utviklingsadministrasjon, emulatorfeilsøking, myk simulering og et integrert utviklingsmiljø. Utviklingsverktøysettet inkluderer Softune Workbench, C-kompilator, Assembler, Linker, C Checker, C Analyzer. Softune V3 støtter både C- og assembly-språk.


Under selve bruken av MB90F543 bør følgende problemer noteres.


① Innstillingen av Acceptance Mark Selection Register (AMSR). Hver meldingsbuffer kan velge én metode for akseptmarkering: full bitsammenligning, full bitmaske eller bitmaskegodkjenning. Full-bitsammenligning betyr at ID-en til informasjonen som mottas av noden, må være nøyaktig den samme som ID-en angitt av informasjonsbufferen for at informasjonen skal passere akseptidentifikatoren; full-bitmaskering trenger ikke å sammenligne ID-en til informasjonen, noe som kan tolkes som ubetinget overføring av akseptidentifikatoren; bit-maskeringsaksept kan spesifisere ID-bitene som skal sammenlignes og ID-bitene som skal maskeres, dvs. delvis sammenligne aksepten. I praksis brukes denne akseptidentifikatoren oftest, så to slike metoder er satt i CAN-kontrolleren til MB90F543-brikken. innstillingen til AMSR gir stor fleksibilitet for utvikleren til å behandle bufferinformasjonen.


② Acceptance Marking Register (AMR) innstilling. Etter at AMSR er satt til bit-masked acceptance-metoden, må AMR settes til å angi hvilke biter av ID-en som skal sammenlignes og hvilke biter som skal maskeres.AMR har totalt fire byte og støtter 29-bits ID-tegn. Det er imidlertid verdt å merke seg at for 29-bits ID-tegnet brukes AM28~AM0; mens for 11-bits ID-tegnet brukes AM28~AM18. derfor må brukeren være forsiktig når du stiller inn AMR, ellers vil det resultere i mottaksfeil. Forfatteren har lidd her.


③ En av funksjonene til Fujitsus CAN-kontroller er at den støtter bruk av meldingsbuffere på flere-nivåer. I tilfellet der mottak forekommer ofte, eller flere forskjellige ID-informasjonsrammer mottas, er det mulig at CPU-en ikke har nok tid til å behandle den mottatte informasjonen, så flere informasjonsbuffere kan dannes til en informasjonsbuffer på flere nivåer for å sikre at informasjonen kan behandles på en rettidig og effektiv måte. På denne måten kan informasjon større enn 8 byte sendes i 1 ramme. En annen fordel med dette arrangementet er at CPU-en kan lese informasjonen til en viss informasjonsbuffer uten å måtte bekymre deg for at bufferinformasjonen skrives om og går tapt umiddelbart.


4 Konklusjon


I utviklingsprosessen av CAN-applikasjonslagsprotokollen, lånes noen mekanismer i DeviceNet-spesifikasjonen, for eksempel å støtte flere former for dataoverføring (selektiv pass, polling, tilstandsendring, etc.); men på grunn av begrensningene til mange faktorer som utviklingssyklusen, må den diagnostiske funksjonen til enheten samt interoperabiliteten med lignende produkter forbedres og utvides. Det dobbelte CAN-redundante kommunikasjonssystemet fungerer stabilt i eksperimentelt stadium, dataoverføringen er pålitelig, redundansbyttet er praktisk mulig, og påliteligheten til bussadministrasjonen er god; den kan brukes på lokomotivstyringssystemet eller andre industrielle kontrollsteder som krever høy pålitelighet.

Sende bookingforespørsel

whatsapp

Telefon

E-post

Forespørsel