Kahden CAN-redundantin tietoliikennejärjestelmän suunnitteluratkaisu ja sovellusanalyysi

Jun 23, 2025 Jätä viesti

Vaikka CAN-protokollalla itsessään on vahva virheiden havaitsemis- ja korjauskyky, teollisessa ohjauspaikassa pistokeliitäntä ei ole kiinteä, siirtoväline on vaurioitunut tai väyläohjain vaurioitunut jne. tuhoavat luotettavan CAN-viestinnän. Korkeaa luotettavuutta vaativassa sovellusjärjestelmässä näitä vikoja ei havaita automaattisesti ja ryhdytä asianmukaisiin toimenpiteisiin niiden korjaamiseksi, jolloin järjestelmä menettää osittain tai jopa kokonaan viestintäkyvyn. Tehokas tapa ratkaista tämä ongelma on käyttää redundanttia tietoliikenteen ohjausta. Näin varmistetaan, että tietoliikennejärjestelmän päätoiminnot toimivat normaalisti, mikä parantaa järjestelmän luotettavuutta.

 

1 Järjestelmän laitteistokomponentit

MB90F543 on 16-bittinen mikro-ohjain, jossa on kaksi Fujitsun CAN-ohjainta. Järjestelmä käyttää kahta väyläsarjaa (CAN0, CAN1), joista jokainen sisältää itsenäisiä väyläkaapeleita, väyläohjaimia ja väyläohjaimia, jotka voivat toteuttaa fyysisen median, fyysisen kerroksen, datalinkkikerroksen ja sovelluskerroksen täyden redundanssin. Kaksi väyläsarjaa toimivat hot backup -tilassa: yksi CAN-ohjain toimii oletus-CAN-järjestelmänä sen jälkeen, kun järjestelmä on päällä (jota voidaan kutsua master-CAN:ksi); toinen toimii järjestelmän valmiustila-CAN:na (jota kutsutaan orja-CAN:ksi) ja toimii redundanssina isäntä-CAN:lle. Kun järjestelmä toimii normaalisti, isäntä CAN-väylä (CAN0) otetaan käyttöön. Kun isäntä CAN-väylä epäonnistuu, orja-CAN-väylä (CAN1) käynnistyy. Jos käynnistys havaitsee vian isäntä-CAN-väylässä, orja-CAN-väylä otetaan automaattisesti käyttöön. Tällä tavalla, kun yksi väyläsarja epäonnistuu, toinen väyläjoukko jatkaa automaattisesti toimintaansa varmistaakseen koko järjestelmän viestintätoiminnon normaalin toiminnan, mikä parantaa huomattavasti järjestelmän luotettavuutta ja toteuttaa CAN-väylän kattavan redundanssisuunnittelun. Lisäksi ohjelmiston tarpeiden mukaan voidaan myös asettaa redundantti- tai ei-toistettu{17}}tila. Ei-redundantissa tilassa käytetään vain pää-CAN-väylää.

info-1-1                               Järjestelmäarkkitehtuurin lohkokaavio

 

RT on väylän päätteen sovitusvastus, jota käytetään vaimentamaan signaalin säteilyhäiriöitä, RT=100Ω tai 120 Ω. Verkko käyttää suojattua kierrettyä parikaapelia viestintävälineenä.


CAN-ohjain integroi CAN-protokollan fyysisen kerroksen ja datalinkkikerroksen toiminnot ja voi suorittaa tietoliikenteen kehystysprosessin, mukaan lukien bittitäyte, datalohkokoodaus, CRC-tarkistussumma ja prioriteettierottelu.


CAN-ohjaimella on seuraavat pääominaisuudet:

◇ Yhteensopiva CAN2.0A- ja CAN2.0B-protokollien kanssa.

◇ Tukee datakehysten ja etäkehysten lähettämistä ja vastaanottoa.

◇ 16 lähetys-/vastaanottopuskuria, jotka tukevat 11-- tai 29--bittisiä tunnisteita ja moni-tason viestipuskurirakennetta; ◇ Tukee täydellistä-bittien vertailua, täyden bitin vertailua ja täyden bitin vertailua.

◇ Tukee kolmea hyväksyntätunnistuksen valintamenetelmää: täydellinen-bittivertailu, täydellinen-bittisuojaus ja bittipeitehyväksyntä; ◇ Kaksi vastaanottotunnusrekisteriä.

◇ Kaksi hyväksymistunnistusrekisteriä tukevat vakiokehys- tai laajennettujen kehysten muotoa.

