Løsning 2004 - Høgskolen i Narvik - hovedside

Side 1 av 3
HØGSKOLEN I NARVIK
Institutt for data-, elektronikk- og romteknologi
LØSNINGSFORSLAG
EKSAMEN
I
Sanntidssystemer
Fagkode: STE6221
11.03.2004

Oppgave 1 (15%)
Side 2 av 3
a) Forklar hvordan sanntidssystemer kan kategoriseres, og gi eksempler på systemer innenfor
hver kategori.
Løsning: Sanntidssystemer kan kategoriseres etter kritiskhet og hastighet:
• Harde sanntidsystemer: Resultatet må, i tillegg til å være korrekt, produseres innen en gitt
tid ellers vil systemet feile. Systemet må altså tilfredstille absolutte tidskrav, og
overskridelse av disse kravene kan gi fatale følger.
• Myke sanntidssystemer: System der variasjon i respons er akseptabel
(applikasjonsavhengig). Tidskrav har gjerne anbefalt øvre grense, men overskridelse får
ikke fatale følger.
• Raske sanntidssystemer: System der responstiden ligger under ett sekund.
• Trege sanntidssystemer: System der responstiden ligger over ett sekund.
Grensen mellom responstid i trege og raske systemer er satt til ett sekund, da problemer i
systemet vanligvis endres fra individuelle beregningsproblemer til generelle systemproblemer
rundt denne tiden.
Raske/harde sanntidssystem:
Magnetisk levitasjonssystem for tog
Fuel tank protection system – teppelegging av gass som følge av flammedeteksjon
Raske/myke sanntidssystem:
3D CAD-system
TV fjernkontroll
Trege/harde sanntidssystem:
Patriot missil styresystem
Preprogrammering av videoopptak
Trege/myke sanntidssystem:
Klimakontrollsystem i bil
Dokumentprinting på nettverksprinter
b) Driftssikker programvare kan sies å være korrekt, pålitelig og sikker. Definer hva som
menes med disse begrepene.
Løsning:
Korrekt programvare: The Dictionary of Computing definerer korrekthet som “the static property that
a program is consistent with its specification”. Med andre ord, dersom vi sjekker koden mot
spesifikasjonen, så gjør den nøyaktig det den skal gjøre.

Side 3 av 3
Pålitelig programvare: IEEE definisjonen av programvare pålitelighet er ” the extent to which a
program can be expected to perform its intended function with required precision”. Det definerer
altså hvor bra et program utfører den ønskede oppgaven på forespørsel.
Sikker programvare: Har egenskapen at ingenting galt skjer ved feil. Gjelder primært
konsekvens av feil.
c) I relasjon til spørsmålet over, vil
• Korrekt programvare alltid være pålitelig?
• Pålitelig programvare alltid være korrekt?
Begrunn svaret.
Løsning: Korrekt programvare trenger ikke å være pålitelig, da en feil i spesifikasjon som er
implementert i programvaren (og følgelig gjør programvaren korrekt) kan medføre at systemet
ikke gir den ønskede respons.
Patriot missile system i Gulf-krigen: Brukte 24-bits aritmetikk som ga avrundingsfeil i sanntids
beregning. Systemet fungerte perfekt ved testing. Etter 100 timers bruk hadde avrundingsfeil bidratt
til en feil på rundt 700 meter i radargenerert range-gate (skillelinje for hvor nærme innkommende
missiler ble fanget opp)
Pålitelig programvare trenger ikke å være korrekt, da for eksempel elementer i spesifikasjonen som
ikke implementeres i koden (og følgelig gjør koden ikke korrekt) kan være overflødige. Systemet kan
fremdeles fungere som forventet, og følgelig være pålitelig. Et annet eksempel er at styresystemer
som ikke er implementert med ønsket nøyaktighet i henhold til spesifikasjon fremdeles kan være
pålitelig dersom feil er små.
Et missilstyringsprogram inkluderte exception handling på enkelte fysiske input. Pga kodefeil ble
ikke alle fysiske input inkludert. SW fungerte allikevel perfekt i mange år, fordi feil aldri oppstod
Oppgave 2 (35%)
a) Hva er de ønskede egenskaper i et sanntids operativsystem (RTOS) i forhold til andre
operativsystem?
Løsning: Ønskede egenskaper ved operativsystemer kan oppsummeres som:
• Mulighet for multitasking
• Kjøring av aktiviteter (tasks) i parallell
• Tilgang til systemets ressurser
• Abstrahering av aktiviteter
• Gjennomstrømning (throughput)
I et RTOS er de ønskede egenskaper:

