Vid planering av uppgifter i realtidssystem, är det viktigt att förstå både de teoretiska och praktiska begränsningarna som uppstår när man arbetar med flera processorer eller kärnor. När ett system har flera processorer eller kärnor ökar flexibiliteten i uppgiftsschemaläggningen avsevärt. I en ideal värld skulle det vara möjligt att schemalägga uppgifter för att köra parallellt utan att ta hänsyn till resursbegränsningar. I verkligheten, särskilt när det handlar om inbyggda system, finns det dock alltid praktiska utmaningar att beakta.

Först och främst måste man förstå att schemaläggning av uppgifter, oavsett om man använder ASAP (As Soon As Possible) eller ALAP (As Late As Possible) algoritmer, förutsätter att ett system har tillräckligt med resurser för att köra alla uppgifter parallellt vid sina respektive starttider. ASAP-algoritmen arbetar med att schemalägga uppgifter så tidigt som möjligt, utan att ta hänsyn till att det i verkligheten ofta är begränsade resurser som styr hur uppgifter kan köras samtidigt. ALAP-algoritmen, å andra sidan, schemalägger uppgifter så sent som möjligt, med samma antagande om obegränsade resurser. Men i ett praktiskt system måste dessa algoritmer justeras för att ta hänsyn till det faktum att det inte går att köra hur många uppgifter som helst på en gång. Detta kan lösas genom att anpassa algoritmerna till de resurser som finns tillgängliga, till exempel genom att köra uppgifterna i en godtycklig sekvens om systemet har en enda processor. När det handlar om ett flerkärnigt system, kan en mer generell lösning behövas.

En sådan lösning innebär att ta hänsyn till antalet tillgängliga processorer när man planerar uppgifterna. För ett flerkärnigt system, där varje processor eller kärna kan hantera sina egna uppgifter utan att behöva byta kontext eller hantera avbrott, minskar kostnaden för preemption och kontextbyten betydligt. Om ett system har två processorkärnor, kan en statisk schemaläggning undvika dessa kostnader helt, vilket gör att uppgifterna körs effektivare. I de flesta fall, särskilt i dynamiska system, innebär schemaläggningen dock att man måste ta hänsyn till så kallad "mobilitet". Mobilitet innebär att man jämför skillnaden mellan starttiderna i ASAP och ALAP, vilket ger en indikation på hur flexibel uppgiftens schemaläggning är.

För att göra denna schemaläggning effektivare används algoritmer som List Scheduling. Denna algoritm tar hänsyn till antalet processorer och vilken uppgift som är redo att köras, baserat på vilka uppgifter som har slutförts. Genom att hålla reda på antalet processorer som för närvarande är i användning och samtidigt beakta prioriteten för uppgifterna, kan algoritmen effektivt tilldela uppgifter till tillgängliga processorer. En viktig aspekt här är att prioritera uppgifter som har längre exekveringstider, eftersom de tenderar att vara de mest resurskrävande.

För att bättre förstå och hantera planering för ett flerkärnigt system behöver man också uppskatta exekveringstiderna för varje uppgift. Ett vanligt begrepp som används i sådana sammanhang är WCET (Worst-Case Execution Time), det vill säga den längsta möjliga tiden en uppgift kan ta att köra. WCET uppskattningar är ofta osäkra och bygger på simulerade förhållanden som inte alltid reflekterar verkligheten. Till exempel, om en uppgift körs på en cykelräknareplattform, kan inte alla faktorer som påverkar exekveringstiden, såsom avbrott eller delade resurser, simuleras korrekt. Även om uppskattningar av WCET vanligtvis är säkra, kan de vara för stora eller för små beroende på systemets komplexitet.

Det är också viktigt att beakta hur delade resurser, såsom cacheminne eller externa enheter, kan påverka exekveringstiden för uppgifter. För att dessa uppskattningar ska vara användbara, måste de vara både "säkra" och "tighta". Det innebär att de inte får vara för låga, vilket riskerar att systemet blir överbelastat, men inte heller för höga, så att resurser används ineffektivt.

