Immunitetsbevisst programmering - Immunity-aware programming

Når du skriver firmware for et innebygd system , refererer immunitetsbevisst programmering til programmeringsteknikker som forbedrer toleransen for forbigående feil i programtelleren eller andre moduler i et program som ellers vil føre til feil. Forbigående feil er vanligvis forårsaket av forstyrrelser fra en enkelt hendelse , utilstrekkelig kraft eller av sterke elektromagnetiske signaler overført av en annen "kilde" -enhet.

Immunitetsbevisst programmering er et eksempel på defensiv programmering og EMC-bevisst programmering . Selv om de fleste av disse teknikkene gjelder programvaren i "offer" -enheten for å gjøre den mer pålitelig, gjelder noen få av disse teknikkene programvare i "kilde" -enheten for å få den til å avgi mindre uønsket støy.

Oppgave og mål

Mikrokontrollere ' fastvare kan billig forbedre elektromagnetisk kompatibilitet av en innebygd system .

Fastvare for innebygde systemer anses vanligvis ikke å være en kilde til radiofrekvensinterferens . Radioutslipp er ofte forårsaket av harmoniske frekvenser i systemklokken og svitsjestrømmer. Pulsen på disse ledningene kan ha rask stigning og falltid, noe som får ledningene til å fungere som radiosendere. Denne effekten økes av dårlig utformede kretskort . Disse effektene reduseres ved å bruke mikrocontroller-utgangsdrivere med langsommere økningstider, eller ved å slå av systemkomponenter.

Mikrokontrolleren er enkel å kontrollere. Det er også utsatt for feil fra radiofrekvensinterferens. Derfor kan det å gjøre mikrokontrollers programvare motstå slike feil billig forbedre systemets toleranse for elektromagnetisk interferens ved å redusere behovet for maskinvareendringer.

Mulige forstyrrelser av mikrokontroller-baserte systemer

CMOS- mikrokontrollere har spesifikke svake punkter som kan styrkes av programvare som virker mot elektromagnetisk interferens. Feilmodus og effektanalyse av et system og dets krav er ofte påkrevd. Elektromagnetisk kompatibilitetsproblemer kan lett legges til en slik analyse.

Strømforsyning

Sakte endringer i strømforsyningsspenningen forårsaker ikke betydelige forstyrrelser, men raske endringer kan gjøre uforutsigbare problemer. Hvis en spenning overskrider parametrene i kontrollerens datablad med 150 prosent, kan det føre til at inngangsporten eller utgangsporten henger i en tilstand, kjent som CMOS -låsing . Uten intern strømkontroll fører låsing til at mikrokontrolleren brenner ut. Standardløsningen er en blanding av programvare- og maskinvareendringer. De fleste innebygde systemer har en vakthundtimer . Denne vakthunden skal være utenfor mikrokontrolleren, slik at den sannsynligvis vil være immun mot plausibel elektromagnetisk forstyrrelse. Den skal tilbakestille strømforsyningen og slå den av kort. Vakthundperioden bør være halvparten eller mindre av den tiden og kraften som kreves for å brenne ut mikrokontrolleren. Strømforsyningen skal være jordet og frakoblet ved hjelp av kondensatorer og induktorer nær mikrokontrolleren. noen typiske verdier er 100uF og 0.1uF parallelt.

Lav effekt kan forårsake alvorlige funksjonsfeil i de fleste mikrokontrollere. For at CPUen skal kunne dekode og utføre instruksjoner, må den medfølgende spenningen ikke synke under minimumsspenningsnivået. Når den medfølgende spenningen faller under dette nivået, kan det hende at CPU-en begynner å utføre noen instruksjoner feil. Resultatet er uventet aktivitet på de interne data- og kontrollinjene. Denne aktiviteten kan forårsake:

  • CPU-registerkorrupsjon
  • I / O registrerer korrupsjon
  • I / O-pin tilfeldig veksling
  • SRAM korrupsjon
  • EEPROM korrupsjon