• Predikerbarhet og ytelse
• Pålitelighet
• Scheduling
• Deling av ressurser – mutual exclusion
• Synkronisering og kommunikasjon
Side 4 av 3
I et RTOS er vi mer opptatt av predikerbarhet enn gjennomstrømning. Dersom programvaren
skal være driftssikker, må vi vite at de aktivitetene som skal kjøres, kjøres til rett tid. Et
superraskt system er greit nok, men vi må kunne forutsi at det takler de tidskrav som
foreligger.
b) Forklar hva som menes med tidsdeling (scheduling) i sanntidssystemer og gi en beskrivelse
av algoritmen for cyclic scheduling.
Løsning: Scheduling i sanntidssystemer går ut på hvordan CPU skal tilordnes til de
forskjellige aktiviteter slik at disse får utført sine oppgaver uten å overskride tidskrav.
Cyclic cheduling: Aktiviteter som ønsker å kjøre legges i en FIFO-kø, og kjøres etter tur. Hver
aktivitet får kjøre til den er ferdig med sin oppgave. Dersom denne etter kjøring ønsker å kjøre
på nytt, legges den bakerst i køen. Nye aktiviteter som kommer inn, legges også bakerst i
køen.
Ulemper med cyclic sheduling:
• Dersom en aktivitet låses, låses hele systemet
• Lange aktiviteter svekker ytelse
• Nye aktiviteter som ønsker å kjøre kan få lang responstid
c) Relatert til oppgaven over, forklar begrepene ”time slice” og prioritet på aktiviteter, og
hvordan disse elementene kan inkluderes i cyclic scheduling. Hvilke fordeler og ulemper
medfører disse elementene?
Løsning:
Time slice: inndeling av CPU-tid i faste tidsintervall. Relatert til cyclic sheduling, vil
aktiviteter fremdeles kjøres etter tur fra en FIFO-kø, men hver aktivitet får nå tildelt en fast tid
for kjøring, før de legges bakerst i køen. Aktiviteter kan mao avbrytes selv om de ikke er
ferdige med sin oppgave. Dette er også kjent som pre-emptive scheduling. Fordelene med
dette er at responstiden for aktiviteter øker (de får starte tidligere med sin kjøring), og vi får en
bedre deling av ressurser. Ulempen er at avbryting av aktiviteter krever context switch (save
og restore av all informasjon vedrørende aktiviteter), noe som forbruker prosessortid. Valg av
time slice vil i de fleste tilfeller være systemavhengig:
Kort time slice: Lav responstid, og tilnærmet parallell kjøring, men hyppig bytting av
aktiviteter vil ta mye prosessortid.
Lang time slice: Prosessortid benyttes sjelden for bytting mellom aktiviteter, men responstiden
vil bli høyere, og det kan medføre mye dødtid for prosessor (dersom en aktivitet er ferdig etter

Side 5 av 3
en liten andel av time slice, vil prosessor stå å vente på neste time slice før neste aktivitet
kjører).
Prioritet: Noen aktiviteter vil i de fleste tilfeller være viktige enn andre, og setting av prioritet
på oppgaver vil gjøre det mulig å la de viktigste aktivitetene ha fortrinnsrett på prosessor.
Køen av aktiviteter som ønsker å kjøre kan tilordnes etter prioriteter, slik at aktiviteter med
høy prioritet kan flyttes lengre frem i køen, i stedet for å stille seg bakerst. Fordelen med
prioritet er at viktige aktiviteter vil få lavere responstid, samt at det øker fleksibiliteten i
systemet. Ulempene er at vi får mer kompleks kjøring i systemet, og det kan bidra til mer
bytting av aktiviteter. Det kan ogsp medføre ’utsulting’ av aktiviteter med lav prioritet.
d) Forklar hva en semafor er, og hvordan dette kan benyttes for å oppnå gjensidig utelukking
(mutual exclusion).
Løsning: Ved deling av ressurser er det ønskelig å benytte en metode som gjør det mulig for
en aktivitet å melde fra til andre aktiviteter om at den ressursen som denne benytter er opptatt
(gjensidig utelukking). For å gjøre dette, trengs et objekt som kan sjekke og sette tilstand i en
udelt operasjon. Et slikt objekt kalles en semafor. En semafor kan tilordnes hver ressurs som
ønskes å deles mellom aktiviteter, og en aktivitet må ta semaforen før ressursen benyttes.
Dersom semaforen er ledig, kan aktiviteten fritt benyttes ressursen. Dersom semaforen er
opptatt, vil RTOS suspendere aktiviteten, og så vekke opp aktiviteten igjen når semaforen blir
ledig. Dersom flere aktiviteter vil ta en opptatt semafor, kan disse legges i en kø (FIFO eller
prioritetsstyrt).
Binære semaforer er semaforer som bare kan være ledig eller opptatt, og fungerer som
beskrevet over. Det finnes også tellende (counting) semaforer, som kan tilordnes flere verdier.
Disse kan for eksempel benyttes der det er tilgjengelig flere ressurser av samme type.
e) Hva menes med deadlock, og hvilke betingelser må være oppfylt for at deadlock skal
oppstå? Gi tre alternative metoder som kan benyttes for å sikre seg mot at deadlock oppstår
(deadlock prevention).
Løsning: Deadlock er en situasjon som kan oppstå når to eller flere aktiviteter ønsker to eller
flere ressurser samtidig.
Eksempel: Aktivitet A1 trenger ressurser R1 og R2, og tar først semafor S1. Før A1 rekker å
ta S2 blir den avbrutt av A2, som også trenger begge ressurser. A2 tar først semafor S2, men
får ikke tilgang til S1, fordi denne er tatt av A1. Denne blir suspendert, og A1 forsøker å ta S2,
som er opptatt.
Deadlock medfører mao at ingen aktiviteter får kjøre fordi alle venter på en ressurs som en
annen aktivitet holder.
Følgende betingelser må alle være oppfylt for at deadlock skal oppstå:
• Mutual exclusion: aktiviteter har eksklusiv rett til ressurser, og kan utestenge andre
aktiviteter

