HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL KONTINUASJONSEKSAMEN Tid: Fredag 18.08.2006, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar kalkulator, med tomt minne. Ingen trykte eller håndskrevne hjelpemidler tillatt. Eksamen består av 5 oppgaver og 3 sider. Faglærer: Førsteamanuensis, Dr.ing. Per J. Nicklasson, Tlf. 76 96 64 01/48 29 72 37 Oppgavenes vekt er angitt i prosent av total poengsum. Hvert nummerert delspørsmål gir 5 poeng.
Oppgave 1 (20%) a) Forklar kort hvilke hovedtyper av feil som kan oppstå ved utvikling av et sanntidssystem. Følgende hovedgrupper av feil kan oppstå: Feil i kravspesifikasjon Feil i systemdesign, altså design av totalsystemet som maskinvaren og programvaren inngår i. Feil i design av programvaren og maskinvaren Feil ved koding (syntaktiske, semantiske feil, logiske og algoritmiske feil) I tillegg kan interaksjonen med omverdenen gir feilsituasjoner ved bruk, fordi man under utvikling ikke har tatt hensyn til alle mulige situasjoner som kan oppstå (kan også tolkes som en ukomplett kravspesifikasjon). b) Hva er det som kjennetegner driftsikker programvare? Driftssikker ( dependable ) programvare kjennetegnes ved at den er: Korrekt ( correct ) Pålitelig ( reliable ) Sikker ( safe ) c) Hvilke 3 hovedtyper av krav benyttes i en kravspesifikasjon for programvare? Funksjonelle krav Ikke-funksjonelle krav Utviklingskrav d) Hva menes med prototyping? Nevn 3 bruksområder for prototyping ved utvikling av programvare. Med protoyping mener vi fremstilling av tidlige versjoner av et produkt (eller deler av produktet) for å kunne studere enkelte egenskaper med produktet. Prototypen er som oftest en nokså ukomplett versjon av produktet. Det kan f.eks. være en en simulering eller animasjon av produktets oppførse vha. dataverktøyl. Utforskende prototyping for å teste om begge parter er enige i krav. Exploratory prototyping Prototyping av krav f.eks. ved hjelp av visuelle verktøy. Solution prototyping. Granskende prototyping (alternative løsninger i designfasen, visuelle verktøy). Investigative prototyping. Verifikasjon (analyse av kode vha. formelle spesifikasjonsmetoder). Verification prototyping. Utviklende prototyping (modifikasjoner og oppgradering). Evolutionary prototyping. Oppgave 2 (15%) a) Hva menes med begrepet bespoke system-on-chip designs når det gjelder maskinvare for sanntidssystemer? Med dette begreper mener vi spesialdesignede maskinvareløsninger der hele systemet (mikroprosessor, minne, etc.) i hovedsak er integrert på en brikke Det kan f.eks. være ASICs (Application Specific Integrated Circuits) eller FPGAs (Field Programmable Gate arrays).
b) Hva er det som gjør testingen av innebygde systemer spesielt vanskelig sammenlignet med testing av konvensjonelle applikasjonssystemer? Det er flere momenter: Utviklingen av programvaren foregår ofte på et annet system enn det den til slutt skal anvendes på. Det fysiske grensesnittet (mangel på skjerm, tastatur, tilkoblingsmuligheter osv.) kan gjøre det vanskelig å få innsikt i hva som skjer på det endelige systemet. Det er vanskelig å teste systemet i de virkelige omgivelsene og under de virkelige operasjonsbetingelsene. c) Anta at du skal designe et sanntids styresystem for et jagerfly. Hvordan vil du sikre deg at systemet er i stand til å takle feil som oppstår på best mulig måte? For det første må det gjøres en grundig jobb under utarbeidelse av kravspesifikasjonen for systemet, og design av systemet. For slike systemer er det vanlig å bruke spesialutviklet maskinvare (spesielle prosessorer som er grundig testet), og dessuten redundans både mhp. maskinvare (flere prosessorer som gjør det samme, og der resultatene veies opp mot hverandre) og programvare (ulike prosessorer kjører forskjellige programvareversjoner som skal gjøre det samme, men som er utviklet med forskjellige verktøy, språk og av ulike team). Det benyttes også vel uttestede sanntids operativsystemer som selvfølgelig har tjenester som gjør det mulig å implemetere harde sanntidskrav. Oppgave 3 (5% 5% 5% 6 5% 45%) a) Hvorfor er det fornuftig å benytte et operativsystem ved konstruksjon av et sanntidssystem der det inngår datamaskiner? Fordi operativsystemet er et verktøy som gjør det lettere å utvikle systemet. Operativsystemet tilbyr ferdige tjenester, slik at de som utvikler resten av systemet kan avgrense sin oppgave. Interaksjonen mellom ulike oppgaver kan være komplisert i et sanntidssystem. b) Hvilke tjenester bør et sanntids operativsystem minst kunne gi dersom det skal benyttes i et hardt sanntidssystem? Mulighet for å definere oppgaver Parallellitet av oppgaveutførelse ( concurrency ) Synkronisering av utførelse. Tilgang til systemressurser på bestemte tidspunkter og tilfeldige tidspunkter (mulighet for avbrudd) Timing av utførelse (spesielt viktig for harde sanntidssystemer) Kommunikasjon mellom oppgaver Alt dette må utføres på en predikterbar og pålitelig måte. c) Anta at det i et hardt sanntidssystem eksisterer oppgaver som utføres som et resultat av avbrudd som kan komme ved tilfeldige tidspunkter. Drøft hvilke konsekvenser dette kan ha mhp. systemets ytelse. Det kan ha den konsekvensen at systemet i verste fall slutter å fungere. Dersom det ikke er satt av stor nok slakke i tidskravene til systemet for at slike oppgaver kan utføres i tillegg til de andre oppgavene, vil det blir for lite tid til at alle oppgaver og avbrudd kan utføres. d) Forklar kort følgende begreper relatert til sanntidssystemer: 1. Scheduling
Tildeling av prosessortid til de ulike oppgavene. 2. Preemptive En oppgave kan avbrytes av operativsystemet slik at en annen oppgave kan få kjøre. 3. Kernel Brukes om et sett med hovedfunksjoner i et operativsystem, dvs. de mest nødvendige operasjoner 4. Concurrent Parallell (samtidig) kjøring av oppgaver. På et system med kun en prosessor er det jo ikke mulig å gjøre dette, så det blir en tilsynelatende parallell kjøring av oppgaver. 5. Reentrant code Kode som er utformet slik at kjøringen av koden kan avbrytes midlertidig, og så kan den samme koden kjøres med andre dataverdier. Etter hvert vil første bruk av koden gjøres ferdig. Alt dette kan skje uten feil. F.eks. kan flere oppgaver ( tasks ) kalle den samme funksjonen, som kan avbrytes midlertidig for så bli kjørt på nytt, uten at noen av resultatene blir feile. 6. Deadlock En situasjon dere en oppgave ikke kan gjøre seg ferdig før en annen oppgave har utført noe, og den andre oppgaven (via en kjede av sammenhenger) venter på den første. Andre oppgaver kan godt fungere utmerket, men dette kan også medføre at hele systemet etterhvert går ned. Oppgave 4 (15 %) a) Forklar hva som menes med vedlikehold av programvare. Vedlikehold av programvare innebærer modifikasjon av eksisterende programvare for enten å rette opp feil, eller for å implementere oppgraderinger (nye tjenester). b) Mange utviklere klager på vanskeligheter under vedlikehold av programvare. Hva kan årsaken til dette være? Det er ikke uvanlig at når et produkt kommer i vedlikeholdsfasen, så har de originale designere/utviklere forlatt åstedet. Følgelig blir vedlikehold vanligvis utført av personer som: Ikke var involvert i utviklingen. Ikke har mulighet til å få tak i de originale designerne. Har tilgang til minimal designdokumentasjon (f.eks. kun kildekode). Har tilgjengelig designdokumentasjon som ikke samsvarer med den faktiske koden. Har begrenset forståelse av systemets overordnede oppgave. Må lære mye om systemet på kort tid, selv for små endringer. Ikke selv ville skrevet koden slik den fremstår. c) Du holder på å starte et nytt programvareprosjekt. Hva vil du gjøre (generelt) for å sikre at skikkelig dokumentasjon blir generert til bruk under vedlikehold etter at systemet er ferdig? De viktigste kravene er at dokumenter skal være: Komplette. Korrekte. Klare og forståelige. Konsistente.
Først må vi definere (i en formell brukermanual) hva som menes med komplett. Vi må mao spesifisere hvilke dokumenter som kreves for prosjektet. Dernest må vi definere korrekthet (for dokumentene, ikke designet): Benytt en notasjon som har definert syntaks og semantikk. Forskrifter om ikke-standard syntaks må inkluderes (av realistiske årsaker). Klarhet og god forståelse oppnås på to måter; ved valg av diagram og valg av symbol i diagram. Dersom et modelleringsspråk er komplekst, bruk et hensiktsmessig subsett (bare det du har bruk for). Hvordan diagrammer benyttes er i virkeligheten knyttet opp mot designteknikk og prosess. Ingen kokebokløsninger er tilgjengelige; den beste guide er designerfaring. Generelt bør vi styre mengden av informasjon som presenteres og kompleksiteten av den. Konsistens oppnås best ved bruk av CASE verktøy. Dette vil ikke stoppe noen fra å gjøre feil, men i det minste vil alle relaterte diagram ha samme feil (konsistent). Videre bør konsistens gjelde også for kode; koden må reflektere designspesifikasjonen (ellers kan du forkaste alle designdokumenter). Til slutt må hele systemet gå under en viss politikk (dvs. rutiner), slik at alle endringer lagres og kan spores, og dokumentasjonen oppdateres ved behov. Oppgave 5 (5%) Hvordan kan diagrammer og diagrammetoder hjelpe til med å produsere forutsigbar og pålitelig programvare? Bruk av diagrammer kan bidrar på mange måter: (i) Som designverktøy. God forståelse av problemet kreves for å kunne tegne diagrammer. Introduserer formalitet og strenghet i designprosessen, spesielt der syntaks og semantikk er klart definert. Prosessen fjerner tvetydighet og tvil. Bedrer mulighet for revidering og analyse av design, og gir kontroll på progresjon. Gir grunnleggende materiell for presentasjon av systemet. (ii) Til bruk ved dokumentasjon. Diagram gir mulighet til å demonstrere at: Vi gjør den rette jobben (høynivå) Vi gjør jobben rett (lavnivå) Vi kan vise at vi gjør den rette jobben ved å bruke diagrammer for å illustrere: Helhetlig og detaljert funksjonalitet i systemet. Funksjonalitet og interaksjon mellom forskjellige delsystemer. Overordnet struktur sammen med de store delsystemer. Overordnet funksjonalitet i design. Samhandling mellom system og miljø. Gode høynivå diagrammer er enkle og forståelige, og viser de store trekkene i systemet. Ved å benytte disse er det relativt enkelt å se effekter på systemets oppførsel ved endringer. Å vise at jobben gjøres rett illustreres ved å benytte diagram som: Er løsningsorientert. Går i detalj. Vektlegger intern informasjon om systemet.