1 Introduksjon
Mikrokontrollere brukes i økende grad i automatiserte kontrollenheter, mikroprosessor-baserte integrerte beskyttelsessystemer for strømnett og andre industrielle automatiseringskontrollfelt, med kompleksiteten til disse enhetene som øker jevnt og trutt. For å imøtekomme sanntids-, multi{3}}oppdragskravene til utviklingsmål, blir den enkle-CPU-en, enkelt-utviklermodellen erstattet av en samarbeidstilnærming som involverer flere CPUer av ulike typer og flere utviklere. Dette nye utviklingsparadigmet introduserer en kritisk utfordring: standardisering av maskinvare og programvare for informasjonsutveksling mellom CPUer under implementering. Denne standardiseringen er sentral for vellykket bruk av denne nye modellen. Blant mange kommunikasjonsmetoder er den UART-baserte RS-485 seriell kommunikasjonsprotokollen mye brukt på grunn av dens enkle kabling, høye pålitelighet og evne til å støtte flere CPUer. Når det gjelder programvarekommunikasjonsprotokoller, tilbyr Modbus-protokollen betydelige fordeler for brukere på grunn av dens universelle natur og modne feilsøkingsprogramvare. Derfor, under utviklingen av den nye omfattende motorbeskyttelsesenheten, ble RS-485-seriekommunikasjonsmetoden og Modbus-kommunikasjonsprotokollen tatt i bruk for å oppnå data- og kontrollkommandoinformasjonsutveksling mellom flere CPUer. For å forbedre effektiviteten og koordineringen av seriell kommunikasjon, implementerte forfatteren en rekke tiltak i maskinvare- og programvarearkitekturen til kommunikasjonsmekanismen, og oppnådde utmerkede resultater. Under systemkommunikasjonsfeilsøkingsfasen ble det brukt en metode der hver CPU-modul først kommuniserte med standard Modbus-testprogramvare før de gjennomgikk gjensidig sammenkoblingsfeilsøking, noe som betydelig forbedret samarbeidsutviklingseffektiviteten. Praksis har vist at denne designfilosofien forenkler systemstrukturen samtidig som den forbedrer enhetens operasjonelle effektivitet og pålitelighet.
2 funksjoner til motorens omfattende beskyttelsesenhet
Utover omfattende beskyttelsesfunksjoner, integrerer motorbeskyttelsesenheten måling, fjernkontroll og kommunikasjonsmuligheter. Dens store-kinesiske LCD-skjerm gir et brukervennlig-grensesnitt. Ved å bruke CAN-busskommunikasjon med overvåkingsverten, danner den et undersystem i et hierarkisk, distribuert understasjonsautomatiseringssystem. For å optimalisere systemfunksjonaliteten for dets multi-krav, ble en multi-CPU-arkitektur tatt i bruk. Én CPU håndterer periodisk pulssampling og overføring; CPU-hovedmodulen styrer databehandling, beregning av elektriske parametere, feildiagnose og bytteoperasjoner; mens kortmodulens CPU overvåker menneskelig-maskininteraksjon og forenkler kommunikasjonen med hovedbeskyttelsesmodulen og overvåkingsverten. Hver CPU-modul har klart definerte oppgaver, noe som letter samarbeidsutvikling av flere ingeniører under implementeringen. Seriell kommunikasjon kobler sammen hoved-CPU og panel-CPU, noe som muliggjør menneskelig-maskininteraksjon og dermed inntar en kritisk posisjon. Etablering av en rasjonell kommunikasjonsmekanisme er kjernen i seriekommunikasjonsseksjonen, som bestemmer kommunikasjonskoordinering og feilsøkingseffektivitet under de senere stadier av systemutvikling.
3 Introduksjon til kommunikasjonsmekanismer
3.1 Maskinvaredesign av kommunikasjonsmekanismen
Kommunikasjonsmekanismen som er foreslått for dette systemet tar sikte på høy effektivitet og pålitelighet. RS-485 bruker en halv-dupleksstruktur, som ofte er mer praktisk enn full dupleks i feltapplikasjoner. Her benyttes en forenklet tilkobling med kun to signallinjer. Systemgrensesnittkretsdiagrammet er vist i figur 1. TTL-logikknivåene som sendes ut av 8051-mikrokontrolleren på hovedbeskyttelsesmodulen er optisk isolert, og deretter konvertert til RS-495-nivåer av MAX485-brikken. Deretter konverterer MAX485-brikken på panelmodulen disse tilbake til TTL-logiske nivåer for lesing av 8031-mikrokontrolleren. På 8051-mikrokontrollersiden kontrollerer pin P2.7 til parallell I/O-port 2 MAX-inngangsaktiveringspinne RE og utgangsaktiveringspinne DE. Som vist i figur 1, når P2.7 sender ut et høyt nivå, er RE aktivert, slik at mikrokontrollersiden kan motta data. Når P2.7 sender ut et lavt nivå, er DE aktivert, slik at mikrokontrollersiden kan overføre data. Denne tilnærmingen forhindrer tap av data på grunn av overlapping forårsaket av blind overføring, og sikrer høy kommunikasjonskvalitet og pålitelig overføringshastighet.
3.2 Kommunikasjonsprotokoll
For å sikre nøyaktig dataoverføring mellom to moduler i beskyttelsesenheten, er et sett med spesifikasjoner som styrer informasjonsoverføring-inkludert overføringsmoduser, dataformater og innhold-essensielt. Dette utgjør protokollen eller kommunikasjonsprotokollen. Uten lett tilgjengelig, moden feilsøkingsprogramvare fungerer hoved-CPU-modulen i hovedsak som en svart boks, noe som fører til mange og vanskelige-å-utfordringer under systemintegrasjonstesting. Derfor ble den bredt vedtatte Modbus-kommunikasjonsprotokollen valgt og forenklet for å passe enhetens spesifikke krav, noe som muliggjør vellykket inter-modulkommunikasjon med bevist effektivitet. Modbus bruker en master-slavekommunikasjonsmodell. Masteren sender først en kommunikasjonsforespørselskommando til slaven. Slaven svarer deretter masteren med data basert på funksjonskoden i forespørselskommandoen. Hver slave har en unik adresse. Både forespørselsrammene sendt av masteren og svarrammene sendt av slaven begynner med slavens adresse. Slaver leser bare kommandoer adressert til seg selv og ignorerer meldinger som starter med andre slaveadresser. Denne funksjonaliteten er implementert ved å bruke 8051-serieportens modus 2 eller modus 3. Denne kommunikasjonsmodellen for spørsmål-og-svar forbedrer kommunikasjonsnøyaktigheten betydelig. RTU-overføringsmodusen til Modbus er tatt i bruk i denne enheten.
4 Tiltak for å forbedre kommunikasjonspålitelighet
De siste to bytene av en Modbus-melding fungerer som kontrollsumbyte. RTU-kommunikasjon bruker CRC-16 syklisk redundanssjekk for feildeteksjon. Dens kodings-/dekodingsmekanisme er relativt enkel med lav feilrate, oppnåelig gjennom beregnings- eller programmeringsmetoder. Flere tilnærminger er skissert nedenfor:
4.1 Grunnleggende algoritme (manuell beregning)
Ved å bruke CRC16-CCITT som et eksempel: CRC-sjekksummen er 16 biter, og det genererende polynomet er 17 biter. Anta at datastrømmen er på 4 byte: BYTE, BYTE, BYTE, BYTE[0];
Skift datastrømmen igjen med 16 biter, og utvider den effektivt med en faktor på 256×256. Utfør deretter divisjon med generatorpolynomet 0x11021 ved å bruke ikke-lånedivisjon (tilsvarer bitvis XOR). Den resulterende resten er CRC-sjekksummen. Den overførte datastrømmen består av 6 byte: BYTE, BYTE, BYTE, BYTE[0], CRC, CRC[0].
4.2 Computer Algorithm 1 (Bit-Type Algorithm)
1) Plasser de øvre 16 bitene (BYTE, BYTE) av den utvidede datastrømmen (6 bytes) i et 16-bits register;
2) Hvis den mest signifikante biten i registeret er 1, skift registeret til venstre med én bit (oppnå den minst signifikante biten fra neste byte), utfør deretter en XOR-operasjon med den forenklede formen til generatorpolynomet; ellers, forskyv registeret til venstre med én bit (oppnå den minst signifikante biten fra neste byte);
3) Gjenta trinn 2 til hele datastrømmen (6 byte) er flyttet inn i registeret;
4) Verdien i registeret er CRC sjekksum CRC, CRC[0].
4.3 Computer Algorithm 2 (Byte-Type Algorithm) (256^n angir 256 hevet til n)
Representer den byte--ordnede datastrømmen som et matematisk polynom. La datastrømmen være BYTE[n] BYTE[n-1] BYTE[n-2] ... BYTE[0] er representert som det matematiske uttrykket
BYTE[n] × 256^n + BYTE[n-1] × 256^(n-1) + ... + BYTE × 256 + BYTE[0], der "+" angir XOR-operasjonen. La generatorpolynomet være G17 (17-bit), så er CRC-koden CRC16.
CRC16=(BYTE[n] × 256^n + BYTE[n-1] × 256^(n-1) + ... + BYTE × 256 + BYTE[0]) × 256^2 / G17
Dette innebærer å forskyve datastrømmen til venstre med 16 biter og deretter dele med generatorpolynomet G17.
Utledning viser at CRC-sjekkkoden for BYTE[n-1] er lik XOR-resultatet av de øvre 8 bitene av forrige bytes CRC-sjekkkode Y[n] (YH8[n]) og gjeldende byte BYTE[n-1].
Algoritmen av byte-type er som følger:
1) Initialiser CRC-registergruppen til alle "0" (0x0000).
2) Skift CRC-registergruppen 8 biter til venstre og lagre den i CRC-registergruppen.
3) Utfør en XOR-operasjon mellom den opprinnelige CRC-registergruppens høye 8 bits (forskyvd 8 biter til høyre) og databyten for å få en indeks som peker til verditabellen.
4) Utfør en XOR-operasjon mellom tabellverdien pekt på av indeksen og CRC-registergruppen.
5) Øk datapekeren. Hvis databehandlingen ikke er fullført, gjenta trinn 2).
6) Skaff CRC.
5 tiltak for å forbedre kommunikasjonseffektiviteten
5.1 Separate kommunikasjonsmottaks- og overføringsoppgaver
8051-mikrokontrolleren kan overføre og motta data via den serielle porten ved hjelp av avbrudd. Seriell portkontrolleren SCON støtter initialisering og bitadressering. Når en seriell portavbruddsforespørsel oppstår, låser de to nederste bitene av SCON sende- og mottaksavbruddene. Når CPUen skriver data eller et tegn til den serielle portens sendebuffer SUBF (instruksjon: MOV SUBF, A) begynner senderen å sende. Etter å ha fullført én dataramme, setter maskinvaren TI-flagget til "1", noe som indikerer at serieporten ber om et avbrudd fra CPU for å sende neste dataramme. Tilsvarende, hvis serieportmottakeren er aktivert for mottak, ved mottak av en dataramme, settes RI-flagget til 1, noe som indikerer at den serielle porten ber om et avbrudd fra CPU for å lese data fra mottaksdatabufferen.
5.2 Redusere avbruddsvarighet
Siden flere avbrudd brukes i programvarearkitekturdesignet, for å sikre pålitelig programdrift og minimere sannsynligheten for konflikter mellom forskjellige oppgaver, bør programvareimplementeringen strebe etter å strømlinjeforme oppgavene til forskjellige avbrudd og forkorte utførelsestiden. Innenfor kommunikasjonsavbruddssubrutinen, utfør viktige oppgaver når du går inn i avbruddet, slik som: sletting av de tilsvarende statusbitene i serieportkontrollregisteret, lesing av mottatte tegn eller skriving av tegn som skal overføres fra/til bufferen, øke antallet mottatte eller overførte tegn, etc. Avslutt deretter avbruddet umiddelbart. Andre oppgaver, som å validere rammer, svare på mottatte rammekommandoer (telemetri/telekommando), og forberede overføringsrammer, bør håndteres i hovedprogrammet.
5.3 Effektiv rammeavslutningsdeteksjon for å hindre kommunikasjonsstagnasjon
Å bruke en dedikert programvaretimer for å oppdage slutten av en mottatt ramme forhindrer kommunikasjonsoppgaver i å dvele hvis en ramme mottas ufullstendig, og sikrer dermed rettidig mottak av påfølgende rammer. Siden tidsintervallet mellom byte innenfor en ramme er mye kortere enn rammeintervallet-til-, startes programvaretimeren hver gang en ny byte mottas. Tidtakeren er satt til minimumsintervallet mellom bilde-til-bilde. Dette intervallet varierer med forskjellige overføringshastigheter. Hvis neste byte mottas før den forhåndsinnstilte tiden går ut, indikerer det at rammen er ufullstendig, og timeren starter på nytt. Hvis timeren teller ned til den forhåndsinnstilte tiden, utløser den det tilsvarende avbruddsnummeret. Innenfor timeravbruddssubrutinen settes rammesluttflaggbyten, noe som betyr at rammemottaket er fullført. Etter at masterprogrammet har oppdaget en fullføring av rammemottak, validerer det rammens integritet ved å verifisere slaveadressen og syklisk redundanssjekk (CRC) byte. Hvis bekreftet som en gyldig ramme beregnet på masteren, behandler den rammekommandoen basert på funksjonskoden og forbereder seg på å sende en ramme. Når slaven mottar en feil melding, sender den tilbake en feilramme. Hvis den mottatte meldingen har en feil CRC, kan slaven velge å ikke svare. Hvis masteren ikke mottar svar fra slaven innen den angitte tiden, vil den sende forespørselsmeldingen på nytt. Hvis flere reoverføringer ikke mottar et svar fra slaven, rapporteres en kommunikasjonsfeil.
5.4 Bestemme kommunikasjonshastighet
Siden alle enheter befinner seg innenfor samme chassis, er avstanden mellom modulene minimal. Modbus opererer på RS485 for langdistansekommunikasjon, og eliminerer behovet for å vurdere avstandseffekter på baudhastigheten. Videre forhindrer kommunikasjonsmodusen for master-slave linjeoverbelastning. Derfor, fra et kommunikasjonseffektivitetsperspektiv, så lenge den innstilte overføringshastigheten ikke overskrider maksimal overføringshastighetsgrense for brikken som brukes i modulen, resulterer en høyere overføringshastighet i raskere informasjonsutveksling og høyere kommunikasjonseffektivitet. Innstilling av overføringshastigheten til å være nøyaktig den samme for begge kommunikasjonspartene sikrer at mottakerenden sampler hver databit ved midtpunktet av bitsyklusen, for derved å oppnå pålitelig kommunikasjon.
5.5 Rimelige feilsøkingsmetoder
Under feilsøking, test først kommunikasjonen mellom hver CPU-modul og mikrodatamaskinen via RS485/RS232-datakonverteringsmodulen. Etter vellykket individuell testing, fortsett til inter-modul-feilsøking, noe som forbedrer den generelle feilsøkingseffektiviteten betydelig. Under modul-til-datakommunikasjonsfeilsøking, bruker datamaskinen Modbus-feilsøkingsprogramvare for å simulere masterens kommunikasjonsprosess, og ber aktivt om informasjon fra slaven. Dette gjør hele mottaks- og overføringsprosessen transparent og oversiktlig, noe som muliggjør rettidig løsning av modulproblemer. Under felles debugging observerer bussovervåkingsprogramvaren data fra begge sider for raskt å identifisere og løse problemer.
6 innovasjonspunkter i denne artikkelen
For det første bruker denne artikkelen Modbus, en universell industristandard, i beskyttelsesenheten. Den nødvendige verktøyprogramvaren kan fås direkte fra relevante nettsteder uten å pådra seg immaterielle kostnader. For det andre implementerer beskyttelsesenheten multitasking og bruker Modbus-protokollen for å skape en rimelig felles feilsøkingsmekanisme mellom CPU-moduler, noe som i stor grad forbedrer effektiviteten av samarbeidende systemutvikling.