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: STE6221 XX

2 Side 2 av 3 Oppgave 1 (35%) a) Definer hva det vil si at et datasystem opererer i sann tid ( real time ). Løsning: Et datasystem sies å operere i sann tid når det i tillegg til et krav om at oppgavene systemet skal utføre må utføres på en logisk korrekte måte, også er et krav til utførelsestiden for oppgavene. Systemer som ikke klarer å tilfredsstille begge kravene (logisk korrekthet, tidskrav) har feilet! b) Forklar hva som menes med myke sanntidssystemer og harde sanntidssystemer, og gi eksempler på systemer innenfor hver kategori. Løsning: Myke og harde sanntidssystemer er kategorier der sanntidssystemer deles inn etter hvor viktig det er å overholde deadlines. 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. Typiske eksempler: magnetisk levitasjonssystem for tog, airbag-systemer etc. Myke sanntidssystemer: System der variasjon i respons er akseptabel (applikasjonsavhengig). Tidskrav har gjerne anbefalt øvre grense, men overskridelse får ikke fatale følger. Typiske eksempler: TV fjernkontroll, klimakontrollsystem i bil etc. c) Forklar hva som menes med sikkerhetskritiske og oppgavekritiske systemer, og gi eksempler på systemer innenfor hver kategori. Løsning: Sikkerhetskritiske og oppgavekritiske systemer er kategorier der datasystemer deles inn etter alvorlighetsgrad av konsekvens av feil. 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 Oppgavekritiske (Mission-critical) system: Feil på systemet medfører at planlagte operasjoner ikke kan gjennomføres. Search radar, telecommunication switches, online money transaction systems d) Beskriv hvilke operasjonelle krav som gjelder for systemer av følgende typer: Fail-operational (FO) Fail-active (FA) Fail-safe (FS) High-availability (HA)

3 Side 3 av 3 Løsning: Fail-operational (FO): Krever kontinuerlig operasjon med full ytelse til enhver tid. Fail-active (FA): Krever kontinuerlig operasjon, men redusert ytelse er akseptabelt over kortere tidsrom. Dette er ofte beskrevet som graceful degradation. Fail-safe (FS): Avbryting av operasjon er akseptabelt, men dette skal gjøres på en sikker måte. Normalt låses slike system i en predefinert modus og må omstartes manuelt. High-availability (HA): Avbryting av operasjon er akseptabelt, men systemet må startes opp igjen innen relativt kort tid. Dette kan involvere at enheter med feil kan erstattes under kjøring (Hot-swap). e) Forklar hva som menes med begrepet hot-swap i forbindelse med feiltolerante strukturer. Løsning: Systemer som er utstyrt med hot-swap (HS) er en feiltolerant struktur der det er mulig å bytte ut komponenter under kjøring (runtime). CompactPCI standarden definerer flere nivå av hot-swap: Basic HS: Ingen identifikasjon eller konfigurering av nye kort. Kortet som settes inn må være nøyaktig likt kortet som ble tatt ut. Full HS: Definert grensesnitt på kort som benyttes. Dette omgår kravet om identifikasjon/konfigurering. High availability HS for singleprosessorsystem: Mulighet for styring og kontroll av kort som benyttes. Dersom en kontroll viser at et kort har feilet, kan dette omstartes eller stoppes av prosessor High availability HS for singleprosessorsystem: Prosessor HS, basert på en host prosessor. Har mulighet for dynamisk endring av last på prosessorer, også erstatte prosessorer under kjøring Oppgave 2 (35%) a) Hva er forskjellen mellom et preemptive og et non-preemptive sanntids operativsystem (RTOS)? Løsning: Et RTOS som fullfører (dvs. ikke avbryter) kjørende oppgaver med lavere prioritet når en annen oppgave med høyere prioritet er flyttet fra blokkert tilstand til klar-tilstand, kalles et non-preemptive RTOS. Et preemptive RTOS vil avbryte en oppgave med lavere prioritet når en oppgave med høyere prioritet er klar til å kjøre.