Utbruddsdeteksjon løser de fleste av disse problemene i de fleste systemer ved å få systemet til å slå seg av når hovedstrømmen er upålitelig. Et typisk system utløser en tidtaker hver gang AC-hovedspenningen overstiger 90% av nominell spenning. Hvis tidtakeren utløper, avbryter den mikrokontrolleren, som deretter slår av systemet. Mange systemer måler også strømforsyningen for å beskytte mot langsom nedbrytning av strømforsyningen.

Oscillatoren

Inngangsportene til CMOS- oscillatorer har høye impedanser , og er dermed veldig utsatt for forbigående forstyrrelser. I følge Ohms lov forårsaker høy impedans høyspenningsforskjeller. De er også veldig følsomme for kortslutning fra fuktighet eller støv.

En typisk feil er når oscillatorenes stabilitet påvirkes. Dette kan føre til at den stopper, eller endrer perioden. De normale systemhekkene er å ha en hjelposcillator ved hjelp av en billig, robust ordning, for eksempel en ring av omformere eller en motstandskondensator one-shot timer. Etter en tilbakestilling (kanskje forårsaket av en vakthundtimer), kan systemet være standard til disse, bare bytte inn den følsomme krystalloscillatoren når tidsmålingene har vist seg å være stabil. Det er også vanlig i systemer med høy pålitelighet å måle klokkefrekvensen ved å sammenligne den med en ekstern standard, vanligvis en kommunikasjonsklokke, kraftledningen eller en motstandskondensator-tidtaker.

Utbrudd av elektromagnetisk interferens kan forkorte klokkeperioder eller forårsake pulser som fører til feil datatilgang eller utførelse av kommando. Resultatet er feil minneinnhold eller programpekere. Standardmetoden for å overvinne dette i maskinvare er å bruke en faselåst sløyfe på brikken for å generere mikrokontrollers faktiske klokkesignal. Programvare kan med jevne mellomrom verifisere datastrukturer og lese kritiske porter ved hjelp av stemmegivning, distribuere lesningene i tid eller rom.

Inngangs- / utgangsporter

Inngangs- / utgangsporter - inkludert adresselinjer og datalinjer - forbundet med lange linjer eller eksterne periferiutstyr er antennene som tillater forstyrrelser å ha effekter. Elektromagnetisk interferens kan føre til feil data og adresser på disse linjene. Sterke svingninger kan føre til at datamaskinen misles I / O-registre eller til og med stopper kommunikasjonen med disse portene. Elektrostatisk utladning kan faktisk ødelegge porter eller forårsake funksjonsfeil.

De fleste mikrokontrollers pinner er høyimpedansinnganger eller blandede innganger og utganger. Høyimpedansinngangspinner er følsomme for støy, og kan registrere falske nivåer hvis de ikke avsluttes ordentlig. Pins som ikke er avsluttet inne i en IC, trenger motstander festet. Disse må kobles til jord eller forsyning, for å sikre en kjent logisk tilstand.

Image
Årsak og virkningstall. Årsaken må bestemmes, slik at problemet kan løses.

Korrigerende tiltak

En analyse av mulige feil før korreksjon er veldig viktig. Årsaken må bestemmes slik at problemet kan løses.

The Motor Industry Software Pålitelighet Association identifiserer de nødvendige skritt i tilfelle av en feil som følger:

  • Informasjon / advarsel brukeren
  • Lagre feil data til en definert tilbakestilling kan utføres
  • Hold systemet i en definert tilstand til feilen kan rettes

I utgangspunktet bruker man redundans for å motvirke feil. Dette inkluderer å kjøre ekstra kode (redundans i tid) samt beholde ekstra biter (redundans i rommet).

Instruksjonspeker (IP) feilbehandling