Side 6 av 3
• Hold and wait: En aktivitet kan holde en ressurs mens den venter på en annen
• Circular waiting: Det foreligger en sirkulær avhengighet av aktiviteter og ressurser
• No resource pre-emption: En aktivitet frigir ikke ressurser før den er ferdig å benytte de
• Non-recovery: Når deadlock inntreffer, varer det evig
Deadlock prevention - Sørge for at deadlock ikke kan oppstå
• Design basert på ressursbruk
• Unngå flaskehalser og konfliktområder
Metoder:
• Tillat deling av ressurser – ingen mutual exclusion
o Kølappsystem med ressurshåndterer
o Hver aktivitet må trekke kølapp før bruk av ressurs
• Tillat resource pre-emption
o En aktivitet kan ta en ressurs fra en suspendert aktivitet (styrt av RTOS)
o Typisk lesing av data fra lager, I/O etc (Skriving ikke tillatt)
o Krever ressurshåndtering som gir overhead i tid
• Styring av ressursallokering
o Begrens antallet ressurser som en aktivitet benytter samtidig
o Minimaliser tiden en ressurs benyttes
• Hold and wait prevention
o Ta alle ressurser samtidig uten venting
o Dersom en ressurs er opptatt når en aktivitet trenger den, frigjøres alle andre
ressurser som aktivitet har før den suspenderes
o Kan gi ytelsesproblem, og er ikke predikerbart
• Circular wait prevention
o Definert rekkefølge av ressursallokering (ressurser får tildelt en verdi)
o Alle aktiviteter følger samme rekkefølge ved allokering (f eks stigende
rekkefølge)
• Disable interrupt ved benyttelse av delte ressurser
o Medfører ingen context switch – enkelt, billig, lett å implementere
o Skummelt å disable interrupt – bør minimaliseres
f) Forklar hva som menes med prioritetsinversjon (priority inversion). Hvilken mekanisme
kan benyttes for å løse slike problem?
Løsning: Prioritetsinversjon oppstår når flere oppgaver kjører samtidig, og en oppgave med
høy prioritet blokkeres av en oppgave med lavere prioritet, slik at andre oppgaver med
mellomliggende prioritet kan kjøre.