4 Side 4 av 3 b) Forklar hva som menes med begrepet interrupt latency, og beskriv hvordan denne påvirkes av lengden på klokkeperioden ( tick ) i systemet. Løsning: Begrepet interrupt latency omhandler tiden som forløper fra et avbrudd inntreffer til den ønskede operasjonen knyttet til avbruddet starter. Ved første tick etter at avbruddet er registrert, vil den kjørende aktivitet byttes ut med en interrupt service routine (ISR) som håndterer avbruddet og starter den ønskede operasjon. Dersom klokkeperioden er lang, vil sannsynligheten for lang interrupt latency være større. Dersom derimot klokkeperioden er kort, sikres vi en lav interrupt latency, men systemet vil generelt får mer overhead i tid. c) Hva vil det si at en subrutine er gjenbrukbar ( re-entrant )? Løsning: Dersom en subrutine er re-entrant så har den egenskapen at den kan deles mellom aktiviteter under kjøring. Når en aktivitet avbrytes inne i subrutinen av en annen aktivitet som vil kjøre samme subrutine, så lagres alle data på privat stakk. Dette gjør at aktiviteten som ble avbrutt kan fortsette der den slapp, uten fare for at data som benyttes i subrutina er endret. d) Forklar hvorfor avbruddsrutiner ( interrupt service routines ) i sanntidssystemer bør inneholde lite kode. Løsning: Selv avbrudd som har lav prioritet utføres før vanlige oppgaver, slik at lange avbruddsrutiner direkte medfører økende responstid for oppgaver. Lange avbruddsrutiner inviterer også til programmeringsfeil som er meget vanskelig å oppdage. Feil som oppstår i en ISR vil mest sannsynlig låse hele systemet når de inntreffer. e) Gi en beskrivelse av rate monotonic scheduling (RMS) og hvilke antakelser som ligger til grunn for denne metoden, og angi fordeler og ulemper med metoden. 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 Ulempen 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

5 Side 5 av 3 U n Tei n = n der U T i= 1 pi når n Dette kan sies å være en fordel, da overholdelse av tidskrav kan bevises matematisk. En god del av antakelsene som ligger til grunn kan omgås på forskjellige måter, slik at systemer der aktivitetene ikke tilfredstiller kravene fremdeles kan vises å garantere overholdelse av tidskrav ved bruk av RMS. 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. Oppgave 3 (10%) a) Forklar hva en proaktiv metode for å håndtere tidskrav under design av programvare er. Løsning: En proaktiv metode integrerer ytelsesbasert utvikling i design/utvikling; ytelse bygges inn i systemet. Dette gjøres med utvikling og analyse av systemmodeller gjennom prosjektets livssyklus, ved å (se figur under): Analyze system requirements and quantify timing needs Design Predict performance Evaluate predicted performance [OK]? [NOK] Build Measure performance [OK]? [NOK]

6 Side 6 av 3 Forstå og sett tall på systemets tidskrav. Dette vil normalt involvere modellering av eksternt fysisk miljø. Design systemet. Forutsi ytelse under designfasen. Dersom ytelsen ikke er tilfredstillende, modifiser design og reevaluer ytelse. Bygg systemet. Mål ytelsen. Dersom ytelsen ikke er tilfredstillende, modifiser design og gjenta prosessen. b) Hva er fordelene og ulempene med denne metoden? Løsning: Fordelene med denne teknikken er: Rask og billig måte å evaluere alternative design og finne ytelsesproblemer før de oppstår. Gir estimat av ytelse lenge før noe kan måles. Nyttig testing kan gjennomføres før programvare implementeres på target. Eksperimenter som i virkeligheten er upraktiske kan gjennomføres. Ulempene med metoden er at: Prosessen koster tid og penger. Lengre design/utvikling. Krever spesielle ferdigheter. Forutsett ytelse er fremdeles bare forutsigelser, og kan være feil. Kan være unødvendig arbeid (og bortkastede penger). Oppgave 4 (20%) a) Hva er fordelene med debugging av programvare på utviklingsmaskin (host)? Løsning: Vi kan teste/debugge det meste av applikasjonen. I enkelte tilfeller kan dette være så mye som 90% av det endelige produktet. Vi kan interagere direkte med programmet og se nøyaktig oppførsel. Effekt av endringer kan sees nesten umiddelbart. Vi sparer tid og penger involvert med programlisting og kodesjekker. Resultater fra kjøring kan lagres for senere analyse. Informasjon om kjøretider gir mulighet for å evaluere ytelse. Dette bidrar til høy produktivitet, reduserte kostnader og raskere utvikling. b) Hvilke svakheter ved programvarebaserte debuggere har ført til utviklingen av maskinvarebaserte produkter?