En forstyrret instruksjonspeker kan føre til alvorlige feil, for eksempel et udefinert hopp til et vilkårlig punkt i minnet, der ulovlige instruksjoner leses. Systemets tilstand vil være udefinert. IP-feil kan håndteres ved bruk av programvarebaserte løsninger som funksjonstokener og et NOP-lysbilde .

Mange prosessorer, for eksempel Motorola 680x0, har en maskinvarefelle når de møter en ulovlig instruksjon. En riktig instruksjon, definert i fellevektoren, blir utført, i stedet for den tilfeldige. Feller kan håndtere et større utvalg feil enn funksjonstokener og NOP-lysbilder. Tillegg til ulovlige instruksjoner, håndterer maskinvarefeller sikkert brudd på minnetilgang, overløp eller en divisjon med null.

Token passerer (funksjonstoken)

Image
Token passerer som eksekveringsflytekontroll
Image
C kilde: token passerer med global funksjons-ID.

Forbedret støyimmunitet kan oppnås ved utførelsesflytekontroll kjent som tokenpassing. Figuren til høyre viser funksjonsprinsippet skjematisk. Denne metoden omhandler programflytfeil forårsaket av instruksjonspekerne.

Implementeringen er enkel og effektiv. Hver funksjon er merket med en unik funksjons-ID. Når funksjonen kalles, blir funksjons-IDen lagret i en global variabel. Funksjonen utføres bare hvis funksjons-ID-en i den globale variabelen og ID-en for funksjonen samsvarer. Hvis ID-ene ikke samsvarer, har det oppstått en instruksjonspekerfeil, og spesifikke korrigerende tiltak kan utføres. En prøveimplementering av tokenpassering ved hjelp av en global variabel programmert i C er angitt i følgende kildeliste.

Dette er egentlig en "arm / fire" -sekvensering, for hver funksjonsanrop. Å kreve en slik sekvens er en del av sikre programmeringsteknikker, da det genererer toleranse for feil på enkeltbit (eller i dette tilfellet stray instruction pointer).

Implementeringen av funksjonstokener øker programkodestørrelsen med 10 til 20%, og reduserer ytelsen. For å forbedre implementeringen, i stedet for globale variabler som ovenfor, kan funksjons-ID sendes som et argument i funksjonsoverskriften som vist i kodeeksemplet nedenfor.

Image
C kilde: token passerer med funksjonsparametere

NOP-lysbilde

Med NOP-Fills kan påliteligheten til et system i tilfelle en forstyrret instruksjonspeker i noen tilfeller forbedres. Hele programminnet som ikke brukes av programkoden er fylt med NOP- instruksjoner. I maskinkode blir en NOP-instruksjon ofte representert med 0x00 (for eksempel Intel 8051, ATmega16, etc.). Systemet holdes i en definert tilstand. På slutten av det fysiske programminnet må en instruksjonshåndteringsfeilhåndtering (IPEH IP-Error-Handler) implementeres. I noen tilfeller kan dette være en enkel tilbakestilling.

Hvis en instruksjonspekerfeil oppstår under utførelsen, og et program peker på et minnesegment fylt med NOP-instruksjoner, oppstod uunngåelig en feil og gjenkjennes.

Tre metoder for implementering av NOP-Fills er anvendelige:

  • I den første metoden settes det ubrukte fysiske minnet til 0x00 manuelt ved å søke og erstatte i (HEX) programfilen . Ulempen med denne metoden er at dette må gjøres etter hver samling.
Image
Programminne fylt med kode, NOPer og feilbehandler
  • Den andre metoden bruker utfyllingsalternativet til linkeren, som fyller de ubrukte minneområdene med en forhåndsdefinert konstant (i dette tilfellet 0x00).
  • Den tredje måten er å inkludere et tilsvarende antall NOP- monteringsdirektiver direkte i programkoden.

