Inbyggda realtidsystem
Ett inbyggt realtidsystem är ett datorbaserat system som styr en fysisk omgivning, såsom styrsystem för flygplan, bilar, robotar, medicinsk utrustning, osv. I MultEx sammanhang kan man se styrsystem, något förenklat, som en synonym för inbyggda realtidssystem. Skillnaden mellan ett styrsystem och den dator du har hemma eller på jobbet är att i styrsystem måste datorn kunna anpassa sig till sin omgivning för att kunna styra omgivningen på ett bra sätt. För datorn du har på skrivbordet är förhållandet precis tvärtom, du får snällt anpassa dig till datorns arbetstakt. I de flesta fall så går detta bra eftersom datorn arbetar så mycket snabbare än vad du gör, men ibland, speciellt när datorn har många olika uppgifter att utföra, har du säkert blivit irriterad varför det går så segt. Du har säkert också varit med om att datorn "hängt sig" sig, eller fått en s.k. "blåskärm", och du blivit tvungen att starta om datorn.
Tänk dig nu samma beteende för ett styrsystem för ett flygplan som går in för landning, eller en airbag i en bil när du precis är på väg att krocka. Du vill inte att styrsystemet (datorn) går segt eller i värsta hänger sig. Sålunda, för ett inbyggt realtidssystem, är det av yttersta vikt att på förhand kunna garantera att datorsystemet beter sig på förutsägbart sätt. Förutsägbarheten består inte bara av att datorns beräkningar utförs på ett korrekt sätt, utan också i lika stor grad, att de utförs i rätt tid. Som ett tankeexperiment tänk situationen en krockkude, i en bil, den utlöses för sent, ... för tidigt? Nej, det vi vill är att på förhand kunna garantera att krockkudden utlöses precis vid rätt ögonblick, varken för tidigt (snabbt styrsystem) eller för sent (långsamt styrsystem).
Exekveringsmodell
En exekveringsmodell är en modell över det sätt en dator arbetar för att utföra de aktiviteter och tjänster den blivit ålagd att göra. Enkelt uttryckt: hur omgivningen kan aktivera tjänster/aktiviteter, och hur datorn sedan utför dessa tjänster/aktiviteter. Två vanliga exekveringsmodeller är den tidstyrda (TT, time triggered) och den händelsestyrda (ET, event triggered) exekveringsmodellen. Den tidstyrda modellen kan liknas vid att du med jämna mellanrum (periodiskt) tittar i skafferiet för att se om du behöver handla mat för nästkommande vecka. Dvs, det är du som periodiskt tittar i skafferiet (posten) om en aktivitet (att gå och handla) behöver göras. Ett annat exempel är att se om du fått någon post i brevlådan. Den händelsestyrda (ET) modellen kan t.ex. liknas vid att telefonen eller dörrklockan ringer och du utför då aktiviteten att svara/öppna dörren.
I styrsystem i en bil så finns det massor av aktiviteter som måste utföras: ABS bromsar, motorstyrning, fönsterhissar, krockkudde, osv. Till vissa av dessa aktiviteter passar en TT-modell bättre medan en ET-modell passar andra bättre. Vanligtvis måste man välja antingen TT eller ET för dessa system, vilket innebär ett mer komplicerat och tillkrånglat system som utnyttjar onödigt mycket resurser. Tänk dig till exempel att du bara har tillgång till ett tidstriggat system. Då måste du utföra aktiviteterna att svara i telefon och att se om någon står bakom dörren med viss periodicitet. Du kommer att slösa mycket tid till att bara kontrollera om något har hänt och du måste göra dessa saker rätt ofta för att den som ringer eller besökaren inte ska tröttna på att vänta. Precis som i vanliga livet så passar vissa aktiviteter för TT- och andra för ET-modellen.
MultEx projektet
I MultEx tittar vi på hur man kan stödja flera olika exekveringsmodeller, t ex. både tidstyrd och händelsestyrd, i en dator för inbyggda realtidssystem (styrsystem). I och med detta så kan vi få mer effektiv utveckling av dessa system genom:
- Minskad utvecklingstid och -kostnad. En mer naturlig exekveringsmodell kan användas för olika aktiviteter istället för att "tvinga" alla aktiviteter att anpassa till en enda övergripande exekveringsmodell.
- Högre mjukvarukvalité. I och med att en mer naturligt anpassad exekveringsmodell antas för olika aktiviteter så ökas även mjukvarukvalién genom att man slipper att införa onödig och tillkrånglad komplexitet.
- Hårdvaruutnyttjande. Man slipper tillbringa onödig tid och onödiga resurser för att kontrollera om viktiga aktiviteter behöver utföras. Exempelvis slipper man hela tiden, med jämna och korta mellanrum, kontrollera om krockkudden behöver utlösas.
Detta gör vi med avseende på komponentbaserad utveckling (CBSE) som bygger på att man bygger system av färdiga och återanvändbara komponenter. CBSE tillhandahåller en högre abstraktionsnivå som gör att man kan lyfta sig ifrån detaljnivån och koncentrera sig på att lösa uppgiften istället för att fastna i detaljer. Komponentänkandet gör också att man kan utveckla flera saker parallellt för att i slutändan "koppla ihop" dessa komponenter till ett helt system.