Att hantera dessa problem kräver att man använder sofistikerade metoder för att uppskatta exekveringstider, ta hänsyn till hur uppgifterna interagerar med varandra och förstå de verkliga resursbegränsningarna i systemet. I praktiken innebär detta att både hårdvara och mjukvara måste anpassas för att optimera resursutnyttjandet utan att överskrida tidsgränserna som kan uppstå i realtidssystem.

Hur fungerar ändliga tillståndsmaskiner och varför är de viktiga för systemdesign?

De flesta inbäddade system uppvisar ett tillståndsbaserat beteende, vilket kan ses tydligt genom sekvensdiagrammen som beskrivs i tidigare kapitel. Ett tillstånd innebär en situation där systemet väntar på något att hända – antingen ett inmatat signal eller en förutbestämd tidsperiod. Till exempel är en bankomat i sitt "idle"-tillstånd under tiden den väntar på att en användare ska starta en transaktion. När användaren trycker på startknappen går bankomaten in i ett nytt tillstånd – där den väntar på att användaren ska skriva in sitt användar-ID eller svepa sitt kreditkort. När detta sker, övergår systemet till ett tredje tillstånd – där den väntar på att användaren ska mata in sitt lösenord. I varje tillstånd orsakar vissa inmatningar att systemet svarar på något sätt, och ofta leder det till att systemet går över till ett annat tillstånd.

En intressant aspekt av tillståndsövergångarna i sådana system är deras förmåga att hantera oväntade eller felaktiga inmatningar. Om användaren i "idle"-tillståndet trycker på en annan knapp än startikonen, kan systemet helt enkelt ignorera inmatningen och förbli i sitt nuvarande tillstånd. Detta tillståndsorienterade beteende är centralt för designen av inbäddade system och skiljer sig från traditionella datorprogram, där programmet ofta inte stoppar för att vänta på ytterligare användarinmatning, utan bara fortsätter tills en viss uppgift är slutförd.

I kapitel 3 undersöks användningen av ändliga tillståndsmaskiner (FSM), en central modell för att beskriva systemens inre beteende. FSM är särskilt användbara för att modellera tillståndsbaserade operationer, där systemet väntar på och svarar på externa eller interna händelser. De används främst för att strukturera beteendet hos system där tillstånd och övergångar mellan dessa tillstånd är viktiga för att förstå och beskriva systemets funktionalitet.

FSMs kan representeras både formellt genom mängdnotation och grafiskt som en riktad graf. Även om den formella notation är användbar, är den grafiska formen mer lättförståelig och analysvänlig för människor. Ett antal verktyg för utveckling och analys av FSMs finns tillgängliga, och de kan automatiskt generera kod från modellen när designteamet är redo att implementera eller testa den.

FSMs har sina rötter i formella språk och användes ursprungligen för att beskriva grammatikstrukturer i programmeringsspråk på 1960-talet. En accepterande FSM (Accepting FSM) används för att avgöra om en given sträng av symboler tillhör en viss grammatik, som kan definiera ett programmeringsspråk. Ett exempel på en sådan FSM kan vara en som accepterar en sträng av binära siffror där antalet 1:or är udda. Detta kan illustreras med en enkel graf där FSM:n växlar mellan tillstånd beroende på om en 1 eller 0 läses in, och det slutgiltiga tillståndet anger om strängen är accepterad eller inte. FSM:n kan, beroende på sin struktur, också användas för att översätta en inputsträng till en outputsträng, som i fallet med en transducer-FSM.

För att fördjupa förståelsen av FSM:er är det viktigt att se på hur dessa modeller kan tillämpas på mer komplexa system, inklusive sådana som har flera samtidiga tillstånd eller delsystem. I dessa fall kan FSM:er kombineras med andra modelleringsverktyg för att hantera beroenden mellan uppgifter, delade resurser och distribution, vilket gör det möjligt att skapa ännu mer robusta och flexibla system.

