Forlæsningsplan

1. Del 1: Introduktion, definition af sandtidssystemer og gennemgang af analyse og design metoder. Kort intro til AVR platform. Del 2: Scheduleringsprincipper: Statiske/dynamiske f.eks. round robin/dynamic priority. Scheduleringskriterier: Generelt og for enkelte scheduleringsprincipper. Del 3: Schedulerbarhedskriterier ved fixed priority schedulering. Del 4: Schedulerbarhedskriterier ved dynamic priority schedulering. Del 5: Aperiodiske tasks og lidt køteori. Forlæsningsplan

2. Introduktion: Generelt • Begrebet system har tæt sammenhæng med definitionen af en matematisk funktion. • Mapping fra rum til billedrum. • Sekvens af data mappet til en associeret sekvens af data. • Sandtidssystemer. • Rum og billedrum er sekvenser af hændelser. • En modsætning til ikke-sandtidssystemer. (Der er ikke en fælles mængde – det er enten eller!) • Tænk! • Er føren af en bil et sandtidssystem? • Hvad gør han/hun er det eller ikke er det? • Er en automatisk oversættelse af ”Ringenes Herre” fra engelsk til dansk et sandtidssystem. • Kan det være både/og?

3. Introduktion: Eksempel • HW opdeling i forhold til et sandtidssystems natur. • I/O punkter. • Hændelsesgeneratorer. • Hændelsesreflektorer. • Tænk! • Hvor meget kræves der af en microcontroller for at fungere som kerne i et sandtidssystem? • Er alle input punkter hændelsgeneratorer? • Er alle output punkter forbundet til en ekstern enhed hændelsesreflektorer?

4. Deling af et system (eller ej) • To intuitive dele i et system • Process: Den fysiske verden der eksistere udafhængigt af vores teknologiske indsats. • Controller: Den enhed (Et meget brugt IKKE-ORD!) der konstrueres for at interagere med den fysiske verden. • Begge dele kan opfattes som hvert sit sandtidssystem. • Begge har sekvenser af hændelser som input og output. • Tænk! • Findes der sandtidssystemer andre steder end inden for process kontrol? • Vil vi altid kunne dele et system i process og controller? • Fysisk? • Logisk?

5. Implementering og systemtyper • Lokalt eller distribueret system • Sand parallelisme. • Multiple uafhængige controllere. • Tyndt interface mellem controllerne. • Køre fysisk set parallelt. • Falsk/pseudo parallelisme. • Implementeret i SW med scehduler. • Udnytter differentieret adgang til den fysiske verden. • Se ud til at køre parallelt. • Real-time OS • RTOS, Solaris, Windows NT, RT Linux, OSE, eCos etc. • Indeholder IPC (Inter Process Comm.) • Tænk! • Kan et system både indeholde sand og pseudo parallelisme?

6. Hård eller blød sandtid • Den teoretiske beskrivelse • Hård sandtid: systemet er kun anvendeligt hvis de korrekte resultater opnåes før fastsatte dead-lines. • Blød sandtid: systemer er anvendeligt hvis de korrekt resultater opnåes inden for en given periode. (Blødere end dead-lines!) • Den praktiske beskrivelse • Hård sandtid: systemet er kun anvendeligt hvis de korrekte resultaterne opnåes mens de er relevante. (Systemet dør med et udeblevet resultat.) • Blød sandtid: systemet er anvendeligt selv om alle hændelser ikke opfattes og behandles hver gang de opstår. (Systemet overlever selv om resultater udebliver.) • Tænk! • Er hård sandtid ofte relevant?

7. Analyse og design: Forudsætninger • Sandtid er en egenskab der basere sig på vores synsvinkel og er ikke en system egenskab • Sandtidssystemer agerer i forhold til en parallel verden med op til flere forskellige interface og har derfor selv en parallel natur • Nogle metoder til analyse og design: • COBRA – Concurrent Object-Based Real-Time Analysis • RTSA – Real-Time Structured Analysis • CODARTS – Concurrent Object oriented Design and Analysis of Real-Time Systems • Real-Time UML – Real-Time Unified Modeling Language • Er ikke ROOM (UML Real-Time) • Er ikke SDL • Tænk! • Er A & D metoder nødvendige?

8. Real-Time UML og ROPES • ”Iterative Rapid Development Process” er bedre kendt som ROPES (Rapid Object-Oriented Process for Embedded Systems) • Hver iteration generere en virkende model (Artifact) • Korte dead-lines og høj målbarhed • Use-Case baseret krav analyse • Aktører behøver ikke være mennesker • Use-Case diagrammer viser black-box egenskaber for et system • Indholdet af use-cases skal være tilgængeligt for ikke-teknikkere • Kan løbende udbygges med yderligere informationer efterhånden som ”eksperterne” oplyser dem • Giver overblik • Tænk! • Hvad er fordelene ved en udviklingsspiral? • Hvad er alternativerne til use-cases?

9. Real-Time UML og Use-Cases • Use-cases kan relateres til hinanden • Inkludere – sub use-case • Udvider – super use-case • Generalisere – specialiseret use-case • QoS (Quality of Service) krav • Tilføjes som kommentarer i de enkelte use-cases • Kan løbende uddybes • Normale real-time QoS elementer • Hastighed • Tidslinier • Kapacitet • Forudsigelighed • Stabilitet • Sikkerhed • Tænk! • Hvornår stopper udvidelserne af en use-case?