Side 7 av 3
Løsningen på prioritetsinversjon er prioritetsarv, som innebærer at oppgaven med lav prioritet
arver prioriteten til oppgaven den blokkerer for.
g) Hva er rate monotonic scheduling (RMS), og hvilke antakelser er denne metoden bygget
på? Gi også en beskrivelse av hvordan metoden kan utbedres for system med aperiodiske
aktiviteter.
Løsning: RMS er en algoritme for scheduling som baseres på aktiviteters periodetid. Prioritet
tildeles etter prinsippet om at aktiviteter som kjører ofte (lav periodetid) får høy prioritet.
Antakelser for RMS:
• Periodiske aktiviteter
• Deadline er det samme som periode for alle aktiviteter
• Aktiviteter kan avbrytes (pre-emption)
• Alle aktiviteter er like viktige
• Alle aktivitetene er uavhengige
• Worst-case eksekveringstid for en aktivitet er konstant
Svakheten ved RM ligger i disse antakelsene, som sjelden kan sies å være realistiske. Dersom
allikevel alle aktiviteter i systemet tilfredstiller antakelsene ovenfor, vil RMS garantere at alle
n aktiviteter overholder sine tidskrav dersom utnyttelsesgraden U (Andel av tilgjengelig
prosessortid som benyttes til eksekvering av aktiviteter) i systemet er slik at
U
Til sensor: Det kreves ikke at studentene kan denne formelen i detalj, det er tilstrekkelig at de
vet prinsippet med algoritmen og antakelser som ligger til grunn, og at det er mulig å
bestemme matematisk om tidskrav overholdes eller ikke.
Dersom det eksisterer aperiodiske aktiviteter i systemet, kan disse inkluderes i algoritmen ved
å anta disse periodisk, og sette av en definert periode i kjøreplanen for å håndtere disse når de
forekommer.
Oppgave 3 (20%)
n
= ∑
i= 1
pi
Tei
⎜
⎛ n ≤ n 2 −1⎟
⎞ der U → 0.
693
T ⎝ ⎠
1
a) Hva er nytten av å bruke diagrammetoder i designfasen av et prosjekt, og hva er de
grunnleggende kvalitetene i diagram?
Løsning: Den hovedsaklige årsaken for å benytte diagram er at ”et bilde sier mer enn tusen”,
altså vil dokumenter som utarbeides under et prosjekts oppstart, utvikling og avslutting, bli
mer forståelige og gi et bedre bilde av det som skal forklares.
Å benytte diagrammetoder i designfasen av et prosjekt, vil:
• Bidra til god forståelse av systemet
når
n
→ ∞