◇ Tiedonsiirtonopeus on ohjelmoitavissa välillä 10Kbps - 1Mbps.


Väyläohjain ottaa PCA82C250:n rajapintana CAN-ohjaimen ja fyysisen väylän välillä parantaakseen väylän differentiaalista lähetys- ja vastaanottokykyä.

info-1-1

 

2 Järjestelmäohjelmiston suunnittelu

 

2.1 Kaksois-CAN-redundantin ohjaustoiminnon toteutus

 

Kaksois-CAN-redundanssijärjestelmässä ohjelmistosuunnittelu on laitteistorakenteeseen verrattuna suhteellisen monimutkaisempi. Yleisen CAN-väylän tietoliikenneohjelman tulee sisältää kolme perusosaa: CAN-alustusohjelma, CAN-lähetysohjelma ja CAN-vastaanotto-ohjelma. Tässä redundantissa järjestelmäohjelmiston suunnittelussa edellä mainittuja kolmea osaa käytetään kolmena perusmoduulina järjestelmän muiden ohjelmistomoduulien kutsumiseksi.


MB90F543 pystyy käsittelemään 256 erilaista keskeytyslähdettä, ja CAN-ohjaimeen liittyy neljä laitteistokeskeytystä: CAN0 RX (CAN0 vastaanotto täydellinen keskeytys), CAN0 TX /NS (CAN0 lähetys valmis/solmun tilamuutos keskeytys), CAN1 RX (CAN1 vastaanottaa täydellinen keskeytys), CAN1 tilanmuutos keskeytys /NS ei (CAN1 tilanmuutos lähetä /NS). CAN1 TX /NS (CAN1 lähetys valmis/solmun tilan muutoskeskeytys). Tässä ohjelmistosuunnittelussa käytetään kyselyn lähetystä ja keskeytysvastaanottoa. Solmun tilan muutosten keskeytysalirutiinia käytetään solmun tilan muutoksen käsittelyyn. Tämä johtuu siitä, että CAN2.0-protokolla määrittää, että solmu on jossakin seuraavista kolmesta tilasta: virhe-aktivoitu tila, virhe-ohitattu tila ja off{20}}väylätila. MB90500-sarjassa on myös lisävaroitustila, joka ilmaisee, että lähetys/vastaanottovirhelaskurin arvo on ylittänyt arvon 96 ja solmun tilan muutos aiheuttaa vastaavan keskeytyksen.


Koska järjestelmä toimii kahden CAN-redundanssin kuumavalmiustilassa, molempien CAN-ohjainten on oltava hot standby -tilassa. Järjestelmän kaikkien solmujen molemmat CAN-ohjaimet on alustettu olemaan valmiita vastaanottamaan viestejä milloin tahansa, mutta yksi ja vain yksi CAN-ohjain lähettää viestejä. Toisin sanoen jossain vaiheessa vain yksi CAN-kanava on aktiivinen, kun taas toinen kuuntelee (normaalikäytössä) tai vikatilassa (vian sattuessa).


Avain kaksois-CAN-redundantin ohjausjärjestelmän ohjelmistosuunnittelun monimutkaisuuteen verrattuna yhteen CAN-ohjausjärjestelmään on CAN-järjestelmän vian havaitsemisessa ja CAN-järjestelmän automaattisessa vaihtamisessa. Koska käytössä on kaksi täysin riippumatonta tiedonsiirtovälinesarjaa, väyläohjaimia ja väyläohjaimia, joten ne voidaan havaita riippumatta niiden omista kanavavioista, kuten CANH- ja CANL-oikosulku-, CANH- tai CANL-katkos, CANH- ja maaoikosulku-, CANL- ja virtaoikosulku-väylän ohjainvauriot, ja niin edelleen. Varsinaisessa virheenkorjauksessa havaitaan, että jos CANH, CANL on irrotettu tai väylällä on vain yksi lähetin, se aiheuttaa lähetys/vastaanottovirhelaskurin nousevan arvoon 128, mikä asettaa solmun huomiotta jätettyyn virhetilaan; ja oikosulku CANH:n ja CANL:n välillä, oikosulku-CANH:n ja maan välillä tai oikosulku-CANL:n ja virtalähteen välillä aiheuttaa lähetys-/vastaanottovirhelaskurin nousemisen arvoon 256, mikä asettaa solmun väylä Disconnected-tilaan. Siksi kutsumalla CAN-redundanssimoduulia solmun tilanmuutoskeskeytysalirutiinissa voimme saavuttaa yllä mainitun automaattisen vian havaitsemisen ja CAN-järjestelmän automaattisen kytkennän tavoitteen. CAN0-solmun tilanmuutoskeskeytysaliohjelma on seuraava:

 