Når du bruker CodevisionAVR C kompilatoren, kan NOP fyllinger enkelt implementeres. Chip programmerer tilbud funksjonen til å redigere programmet flash og EEPROM å fylle det med en bestemt verdi. Ved bruk av Atmel ATmega16 trenger ikke noe hopp til å tilbakestille adresse 0x00 implementeres, da overløpet av instruksjonspekeren automatisk setter verdien til 0x00. Dessverre tilsvarer tilbakestillinger på grunn av overløp ikke tilsiktet tilbakestilling. Under den tiltenkte tilbakestillingen tilbakestilles alle nødvendige MC-registre med maskinvare, noe som ikke gjøres ved å hoppe til 0x00. Så denne metoden vil ikke bli brukt i følgende tester.

Image
Minne før og etter implementeringen av både funksjonstoken og NOP-Fills

I / O-registerfeil

Mikrokontrollerarkitektur krever at I / O-ledningene plasseres ved ytterkanten av silisiumdysen. Dermed påvirkes I / O-kontakter sterkt av forbigående forstyrrelser på vei til silisiumkjernen, og I / O-registre er en av de mest sårbare delene av mikrokontrolleren. Feillesede I / O-registre kan føre til feil systemtilstand. De alvorligste feilene kan oppstå ved tilbakestillingsporten og avbryte inngangsportene. Forstyrrede dataretningsregistre (DDR) kan hemme skriving til bussen.

Disse forstyrrelsene kan forhindres som følger:

1. Syklisk oppdatering av de viktigste registrene

Ved syklisk oppdatering av det viktigste registeret og dataene i dataretningsregistrene i kortest mulig intervaller, kan feil reduseres. Dermed kan en feil satt bit korrigeres før den kan ha negative effekter.

2. Flere avlesning av inngangsregistre

En ytterligere metode for å filtrere forstyrrelser er flere avlesninger av inngangsregister. Innlesningsverdiene blir deretter sjekket for konsistens. Hvis verdiene er konsistente, kan de betraktes som gyldige. En definisjon av et verdiområde og / eller beregning av en middelverdi kan forbedre resultatene for noen applikasjoner.
Bivirkning : økt aktivitet
En ulempe er den økte aktiviteten på grunn av permanente oppdateringer og avlesninger av eksterne enheter. Denne aktiviteten kan gi ytterligere utslipp og feil.
Eksterne avbrytelsesporter; stack overflow
Eksterne avbrudd utløses av fallende / stigende kanter eller høyt / lavt potensial ved avbruddsporten, noe som fører til en avbruddsforespørsel (IRQ) i kontrolleren. Maskinvareavbrudd er delt inn i maskerbare avbrudd og ikke-maskerbare avbrudd (NMI). Utløsningen av maskerbare avbrudd kan stoppes i noen tidskritiske funksjoner. Hvis et avbrudd kalles, blir den nåværende instruksjonspekeren (IP) lagret på stabelen, og stabelpekeren (SP) blir redusert. Adressen til avbruddsrutiner (ISR) leses fra avbruddsvektortabellen og lastes til IP-registeret, og ISR utføres som en konsekvens.
Hvis avbrudd - på grunn av forstyrrelser - genereres raskere enn behandlet, vokser stabelen til alt minne er brukt. Data på stabelen eller andre data kan bli overskrevet. En defensiv programvarestrategi kan brukes. Stakkpekeren (SP) kan sees. Dyrking av stabelen utover en definert adresse kan deretter stoppes. Verdien av stakkpekeren kan kontrolleres ved starten av avbruddsrutinen. Hvis SP peker på en adresse utenfor de definerte stabelgrensene, kan en tilbakestilling utføres.

Dataredundans

I systemer uten feiloppdagelses- og korrigeringsenheter kan systemets pålitelighet forbedres ved å gi beskyttelse gjennom programvare. Å beskytte hele minnet (kode og data) er kanskje ikke praktisk i programvare, da det forårsaker en uakseptabel mengde overhead, men det er en programvare implementert billig løsning for kodesegmenter.

