Christer Norström, Kristian Sandström, Jukka Mäki-Turja, Hans Hansson, Henrik Thane och Jan Gustafsson Mälardalen Real-Time Research Centre {cen,ksm,

Transkript

1 Christer Norström, Kristian Sandström, Jukka Mäki-Turja, Hans Hansson, Henrik Thane och Jan Gustafsson Mälardalen Real-Time Research Centre {cen,ksm, jma, han, hte,

2 Version: rts-bok Christer Norström, Kristian Sandström, Jukka Mäki-Turja, Hans Hansson, Henrik Thane och Jan Gustafsson Detta verk är skyddat av upphovsrättslagen. Kopiering är förbjuden utöver vad som avtalats mellan upphovsrättsorganisationer och högskolor enligt avtalslicensen i 13 upphovsrättslagen. Den som bryter mot lagen om upphovsrätt kan åtalas av allmän åklagare och dömas till böter eller fängelse i upp till två år samt bli skyldig erlägga ersättning till upphovsman/rättsinnehavare.

3 Förord Detta kompendium har vuxit fram ur föreläsningsanteckningar som använts vid ett otal kurser såväl kortkurser för ingenjörer från industrin som reguljära kurser vid universitet och högskolor, dock främst vid Mälardalens högskola. Målet med kompendiet är att ge en introduktion till ämnet realtidssystem och grundläggande kunskap om metoder och tekniker som är ingenjörsmässigt användbara vid konstruktion av realtidssystem. Den som läst och förstått detta kompendium har en god grund för att kunna utveckla inbyggda realtidssystem. Genomgående i hela kompendiet kommer vi att belysa både tidsstyrda och händelsestyrda system samt jämföra dessa. Tidsstyrda system är system som enbart drivs av klockan medan händelsestyrda system är system som triggas av yttre händelser som t.ex. avbrott. Redan i kapitel 2 introduceras realtidsoperativsystem, den programvaruplattform som allt fler realtidssystem byggs på. Vi kommer inte att lovprisa användningen av realtidsoperativsystem, i stället försöker vi ge en nykter syn på dess användbarhet samt noggrant diskutera vilka fallgropar som finns och hur man undviker dessa. I kapitel 3 visar vi olika tekniker för analys av ett realtidssystems beteende. Kapitel 3 har en helt annan karaktär än kapitel 2 - det är mer precist och innehåller en ansenlig mängd teori. Kapitlet kommer främst att visa hur man kan analysera system där program (processer) tilldelas statiska prioriteter samt hur man kan konstruera statiska scheman. Båda dessa konstruktionsmetoder används i industrin idag, t.ex. används den första tekniken vid konstruktionen av styrsystemet för Volvo S80 och den andra JAS 39 Gripen. I kapitel 4 kommer vi att introducera design av inbyggda system, dvs vi kommer att studera de olika aktiviteterna som måste utföras inom ett utvecklingsprojekt. Vi kommer specifikt introducera en metod som utvecklats vid MRTC och som numera används i industrin. Denna metod går ut på att integrera tidskrav i utvecklingsmodellen och inkludera dessa i samtliga utvecklingssteg från kravspecifikation till implementation och underhåll. Metoden gör desutom tydlig åtskillnad mellan design och implementering; designerns slutresultat är ett målsystemoberoende specifikation som i implementeringsfasen kan. mappas till olika exekveringsprinciper. I kapitel 5 introducerar vi olika typer datakommunikation i realtidssystem. Specifikt kommer vi att studera ett tidstriggat protokoll Time Division Multiple Access (TDMA) och ett händelsetriggat protokoll Carrier Sense Multiple Access with Collision Resolution (CSMA/CR). TDMA protokoll har sin största användning i säkerhetskritiska system medan CSMA/CR är en teknik som t.ex. nyttjas i den så populära CAN-bussen. För både dessa tekniker kommer vi att presentera analysmetoder med vars hjälp svarstider på de ramar som sänds på bussen kan beräknas. Kapitel 6 innehåller teori om distribuerade realtidssystem. Vi kommer studera dels system som är rent tidsstyrda och system som är rent händelsestyrda. Vi visar hur

4 analysteknikerna i kapitel 3 och 5 kan kombineras för analys av distribuerade funktioner. I kapitel 7 ger vi en mer detaljeras presentation av CAN-bussen och vi kommer dessutom att beskriva hur CAN nätverket kan användas i distribuerade realtidssystem, hur trafiken som går på nätet kan analyseras och hur denna analys kan kombineras med analysen i datornoderna. I kapitel 8 kommer vi att kort presentera TTP som är ett tidstriggat protokoll speciellt utvecklat för tillämpningar där det ställs mycket höga krav på tillförlitlighet. Protokollet är utvecklat inom ett antal EU-finansierade projekt där ett flertal biltillverkare har deltagit och där det Tekniska universitetet i Wien har varit drivande. Protokollet är tänkt att kunna hantera så kallade "X - by wire" tillämpningar i fordon, såsom steer-by-wire eller brake-by-wire, dvs tillämpningar där det mekaniska/hydrauliska systemet ersätts med elektronisk styrning. Utöver de 8 kapitlen innehåller kompendiet två appendix som behandlar klocksynkronisering och membership. Appendixet om klocksynkronisering beskriver olika principer för hur klockor i ett distribuerat system kan synkroniseras. Appendixet om membership presenterar metoder för att säkerställa att noderna i ett distribuerat system har en konsistent vy av vilka noder som fungerar samt får reda på om en nod havererar inom en viss tid. Eftersom detta är en tidig utgåva av kompendiet så hoppas vi att ni har överseende med vissa brister och ofullständigheter. Vi är mycket tacksamma för alla konstruktiva synpunkter! En hemsida ( för kompendiet finns, där förslag till förbättringar kan lämnas och en errata kommer att finnas. Vi vill tacka följande personer som kommit med förslag på förbättringar: Björn Lisper, Mikael Sjödin, Andreas Ermedal, Markus Lindgren och Ralf Elvsén. Rickard Lindell som bidragit med avsnittet om konsumentprodukter och realtid och Andreas Engberg och Anders Pettersson som bidragit med avsnittet om vänte och låsningsfri kommunikation. Martin Mileros och Henrik som utarbetat lösningar till vissa uppgifter. Dessutom vill vi tacka alla studenter som kommit med kommentarer och speciellt Dan Johansson, Mikael Bendtsen, Daniel Zetterman Västerås augusti 2000 Författarna

5

6

7 Innehållsförteckning 1 Introduktion till realtidssystem Introduktion Vad är ett realtidssystem? Ett historiskt perspektiv Programmable Logic Controller PLC Mikroprocessorns intåg Dagens state of the practice Olika typer av tillämpningar Vad är problemet? Några erfarenheter av att utveckla realtidssystem Vidare läsning Referenser Övningar Realtidsoperativsystem Introduktion Grundläggande begrepp Vad skiljer ett realtidsoperativsystem från ett vanligt operativsystem? Vad finns det för olika typer av realtidsoperativsystem? Vilka funktioner kan vi förvänta oss att hitta i ett händelsestyrt realtidsoperativsystem? Vilka tillstånd kan ett task befinna sig i? Svarstid Vad består ett task av strukturellt? Tidshantering Mekanismer för att exekvera ett task Kommunikation och synkronisering mellan tasks Timeouthantering Avbrottshantering Felhantering Vad kan man använda ett bakgrundstask till? Drivrutiner Minneshantering Tidsstyrda realtidsoperativsystem Hur ser då ett schema ut? Strukturen på ett task Kommunikation och synkronisering Några tips Sammanfattning Vidare läsning... 72

8 2.10 Referenser Övningar Schemaläggning Grundläggande begrepp och definitioner Ett ramverk för att jämföra schemaläggningsalgoritmer Rate Monotonic Inledning Teori och bevis Rate Monotonic Exakt analys Earliest Deadline Sammanfattning: Rate Monotonic och Earliest Deadline Utvidgningar av RM Delade resurser mellan task Semaforprotokoll Beräkning av blocking Blocking och schemaläggningsanalys Precedensrelationer Release jitter Realtidsoperativsystemsoverhead Pre-run-time schemaläggning En enkel pre run-time schemaläggare Method Heuristisk funktion Avancerade pre-run-time schemaläggare Ömsesidig uteslutning Kommunikation Jämförelse mellan Rate Monotonic- och pre-run-time-skolan Determinism Jämförelse När ska man då använda respektive princip? Exekveringstidsanalys Behovet av exekveringstidsanalys Exekveringstidsfaktorer Introduktion till exekveringstidsanalys Timing Schema-metoden Historisk översikt över exekveringstidsanalys Aktuella trender State-of-the-Art i exekveringstidsanalys Högnivåanalys: indata Högnivåanalys: källkoden Lågnivåanalys: optimerande kompilatorer Exempel Vidare läsning

9 3.13 Övningar Design Introduktion RTT designmodell RTT designmetod Exempel: Flaklastbil Implementation Diskussion Flaklastbilen i off-lineschemalagt system Flaklastbilen i FPS-schemalagt system Jämförelse av off-line och FPS-system ur designsynvinkel Case study (VOLVO Construction equipment) Sammanfattning Vidare läsning Referenser Övningar Datakommunikation i realtidssystem Introduktion Time Division Multiple Access (TDMA) Carrier Sense Multiple Access with Collision Resolution (CSMA/CR) Jämförelse mellan CSMA/CR och TDMA Vidare läsning Referenser Distribuerade realtidssystem Introduktion Systemlösningar för distribuerade system Sammanfattning Vidare läsning Referenser CAN och distribuerade system Controller Area Network (CAN) Distribuerade system och holistisk schemaläggningsanalys Sammanfattning Referenser...229

10 8 Timed Triggered Protocol (TTP) Vidare läsning Referenser A) Klocksynkronisering B) Membership...242

11 Definitioner Definition 1-1: Realtidssystem 15 Definition 1-2: Hårda realtidssystem 17 Definition 1-3: Mjuka realtidssystem 17 Definition 2-1: Task 37 Definition 2-2: Bakgrundstask (Idle task) 37 Definition 2-3: Drivrutin (device driver) 37 Definition 2-4: Pre-emption 37 Definition 2-5: Preemptive schemaläggning 38 Definition 2-6: Ickepreemptive schemaläggning 38 Definition 2-7: Resurs 38 Definition 2-8: Semafor (binär semafor) 38 Definition 2-9: Svarstid 45 Definition 2-10: Avbrottsfördröjning (Interrupt latency) 61 Definition 3-1: Deadline 81 Definition 3-2: Release time 82 Definition 3-3: Precedensrelation 84 Definition 3-4: Periodiskt task 85 Definition 3-5: CPU-utnyttjandegraden U 86 Definition 3-6: Kritisk tidpunkt 91 Definition 3-7: Kritisk tidzon 91 Definition 3-8 Bästa möjliga utnyttjande 94 Definition 3-9: Blocking 105 Definition 3-10: Priority inheritance-protokollet: 105 Definition 3-11: Prioritetstak 107 Definition 3-12: Priority ceiling protokollet: 107 Definition 3-13: Release jitter 113 Definition 3-14: Systemtask 121

12

13 INTRODUKTION 13 1 Introduktion till realtidssystem 1.1 Introduktion Att använda datorer för styrning av processer blir allt vanligare inom områden som tidigare helt har styrts av beprövad konventionell teknik som mekanik och elektroteknik. Det kan vi se i t.ex. bilar där bromsar och motorer styrs av datorer, flygplan, medicinsk utrustning som t.ex. respiratorer, etc. Kraven på det styrande datorsystemet är normalt mycket höga, då det måste var minst lika säkert och tillförlitligt som det system det ersätter. Samtidigt möjliggör datorer att en ny typ av funktionalitet kan implementeras vilket också gör hela systemet mer komplext. Anledningen till att man ersätter mekaniska och rent elektriska system är tvåfaldigt: Reducera produktionskostnaderna. T.ex. i en bil är kabelkostnaden mycket stor. För att minska kabelkostnaden bygger man istället distribuerade datorsystem som med hjälp av ett kommunikationsnätverk sköter kommunikationen mellan t.ex. blinkreglaget och blinkersbelysningarna. Detta kommunikationsnätverk används av många olika funktioner i bilen. Kunna addera fler avancerade funktioner till ett system i t.ex. en bil kan det vara ett system för att häva sladdar automatiskt. Att konstruera detta i ren mekanik är mycket komplicerat eller rent av omöjligt. Ett ytterligare exempel är den rent elektriskt styrningen i en bil (tänk er en joy-stick styrd bil), där den inte finns någon mekanisk koppling mellan ratten och hjulen. En sådan lösning möjliggör bättre styregenskaper samt att rattstången inte är något problem vid en krock. Denna typ av funktionalitet finns redan i moderna flygplan. Som man kan misstänka är det inte trivialt att ersätta mekaniska konstruktioner med datorbaserade system. Anledningen till detta är främst att det är mycket svårt att konstruera och visa att det datorbaserade systemet är minst lika tillförlitligt och säkert som det ersatta mekaniska systemet. Varför är det då så svårt att konstruera ett datorbaserat system? Thane (1996) kom till slutsaten att mjukvara skiljer sig från vanliga mekaniska system på två huvudpunkter: 1. Att en dator med sin programvara är diskontinuerlig. Dvs, ett mycket litet fel i ett delsystem av en dator kan få till följd att hela systemet havererar. 2. Det finns inga fysikaliska begränsningar i mjukvaran, som massa, energi, storlek, antal och komponenter, och saknaden av strukturella och funktionella attribut som styrka, densitet och form, vilket gör det väldigt lätt att konstruera mycket komplexa system samt att man inte kan överdimensionera i vanlig mening (som t.ex. en bro).

14 14 INTRODUKTION Den enda fysikaliska egenskapen vi kan mäta i ett mjukvarubaserat system är tid. Och för den typ av system som vi har exemplifierat ovan är det mycket viktigt att systemet fungerar korrekt såväl i tidsdimensionen som i den funktionella dimensionen, dvs beräkningen ska ge ett korrekt värde vid rätt tidpunkt. Dessa system brukar kallas realtidssystem. 1.2 Vad är ett realtidssystem? Ett realtidssystem är typiskt ett system som växelverkar med en fysikalisk process via givare och ställdon. En givare används för att omvandla fysiskt data som t.ex. spänning, temperatur, flöde och tryck till digitalt data som kan behandlas av datorn. Ett ställdon fungerar tvärtom det omvandlar digital information till fysiska data. Ett datorsystem som reglerar hastigheten på en elektrisk motor ett realtidssystem. För att reglera hastigheten på motorn har man oftast en hastighetsgivare som ger den aktuella hastigheten på motorn, en givare som avläser ett reglage som användaren kan använda för ställa in den önskade hastigheten och ett ställdon som kan påverka hastigheten på motorn. Själva datorsystemet exekverar en regleralgoritm som baserat på givaredata beräknar nya värden som sedan skickas via ställdonet till motorn. E Givarvärden Ny styrvärden till motorn Datorsystem Hastighetsreglage Men vad är då realtiden i detta exempel? Figur 1-1: En skiss på systemet. Låt oss omformulera vårt problem så att det bättre passar datorns perspektiv. När systemet reglerar något så måste det: 1. Observera processen, dvs läsa av givarna. Detta brukar man kalla sampla. 2. Ta ett beslut på vad som ska göras, dvs datorn exekverar regleralgoritmen. Själva exekveringen betecknas av de fyllda rektanglarna i Figur Påverka processen med en utsignal till ett ställdon. Detta brukar kallas aktuering.

15 INTRODUKTION 15 Sampling Aktuering Sampling Aktuering Sampling Aktuering Fördröjning Periodtid Figur 1-2: En enkel modell av reglersystemet Tidskraven kan nu delas upp i två delar 1 : 1. Hur ofta måste omvärlden samplas för att vi ska få en tillräckligt bra bild av omvärlden? Detta har beskrivits som periodtid i Figur Hur snabbt måste vi behandla indata och ge svar till omvärlden? För att kunna ge svar på dessa frågor måste man analysera den process man ska styra mycket noggrant med avseende på förändringar. I vårt exempel så har vi antagligen fått tiderna från en reglertekniker som gjort en analys av processen. Problemet som vi har framför oss är alltså att konstruera ett datorsystem så att de krav som reglerteknikern ställer verkligen uppfylls. Om vi t.ex. konstruerar systemet så att periodtiden varierar allt för mycket kan resultatet av regleringen försämras kraftigt. Från exemplet ovan kan vi dra slutsaten att tidsdimensionen är viktig vid konstruktionen av vårt datorsystem. En definition av ett realtidssystem kan nu formuleras. Definition 1-1: Realtidssystem Ett realtidssystem är ett system som reagerar på yttre händelser och utför funktioner baserade på dessa och ger svar inom en bestämd tid. Korrekt beteende beror inte bara på korrekt resultat utan också på vid vilken tidpunkt resultatet produceras. Om vi begrundar definitionen ovan så säger den ingenting om i vilken tidsskala resultatet ska ges. T.ex. så kan en funktion i ett realtidssystem ha svarsstidskrav på sekundnivå medan en annan funktion kan ha krav på mikrosekundnivå. Dvs, det är den process som ska kontrolleras eller styras som bestämmer tidsskalan. 1 Denna syn är något förenklad. Man kan också ta hänsyn till toleranser på både periodtid och fördröjningar.

16 16 INTRODUKTION Ett vanligt missförstånd är: att realtidssystem är det samma som snabba system. Det är helt missvisande. Målet med snabba system är att typiskt för en given mängd aktiviteter försöka minimera den genomsnittliga svarstiden (beräkningar, simuleringar,... ). Målet med realtidssystem är att varje funktion ska klara sina stipulerade tidskrav. Vilka olika typer av realtidssystem finns det? Figur 1-3 illustrerar en klassificering. Tillräckligt med resurser ABS-system Händelsestyrda system Tidsdrivna system Telefonisystem Resursbegränsade system Figur 1-3: Olika typer av realtidssystem X-axeln visar i vilken grad ett system är tidsstyrt eller händelsestyrt. I ett system som är strikt tidsstyrt hanterar systemet yttre händelser vid fördefinierade tidpunkter. Oftast är dessa system cykliska, d.v.s. sådana system repeterar ett förlopp med en viss periodtid. Däremot i ett strikt händelsestyrt system så är det yttre händelser som avgör när ett program ska exekveras, dvs det är omvärldens beteende som propagerar direkt in i datorn när något händer, ofta genom avbrott 2. Y-axeln visar vilken policy man använder med avseende på resurser. Ett system som har tillräckligt med resurser är ett system där man alltid kan garantera att alla funktioner i systemet får exekvera när dom så begär. I ett resursbegränsat system 2 Ett avbrott genereras av en yttre enhet till processorn. När avbrottet sker så avbryter processorn det den för tillfälligt håller på med och börjar exekvera den avbrottsrutin som är kopplad till det specifika avbrottet. När avbrottsrutinen exekverat klart så fortsätter processorn med det den höll på med.

17 INTRODUKTION 17 kan det finnas tillfällen när systemet ej kan hantera alla funktioner som vill exekvera. Låt oss nu placera in några olika typer av system i vårt diagram. ABS-systemet i en bil är ett system som måste fungera under alla körsituationer. Sådana system är oftast konstruerade som tidsstyrda system så att inte t.ex. så kallade falska avbrott kan få till konsekvens att systemet slutar fungera. Ett falskt avbrott kan bero på en glappkontakt i en givare, vilket kan medföra att givaren genererar ett så stort antal avbrott att systemet uteslutande hanterar dessa och därmed ej hinner med allt det måste utföra. Ett telefonisystem kan definieras som ett händelsestyrt system eftersom det är vi som abonnenter som påför händelser: När någon lyfter på telefonluren och slår ett nummer så tas det om hand av telefonisystemet. Detta är ett resursbegränsat system eftersom några kommer att få en spärrton om alla vill ringa samtidigt. Systemet är designat för att fungera bra i normalfallet. Från diskussionen ovan kan vi se att det verkar finnas åtminstone två typer av realtidssytem: System som ej får ha en försämrad servicenivå och system som kan tolerera en försämrad servicenivå. Den förstnämnda typen av system brukar kallas hårda realtidssystem och den andra brukar kallas mjuka realtidssystem. Definition 1-2: Hårda realtidssystem Ett hårt realtidssystem är ett system där kostnaden för att ej uppfylla de funktionella och temporala kraven är mycket stora. Definition 1-3: Mjuka realtidssystem Är ett system där systemet någon gång ibland kan tolereras att ej uppfylla de funktionella respektive temporala kraven. Det betyder att kraven kan missas ibland (typiskt med en övre gräns definierad över ett tidsintervall) att en service kan ges något för sent ibland (igen inom en övre gräns). 1.3 Ett historiskt perspektiv Genom historien har människan försökt styra olika processer. T.ex. så försökte man i det gamla Kina kontrollera vattennivån på risfälten via dammluckor. Här var det alltså människan som var själva styrsystemet. Ögonen var givare, hjärnan var datorn och musklerna användes för aktuering. På 1700-talet utvecklades mekaniska styrsystem. Ett exempel är styrsystemet för Spinning Jenny, en mekanisk spinnmaskin. Under slutet av 1800-talet när explosionsmotorn uppfanns

18 18 INTRODUKTION så fanns det ett hårt kopplat system för styrning av ventilernas öppningstidpunkter i motorn, d.v.s. vevaxeln var kopplad till kamaxeln via en kamkedja. Kamaxeln hade en sådan form att den öppnade ventilerna i rätt ordning samt vid rätt tidpunkt, och lät dem vara öppna under ett visst tidsintervall. En annan funktion som fanns länge i bilar var centrifugalregulatorn som påverkade tändningstidpunkten så att tändningen höjdes vid högre varvtal och sänktes vid lägre varvtal för att uppnå en bra förbränning. Nästa steg i utvecklingen var relästyrning. Alla som har varit inne i en gammal telefonväxel vet hur det tickade där det var reläer. Det finns fortfarande sådana system i drift i Sverige. Funktionen för ett relästyrt system beskrevs med logikscheman. Ett logikschema är ett schema där man kopplar ihop in och utgångar via logiska element som t.ex. AND och OR grindar, dessa element var implementerade med reläer. Som vi kan se så börjar vi nu närma oss digitaltekniken Programmable Logic Controller PLC När datorerna introducerades var steget från reläer till programmerbara system, så kallade Programmable Logic Controller (PLC), inte långt. I ett PLC-system kan reläerna kopplas med hjälp av en programvara och exekveras på en primitiv dator. Dessa system är uppbyggda som en loop med instruktioner som kan hantera indata, göra logiska beräkningar på dessa och därefter skicka ut utdata. Att notera är att alla instruktioner utförs varje varv. Figur 1-4 ger en schematisk bild av hur en PLC kan fungera. Inläsning av digitala värden n I/O-kopiering X = Y AND Z Skicka ut digitala värden. Figur 1-4: Principen för hur en enkel PLC opererar. PLC-system är fortfarande mycket vanliga ute i industrin! Den största fördelen med att använda PLC system är deras enkelhet, vilket får till följd att systemen blir enkla och lätta att underhålla.

19 INTRODUKTION Mikroprocessorns intåg Nästa steg i utvecklingen var mikroprocessorbaserade regler- och styrsystem De första systemen var typiska enprocessorsystem med ett cykliskt program som fungerade ungefär som en PLC. Skillnaden var att man kunde lägga in mer logik genom att det går att lagra tillstånd på ett enkelt sätt, samt att iteration och selektion enkelt gick att implementera. I/O (input/output) var typiskt pollat (avlästes periodiskt). Ett exempel på ett sådant program kan ses nedan. void main (void){ int state1, state2,, staten; } initializeclock(); while(1){ } readsensors( ); if (CalculateNewSetValues( )) else ActuateProcess( ); Error(); WaitForNextCycle( ); Systemen hade ofta en klocka som initierades vid start av systemet och som nyttjades till att ge systemet en viss periodtid. I början av varje cykel laddades nytt I/O till PLC, därefter gjordes en reglerberäkning och till sist skickade man ut nya styrvärden till processen. Därefter väntade man på nästa cykel genom att aktivt polla klockan. Systemet ovan skulle passa alldeles utmärkt för att styra den elektriska motor vi beskrev tidigare i kapitlet. Sedan utvecklades enprocessorsystem med tillhörande avbrottshantering, d.v.s. en cyklisk loop med omgivande avbrottsrutiner för snabba svarstider. Avbrottsrutinerna gjorde det möjligt att hantera funktioner som var ickeperiodiska och som hade kort svarstid. En ickeperioddisk funktion är en funktion som man inte kan definiera en periodtid för, exempel på en sådan funktion är en pulsräknare som räknar antalet bilar som passerar en viss gata. Dessa system fungerar mycket bra om inte tillämpningen som ska styras är för komplex. De är för övrigt fortfarande mycket vanliga när man bygger system som har lite minne och enkel funktionalitet. Speciellt kan man se sådana implementationer i små noder i bilstyrsystem, t.ex. i en nod som hanterar en elektrisk fönsterhiss.

20 20 INTRODUKTION Dagens state of the practice Att beskriva nuläget är mycket svårt eftersom det finns så många olika typer av tillämpningar som styrs och regleras. I huvudsak väljer man i dag att använda realtidsoperativsystem för en nod 3. Man väljer dessutom ofta att koppla ihop noderna med hjälp av ett kommunikationsnätverk för att kunna hantera den totala styrningen om tillämpningens komplexitet kräver det. PLC-system om tillämpningen ej har så hög komplexitet. en kombination av de två ovanstående om så krävs. en loop plus avbrottsrutiner i enklare system där man ej har så mycket minne. Sådana system är ofta baserade på enchipsdatorer. Det är en dator som har en CPU (Central Processing Unit), minne och I/O-enheter integrerade på ett chip. Läs- och skrivminne (RAM) brukar ha en storlek av ca 1 kbyte medan enbart läsminne (EPROM) har en storlek av några 10-tal kilobyte. 1.4 Olika typer av tillämpningar Som vi redan har antytt så finns det mängd olika tillämpningar som kan karakteriseras som realtidssystem. En klassificering som ofta görs är att dela in systemen i inbyggda och icke inbyggda. Ett inbyggt system är ett specialiserat datorsystem som är en del i ett större system eller maskin. Typiskt är ett inbyggt system konstruerat på ett kort, med programvaran i ROM, EPROM eller FLASH. Nästan alla tillämpningar som har ett digitalt gränssnitt, t.ex. klockor, mikrovågsugnar, diskmaskiner, videoapparater och motorstyrsystem, nyttjar ett inbyggt system. Vissa inbyggda system inkluderar ett realtidsoperativsystem, men många är så specialiserade att hela funktionen får plats i ett program. Ett icke inbyggt system är ett system som ofta är baserat på allmänt tillgängliga datorer men inte är inbyggt. Exempel på sådana system är operatörsstationer, övervakningsterminaler, etc. Låt oss lista några olika typer av tillämpningar som karakteriseras som inbyggda system: Styrsystemet till en soldriven gräsklippare. I bilar finns många inbyggda datorsystem; ABS-systemet, tändsystemet, antisladdsystem, växellådsstyrning, EBS etc. Mobiltelefoner. 3 En nod är enhet som är kopplad till ett nätverk. En nod är typiskt en dator.

21 INTRODUKTION 21 Medicinsk utrustning: Respirator, anestesimaskin etc. Hemelektronik: TV, video, tvättmaskiner, etc. Robotar. Inomhusklimatregleringssystem.... Ej inbyggda system är sådana som med viss möda går att programmera om på plats. Exempel är: Telefonisystem Industriella processtyrningssystem: Papper och pappersmassa, stålverk, kemisk industri etc. Elnätsreglering och övervakning. Vanliga PC-datorer Banksystem Internetbaserade system. Observera att många av dessa system innehåller delar som är inbyggda. För att tydliggöra skillnaden mellan inbyggda system och icke inbyggda system, samt för att ge någon form av känsla för olika tillämpningar, så tittar vi på strukturen för dels datorsystemet i en bil (i detta fall Volvo S80) och dels för ett typiskt industriellt styrsystem. Vidare så exemplifierar vi nyttan av realtidskunskap inom konsumentprodukter som Musikteknologi, både mjukvara och hårdvara Dataspel, nätverksspel i 3D miljö, även kallad virtuell verklighet. Video, mjukvara (QuickTime) och hårdvara (DVD) Multimedia Användargränssnitt, framförallt, multimodala och perceptionella men även WIMP/GUI. Bilstyrsystem Styrsystemet till Volvo S80 (se figuren nedan) är uppbyggt av två sammanbundna CAN (Controller Area Network) kommunikationsnätverk. Till nätverket är ett antal noder anslutna.

22 22 INTRODUKTION Figur 1-5: Schematisk figur över kommunikationsnätverk och datorer i Volvo S80. Dessa noder har placerats ut på strategiska ställen, d.v.s. nära givare, ställdon och manövreringskontakter som kräver funktioner implementerade i mjukvara. En nod är typiskt en enchipsdator, dvs en mikroprocessor med tillhörande funktioner för kommunikation, analog till digital omvandling (A/D-omvandlare), digital till analog omvandling (D/A-omvandlare), etc. Alla givare, ställdon och kontakter kopplas till den närmaste noden oberoende av om programvaran för den funktionaliteten finns i just den noden. Om den specifika funktionen ligger på någon annan nod, eller några andra noder, så skickas informationen t.ex. en givares värde över kommunikationsnätverket. Eftersom kommunikationsnätverket är av broadcast-typ 4 så är all information som skickas på kommunikationsnätverket tillgänglig för alla noder i systemet. Industriella styrsystem Industriella styrsystem innehåller en rik flora av delsystem. PLC-programmering används för små enheter nära processen. PLC-enheterna är sedan ofta kopplade till större enheter via en fältbuss (en fältbuss är en buss som stöder enkel anslutning av givare och ställdon). Dessa större enheter brukar sedan vara kopplade till ett fabriksnätverk till vilket operatörsstationer är anslutna. Fabriksnätverken är ofta baserade på Ethernet eller någon token-passing nätverk. 4 Broadcast är egenskap i ett nätverk som gör att alla kan höra vad någon sänder.

23 INTRODUKTION 23 Processstation Operatörsstation Fabriksnätverk Fältbuss Processstation Processstation PLC PLC PLC Figur 1-6: En principskiss på ett litet industriellt styrsystem. I industrin idag är funktionerna oftast tilldelade till specifika noder, dvs det är fortfarande ganska ovanligt att splittra en funktion till flera olika noder. Trenden i dag i industriella styrsystem är att allt fler system integreras med varandra allt ifrån lågnivå styrning till affärssystem. Detta gör att det ställs högre krav på att styrsystem ska vara öppna så att det går att integrera dessa i ett större sammanhang. Konsumentprodukter Realtidsbegreppet med tillämpningsområden expanderar kraftigt inom konsumtionsprodukter och system. Några områden som numer i stor utsträckning omfattas av realtidsbegreppet är: Musikteknologi, både mjukvara och hårdvara Dataspel, nätverksspel i 3D miljö, även kallad virtuell verklighet. Video, mjukvara (QuickTime) och hårdvara (DVD) Multimedia Användargränssnitt, framförallt, multimodala och perceptionella men även WIMP/GUI.

24 24 INTRODUKTION Musikteknologi Såväl som en stor studio (Polar eller Abbey road) som hemma i vardagsrummet så kan vi hitta system med hårda realtidskrav. Idag har persondatorerna blivit kraftfulla nog att utgöra en grunden för en fullvärdig studio helt i mjukvara. Utvecklingen inom det här området går ruskigt fort, idag kan för samma pris som en åttakanals digitalbandspelare för tio år sedan få 64 kanaler hårddiskinspelning, alla möjliga varianter av effekter, mjukvarusynthar och mjukvarusamplers. Antalet olika komponenterna som kan köras samtidigt begränsas bara av CPUkraften hos datorn. Realtidskravet i tempo 120 bpm är 0,5 millisekunder! D.v.s. en hihat måste börja spela inom 0,5 ms för att inte svänget ska uppfattas som annorlunda eller fel. Det kanske ska tilläggas att det hårda kravet inte gäller för alla ljud, för de ljud som har långsam attack (t.ex stråkar och körer) så har millisekunderna inte lika stor betydelse. De tekniker som genererar ljud i ett mjukvarubaserat system använder i stor utsträckning physicalmoduling-algoritmer för att skapa signaler, anledningen är att elektronik låter bättre än matematiska modeller. Systemen bygger alltså vidare på en elektronisk tradition, där komponenterna har blivit mjukvara istället för kiselbrickor, kompilatorn har ersatt lödkolven och kretskortet. Dataspel De spelutvecklare som bygger nätverkspel för 3D-miljöer, använder inte i så stor utsträckning realtid som de borde göra. Man vet att kravet är 30 bildrutor i sekunden, d.v.s varje bild måste genereras inom drygt 30 ms. Många spelutvecklare anpassar sig till den förutsättningen utan att bry sig om realtidstekniker. Den här strategin har fungerat bra så länge man suttit ensam vid en dator eller spelat mot kompisar i ett lan. Nu blir näverksspel över internet alltmer populära, med fler och fller deltagare. Internets låga bandbredd har gjort att man försöker utveckla tekniker för att få fram de små paketen med information som dessa spel använder sig av med ganska hårda realtidskrav, så att fler ska kunna delta i ett och samma spel. Med realtid finns möjligheten att variera innehållet i varje ruta så att man ritar mer detaljerad bilder när det inte finns så mycket information i modellen, men minskar graden av detaljer när det blir mycket information (t.ex botar, flygande och exploderande raketer samt motståndare) för att klara av realtidskravet. Utvecklingen av AI i botar, d.v.s de olika datorstyrda motståndarna i spelen utgör ett intressant område för realtidsagenter och kommunikation mellan dessa, särskilt när både människor och botar ingår i samma spel. För tiden som blir över när de 30 bildrutorna per sekund räknats ut, ska spelet alltså kunna kommunicera över internet och beräkna vad botarna tänker göra härnäst.

25 INTRODUKTION 25 Video Normalt sett har man inte betraktat video som en realtidstillämpning, men i dag är mjukvarurenderad video och hårdvaruvideospelare DVD omfattade av realtid. Ett system som QuicklTime omfattar flera olika typer av media. Dels video (naturligtvis), men även animerad vektorgrafik, VR-video, 3D-grafik, musik och ljud. Man kan även synkronisera med midihårdvara eller mjukvara, d.v.s musiktillämpningar. Tack vara realtid så kan de olika medierna för ljud och bild synkroniseras så att man inte uppfattar det som visas som en dåligt dubbad Italiensk film. Multimedia Det besvärliga begreppet multimedia omfattas även av realtid, men det beror också på vad man menar med multimedia. Inte helt sällan har det uppfattats som ett skal för att visa och spela upp text, bild, grafik, ljud och video. I vidare mening kan man säga att multimedia omfattar alla de ovan nämnda områden, vilket egentligen bara är en tolkning av vad multimedia är. För en organisation som MRTC skulle multimedia vara intressant som ett sätt att marknadsföra realtidsbegreppen inom andra områden än de traditionellt industriella, eftersom så mycket ryms inom multimedia. Användargränssnitt Christine Faulkner säger i boken Usability Eginering att området Människa/Datorinteraktion är ett spädbarn med tonårsföräldrarna Kognition och Datalogi, det är förmodligen sant. Fortfarande kämpar man med grundläggande begrepp inom MDI, om hur knappar ska se ut så att man ska förstå att de är knappar, om man ska använda fotorealistiska ikoner eller om de ska vara stiliserade symboler. Snart kommer även realtidsbegreppet att smyga sig in även här, det första exemplet på det är Webläsaren. Människan är för otålig för att sitta och vänta på en dator, därför var man tvungen att skapa ett gränssnitt till webläsaren som gjorde det möjlig att ladda sidor ett fönster samtidigt som man kunde läsa i ett annat. Ett annat tillämpningsområde för realtid i användargränssnitt skulle vara olika foto-, film- och animationsprogram. Bilder för trycksaker och bioduk är ju normalt enormt mycket större än den kvalitet som visat på en skärm, 50 megabyte för en trycksak det ska jämföras med de 3 mb som går åt för en 1024x768 punkters bildskärm med 32 bitars färgdjup. Om man gjorde gränsnitten för dessa program så att de framställer en förhandsversion av resultetet från användarens aktioner så att denne uppfattar systemet som omedelbart. Aktionerna på den fullupplösta bilen utförs i bakgrunden under tiden som programmet väntar på användarens nästa aktion.

26 26 INTRODUKTION Människan som realtidskrav Vår perceptionella och kognitiva förmåga och begränsning ger ramar för hur snabbt ett system måste reagera och ge användare feedback på dennes aktioner. T.ex så säger man att den visuella reaktionstiden är 0,5 sekunder, men kravet är egentligen hårdare en så, runt 200 ms om man vill få något att upplevas som omedelbart. Om man väljer att ge feedback i form av animationer så får dessa inte vara längre än 1/4 sekund, annars kommer man att börja irritera sig på långa och sega animationer. Det kan var värt att påpekat att människan reagerar snabbare om hon är förvarnad. Reaktionsförmågan för ljud är blott 6 ms, man har med andra ord inte så gott om tid på sig om man vill ge audiell feedback till en aktion. Sammanfattning I takt med att vi omger oss med mer och mer elektronisk och avancerad utrustning, med allt mer avancerade inbyggda system, pda, waptelefoner, smarta hus, navigations system för bilar, fritidsbåten och för fjällvandring. Även om samtida och framtida tillämpningsområden kommer att vara beroende av realtid i varierande utsträckning, så kommer realtid alltid att vara en faktor. 1.5 Vad är problemet? Som vi sett hittills så verkar det gå att utveckla mycket avancerade realtidssystem, Men finns det något problem när man konstruerar realtidssystem? Låt oss först göra en analogi med hur man byggde kyrkor för flera tusen år sedan. När en kyrka, eller vilken större byggnad som helst, byggdes så hade man en föreställning av hur byggnaden skulle se ut. Bygget startade, man byggde och byggde men helt plötsligt kanske kyrkan rasade eller det gick inte att bygga vidare. Anledningen var ofta feldimensionering eller rent av en felaktig konstruktion. Åtgärden var givetvis att försöka på nytt och förr eller senare lyckades man. Vi skulle vilja påstå att det i många fall är precis så här de flesta datorsystem konstrueras idag. I byggbranschen misslyckas man fortfarande ibland, men oftast går det bra. Man kan fråga sig varför? Anledningarna är givetvis många, men först och främst beror det på att man har beprövade modeller som kan användas för att räkna på hållfasthet etc. Dessutom finns det givetvis flera tusen års erfarenhet av byggande som kan nyttjas. När vi däremot konstruerar datorsystem, har vi bristfälliga modeller och metoder. Huvudanledningen till detta är givetvis att detta område är ungt, men också på att vi inte har några fysikaliska lagar som begränsar oss. (Avsaknad av begränsning är oftast något positivt. I datorvärlden leder dock denna frihet ofta till en okontrollerbar komplexitet.) Detta kompendium handlar om realtidssystem, specifikt hur vi ska kunna garantera ett systems tidsbeteende. Vi kommer att presentera olika metoder för hur man kan förutsäga och garantera ett systems tidsbeteende. Dessa metoder kommer förhoppningsvis leda till att vi i

27 INTRODUKTION 27 framtiden bygger systemen effektivare och att vi ej behöver prova och finjustera så mycket i slutändan. Låt oss avsluta detta kapitel med några erfarenheter som vi samlat genom åren, tillsammans med en god historia om Pathfinder som användes för att utforska planeten Mars: Några erfarenheter av att utveckla realtidssystem De system som vi har erfarenhet av är system som har ett realtidsoperativsystem som plattform för utveckling av tillämpningar. Ett realtidsoperativsystem fördelar de olika resurserna i systemet som processor och I/O till tasken genom någon algoritm. De flesta realtidsoperativsystem som används idag baseras på följande resursfördelningsalgoritm: Varje task 5 tilldelas fixa prioriteter. En resursfördelare låter det task som har högst prioritet av de som vill exekvera exekvera. Resursfördelaren exekverar vid varje klocktick och då ett task lämnar över kontrollen (t.ex. via ett anrop till delay,...) Kommunikation mellan olika task är köbaserad. Varje meddelande läggs i en kö och konsumeras efterhand av adressaten. Erfarenheten visar att ett flertal problem uppstår om man ej använder tillgänglig teoribildning. Problem: A. Hur definierar man prioriteten på ett task? Eftersom det alltid är det task som har högst prioritet (bland de som vill exekvera) som får exekvera så vill man ge de task som är viktiga en hög prioritet. Å andra sidan vill man också att task med korta svarstidskrav ska ha en hög prioritet för att uppfylla kraven, dvs prioriteten bör vara en funktion av viktighet och svarstidskrav. Detta är ofta början till en diskussion om vilka prioriteter ett task ska ha. Eftersom man oftast inte använder någon form av analys innan systemet körs så slutar detta ofta i en desperat justering av prioriteter innan systemet går att köra. Vi kommer i kapitel tre att studera olika analysmetoder som kan användas för att avgöra om de olika tasken i systemet klarar sina tidskrav. Vi kommer även 5 Task är enkelt definierat som en uppgift i systemet som har en prioritet relativt andra task i systemet. D.v.s. om det är resursbrist i systemet får det task med högst prioritet exekvera bland de task som vill exekvera.

28 28 INTRODUKTION diskutera hur man sätter prioriteten på ett bra sätt, d.v.s. efter vilka kriterier prioriteten för de task som finns i systemet bör sättas. B. Överlast Eftersom inga analysmetoder användes brukar/brukade system ofta komma i så kallade överlastsituationer, d.v.s. hamna i situationer där det finns fler task i system än systemet klarar av att exekvera (vilket kan jämföras med de kyrkor som rasade). Överlast brukar visa sig på olika sätt, t.ex. genom att de brevlådor som används för kommunikation mellan task blir fulla och att lågprioriterade task aldrig får exekvera (svält). Ofta kan man ironiskt säga att överlast visar sig när systemet behöver fungera som bäst. C. Baklås Eftersom många system använder databaser där poster låses eller har en mängd delade resurser som skyddas av semaforer, så finns det risk att baklås uppstår t.ex. p.g.a. att semaforer 6 låses i fel ordning. Antag att vi har två task, T1 och T2, som delar på två resurser. Dessa två resurser skyddas av var sin semafor, S1 och S2. Antag vidare att T1 låser semaforen S1 och därefter blir avbrutet av task T2 som låser S2 och därefter försöker låsa S1. Men S1 är ju redan låst av T1! Det som då händer är att T2 blir avbruten och T1 återupptar sin exekvering och försöker låsa S2 men den är ju låst av T2 och således blir även T1 blockerad. T1 S1 T2 S2 Figur 1-7: En illustration av baklåssituationen. Heldragen linje indikerar att semaforen är tagen av det task som linjen utgår ifrån. Streckad linje indikerar att ett task väntar på en semafor. En så kallad baklåssituation har uppstått. Det pragmatiska sättet att lösa ett sådant problem är att alla task som använder flera semaforer samtidigt måste låsa semaforerna i samma ordning. Detta leder till att baklås ej kan uppstå. Men även om vi använder en sådan algoritm så kan det inträffa att högprioriterade task kan bli blockerade för en obestämd tid, vilket i vissa fall inte är så bra. Vi kommer att diskutera hur man kan analysera sådana här situationer i kapitel 3. 6 En semafor används för att skydda en delad resurs. Jämför upptaget och ledigt på en toalett.

29 INTRODUKTION 29 D Inkonsistenta data Detta problem kan enkelt förklaras med ett exempel. Antag att två personer ska observera var sitt fordon på en väg och därefter sammanställa positioner för dessa fordon vid en viss tidpunkt. Angreppssättet är att observera fordonen vid samma tidpunkt. Detta kräver att personerna kommer överrens om tidpunkt för observationen och att de har klockor som är bra synkroniserade. Om de ej är synkroniserade tillräckligt bra så kan man få en mycket skev bild av hur det såg ut vid den utvalda tidpunkten (såvida inte fordonen stod stilla!). Om vi nu istället går över till datorvärlden så kan samma problem uppstå när vi ska observera ett specifikt fenomen. Anledningen till att vi kan få inkonsistenta data kan bero på att observationen sker på olika noder som har icke synkroniserade klockor eller, om man gör observationen på en nod, så kan det bero på att ett task har en mycket längre svarstid än det andra. Också en kombination av bägge orsakerna kan inträffa. Inkonsistenta data kan således leda till felaktiga beslut om vad som ska göras. E Utvecklingsmetoder för realtidssystem Det finns få metoder för utveckling av realtidssystem som har ett bra stöd för hantering av tidskrav genom hela utvecklings och underhållsfasen. De flesta metoder som säger sig stödja realtid stödjer oftast endast beskrivning av parallella task vilket i och för sig är bra. En del metoder lägger realtidsstödet i slutfasen av designen. Men hur tidskraven ska hanteras ifrån krav till implementation stöder ingen kommersiellt tillgänglig metod så vitt vi vet. Vi vet inte heller någon metod som automatiskt översätter en design med tidskrav till en implementation. Vi kommer i kapitel 4 visa en metod för hur tidskraven kan integreras i utvecklingsmetoden samt hur den slutgiltiga designen kan översättas till en implementation. Denna metod är utvecklad i samarbete med Volvo Construction Equipment för utveckling av inbyggda system för fordon. Låt oss nu avsluta kapitlet med Pathfinder-problematiken: Pathfinder Pathfinder är en robot som konstruerats för att på Mars samla data om planeten och skicka dessa till jorden. De data som skickades ner var både meteorologiska data och bilder. Den autonoma roboten skickades ned på Mars från ett rymdskepp. Landningen utfördes med hjälp av airbags. Efter några dagar på Mars började datorsystemet på Pathfinder att återstarta sig självt, vilket uppstod när den började samla meteorologiska data. Pathfinder använde ett realtidsoperativystem med namnet WxWorks som är ett prioritetsbaserat realtidsoperativsystem. Tasken som exekverade i datorsystemet hade således prioriteter som hade definierats i enlighet med någon algoritm. Pathfinder innehåller ett kommunikationsnätverk som används för att skicka information mellan olika komponenter. Accessen till kommunikationsnätverket

30 30 INTRODUKTION skyddades med en semafor. Ett högprioriterat näthanteringstask exekverade med en kort periodtid för att flytta data in och ut från systemet. Det fanns dessutom ett lågprioriterat task som hanterade insamlingen av meteorologiska data och som också använde kommunikationsnätverket till att skicka data. När detta task skickade data låste det först semaforen som skyddade bussen och skrev därefter data till bussen och till sist låst den upp semaforen. Om det högprioriterade näthanteringstasket blev aktiverat och försökte låsa semaforen när den redan var upptagen så blev näthanteringstasket blockerat. Dessutom fanns det ett task med mellanprioritet. Största delen av tiden fungerade denna kombination bra. Dessvärre hände det ibland att det mellanprioriterade tasket kom in precis efter det att det högprioriterade tasket hade blivit blockerat. Detta mellanprioriterade task hade en lång exekveringstid och det ledde således till att det lågprioriterade tasket fick vänta ganska länge på att exekvera vilket naturligtvis även det högprioriterade tasket som väntade på semaforen fick göra.. Efter att en viss tid hade gått så utlöstes en feldetektering om att det. högprioriterade tasket ej hade fått exekvera. Effekten av detta larm var att systemet startades om ty avsikten med feldetektering var att detektera låsningar i systemet. Att det högprioriterade tasket och det mellanprioriterade tasket bytte prioritet brukar kallas prioritetsinversion. Felet fixades, otroligt nog, genom att kod från jorden skickades upp till Pathfinder. Denna kod exekverade och ändrade en bit i systemet med resultat att semaforlåsningsprotokollet ändrades och därefter fungerade systemet. Hur denna typ av blockeringssituationer kan undvikas kommer vi att ta upp i schemaläggningsavsnittet i kapitel 3. Slutsatsen från ingenjörerna var att det finns inget bättre än en väl fungerande teori Vidare läsning För en introduktion till realtidssystem kan man läsa många olika böcker och artiklar de vi rekommenderar är Software Design for Real-Time Systems av Cooling [Cooling91]. Real-Time Systems and Their Programming languages av Burn och Wellings [Bur96], Mer akademisk litteratur som introducerar till realtidssystem är 7 som de ej hade tagit del av!

31 INTRODUKTION 31 Real-time Systems Specification, Verification and Anlysis av Joseph. [Jos96] Tutorial Hard Real-Time Systems av John A. Stancovic och Krithi Ramamritham där det finns två artiklar som introducerar realtidssystem, vilka är Real-Time Computing Systems: The Next Generation och What is a real-time system? [STA87] En introduktion till säkerhet och tillförlitlighet kan ni finna i Henrik Thanes artikel Safe and Reliable Computer Control Systems - Concepts and Methods. [THA97]. 1.7 Referenser [Bur96] A. Burns and A. Wellings. Real-Time Systems and Their Programming languages, Second Edition, Addison Wesley [Cooling91] J.E. Cooling, Software Design for Real-Time Systems. International Thomson Computer Press, [Jos96] [Sta87] M. Joseph. Real-time Systems Specification, Verification and Anlysis. Prentice Hall John A. Stancovic And Krithi Ramamritham, Tutorial Hard Real-Time Systems, 1987 [Thane97] Henrik Thane. Safe and Reliable Computer Control Systems - Concepts and Methods. Research Report TRITA-MMK 1996:13, ISSN , ISRN KTH/MMK/R 96/13-SE. Department of Machine Design, The Royal Institute of Technology, S Stockholm. Sweden, 1996.

32 32 INTRODUKTION 1.8 Övningar 1. a) Vad är det för fel i resonemanget: Realtidssystem är detsamma som snabba system? b) Vad är skillnaden mellan hårda och mjuka realtidssystem? c) Vad är problemet med moderna processorer med avseende på realtidssystem? 2 a) Skriv en kort definition av vad ett realtidssystem är. b) Vad är skillnaden mellan tids- och händelsestyrda realtidssystem? c) Ge tre olika tillämpningsområden för realtidssystem, samt motivera varför dessa kategoriseras som realtidssystem?