__interrupt void NodeStateTransmitInt0 (void)

{

if (CSR0_NT) /* solmun tilan muutos */

{

CSR0_NT=0; /*Keskeytyslipun nollaus */

if ( (CSR0_NS==2 ) (CSR0_NS==3 ) ) /* keskeytyksen tai oikosulun aiheuttanut */

{

NoWaitFlg=1; /* toisensa poissulkeva lippu */

Bus0Error( ); /* Bus0Error( ) pysäyttää CAN0:n ja käynnistää redundantin CAN1-alirutiinin */ { NoWaitFlg=1; /* mutex-lippu */

}

}

ICR00 =3; /* muuta keskeytysprioriteetiksi Timer0 keskeytysprioriteetti */ }

ICR03 =2; /* Muuta keskeytysprioriteettia priorisoidaksesi ajastimen 0 keskeytys */ }

}

 

Lisäksi CAN-väyläviestintäprosessissa, kun tietyn tietopuskurin tiedonsiirto on valmis, siirron valmistumisrekisterin vastaava bitti asetetaan arvoon 1. Lähetyksen kyselyprosessissa tätä rekisteriä arvioimalla voit tietää, onko lähetys valmis vai ei. Jos lähetys ei kuitenkaan onnistu, se saa järjestelmän odottamaan koko ajan ja aiheuttaa järjestelmän kaatumisen. Siksi ohjelmiston on asetettava tähän odotusaika, jonka jälkeen CAN-redundanssijärjestelmää kutsutaan pysäyttämään isäntä CAN-kanava ja sallimaan orja-CAN-kanava.


Ohjelmiston suunnittelussa tulee kiinnittää huomiota myös siihen ongelmaan, kuinka alkuperäinen viestintätehtävä palautetaan vara-CAN-vaihdon jälkeen. Ratkaisu on laatia luettelo tehtäväliput, valmiustilassa CAN-kytkentä, lukea taulukko saadaksesi alkuperäisen tehtävän järjestelmän saavuttamiseksi alkuperäisen viestintätehtävän luotettavan vaihtamisen.


2.2 Väylänhallintatoiminnon toteutus


Tämän järjestelmän ohjelmistosuunnittelussa se sisältää reaaliaikaisen-tiedonsiirto- ja vastaanottoohjelman lisäksi myös viestintähallintaohjelman kunkin solmun hallintaa varten. Kaikki solmut on jaettu pääsolmuihin ja orjasolmuihin. Niiden välinen ero on, että pääsolmussa on väylänhallintatoiminto, jonka avulla se voi suorittaa online-solmutilastoja, tunnistaa offline-solmut ja ryhtyä toimenpiteisiin niiden käsittelemiseksi; kun taas orjasolmulla ei ole tätä toimintoa. Pääsolmuja on vain yksi, mutta useita orjasolmuja sallitaan. Pääsolmun väylänhallintatoimintoohjelma, jota kutsutaan silloin tällöin määrittämään, ovatko kaikki solmut online-tilassa: jos kaikki solmut ovat online-tilassa, väylää pidetään normaalina; muussa tapauksessa tunnista offline-solmut ja käsittele niitä vastaavasti. Suunnitteluideana on, että järjestelmän isäntäsolmu lähettää etäkehyksen kaikille väylän orjasolmuille säännöllisin väliajoin, ja jokainen orjasolmu vastaanottaa sen, laittaa oman solmunumeronsa datakehykseen ja lähettää sen isäntäsolmulle, ja isäntäsolmu määrittää vastaanottamansa solmunumeron perusteella, onko solmuvirhe offline-tilassa. Tässä järjestelmässä solmun numero (moduulin osoite) asetetaan moduulin DIP-kytkimellä.

 

Ohjelmiston virheenkorjausprosessissa, vaikka kunkin solmun laitteistorakenne on sama, piirilevyjen johdotuksen ja komponenttien hajoamisen eroista johtuen usein käy niin, etteivät kaikki orjasolmut pysty vastaanottamaan isäntäsolmun lähettämää tietoa tai isäntäsolmu ei vastaanota kaikkea orjasolmujen lähettämää tietoa, eli kyseessä on kehyshäviöongelma. Tämä ongelma on ratkaistu ohjelmistoviiveellä ja vastaanottavan keskeytysohjelman optimoinnilla.


