HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag Tid: Fredag 02.03.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar kalkulator, med tomt minne. Ingen trykte eller håndskrevne hjelpemidler tillatt. Eksamen består av 4 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.
Side 2 av 3 Oppgave 1 (20% ) a) Forklar kort hva som menes med begrepet embedded systems. Med embedded eller innebygde systemer, mener man systemer som inneholder en datamaskin som en integrert del av et system. Systemet er ikke designet for generelle operasjoner lik en PC, men dedikert til bestemte oppgaver. b) På hvilke måter skiller sanntidssystemer seg ut fra vanlige applikasjonssystemer? Sanntidssystemer skiller seg ut fra vanlige applikasjonssystemer først og fremst ved at de har et krav til utførelsestid. I tillegg må selve utførelsen være logisk korrekt, men det bør den helst også være for vanlige applikasjonssystemer. c) Hvordan kategoriserer man vanligvis sanntidssystemer utfra krav til respons? Hint: 4 kategorier. Hard-fast, hard-slow, soft-fast og soft-slow. d) Kan et korrekt sanntidsprogram være upålitelig? Forklar. Ja, et korrekt sanntidsprogram kan være upålitelig. Selv om programmet er testet og funnet korrekt i henhold til spesifikasjonen, kan det vise seg at det i en gitt situasjon gir uventet oppførsel. Dersom spesifikasjonen er feil, vil programmet fremdeles være korrekt, men det kan være upålitelig. Oppgave 2 (10% ) Nedenfor er det gitt et tidsdiagram for kjøring av 3 oppgaver i et sanntidssystem. Oppgavene benytter felles ressurser. Resources ADC Locked DAC Locked Display Locked Tasks Control Task grabs ADC SI task grabs DAC SI task requests ADC Control task requests DAC Alarm task grabs Display Alarm task releases Display Control S R S R DEADLOCKED SI S R Waiting for ADC DEADLOCKED Alarm S R S R S T1 T2 T3 T4 Time a) Forklar hva som skjer, og hvilke konsekvenser denne situasjonen generelt kan ha for et sanntidssystem.
Flere oppgaver benytter de samme ressursene for å utføre det de skal. Oppgaven Control tar ressursen ADC, blir skiftet ut fra prosessoren (slutter å kjøre), og SI tar først DAC en, og etterspør deretter ADC en. Oppgaven må avslutte fordi ADC en ikke er tilgjengelig. Når Control igjen starter opp, vil oppgaven etter en tid ha ha også DAC en, men kan ikke få denne, og må avslutte. De to oppgavene Control og SI venter nå på hverandre, og ingen av dem får prosessortid, slik at de kan frigi den ressursen motparten venter på. Dette kalles for deadlock, og konsekvensene kan være som følger: De to oppgaven som er involvert, får ikke utført det de skal. Dette kan i seg selv være fatalt. De får heller ikke frigitt de ressursene de låser, slik at andre oppgaver kan bruke dem. Etterhvert kan flere oppgaver bli involvert i en ventesituasjon, slik at systemets funksjonalitet reduseres drastisk. Dette kan gi fatale konsekvenser for totalsystemet. b) Forklar hvilke metoder som generelt kan benyttes for å unngå denne situasjonen i et sanntidssystem. Generelt kan man sikre seg mot dette ved: a) Å forhindre at slike situasjoner kan oppstå ( prevention og avoidance ). Her kan man benytte restriksjoner på ressursbruken eller dynamiske sjekker underveis. b) Ha metoder for å komme seg ute av en slik situasjon når den først har oppstått. Arving av prioritet ( priority inheritance ) er f.eks. en metode for å løse en slik situasjon, der en oppgave med lav prioritet midlertid får høyere prioritet for å gjøre seg ferdig med en ressurs.
Side 3 av 3 Oppgave 3 (5% 5% 5% 7 5% 50% ) a) Hva menes med kohesjon ( cohesion )? Hvilke typer kohesjon har man? Kohesjon er et begrep som benyttes for å forklare hvor sterkt komponenter i en programvaremodul hører sammen. I rekkefølgen best til dårligst, har vi følgende kohesjonstyper: Funksjonell Sekvensiell Kommunikasjonsbasert Prosedural Temporal Logisk Tilfeldig b) Hva mens med kobling ( coupling )? Hvilke typer koblinger har man? Kobling er et begrep som benyttes for å forklare hvilke relasjoner det er mellom ulike datamoduler. Følgende koblinger (fra verste til beste tilfelle) eksisterer: Kobling gjennom felles innhold (data, kode) i modulene ( Content coupling ) Kobling gjennom felles ressursbruk (data, kode) utenfor modulene ( Common coupling ) Kobling gjennom overføring av peker til felles datastruktur ( Stamp coupling ) Kobling gjennom overføring av dataadresser ( Data coupling by reference. ) Kobling gjennom overføring av dataverdier ( Data coupling by value ) c) Forklar hvilke typer av kommunikasjon man har bruk for mellom oppgaver ( tasks ) i et sanntidssystem. Hint: 3 typer Synkronisering og koordinering av oppgaver uten dataoverføring Dataoverføring mellom oppgaver uten synkronisering Synkronisering av oppgaver med dataoverføring d) Forklar kort følgende begreper relatert til sanntidssystemer: 1. Nanokernel De mest nødvendige funksjoner (opprettelse av oppgaver, håndtering av oppgaver, timing og avbrudd) et operativsystem må inneholde for å kunnebrukes. Ikke standardisert begrep. 2. Priority Ulike oppgaver har ulik prioritet, som angir oppgavens viktighet 3. Memory leakage Betegner en situasjon der minne som allokeres ikke eksplisitt frigjøres, selv om bruken av det opphører. Området kan ikke brukes på nytt fordi ingen vet at det er ledig, og den opprinnelige brukeren har ikke lenger adressen til det. Ofte foregår dette ved at pekeren til området endres (slettes, får ny verdi), slik at adressen til området ikke lenger benyttes. 4. Task context Registerverdier og alle andre dataverdier som må bevares for å kunne starte en oppgave i eksakt samme
tilstand som den var da den ble stoppet. 5. Task states Tilstanden til oppgaver. Ikke standardisert begrep, men følgende hovedtilstander forekommer ofte: Kjørende Klar (til kjøring) Blokkert ( Blocked/suspended ) 6. Time slicing En fordeling av prosessortid der det benyttes faste tidsintervaller. Oppgaver som kjører får en angitt tidsluke, og skiftes så ut. 7. Mutual exclusion Gjensidig utelukkelse. Oppgaver kan ikke samtidig benytte en resurss (data, maskinvare) de begge har behov for, fordi dette kan resultere i feilaktige resultat 8eller i verste fall systemkræsj). Oppgave 4 (20% ) Anta at vi tar for oss et nøkkelkortsystem tilsvarende det som er installert på hovedinngangen her ved HiN. Systemet består i korte trekk av en kortleser med rødt og grønt lys, en prosesserende enhet, samt en motor som styrer låsen og døra. For enkelhets skyld antar vi at du må bruke adgangskort for å låse opp døra til alle tider på døgnet. Prinsippet er at når en person vil inn, drar denne adgangskortet gjennom kortleseren. Den prosesserende enheten sjekker da om adgangskortet er gyldig. Hvis det er et gyldig adgangskort, settes lys til grønt, så startes motoren, døren låses opp og døren åpnes, hvis ikke forblir døren låst. Etter at døren har vært åpen i 10 sekunder, lukkes og låses døren igjen, og lyset skifter til rødt. Systemet har altså to aktiviteter, aktivitet A1 som leser/sjekker adgangskort og aktivitet A2 som styrer låsen/døra. Kommunikasjonen mellom disse aktivitetene går med signaler, der A1 sender signal til A2 når døra skal åpnes, og A2 sender signal til A1 når døra er lukket etter åpning. a) Relatert til UML use case diagram, gi en kort beskrivelse av forskjellen mellom direkte og indirekte aktører ( actors ), og angi hva som er aktørene til systemet beskrevet ovenfor. En direkte aktør til et system er en enhet som kommuniserer direkte med systemet, for eksempel tastatur, skjerm, lys osv. En indirekte aktør kommuniserer med systemet via de direkte aktørene, og er typiske brukere med forskjellige roller. For dette systemet kan en si at personer med adgangskort vil være indirekte aktører, mens kortleseren og lysdiodene vil være direkte aktører. Det er mulig å se på kortleseren og lys som en enhet og en aktør, men dette må i så tilfelle beskrives. b) Sett opp et overordnet use case for systemet. Et use case av systemet er gitt i figuren under.
Studentene bør minst få med de to aktivitetene som er beskrevet i teksten, samt en kobling mot aktører. Alternativt kan indirekte aktører benyttes, men da bør det foreligge en beskrivelse av hvilke aktiviteter som inneholder kortleser og lysdioder. Det kan også, ut fra oppgaveteksten, være fristende å benytte A1 og A2 som navn på use case, men dette er ikke i tråd med UML tankegang om å beskrive hva aktivitetene gjør, og godkjennes ikke. c) Angi best case scenario for den prosesserende enheten, samt et worst case scenario der brukeren ikke har et gyldig adgangskort. Start 1. Vent på kort. 2. Les kortinformasjon. 3. Sjekk kortinformasjon. 4. Sett grønt lys. 5. Send signal for å åpne dør. 6. Vent på signal for dør lukket. 7. Sett rødt lys. 8. Gå til 1. Slutt Worst case scenario - ugyldig kort: Start 1. Vent på kort. 2. Les kortinformasjon. 3. Sjekk kortinformasjon. 3.1 Kort ugyldig 3.2 Gå til 1. 4. Sett grønt lys.
5. Send signal for å åpne dør. 6. Vent på signal for dør lukket. 7. Sett rødt lys. 8. Gå til 1. Slutt Scenariene skal beskrive gangen i systemets kjøring, men det er selvfølgelig mulig å slå sammen noen punkter ovenfor. Allikevel bør scenariene helst utbroderes så mye som mulig, for å gi en bedre oversikt over detaljene i kjøringen. d) Sett opp et UML sekvensdiagram for aktivitetene i systemet ved normal kjøring. Et forslag til løsning er gitt i figuren under. Det kan variere litt avhengig av hvordan scenariet er satt opp, og også i dette tilfellet er det mulig å slå sammen enkelte punkt. Studenten bør minimum klare å sette opp diagrammet med de to angitte aktivitetene, med skraverte bokser for å angi hvilken aktivitet som har fokus, samt signalisering mellom aktivitetene.