7 Side 7 av 3 Løsning: Maskinvaren må i prinsippet være feilfri. Debugger kan benyttes for å få maskinvare som fungerer delvis opp å stå, men det må gjøres med forsiktighet og krever detaljert kjennskap til maskinvarens design (og er ikke en idiotsikker metode). Håndtering av asynkrone interrupt er vanskelig (umulig i enkelte tilfeller). Stepping og breakpoint styring forstyrrer vanligvis normal kjøring, og resulterer i redusert hastighet. Et program kan fungere fint under debugging men feile i normal hastighet. Debugger benytter en andel av RAM. Det er derfor mulig for applikasjonen å overskrive debugger med påfølgende kaos som konsekvens. c) Hva er hovedteknikkene for maskinvarebasert debugging? Gi eksempler på hvilke verktøy som benyttes for å støtte disse metodene? Løsning: Maskinvarebasert debugging består hovedsaklig av to kategorier, som i figuren under. Den første benytter innebygde fasiliteter, den andre benytter plug-on enheter. Følgende verktøy benyttes for å støtte hardware-basert debugging: (i) Single-step med buss monitor. En av de enkleste testmetoder for hardware er å monitorere prosessorens tilstand under stepping gjennom programmet. Dette involverer minimalt monitorering av adresse-, display- og kontroll-linjer. (ii) Logisk analysator. I den enkleste form er en logisk analysator en datainnsamler, som henter informasjon fra valgte punkt i mikrokontrolleren. (iii) In-circuit emulator (ICE). Dette er en plug-in erstatning for mikroprosessoren. Den tilbyr all funksjonalitet i prosessoren, sammen med muligheter for integrasjonsstøtte av maskinvare og programvare på target. (iv) Integrerte utviklingsmiljø. Dette er enheter med fullt sett av verktøy (inkludert logiske analysatorer, emulatorer osv) som er konstruert for et spesifikt miljø, og benyttes for utvikling og debugging av target system. Til sensor: Detaljkunnskap om de forskjellige verktøyene kreves ikke, ei heller at de kan alle som er skrevet her. Full score krever hovedgrupperinger pluss min. to eksempler.

8 Side 8 av 3 d) Forklar hva maskinvarebasert analyse av dekningsgrad (coverage analysis) er og hvorfor det er ønskelig å benytte dette på målmaskin (target). Løsning: Analyse av dekningsgrad benyttes for å teste effektiviteten i programvaretester. Maskinvarebasert analyse oppnås ved å benytte et verktøy for analyse av ytelse (PAT) for å samle inn kjøredata fra systemet for offline analyse. Majoriteten av tradisjonelle verktøy kjører på host, og kjører analyse av dekningsgrad på kode på host. Det skaper følgende problemer for oss (såfremst ikke PC benyttes som target): Kode på host er ikke nødvendigvis (faktisk sjelden) den samme som på target. Maskinvaren som koden sjekkes på er ikke samme som target. Tidsaspekter kan være veldig forskjellige fra de på target. I noen tilfeller kan det være forskjeller på område og oppløsning på tallsystemene på host og target, noe som kan gi forskjellig oppførsel i algoritmer.