3 Kehitysympäristössä ja sovelluksessa tulee kiinnittää huomiota useisiin seikkoihin


Softune V3 -ohjelmistotyöpöytä on integroitu ohjelmistokehitysympäristö Fujitsu FFMC-8L-, FFMC-16L/LX- ja FR-sarjan mikro-ohjainohjelmien kehittämiseen, mukaan lukien kehityshallinta, emulaattorin virheenkorjaus, pehmeä simulointi ja integroitu kehitysympäristö. Sen kehitystyökalupakki sisältää Softune Workbenchin, C-kääntäjän, Assemblerin, Linkerin, C Checkerin, C Analyzerin. Softune V3 tukee sekä C- että assembly-kieliä.


Seuraavat ongelmat tulee huomioida MB90F543:n todellisen käytön aikana.


① Hyväksyntämerkin valintarekisterin (AMSR) asetus. Jokainen viestipuskuri voi valita yhden hyväksymismerkintämenetelmän: täyden bitin vertailun, täyden bitimaskin tai bitimaskin hyväksynnän. Täysi-bittivertailu tarkoittaa, että solmun vastaanottaman tiedon tunnuksen on oltava täsmälleen sama kuin tietopuskurin asettama ID, jotta tiedot läpäisivät hyväksymistunnisteen. full-bit masking ei tarvitse verrata informaation tunnusta, joka voidaan tulkita hyväksymistunnisteen ehdottomaksi välitykseksi; bit-masking hyväksyntä voi määrittää verrattavat ID-bitit ja maskattavat ID-bitit eli osittain vertailla hyväksyntää. Käytännössä tätä hyväksyntätunnistemenetelmää käytetään useimmiten, joten MB90F543-sirun CAN-ohjaimessa on asetettu kaksi tällaista menetelmää. AMSR-asetus tarjoaa kehittäjälle suuren joustavuuden puskuritietojen käsittelyssä.


② Hyväksymismerkintärekisterin (AMR) asetus. Kun AMSR on asetettu bitti On kuitenkin syytä huomata, että 29-bittisessä ID-merkissä käytetään AM28~AM0; kun taas 11-bittisessä ID-merkissä käytetään AM28-AM18. siksi käyttäjän on oltava varovainen AMR:ää asettaessaan, muuten se johtaa vastaanottovirheeseen. Kirjoittaja on kärsinyt täällä.


③ Yksi Fujitsun CAN-ohjaimen ominaisuuksista on, että se tukee moni{0}}tason viestipuskurien käyttöä. Jos vastaanotto tapahtuu usein tai vastaanotetaan useita erilaisia ​​ID-tietokehyksiä, on mahdollista, että CPU:lla ei ole tarpeeksi aikaa käsitellä vastaanotettuja tietoja, joten useista tietopuskureista voidaan muodostaa monitasoinen tietopuskuri varmistaakseen, että tiedot voidaan käsitellä oikea-aikaisesti ja tehokkaasti. Tällä tavalla yli 8 tavua suurempia tietoja voidaan lähettää yhdessä kehyksessä. Toinen tämän järjestelyn etu on, että CPU pystyy lukemaan tietyn tietopuskurin tiedot ilman, että sen tarvitsee huolehtia puskuritietojen uudelleenkirjoituksesta ja katoamisesta välittömästi.


4 Johtopäätös


CAN-sovelluskerroksen protokollan kehitysprosessissa lainataan joitakin DeviceNet-määrittelyn mekanismeja, kuten useiden tiedonsiirtomuotojen tukeminen (selektiivinen passi, kysely, tilanmuutos jne.); Kuitenkin monien tekijöiden, kuten kehityssyklin, rajoitusten vuoksi laitteen diagnostiikkatoimintoa sekä yhteentoimivuutta vastaavien tuotteiden kanssa on parannettava ja laajennettava. Kaksois-CAN-redundanttiviestintäjärjestelmä toimii vakaasti kokeellisessa vaiheessa, tiedonsiirto on luotettavaa, redundanssikytkentä on mahdollista ja väylänhallinnan luotettavuus on hyvä; sitä voidaan soveltaa veturien ohjausjärjestelmään tai muihin korkeaa luotettavuutta vaativiin teollisuuden ohjauskohteisiin.

Lähetä kysely

whatsapp

Puhelin

Sähköposti

Tutkimus