Side 8 av 3
• Gjøre designdokumenter formelle og strukturerte
• Fjerne tvetydighet og tvil
• Gjøre det lettere å revidere og analysere design
• Synliggjøre ulogisk design og feil
Grunnleggende kvaliteter ved diagram:
• Små
• Enkle og forståelige
• Komplett
• Benytter konkrete symboler
• Formelt definert
b) Gi en beskrivelse av de grunnleggende elementene i et use case diagram, og forklar hva
som er hensikten med slike diagram.
Løsning: Hensikten med et use case er å illustrere hvorfor systemet benyttes og hvem som benytter
det. Et use case kan bestå av aktører (actors), use case’er og use case beskrivelser. Hvert system har
sin egen modell, der aktører presenterer brukeres roller. Hvorfor disse aktørene benytter systemet er
vist som et sett av use case’er inni systemets ytre grense (boundary). Dette støttes opp av use case
beskrivelser.
Actors
Navigator
Driver
Use Case 1
Use Case 2
Use Case 3
Use cases
Vehicle navigation
system
Get navigation
waypoints
Text for use case 1
Text for use case 2
Text for use case 3
Use case descriptions
c) Beskriv oppbygning av og hensikten med et UML sekvensdiagram (sequence diagram).

Side 9 av 3
Løsning: Den fundamentale hensikten med et UML sekvensdiagram er å vise samhandlinger
mellom objekter over tid. Det grunnleggende konseptet for et system med to objekter er vist i
figuren under.
Det illustrerer:
• Hvilke meldinger som sendes.
• Når meldinger sendes.
• Hvem sender og mottaker er.
• Tidsforløp mellom sending og mottak.
De vertikale linjene kalles livslinjer (lifelines) i UML. Andre aspekter ved semantikk i UML
sekvensdiagram er:
• Focus of control: Tidsperioden som et objekt benytter for å utføre en aksjon. Dette
representeres ved å vise livslinjen som et høyt, tynt rektangel mens aksjonen utføres.
Ellers er livslinjen tegnet som stiplet linje.
• Melding eller stimuli: UML definerer kommunikasjonen mellom objekter som en
stimuli, vist som en horisontal pil mellom livslinjer.
Oppgave 4 (20%)
a) Hvilke to grunnleggende metoder har vi for testing av kvalitet og oppførsel i programvare?
Løsning:
T 0
T 1
T 2
T 3
T 4
Time
Processing
Send
message
Processing
Message arrival
and detection
Processing
Object 1 Object 2
Statisk testing (test av kvalitet):
• Manuell eller automatisert analyse av kode for å finne feil
• Sjekk av kode mot designmodeller og kodestandarder
Processing
Message arrival
and detection
Send
acknowledgement
Processing

Side 10 av 3
Dynamisk testing (test av oppførsel):
• Kjøring av programvare etter spesifiserte retningslinjer for test
• Måling av ytelse
• Testing av målte resultater mot forventede resultater
b) Beskriv prinsippet med programvarebasert debugging på målmaskin (target), og angi
fordeler og ulemper med denne metoden.
Løsning: For å gjennomføre programvarebasert debugging på target, trengs følgende
fasiliteter (se figur under):
GUI
interface
Host
Target
Macroprocessor
Compiler
Debugger and
execution control
interface
Execution monitor
Application software
Symbol table
Source program
Prinsippet er at systemet kjøres på target i sitt virkelige miljø, mens debugging styres fra
utviklingsmaskin (host). Programvaren for debugging av to ting, et grensesnitt for debugging og en
eksekveringsmonitor. Grensesnittet ligger på host mens monitoren plasseres på target. Ekstra
programvare trengs for kommunikasjon mellom disse. Dette består av kommunikasjonsfasiliteter på
host og target. Kommunikasjon foregår vanligvis over serielle linjer, typisk RS232 eller Ethernet (på
PC som host benyttes også ofte parallellporter).
Programvarebasert debugging på target gjør det mulig å se hvordan systemet vil oppføre seg i sitt
virkelige miljø, og det er mulig å analysere ytelse og identifisere feil som kan være vanskelig å
oppdage dersom programvaren kjøres i en simulator på host. I tillegg vil oppsettet som er beskrevet
her ha andre fordeler. For det første ligger all symbolinformasjon på host, selv om debugging gjøres
på target. Dette gjør det mulig å tilby kraftige brukergrensesnitt med minimale krav til minne på
target. En target run-time support pakke tar typisk noen få kilobyte kode. For det andre kan kjøring
lagres på disk på host for senere analyser, og skrives ut. Den siste fordelen er at det eneste