Et annet grunnleggende krav til digitale systemer er feilfri overføring av data. Kommunikasjon med andre komponenter kan være det svake punktet og en kilde til feil i et system. En gjennomtenkt overføringsprotokoll er veldig viktig. Teknikkene beskrevet nedenfor kan også brukes på data som overføres, og dermed øke overføringssikkerheten.

Syklisk redundans og paritetskontroll

En syklisk redundanssjekk er en type hashfunksjon som brukes til å produsere en kontrollsum , som er et lite heltall fra en stor datablokk, for eksempel nettverkstrafikk eller datafiler. CRC beregnes før og etter overføring eller duplisering, og sammenlignes for å bekrefte at de er like. En CRC oppdager alle en- eller to-bits feil, alle rare feil, alle burst-feil hvis burst er mindre enn CRC, og de fleste av wide-burst-feilene. Paritetskontroller kan brukes på enkelttegn (VRC— vertikal redundanskontroll ), noe som resulterer i en ekstra paritetsbit eller på en datablokk (LRC— langsiktig redundanskontroll ), og utsteder et blokkkontrolltegn . Begge metodene kan implementeres ganske enkelt ved å bruke en XOR-operasjon. En avveining er at færre feil kan oppdages enn med CRC. Paritetskontroller oppdager bare oddetall vendt bit. Det jevne antall bitfeil blir ikke oppdaget. En mulig forbedring er bruken av både VRC og LRC, kalt Double Parity eller Optimal Rectangular Code (ORC).

Noen mikrokontrollere har en CRC-enhet for maskinvare.

Ulike typer duplisering

En spesifikk metode for dataredundans er duplisering, som kan brukes på flere måter, som beskrevet i det følgende:

  • Data duplisering
For å takle korrupsjon av data kan flere kopier av viktige registre og variabler lagres. Konsistenssjekker mellom minneplasser som lagrer de samme verdiene, eller stemmeteknikker, kan deretter utføres når du får tilgang til dataene.
To forskjellige modifikasjoner av kildekoden må implementeres.
  • Den første tilsvarer å duplisere noen eller alle programvariablene for å introdusere dataredundans, og endre alle operatørene for å administrere den introduserte replikaen til variablene.
  • Den andre modifikasjonen introduserer konsistenskontroller i kontrollflyten, slik at konsistens mellom de to kopiene av hver variabel blir verifisert.

Når dataene leses opp, sammenlignes de to datasettene. En forstyrrelse oppdages hvis de to datasettene ikke er like. Det kan rapporteres om en feil. Hvis begge datasettene er ødelagt, kan det rapporteres om en betydelig feil, og systemet kan reagere tilsvarende.

I de fleste tilfeller har sikkerhetskritiske applikasjoner strenge begrensninger når det gjelder minneutnyttelse og systemytelse. Kopiering av hele variabelsettet og innføring av en konsistensjekk før hver leseoperasjon representerer det optimale valget fra feildekningssynspunktet. Duplisering av hele variabelsettet gjør det mulig å dekke en ekstremt høy prosentandel av feil med denne programvaredundanseringsteknikken. På den andre siden, ved å duplisere en lavere prosentandel av variabler, kan man bytte ut den oppnådde feildekningen med CPU-tidsomkostningene.

Image
En eksperimentell analyse av CPU-tidsomkostninger og mengden dupliserte variabler

Det eksperimentelle resultatet viser at duplisering av bare 50% av variablene er nok til å dekke 85% av feilene med en CPU-overhead på bare 28%.

Det bør også tas hensyn til implementeringen av konsistenskontrollen, da den vanligvis utføres etter hver leseoperasjon eller på slutten av hver variabels levetid. Å implementere denne kontrollen nøye kan minimere CPU-tid og kodestørrelse for dette programmet.

Image
C eksempelkode: duplisering av funksjonsparameter
Image
C prøvekode: duplisering av testbetingelser
  • Duplisering av funksjonsparameter

