Forlæsningsplan 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.

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?

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?

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?

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?

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?

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?

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?

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?

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

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

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?

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?

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?

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?

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 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?

Task: Karakteristikker og definitioner 1 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 2 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?

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?