Side 11 av 3
periferiutstyr som trengs på target er seriell kommunikasjon, alle andre kan fritt benyttes av
applikasjonen.
Ulempene med programvarebasert debugging på target er at vi forstyrrer systemets normale
kjøring gjennom styring av eksekvering (stepping, breakpoints osv) og monitorering. Følgelig
vil ikke systemet kjøre på samme måte under debugging som ved normal kjøring. Andre
ulemper er at maskinvaren i systemet må fungere feilfritt, og det kan være vanskelig å
håndtere asynkrone interrupts. En siste ulempe er at programvaren som ligger på target er
plassert i RAM, uten noe fysisk skille fra systemet. Dette kan medføre minneproblematikk og
interferens mellom debugger og system, i tillegg til at den tar opp plass.
c) Forklar hvordan en software trace debugger fungerer.
Løsning: Software trace debugging er i prinsippet å debugge kode på target ved å sammenligne
kildekoden på host med en trace av koden som eksekveres, som i figuren under.
En logikkanalysator benyttes som å samle informasjon i sann tid fra target. Dette disassembles
og sendes til en programvareanalysator, der det sammenlignes med informasjonen i
symbolfiler eller en database av kilden. Når traceinformasjonen er lagret, kan den vises i det
samme programmeringsspråket som benyttes for kildekoden. En komplett nedtegning kan
steppes gjennom for å finne ut nøyaktig hva som skjedde på target ved gitte tidspunkt.
Oppgave 5 (10%)
a) Hvilke to hovedkategorier for sikkerhetskritiske systemer finnes? Forklar forskjellen
mellom disse to kategoriene, og gi eksempler på systemer i hver kategori.
Løsning:
Logic
analyzer
Disassembler
Address, control, data
Software
analyzer
Symbol
database
Target
Compiler
Host machine
Object
code
Sikkerhetskritiske (Safety-critical) system:
• Feil på systemet medfører alvorlig skade eller dødsfall.
• Fly-by-wire, aero engine control systems, aircraft autoland systems, airbag systems

Side 12 av 3
Oppgavekritiske (Mission-critical) system:
• Feil på systemet medfører at planlagte operasjoner ikke kan gjennomføres.
• Search radar, telecommunication switches, online money transaction systems
b) Forklar begrepene ”Backward error recovery (rollback)” og ”N-version programming” i
forbindelse med håndtering av feil i en applikasjon under kjøring. Beskriv fordeler og ulemper
med disse to metodene.
Løsning:
Backward error recovery:
• Kode består av et sjekkpunkt, primærkode, alternative koder og en akseptansetest.
• System data holdes i sjekkpunkt mens primærkode utføres. Dersom resultat ikke
godkjennes av akseptansetest, kjøres alternativ kode 1. Dersom resultatet av denne
ikke godkjennes kjøres alternativ kode 2. Dersom ingen godtaes, sendes en feilmelding
Fordelen med metoden er at feil i koden kan detekteres, og denne kan fjernes med å kjøre
alternative algoritmer. Ulempene er at dersom alle alternative algoritmer gjennomføres med
feil resultat, stopper applikasjonen opp inntil ekstern recovery gjennomføres. I tillegg kan
eksekveringstider variere mellom hver kjøring, noe som kan medføre problemer med ytelse.
Det kan også være vanskelig å konstruere akseptansetest, da dette krever god kjennskap til
systemet.
N-version programming:
• Benytter N versjoner av en algoritme
• Output sjekkes av en voter, som sammenligner resultater, og sender ut det som flest
(normalt N-1) mener er riktig
Fordelen med denne metoden, er at vi har ingen behov for akseptansetest. Det er uinteressant
hva resultatet er, bare flere er enige om det samme resultat. Ulempene er at det tar mye tid å
kjøre N versjoner av en algoritme, og at dersom majoriteten av algoritmene kommer ut med
feil resultat, så vil dette bli godkjent og sendt videre.