Ettersom deteksjonen av feil i data oppnås ved å duplisere alle variablene og legge til konsistenskontroller etter hver leseoperasjon, må det tas spesielle hensyn i henhold til prosedyregrensesnittene. Parametere som sendes til prosedyrer, samt returverdier, anses å være variabler. Derfor er hver prosedyreparameter duplisert, samt returverdiene. En prosedyre kalles fortsatt bare én gang, men den returnerer to resultater, som må ha samme verdi. Kildelisten til høyre viser en eksempelimplementering av duplisering av funksjonsparametere.

  • Test duplisering

Å duplisere en test er en av de mest robuste metodene som eksisterer for generisk deteksjon av myke feil. En ulempe er at det ikke kan gjøres noen streng antagelse om årsaken til feilene (EMI, ESD osv.), Og heller ikke om hvilken type feil du kan forvente (feil som påvirker kontrollflyten, feil som påvirker data osv.). Feilbitte endringer i databytes mens de er lagret i minne, cache, register eller overført på en buss er kjent. Disse databytes kan være operasjonskoder (instruksjoner), minneadresser eller data. Dermed er denne metoden i stand til å oppdage et bredt spekter av feil, og er ikke begrenset til en spesifikk feilmodell. Ved å bruke denne metoden øker minnet omtrent fire ganger, og utførelsestiden er omtrent 2,5 ganger så lang som det samme programmet uten duplisering av testen. Kildeliste til høyre viser en implementering av eksempler på duplisering av testbetingelser.

  • Forgrening duplisering
Image
Gren duplisering

Sammenlignet med test duplisering, hvor en betingelse krysses av, med forgrenings duplisering dupliseres tilstanden.

For hver betinget test i programmet, bør tilstanden og det resulterende hoppet revurderes, som vist i figuren. Bare hvis vilkåret er oppfylt igjen, blir hoppet utført, ellers har det oppstått en feil.

  • Instruks duplisering og mangfold i implementering

Hva er fordelen med når data, tester og grener dupliseres når det beregnede resultatet er feil? En løsning er å duplisere en instruksjon helt, men implementere dem annerledes. Så to forskjellige programmer med samme funksjonalitet, men med forskjellige datasett og forskjellige implementeringer, blir utført. Resultatene deres sammenlignes, og må være like. Denne metoden dekker ikke bare bit-flips eller prosessorfeil, men også programmeringsfeil (bugs). Hvis det er ment å håndtere maskinvarefeil (CPU) feil, kan programvaren implementeres ved hjelp av forskjellige deler av maskinvaren; for eksempel bruker den ene implementeringen en maskinvaremultiplikasjon og den andre implementeringen multipliserer ved å skifte eller legge til. Dette forårsaker en betydelig overhead (mer enn en faktor to for størrelsen på koden). På den annen side er resultatene enestående nøyaktige.

Porter

Tilbakestill porter og avbryt porter

Tilbakestill porter og avbrudd er veldig viktig, da de kan utløses av stigende / fallende kanter eller høyt / lavt potensial ved avbruddsporten. Forbigående forstyrrelser kan føre til uønskede tilbakestillinger eller utløse avbrudd, og dermed føre til at hele systemet krasjer. For hver utløst avbrudd lagres instruksjonspekeren på stabelen, og stabelpekeren blir redusert.

Prøv å redusere mengden kantutløste avbrudd . Hvis avbrudd bare kan utløses med et nivå, hjelper dette med å sikre at støy på en avbryterpinne ikke vil forårsake en uønsket operasjon. Det må huskes at nivåutløste avbrudd kan føre til gjentatte avbrudd så lenge nivået holder seg høyt. I implementeringen må denne egenskapen vurderes; gjentatte uønskede avbrudd må deaktiveres i ISR. Hvis dette ikke er mulig, bør en programvarekontroll på pinnen ved umiddelbar inntasting av en kantutløst avbrudd for å avgjøre om nivået er riktig.

For alle ubrukte avbrudd må en feilhåndteringsrutine implementeres for å holde systemet i en definert tilstand etter en utilsiktet avbrudd.