10. Real-Time UML og sekvens diagrammer • Use-cases fører til scenarier som kan beskrivelse i sekvens diagrammer • Viser sekvenser af messages mellem objekter • Vertikale linier repræsenterer objekter • Horisontale linie repræsenterer messagess • To message type i UML, signal og metode • Sekvens diagrammer kan bruges til at fange • Mulige tilstande i et objekt • Mulige tilstandsskift – typisk på begrund af et signal og ikke en metode • Timing begrænsninger • Kommunikationsflow • Et system kan typisk have fra nogle få til nogle dusin use-case • En use-case kan typisk have fra nogle få til nogle dusin scenarier

11. RT-UML: Use-case opstart • Råd og retningslinier • Glem teknikken • Spørg brugerne • Glem teknikken • Observer brugerne • Glem teknikken • Beskriv systemet ud fra brugernes synsvinkel • Glem teknikken • Hold konsentrationen omkring den strukturelle kontekst • Glem teknikken • Tænk! • Er der andet man skal holde sig for øjet når man går igang med use-cases?

12. RT-UML: Opdagelse af objekter • En iterativ process • Man kan ikke finde alle objekter i første hug • Initial identificering • Begreb understregning • Fysiske elementer • Transaktioner • etc. • De enkelte mulige objekter skal valideres som anvendelige objekter • Hold hovedet koldt • Der er en overhængende fare for overstrukturering • Vær kritisk overfor de mulige objekter • Tænk! • Hvordan ved man om man har overstruktureret? • Hvordan ved man at man har fundet de korrekte objekter?

13. RT-UML: Use-case til objekt-model • Samarbejdes (Collaboration) diagram • Tag udgangspunkt i de enkelt use-cases • Indsæt idenficerede sæt af objekter • Træk relationer mellem aktører og objektsæt • Første tekniske realisering af use-cases • Systemets funktionalitet er identificeret før der udføres objekt analyse • Hold overgangen fra use-cases til objekt-model simpel • Tænk! • Er det en fordel at vente med tekniske beskrivelser til nuværende tidspunkt? • Hvordan adskiller dette sig fra CODARTS?

14. RT-UML: Sekvens til objekt model • Udvidelse af scenarie sekvens diagrammer • Udgangspunkt i collaboration diagrammerne • Tilføje kommunikation mellem objeksæt • Udvid med nye identificerede tilstande (states) • Tænk! • Hvor tæt er vi på et egentligt design? • Har vi alle detaljer omkring timing på dette stadie?

15. RT-UML: Class diagram • Objekt adfærd • Beskrives i class diagrammer • Alle realiterede objekter includeres i deres respektive sub-systemer • Deres indbyrdes relationer uddybes • Relationer til tidligere arbejde • Use-case diagrammer • Collaboration diagrammer • Objekt og attribut identificering • Tænk! • Hvor er timingen blevet af? • Adskiller Real-time UML sig indtil videre fra standard UML?

16. Real-time UML er mere under overfladen • Yderligere detaljeringsgrader • Message stereotypes • Tilstandsdiagrammer • Tilstandstiming • Objekt timing • Detaljeret design • etc. • Sammenhæng med andre analyse og design metoder • Tilstandsdiagrammer • Tilstandstiming • Objekt timing • Detaljeret design • etc. • Høj abstraktionsgrad • Use-case dybt indlejret i analyse og design metoden • Tænk! • Hvor store er forskellene mellem de forskellige analyse og design metoder?

17. Et job er en afgrænset mængde arbejde der skal udføres af en task i sandtidssystemet En task er en samling af jobs (J1, J2....) Ready time r er tidspunktet hvorfra et job kan begynde en eksekvering Computation time c er tiden et job antages at tage i total processor tid. Starting time S er tidspunktet hvor jobbet starter. Completion time C er tidspunktet hvor jobbet afsluttes. Deadline d er tidspunktet hvor jobbet skal være afsluttet for at overholde de givne sandtidskrav. At afbryde et job Preemptible Non-preemptible At afbryde en task Preemptible, hvis alle jobs er preemptible Tænk! Hvad er den mest normale job type som preempter andre jobs? Gælder dette også for ikke sandtidssystemer? Task: Karakteristikker og definitioner 1

18. Task kategorier Deterministisk, hvis det til tiden 0 er muligt at forudsige alle ready tider for de associerede jobs Ikke-determinstisk, hvis tasken ikke opfylder kravet til en determinisk task Interarrival time T(j) T(j) er lig tiden mellem r(j-1) og r(j) Periodisk, hvis alle T(j) = T (T = periode) Aperiodisk, hvis tasken ikke er periodisk Aperiodiske tasks Der må findes en minimum interarrival time, Tmin Er Tmin >> c kaldes tasken sporadisk Tænk! Kan et timer interrupt i en microcontroller være aperiodisk? Kan man tillade sig at behandle aperiodisk tasks med svagt divergerende T(j) som periodiske tasks? Sandtid Hvis d <= T er tasken underlagt hård sandtid Hvis d > T er tasken underlagt sandtid Hvis d = en gennemsnitsværdi er tasken underlagt blød sandtid Ingen d er tasken ikke underlagt sandtid Tænk! Passer overstående med de tidligere definitioner af sandtid? Task: Karakteristikker og definitioner 2

19. AVR microcontroller: Den store • RISK baseret 8-bit microcontroller • 4K intern SRAM • 4K intern EEPROM • 128K intern Flash (64K instruktioner) • Multiple timere • Et hav at I/O muligheder • Op til 16MHz clock frekvens • Free/Open Source RTOS (http://www.avrfreaks.net) • FreeRTOS • AvrX RTOS • Ethernut • Tænk! • Hvad er det største problem fra en Atmel AVR når den skal køre et RTOS? • Kan et RTOS på en Atmel AVR bruges til noget fornuftigt eller er det bare leg?