Løsning 2004 - Høgskolen i Narvik - hovedside
Løsning 2004 - Høgskolen i Narvik - hovedside
Løsning 2004 - Høgskolen i Narvik - hovedside
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Side 1 av 3<br />
HØGSKOLEN I NARVIK<br />
Institutt for data-, elektronikk- og romteknologi<br />
LØSNINGSFORSLAG<br />
EKSAMEN<br />
I<br />
Sanntidssystemer<br />
Fagkode: STE6221<br />
11.03.<strong>2004</strong>
Oppgave 1 (15%)<br />
Side 2 av 3<br />
a) Forklar hvordan sanntidssystemer kan kategoriseres, og gi eksempler på systemer innenfor<br />
hver kategori.<br />
<strong>Løsning</strong>: Sanntidssystemer kan kategoriseres etter kritiskhet og hastighet:<br />
• Harde sanntidsystemer: Resultatet må, i tillegg til å være korrekt, produseres innen en gitt<br />
tid ellers vil systemet feile. Systemet må altså tilfredstille absolutte tidskrav, og<br />
overskridelse av disse kravene kan gi fatale følger.<br />
• Myke sanntidssystemer: System der variasjon i respons er akseptabel<br />
(applikasjonsavhengig). Tidskrav har gjerne anbefalt øvre grense, men overskridelse får<br />
ikke fatale følger.<br />
• Raske sanntidssystemer: System der responstiden ligger under ett sekund.<br />
• Trege sanntidssystemer: System der responstiden ligger over ett sekund.<br />
Grensen mellom responstid i trege og raske systemer er satt til ett sekund, da problemer i<br />
systemet vanligvis endres fra individuelle beregningsproblemer til generelle systemproblemer<br />
rundt denne tiden.<br />
Raske/harde sanntidssystem:<br />
Magnetisk levitasjonssystem for tog<br />
Fuel tank protection system – teppelegging av gass som følge av flammedeteksjon<br />
Raske/myke sanntidssystem:<br />
3D CAD-system<br />
TV fjernkontroll<br />
Trege/harde sanntidssystem:<br />
Patriot missil styresystem<br />
Preprogrammering av videoopptak<br />
Trege/myke sanntidssystem:<br />
Klimakontrollsystem i bil<br />
Dokumentprinting på nettverksprinter<br />
b) Driftssikker programvare kan sies å være korrekt, pålitelig og sikker. Definer hva som<br />
menes med disse begrepene.<br />
<strong>Løsning</strong>:<br />
Korrekt programvare: The Dictionary of Computing definerer korrekthet som “the static property that<br />
a program is consistent with its specification”. Med andre ord, dersom vi sjekker koden mot<br />
spesifikasjonen, så gjør den nøyaktig det den skal gjøre.
Side 3 av 3<br />
Pålitelig programvare: IEEE definisjonen av programvare pålitelighet er ” the extent to which a<br />
program can be expected to perform its intended function with required precision”. Det definerer<br />
altså hvor bra et program utfører den ønskede oppgaven på forespørsel.<br />
Sikker programvare: Har egenskapen at ingenting galt skjer ved feil. Gjelder primært<br />
konsekvens av feil.<br />
c) I relasjon til spørsmålet over, vil<br />
• Korrekt programvare alltid være pålitelig?<br />
• Pålitelig programvare alltid være korrekt?<br />
Begrunn svaret.<br />
<strong>Løsning</strong>: Korrekt programvare trenger ikke å være pålitelig, da en feil i spesifikasjon som er<br />
implementert i programvaren (og følgelig gjør programvaren korrekt) kan medføre at systemet<br />
ikke gir den ønskede respons.<br />
Patriot missile system i Gulf-krigen: Brukte 24-bits aritmetikk som ga avrundingsfeil i sanntids<br />
beregning. Systemet fungerte perfekt ved testing. Etter 100 timers bruk hadde avrundingsfeil bidratt<br />
til en feil på rundt 700 meter i radargenerert range-gate (skillelinje for hvor nærme innkommende<br />
missiler ble fanget opp)<br />
Pålitelig programvare trenger ikke å være korrekt, da for eksempel elementer i spesifikasjonen som<br />
ikke implementeres i koden (og følgelig gjør koden ikke korrekt) kan være overflødige. Systemet kan<br />
fremdeles fungere som forventet, og følgelig være pålitelig. Et annet eksempel er at styresystemer<br />
som ikke er implementert med ønsket nøyaktighet i henhold til spesifikasjon fremdeles kan være<br />
pålitelig dersom feil er små.<br />
Et missilstyringsprogram inkluderte exception handling på enkelte fysiske input. Pga kodefeil ble<br />
ikke alle fysiske input inkludert. SW fungerte allikevel perfekt i mange år, fordi feil aldri oppstod<br />
Oppgave 2 (35%)<br />
a) Hva er de ønskede egenskaper i et sanntids operativsystem (RTOS) i forhold til andre<br />
operativsystem?<br />
<strong>Løsning</strong>: Ønskede egenskaper ved operativsystemer kan oppsummeres som:<br />
• Mulighet for multitasking<br />
• Kjøring av aktiviteter (tasks) i parallell<br />
• Tilgang til systemets ressurser<br />
• Abstrahering av aktiviteter<br />
• Gjennomstrømning (throughput)<br />
I et RTOS er de ønskede egenskaper:
• Predikerbarhet og ytelse<br />
• Pålitelighet<br />
• Scheduling<br />
• Deling av ressurser – mutual exclusion<br />
• Synkronisering og kommunikasjon<br />
Side 4 av 3<br />
I et RTOS er vi mer opptatt av predikerbarhet enn gjennomstrømning. Dersom programvaren<br />
skal være driftssikker, må vi vite at de aktivitetene som skal kjøres, kjøres til rett tid. Et<br />
superraskt system er greit nok, men vi må kunne forutsi at det takler de tidskrav som<br />
foreligger.<br />
b) Forklar hva som menes med tidsdeling (scheduling) i sanntidssystemer og gi en beskrivelse<br />
av algoritmen for cyclic scheduling.<br />
<strong>Løsning</strong>: Scheduling i sanntidssystemer går ut på hvordan CPU skal tilordnes til de<br />
forskjellige aktiviteter slik at disse får utført sine oppgaver uten å overskride tidskrav.<br />
Cyclic cheduling: Aktiviteter som ønsker å kjøre legges i en FIFO-kø, og kjøres etter tur. Hver<br />
aktivitet får kjøre til den er ferdig med sin oppgave. Dersom denne etter kjøring ønsker å kjøre<br />
på nytt, legges den bakerst i køen. Nye aktiviteter som kommer inn, legges også bakerst i<br />
køen.<br />
Ulemper med cyclic sheduling:<br />
• Dersom en aktivitet låses, låses hele systemet<br />
• Lange aktiviteter svekker ytelse<br />
• Nye aktiviteter som ønsker å kjøre kan få lang responstid<br />
c) Relatert til oppgaven over, forklar begrepene ”time slice” og prioritet på aktiviteter, og<br />
hvordan disse elementene kan inkluderes i cyclic scheduling. Hvilke fordeler og ulemper<br />
medfører disse elementene?<br />
<strong>Løsning</strong>:<br />
Time slice: inndeling av CPU-tid i faste tidsintervall. Relatert til cyclic sheduling, vil<br />
aktiviteter fremdeles kjøres etter tur fra en FIFO-kø, men hver aktivitet får nå tildelt en fast tid<br />
for kjøring, før de legges bakerst i køen. Aktiviteter kan mao avbrytes selv om de ikke er<br />
ferdige med sin oppgave. Dette er også kjent som pre-emptive scheduling. Fordelene med<br />
dette er at responstiden for aktiviteter øker (de får starte tidligere med sin kjøring), og vi får en<br />
bedre deling av ressurser. Ulempen er at avbryting av aktiviteter krever context switch (save<br />
og restore av all informasjon vedrørende aktiviteter), noe som forbruker prosessortid. Valg av<br />
time slice vil i de fleste tilfeller være systemavhengig:<br />
Kort time slice: Lav responstid, og tilnærmet parallell kjøring, men hyppig bytting av<br />
aktiviteter vil ta mye prosessortid.<br />
Lang time slice: Prosessortid benyttes sjelden for bytting mellom aktiviteter, men responstiden<br />
vil bli høyere, og det kan medføre mye dødtid for prosessor (dersom en aktivitet er ferdig etter
Side 5 av 3<br />
en liten andel av time slice, vil prosessor stå å vente på neste time slice før neste aktivitet<br />
kjører).<br />
Prioritet: Noen aktiviteter vil i de fleste tilfeller være viktige enn andre, og setting av prioritet<br />
på oppgaver vil gjøre det mulig å la de viktigste aktivitetene ha fortrinnsrett på prosessor.<br />
Køen av aktiviteter som ønsker å kjøre kan tilordnes etter prioriteter, slik at aktiviteter med<br />
høy prioritet kan flyttes lengre frem i køen, i stedet for å stille seg bakerst. Fordelen med<br />
prioritet er at viktige aktiviteter vil få lavere responstid, samt at det øker fleksibiliteten i<br />
systemet. Ulempene er at vi får mer kompleks kjøring i systemet, og det kan bidra til mer<br />
bytting av aktiviteter. Det kan ogsp medføre ’utsulting’ av aktiviteter med lav prioritet.<br />
d) Forklar hva en semafor er, og hvordan dette kan benyttes for å oppnå gjensidig utelukking<br />
(mutual exclusion).<br />
<strong>Løsning</strong>: Ved deling av ressurser er det ønskelig å benytte en metode som gjør det mulig for<br />
en aktivitet å melde fra til andre aktiviteter om at den ressursen som denne benytter er opptatt<br />
(gjensidig utelukking). For å gjøre dette, trengs et objekt som kan sjekke og sette tilstand i en<br />
udelt operasjon. Et slikt objekt kalles en semafor. En semafor kan tilordnes hver ressurs som<br />
ønskes å deles mellom aktiviteter, og en aktivitet må ta semaforen før ressursen benyttes.<br />
Dersom semaforen er ledig, kan aktiviteten fritt benyttes ressursen. Dersom semaforen er<br />
opptatt, vil RTOS suspendere aktiviteten, og så vekke opp aktiviteten igjen når semaforen blir<br />
ledig. Dersom flere aktiviteter vil ta en opptatt semafor, kan disse legges i en kø (FIFO eller<br />
prioritetsstyrt).<br />
Binære semaforer er semaforer som bare kan være ledig eller opptatt, og fungerer som<br />
beskrevet over. Det finnes også tellende (counting) semaforer, som kan tilordnes flere verdier.<br />
Disse kan for eksempel benyttes der det er tilgjengelig flere ressurser av samme type.<br />
e) Hva menes med deadlock, og hvilke betingelser må være oppfylt for at deadlock skal<br />
oppstå? Gi tre alternative metoder som kan benyttes for å sikre seg mot at deadlock oppstår<br />
(deadlock prevention).<br />
<strong>Løsning</strong>: Deadlock er en situasjon som kan oppstå når to eller flere aktiviteter ønsker to eller<br />
flere ressurser samtidig.<br />
Eksempel: Aktivitet A1 trenger ressurser R1 og R2, og tar først semafor S1. Før A1 rekker å<br />
ta S2 blir den avbrutt av A2, som også trenger begge ressurser. A2 tar først semafor S2, men<br />
får ikke tilgang til S1, fordi denne er tatt av A1. Denne blir suspendert, og A1 forsøker å ta S2,<br />
som er opptatt.<br />
Deadlock medfører mao at ingen aktiviteter får kjøre fordi alle venter på en ressurs som en<br />
annen aktivitet holder.<br />
Følgende betingelser må alle være oppfylt for at deadlock skal oppstå:<br />
• Mutual exclusion: aktiviteter har eksklusiv rett til ressurser, og kan utestenge andre<br />
aktiviteter
Side 6 av 3<br />
• Hold and wait: En aktivitet kan holde en ressurs mens den venter på en annen<br />
• Circular waiting: Det foreligger en sirkulær avhengighet av aktiviteter og ressurser<br />
• No resource pre-emption: En aktivitet frigir ikke ressurser før den er ferdig å benytte de<br />
• Non-recovery: Når deadlock inntreffer, varer det evig<br />
Deadlock prevention - Sørge for at deadlock ikke kan oppstå<br />
• Design basert på ressursbruk<br />
• Unngå flaskehalser og konfliktområder<br />
Metoder:<br />
• Tillat deling av ressurser – ingen mutual exclusion<br />
o Kølappsystem med ressurshåndterer<br />
o Hver aktivitet må trekke kølapp før bruk av ressurs<br />
• Tillat resource pre-emption<br />
o En aktivitet kan ta en ressurs fra en suspendert aktivitet (styrt av RTOS)<br />
o Typisk lesing av data fra lager, I/O etc (Skriving ikke tillatt)<br />
o Krever ressurshåndtering som gir overhead i tid<br />
• Styring av ressursallokering<br />
o Begrens antallet ressurser som en aktivitet benytter samtidig<br />
o Minimaliser tiden en ressurs benyttes<br />
• Hold and wait prevention<br />
o Ta alle ressurser samtidig uten venting<br />
o Dersom en ressurs er opptatt når en aktivitet trenger den, frigjøres alle andre<br />
ressurser som aktivitet har før den suspenderes<br />
o Kan gi ytelsesproblem, og er ikke predikerbart<br />
• Circular wait prevention<br />
o Definert rekkefølge av ressursallokering (ressurser får tildelt en verdi)<br />
o Alle aktiviteter følger samme rekkefølge ved allokering (f eks stigende<br />
rekkefølge)<br />
• Disable interrupt ved benyttelse av delte ressurser<br />
o Medfører ingen context switch – enkelt, billig, lett å implementere<br />
o Skummelt å disable interrupt – bør minimaliseres<br />
f) Forklar hva som menes med prioritetsinversjon (priority inversion). Hvilken mekanisme<br />
kan benyttes for å løse slike problem?<br />
<strong>Løsning</strong>: Prioritetsinversjon oppstår når flere oppgaver kjører samtidig, og en oppgave med<br />
høy prioritet blokkeres av en oppgave med lavere prioritet, slik at andre oppgaver med<br />
mellomliggende prioritet kan kjøre.
Side 7 av 3<br />
<strong>Løsning</strong>en på prioritetsinversjon er prioritetsarv, som innebærer at oppgaven med lav prioritet<br />
arver prioriteten til oppgaven den blokkerer for.<br />
g) Hva er rate monotonic scheduling (RMS), og hvilke antakelser er denne metoden bygget<br />
på? Gi også en beskrivelse av hvordan metoden kan utbedres for system med aperiodiske<br />
aktiviteter.<br />
<strong>Løsning</strong>: RMS er en algoritme for scheduling som baseres på aktiviteters periodetid. Prioritet<br />
tildeles etter prinsippet om at aktiviteter som kjører ofte (lav periodetid) får høy prioritet.<br />
Antakelser for RMS:<br />
• Periodiske aktiviteter<br />
• Deadline er det samme som periode for alle aktiviteter<br />
• Aktiviteter kan avbrytes (pre-emption)<br />
• Alle aktiviteter er like viktige<br />
• Alle aktivitetene er uavhengige<br />
• Worst-case eksekveringstid for en aktivitet er konstant<br />
Svakheten ved RM ligger i disse antakelsene, som sjelden kan sies å være realistiske. Dersom<br />
allikevel alle aktiviteter i systemet tilfredstiller antakelsene ovenfor, vil RMS garantere at alle<br />
n aktiviteter overholder sine tidskrav dersom utnyttelsesgraden U (Andel av tilgjengelig<br />
prosessortid som benyttes til eksekvering av aktiviteter) i systemet er slik at<br />
U<br />
Til sensor: Det kreves ikke at studentene kan denne formelen i detalj, det er tilstrekkelig at de<br />
vet prinsippet med algoritmen og antakelser som ligger til grunn, og at det er mulig å<br />
bestemme matematisk om tidskrav overholdes eller ikke.<br />
Dersom det eksisterer aperiodiske aktiviteter i systemet, kan disse inkluderes i algoritmen ved<br />
å anta disse periodisk, og sette av en definert periode i kjøreplanen for å håndtere disse når de<br />
forekommer.<br />
Oppgave 3 (20%)<br />
n<br />
= ∑<br />
i= 1<br />
pi<br />
Tei<br />
⎜<br />
⎛ n ≤ n 2 −1⎟<br />
⎞ der U → 0.<br />
693<br />
T ⎝ ⎠<br />
1<br />
a) Hva er nytten av å bruke diagrammetoder i designfasen av et prosjekt, og hva er de<br />
grunnleggende kvalitetene i diagram?<br />
<strong>Løsning</strong>: Den hovedsaklige årsaken for å benytte diagram er at ”et bilde sier mer enn tusen”,<br />
altså vil dokumenter som utarbeides under et prosjekts oppstart, utvikling og avslutting, bli<br />
mer forståelige og gi et bedre bilde av det som skal forklares.<br />
Å benytte diagrammetoder i designfasen av et prosjekt, vil:<br />
• Bidra til god forståelse av systemet<br />
når<br />
n<br />
→ ∞
Side 8 av 3<br />
• Gjøre designdokumenter formelle og strukturerte<br />
• Fjerne tvetydighet og tvil<br />
• Gjøre det lettere å revidere og analysere design<br />
• Synliggjøre ulogisk design og feil<br />
Grunnleggende kvaliteter ved diagram:<br />
• Små<br />
• Enkle og forståelige<br />
• Komplett<br />
• Benytter konkrete symboler<br />
• Formelt definert<br />
b) Gi en beskrivelse av de grunnleggende elementene i et use case diagram, og forklar hva<br />
som er hensikten med slike diagram.<br />
<strong>Løsning</strong>: Hensikten med et use case er å illustrere hvorfor systemet benyttes og hvem som benytter<br />
det. Et use case kan bestå av aktører (actors), use case’er og use case beskrivelser. Hvert system har<br />
sin egen modell, der aktører presenterer brukeres roller. Hvorfor disse aktørene benytter systemet er<br />
vist som et sett av use case’er inni systemets ytre grense (boundary). Dette støttes opp av use case<br />
beskrivelser.<br />
Actors<br />
Navigator<br />
Driver<br />
Use Case 1<br />
Use Case 2<br />
Use Case 3<br />
Use cases<br />
Vehicle navigation<br />
system<br />
Get navigation<br />
waypoints<br />
Text for use case 1<br />
Text for use case 2<br />
Text for use case 3<br />
Use case descriptions<br />
c) Beskriv oppbygning av og hensikten med et UML sekvensdiagram (sequence diagram).
Side 9 av 3<br />
<strong>Løsning</strong>: Den fundamentale hensikten med et UML sekvensdiagram er å vise samhandlinger<br />
mellom objekter over tid. Det grunnleggende konseptet for et system med to objekter er vist i<br />
figuren under.<br />
Det illustrerer:<br />
• Hvilke meldinger som sendes.<br />
• Når meldinger sendes.<br />
• Hvem sender og mottaker er.<br />
• Tidsforløp mellom sending og mottak.<br />
De vertikale linjene kalles livslinjer (lifelines) i UML. Andre aspekter ved semantikk i UML<br />
sekvensdiagram er:<br />
• Focus of control: Tidsperioden som et objekt benytter for å utføre en aksjon. Dette<br />
representeres ved å vise livslinjen som et høyt, tynt rektangel mens aksjonen utføres.<br />
Ellers er livslinjen tegnet som stiplet linje.<br />
• Melding eller stimuli: UML definerer kommunikasjonen mellom objekter som en<br />
stimuli, vist som en horisontal pil mellom livslinjer.<br />
Oppgave 4 (20%)<br />
a) Hvilke to grunnleggende metoder har vi for testing av kvalitet og oppførsel i programvare?<br />
<strong>Løsning</strong>:<br />
T 0<br />
T 1<br />
T 2<br />
T 3<br />
T 4<br />
Time<br />
Processing<br />
Send<br />
message<br />
Processing<br />
Message arrival<br />
and detection<br />
Processing<br />
Object 1 Object 2<br />
Statisk testing (test av kvalitet):<br />
• Manuell eller automatisert analyse av kode for å finne feil<br />
• Sjekk av kode mot designmodeller og kodestandarder<br />
Processing<br />
Message arrival<br />
and detection<br />
Send<br />
acknowledgement<br />
Processing
Side 10 av 3<br />
Dynamisk testing (test av oppførsel):<br />
• Kjøring av programvare etter spesifiserte retningslinjer for test<br />
• Måling av ytelse<br />
• Testing av målte resultater mot forventede resultater<br />
b) Beskriv prinsippet med programvarebasert debugging på målmaskin (target), og angi<br />
fordeler og ulemper med denne metoden.<br />
<strong>Løsning</strong>: For å gjennomføre programvarebasert debugging på target, trengs følgende<br />
fasiliteter (se figur under):<br />
GUI<br />
interface<br />
Host<br />
Target<br />
Macroprocessor<br />
Compiler<br />
Debugger and<br />
execution control<br />
interface<br />
Execution monitor<br />
Application software<br />
Symbol table<br />
Source program<br />
Prinsippet er at systemet kjøres på target i sitt virkelige miljø, mens debugging styres fra<br />
utviklingsmaskin (host). Programvaren for debugging av to ting, et grensesnitt for debugging og en<br />
eksekveringsmonitor. Grensesnittet ligger på host mens monitoren plasseres på target. Ekstra<br />
programvare trengs for kommunikasjon mellom disse. Dette består av kommunikasjonsfasiliteter på<br />
host og target. Kommunikasjon foregår vanligvis over serielle linjer, typisk RS232 eller Ethernet (på<br />
PC som host benyttes også ofte parallellporter).<br />
Programvarebasert debugging på target gjør det mulig å se hvordan systemet vil oppføre seg i sitt<br />
virkelige miljø, og det er mulig å analysere ytelse og identifisere feil som kan være vanskelig å<br />
oppdage dersom programvaren kjøres i en simulator på host. I tillegg vil oppsettet som er beskrevet<br />
her ha andre fordeler. For det første ligger all symbolinformasjon på host, selv om debugging gjøres<br />
på target. Dette gjør det mulig å tilby kraftige brukergrensesnitt med minimale krav til minne på<br />
target. En target run-time support pakke tar typisk noen få kilobyte kode. For det andre kan kjøring<br />
lagres på disk på host for senere analyser, og skrives ut. Den siste fordelen er at det eneste
Side 11 av 3<br />
periferiutstyr som trengs på target er seriell kommunikasjon, alle andre kan fritt benyttes av<br />
applikasjonen.<br />
Ulempene med programvarebasert debugging på target er at vi forstyrrer systemets normale<br />
kjøring gjennom styring av eksekvering (stepping, breakpoints osv) og monitorering. Følgelig<br />
vil ikke systemet kjøre på samme måte under debugging som ved normal kjøring. Andre<br />
ulemper er at maskinvaren i systemet må fungere feilfritt, og det kan være vanskelig å<br />
håndtere asynkrone interrupts. En siste ulempe er at programvaren som ligger på target er<br />
plassert i RAM, uten noe fysisk skille fra systemet. Dette kan medføre minneproblematikk og<br />
interferens mellom debugger og system, i tillegg til at den tar opp plass.<br />
c) Forklar hvordan en software trace debugger fungerer.<br />
<strong>Løsning</strong>: Software trace debugging er i prinsippet å debugge kode på target ved å sammenligne<br />
kildekoden på host med en trace av koden som eksekveres, som i figuren under.<br />
En logikkanalysator benyttes som å samle informasjon i sann tid fra target. Dette disassembles<br />
og sendes til en programvareanalysator, der det sammenlignes med informasjonen i<br />
symbolfiler eller en database av kilden. Når traceinformasjonen er lagret, kan den vises i det<br />
samme programmeringsspråket som benyttes for kildekoden. En komplett nedtegning kan<br />
steppes gjennom for å finne ut nøyaktig hva som skjedde på target ved gitte tidspunkt.<br />
Oppgave 5 (10%)<br />
a) Hvilke to hovedkategorier for sikkerhetskritiske systemer finnes? Forklar forskjellen<br />
mellom disse to kategoriene, og gi eksempler på systemer i hver kategori.<br />
<strong>Løsning</strong>:<br />
Logic<br />
analyzer<br />
Disassembler<br />
Address, control, data<br />
Software<br />
analyzer<br />
Symbol<br />
database<br />
Target<br />
Compiler<br />
Host machine<br />
Object<br />
code<br />
Sikkerhetskritiske (Safety-critical) system:<br />
• Feil på systemet medfører alvorlig skade eller dødsfall.<br />
• Fly-by-wire, aero engine control systems, aircraft autoland systems, airbag systems
Side 12 av 3<br />
Oppgavekritiske (Mission-critical) system:<br />
• Feil på systemet medfører at planlagte operasjoner ikke kan gjennomføres.<br />
• Search radar, telecommunication switches, online money transaction systems<br />
b) Forklar begrepene ”Backward error recovery (rollback)” og ”N-version programming” i<br />
forbindelse med håndtering av feil i en applikasjon under kjøring. Beskriv fordeler og ulemper<br />
med disse to metodene.<br />
<strong>Løsning</strong>:<br />
Backward error recovery:<br />
• Kode består av et sjekkpunkt, primærkode, alternative koder og en akseptansetest.<br />
• System data holdes i sjekkpunkt mens primærkode utføres. Dersom resultat ikke<br />
godkjennes av akseptansetest, kjøres alternativ kode 1. Dersom resultatet av denne<br />
ikke godkjennes kjøres alternativ kode 2. Dersom ingen godtaes, sendes en feilmelding<br />
Fordelen med metoden er at feil i koden kan detekteres, og denne kan fjernes med å kjøre<br />
alternative algoritmer. Ulempene er at dersom alle alternative algoritmer gjennomføres med<br />
feil resultat, stopper applikasjonen opp inntil ekstern recovery gjennomføres. I tillegg kan<br />
eksekveringstider variere mellom hver kjøring, noe som kan medføre problemer med ytelse.<br />
Det kan også være vanskelig å konstruere akseptansetest, da dette krever god kjennskap til<br />
systemet.<br />
N-version programming:<br />
• Benytter N versjoner av en algoritme<br />
• Output sjekkes av en voter, som sammenligner resultater, og sender ut det som flest<br />
(normalt N-1) mener er riktig<br />
Fordelen med denne metoden, er at vi har ingen behov for akseptansetest. Det er uinteressant<br />
hva resultatet er, bare flere er enige om det samme resultat. Ulempene er at det tar mye tid å<br />
kjøre N versjoner av en algoritme, og at dersom majoriteten av algoritmene kommer ut med<br />
feil resultat, så vil dette bli godkjent og sendt videre.