Utilsiktede tilbakestillinger forstyrrer riktig programutførelse, og er ikke akseptable for omfattende applikasjoner eller sikkerhetskritiske systemer.

Tilbakestill differensiering (kald / varm start)

Et hyppig systemkrav er automatisk gjenopptakelse av arbeid etter en forstyrrelse / forstyrrelse. Det kan være nyttig å registrere tilstanden til et system ved avslutning og å lagre dataene i et ikke-flyktig minne. Ved oppstart kan systemet evaluere om systemet starter på nytt på grunn av forstyrrelse eller feil (varm start), og systemstatusen kan gjenopprettes eller en feil kan angis. Ved kaldstart kan de lagrede dataene i minnet betraktes som gyldige.

Måling av eksternt strømforbruk

Image
Hard- og programvarekombinasjon: påvisning av svingninger i strømforsyningen ved hjelp av en AD-omformer

Denne metoden er en kombinasjon av hard- og programvareimplementeringer. Den foreslår en enkel krets for å oppdage en elektromagnetisk interferens ved hjelp av enhetens egne ressurser. De fleste mikrokontrollere, som ATmega16, integrerer analoge til digitale omformere (ADCer), som kan brukes til å oppdage uvanlige svingninger i strømforsyningen forårsaket av forstyrrelser.

Når en forstyrrelse oppdages av programvaren, kan mikrokontrolleren komme inn i en sikker tilstand mens den venter på at aggresjonen skal passere. Under denne sikre tilstanden er ingen kritiske henrettelser tillatt. Grafikken viser hvordan interferensdeteksjon kan utføres. Denne teknikken kan enkelt brukes med hvilken som helst mikrokontroller som har en AD-omformer.

Vakthund

En vakthundtimer er en elektronisk tidtaker som oppdager unormal drift av andre komponenter og setter i gang korrigerende tiltak for å gjenopprette normal drift. Det sørger spesielt for at mikrokontrollerkontrollerte enheter ikke mislykkes helt hvis det oppstår en programvarefeil eller en midlertidig maskinvarefeil. Watchdog-tidtakere er vanligvis basert på enten en monostabil tidtaker eller digital teller. Tidtakerkretsen kan være integrert i mikrokontrollerbrikken eller implementeres som en ekstern krets. Watchdog-tidtakere kan forbedre påliteligheten til en mikrokontroller betydelig i et elektromagnetisk påvirket miljø.

Programvaren informerer vakthunden med jevne mellomrom om at den fremdeles fungerer som den skal. Hvis vakthunden ikke blir informert, betyr det at programvaren ikke fungerer som spesifisert lenger. Deretter tilbakestiller vakthunden systemet til en definert tilstand. Under tilbakestillingen er ikke enheten i stand til å behandle data og reagerer ikke på samtaler.

Siden strategien for å tilbakestille vakthundtimeren er veldig viktig, må to krav overholdes:

  • Vakthunden kan bare tilbakestilles hvis alle rutiner fungerer som de skal.
  • Tilbakestillingen må utføres så raskt som mulig.

Enkel aktivering av vakthunden og regelmessige tilbakestillinger av tidtakeren gjør ikke optimal bruk av en vakthund. For best resultat, må oppdateringssyklusen til tidsuret settes så kort som mulig og ringes fra hovedfunksjonen, slik at en tilbakestilling kan utføres før skaden er forårsaket eller det oppstod en feil. Hvis en mikrokontroller ikke har en intern vakthund, kan en lignende funksjonalitet implementeres ved bruk av en tidsavbrudd eller en ekstern enhet.

Brun ut

En utbrent krets overvåker VCC-nivået under drift ved å sammenligne det med et fast utløsernivå. Når VCC synker under utløsernivået, aktiveres tilbakestillingen av utbrudd umiddelbart. Når VCC stiger igjen, startes MCU på nytt etter en viss forsinkelse.

Se også

Merknader

Eksterne linker