I designen av inbäddade system och andra tillståndsbaserade applikationer är det väsentligt att förstå att FSM:er inte ensamma kan lösa alla designproblem. FSM:er är kraftfulla för att beskriva beteende i tillståndsorienterade system, men de är bara en del av ett större verktygslåda. När ett system utvecklas behöver fler modeller för att hantera tid, beroenden och andra faktorer också användas. FSM:er erbjuder en elegant lösning för system där tillstånd och övergångar är centrala, men de ger inte en fullständig bild på egen hand.

I tillägg till att beskriva systemets tillstånd är det viktigt att betrakta hur användaren interagerar med systemet, och hur oväntade eller felaktiga inmatningar ska hanteras för att säkerställa att systemet fortsätter att fungera korrekt. Det är också centralt att förstå hur systemets tillståndsförändringar kan påverka andra delar av systemet, särskilt när det gäller större och mer komplexa applikationer.

Hur fungerar operativsystem i inbyggda system och när behövs de?

I moderna inbyggda system, som till exempel ett styrsystem för en bro eller en intelligent byggnadsstyrning, är det viktigt att hantera en mängd processer och resurser på ett effektivt sätt. Varje uppgift, såsom att läsa temperaturer varje sekund eller uppdatera en operatorpanel varje minut, kräver noggrant tidsstyrd exekvering av processer. Ett operativsystem (OS) ansvarar för att planera dessa uppgifter och säkerställa att alla processer körs vid rätt tidpunkt.

En mer avancerad arkitektur kan inkludera flera processorer (CPUs), och här spelar operativsystemet en avgörande roll i att tilldela processerna till de olika processorerna. OS hanterar dessutom resursdelning mellan processerna – exempelvis mellan olika enheter som diskar eller kommunikationskanaler. Om en process väntar på en resurs eller ett externt händelseförlopp, så kan operativsystemet byta ut den och ge andra processer möjlighet att använda processorkraften.

Ett inbyggt system skiljer sig från en vanlig dator, inte bara i funktionalitet utan också i sina krav på resurshantering. I en dator är det vanligt med externa masslagringsenheter och ett komplext filsystem, medan ett inbyggt system oftast inte har denna typ av lagring. I stället fokuserar OS i ett inbyggt system främst på intern minneshantering, såsom hantering av cacheminne eller arbetsminne (scratchpad).

Ett av operativsystemets grundläggande syften är att underlätta interaktionen mellan processer och fysiska enheter. Till exempel, i en PC behövs drivrutiner för att hantera olika enheter som skärmar eller hårddiskar. Detta gör att applikationer kan använda generella OS-operationer, såsom att öppna eller stänga filer, utan att behöva känna till de specifika detaljerna för varje enhet. I inbyggda system kan dock enheterna vara mycket mer begränsade, vilket innebär att de kan vara specifika för systemets funktion. Exempelvis, en brostyrmodul kommer förmodligen inte ha en bildskärm eller tangentbord, utan kommunicerar istället direkt med andra delar av systemet eller med ett centralt kontrollsystem.

Säkerheten är ytterligare en viktig aspekt av ett operativsystem. I vanliga datorer är säkerhetsriskerna främst förknippade med e-postklienter, webbläsare och filnedladdningar, medan dessa risker är betydligt lägre i inbyggda system. Ett styrsystem på en bro, till exempel, behöver inte hantera e-post eller webbläsartjänster, vilket minskar risken för externa säkerhetshot. Det innebär också att säkerheten i dessa system inte behöver vara lika komplex som i vanliga datorer.

