LØSNINGSFORSLAG. EKSAMEN I Sanntidssystemer Fagkode: STE6221

Transkript

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

2 Side 2 av 3 Oppgave 1 (15%) 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.

3 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:

4 Side 4 av 3 Predikerbarhet og ytelse Pålitelighet Scheduling Deling av ressurser mutual exclusion Synkronisering og kommunikasjon 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

5 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

6 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.

7 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 n Tei n = n der U T i= 1 pi når n 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%) 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

8 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. Use Case 1 Text for use case 1 Use Case 2 Text for use case 2 Use Case 3 Text for use case 3 Actors Use cases Use case descriptions Navigator Vehicle navigation system Driver Get navigation waypoints c) Beskriv oppbygning av og hensikten med et UML sekvensdiagram (sequence diagram).

9 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. Time Object 1 Object 2 T 0 Processing Processing T 1 T 2 T 3 T 4 Send message Processing Message arrival and detection Processing Message arrival and detection Send acknowledgement Processing 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: Statisk testing (test av kvalitet): Manuell eller automatisert analyse av kode for å finne feil Sjekk av kode mot designmodeller og kodestandarder

10 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 Macroprocessor Compiler Symbol table Source program Host Debugger and execution control interface Target Execution monitor Application software 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

11 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. Logic analyzer Address, control, data Target Object code Disassembler Symbol database Compiler Software analyzer Host machine 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: 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

12 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.