En annan viktig funktion hos operativsystem är felhantering och skydd mot olika interna problem. OS kan till exempel återställa systemet efter minnesfel eller stacköverflöde. Även om dessa problem kan uppstå i inbyggda system, är de ofta hanterade genom noggrann programvarutestning snarare än genom ett traditionellt OS. Eftersom en inbyggd lösning ofta inte kräver nya enheter eller ändringar i systemets hårdvara efter implementering, är behovet av att lägga till nya enheter eller hantera avbrott genom ett OS mycket mindre.

Vid val av operativsystem är det också viktigt att förstå att det inte alltid är nödvändigt att använda ett fullt fungerande OS i inbyggda system. Vissa system har mycket begränsade krav på in- och utdata, vilket innebär att ett OS kan vara onödigt eller till och med hinder för systemets effektivitet. Till exempel, ett enkelt trafikljus-system behöver inte ett OS för att hantera sina grundläggande funktioner. Ett sådant system använder bara enkla digitala ingångar och utgångar samt avbrott från sensorer och radiosignaler.

I det här sammanhanget bör man överväga att antingen köpa ett OS eller bygga ett eget beroende på systemets specifika behov och hur de olika delarna av systemet kommunicerar med varandra. För de enklare delsystemen som kräver minimal funktionalitet kan ett inbyggt system utan OS vara mer effektivt. För mer komplexa system, som en huvudkontrollmodul för en bro, kan behovet av ett OS vara mer påtagligt, särskilt om systemet behöver interagera med externa system eller ge en mänsklig operatör ett gränssnitt.

Således handlar beslutet om huruvida ett OS ska användas eller inte, inte bara om systemets storlek eller komplexitet, utan om de specifika kraven på interaktion, kommunikation och säkerhet i systemet.

Hur koordinering av tid fungerar i inbyggda system

När vi diskuterar tid i inbyggda system, handlar det ofta om att hantera och koordinera tid mellan olika moduler eller element inom ett system. Detta kan vara en utmaning, särskilt när det gäller att använda globala tidskällor som GPS eller UTC. För inbyggda system som inte är implementerade på PC eller bärbara datorer, måste tidshantering programmeras på andra sätt. En vanlig metod är att hämta tid från internationella eller globala tidsstandarder.

Det finns flera globala tidsstandarder för att mäta tid på olika sätt. Universell Tid (UT) är en sådan standard som baseras på jordens rotation. Dock är jordens rotation inte konstant, vilket innebär att UT kan avvika från verklig tid och behöva justeras vid vissa tillfällen. Detta gör att versionerna av UT, som till exempel UT1, kan behöva justeringar för att säkerställa en mer exakt tid.

Internationell Atomtid (TAI) är ett annat exempel och representerar ett genomsnitt av hundratals atomklockor världen över. Eftersom atomklockor påverkas av lokala förhållanden som gravitation, ger genomsnittsberäkningen en mer stabil och exakt tid. Global Positioning System (GPS) är en annan källa som tillhandahåller tidsstämpel i sina datapaket.

En viktig tidsstandard som ofta används är Universal Time Coordinated (UTC). UTC är också baserat på atomtimmar men försöker hålla sig nära UT genom att lägga till ”skottsekunder” vid behov. UTC är därför den vanligaste referensen för tid, men även den kräver justeringar för att hålla jämna steg med jordens rörelse. Detta gör att olika tidskällor ibland kan skilja sig åt, vilket kan leda till små avvikelser.

Men om alla moduler inom ett inbyggt system använder samma tidskällor kan koordinering bli ganska enkel. Ett viktigt beslut vid designen av sådana system är vilken upplösning av tid som krävs för applikationen. Vissa system behöver bara koordinera tid på sekundnivå, medan andra applikationer kan behöva noggrannhet på mikrosekundnivå för att vara effektiva.

I många fall räcker det att systemet använder tid på en sekunds nivå för att fungera korrekt. Till exempel, trafikljus som växlar beroende på tid på dygnet eller helger kan hantera små avvikelser i tidsinställningar. System som inte kräver strikt samordning eller exakta tidsstämplar kan tolerera sådana små variationer utan att påverka funktionaliteten.

I mer avancerade applikationer, som rymdprogram eller precisionsstyrning av robotar, kan även mikrosekundnivåer vara avgörande. Här är det inte bara själva klockinformationen som är viktig, utan också hur snabbt denna information når systemet och hur snabbt den bearbetas. I dessa fall spelar fördröjningar en stor roll. Till exempel, även om en GPS-paket har en tidsstämpel för när den skickades, kommer detta paket inte att nå GPS-mottagaren omedelbart. Om applikationen kräver noggrann koordinering på mikrosekundnivå, kan denna lilla fördröjning vara katastrofal.

En annan utmaning för systemdesigners är att hantera tidsinformation från externa källor. GPS-enheter kan till exempel beräkna exakt realtid från sina egna datapaket, men om överföringsvägen från GPS-enheten till processorn är långsam, kan fördröjningarna göra att den höga upplösningen inte återspeglas i systemet. Ett system som använder GPS kan till exempel skicka tid till en processor via USB eller RS232, och dessa gränssnitt kan introducera fördröjningar som är mycket större än de hundra nanosekunder som GPS-enheten kan erbjuda.

Därför måste noggrant övervägas hur tid tas emot och bearbetas av systemen. För system som kräver exakt tidshantering, är det viktigt att ha rätt protokoll och korrekt mjukvara som kan hantera fördröjningar och exakt beräkna den verkliga tiden. En GPS-enhet kan vara i stånd att leverera data med en upplösning på upp till 100 nanosekunder, men om den långsamma kommunikationen mellan modulerna är för långsam, förloras denna noggrannhet.

Tidsinformation från globala tidstjänster skickas ofta i datapaket som följer ISO 8601-formatet. Detta gör att system och tjänster kan använda en enhetlig tidsrepresentation, vilket förenklar koordinering mellan olika moduler. En viktig aspekt är att olika tidsprotokoll kan ha sina egna unika egenskaper som måste beaktas vid systemdesign. Vissa system tar inte hänsyn till skottår eller tidszoner. Andra system kan endast ge den passerade tiden sedan en given referenspunkt, vilket kan vara otillräckligt i vissa tillämpningar. UTC har också en begränsning i att den inte kan förutsäga exakt när nästa "skottsekund" kommer att inträffa.

För att säkerställa att tidshanteringen fungerar optimalt, måste systemingenjörer noggrant studera applikationens krav och matcha dessa med kapabiliteterna hos olika tidsprotokoll. Det handlar inte bara om att välja rätt protokoll, utan också att förstå hur dessa protokoll påverkar systemets prestanda och tillförlitlighet.

För att lösa problem med tidssynkronisering kan moduler som använder interna klockor och kristaller behöva övervakas noggrant. Olika moduler kan använda olika frekvenser för sina kristaller, vilket leder till avvikelser i tid. I ett system där flera moduler är placerade nära varandra, som på en gemensam kretskort, kan en gemensam tidsbas användas för att eliminera dessa skillnader. I mer komplexa system med moduler på avstånd, måste systemet ta hänsyn till dessa driftproblem och ha mekanismer för att synkronisera tid på ett effektivt sätt.

När samordning av tid inte krävs på högsta nivå, kan system som använder interna klockor och periodiska synkroniseringar mellan moduler också fungera effektivt. Om synkroniseringen sker på sekundnivå eller långsammare, kan modulerna enkelt justera sina tider genom att lyssna på ett centralt tidsutskick.

Hur säkerställer vi kvaliteten i mjukvaruutveckling genom processer och verifiering?
Hur Trumps Presidensval Påverkade Partipolarisering och Kongressens Dynamik
Vad är effekten av katalysatorer på superkritisk vattenförgasning?
Hur påverkar Trump-byråkraterna och den neutrala kompetensen?