Hur man uppskattar kostnader och bearbetningstid i inbyggda system

När det gäller inbyggda system är en av de mest centrala utmaningarna att korrekt uppskatta kostnader och bearbetningstid för de olika funktionerna i systemet. Detta gäller särskilt när det handlar om schemaläggning och prioritering av uppgifter, där det kan vara svårt att förutsäga hur olika händelser som avbrott eller delade resurser kommer att påverka systemets prestanda. Att noggrant analysera dessa aspekter är avgörande för att säkerställa att alla uppgifter inom systemet genomförs inom sina tidsramar och att inga uppgifter missar sina deadlines.

Ett vanligt problem i inbyggda system är hanteringen av avbrott. I vissa fall kan det finnas en separat uppgift för att bearbeta avbrott, där avbrottsfunktionen enbart registrerar avbrottshändelsen och därigenom påtvingar minimala förseningar på andra uppgifter i schemat. Själva bearbetningen av avbrott kan sedan behandlas som en vanlig uppgift i schemaläggningsalgoritmen. Detta tillvägagångssätt kan fungera bra för att hålla fördröjningarna inom rimliga gränser, men det finns andra aspekter av systemet som är svårare att hantera, särskilt när det handlar om mer komplexa delade resurser.

Ett vanligt problem är att bestämma övre gränser för rekursiva funktioner. Generellt sett bör realtidsystem undvika loopar för vilka en övre gräns inte kan identifieras. En funktion som innehåller en loop som körs tills någon beräkning konvergerar kan aldrig avslutas eller ta för lång tid och därigenom göra andra uppgifter försenade. En liknande risk finns för rekursiva funktioner. Att fastställa en övre gräns på loopar och funktionsanrop är generellt sett inte ett beslut som kan fattas utan ytterligare analys.

För att kunna fastställa dessa gränser bör det göras i samband med systemdesignprocessen, till exempel under fasen för UML-modellering. I vissa fall kan det finnas naturliga gränser, men designteamet kan vilja införa en striktare gräns än den naturliga gränsen. Till exempel, i ett broprojekt där sensorn kan detektera båtar inom ett visst avstånd, skulle designteamet kunna besluta att endast ta hänsyn till de närmaste fem båtarna istället för alla båtar inom detekteringsområdet, vilket gör att bearbetningen av väntande båtar kan begränsas till fem iterationer istället för ett större antal.

När gränserna för algoritmerna har fastställts och det är möjligt att identifiera alla vägar från funktionens start till dess avslutningspunkter, kan dessa analyseras. För relativt enkla uppgifter, som att kontrollera om det finns bilar eller gående på en bro, kan detta göras manuellt eller med hjälp av automatiserade verktyg. För mer komplexa uppgifter där många iterationer och grenar av vägar förekommer, kan det vara användbart att använda simuleringar för att göra noggrannare uppskattningar av köruppgifter och tidskostnader.

När det gäller att uppskatta WCET, är det viktigt att förstå att den längsta vägen i algoritmen inte alltid leder till den högsta kostnaden. En kortare väg kan innehålla dyra instruktioner, som multiplikation eller division, eller funktioner som har längre exekveringstider. Dessa kostnader kan beräknas antingen manuellt eller med hjälp av cykelräknare som simulerar maskinkodens körning.

När den första uppskattningen av WCET har gjorts kan denna justeras för faktorer som kan påverka exekveringstider, såsom avbrott eller fördröjningar orsakade av delade resurser. Det är ofta svårt att förutsäga hur många avbrott som kan inträffa under exekveringstiden för en specifik uppgift, eller hur länge en delad resurs kan vara upptagen. I dessa fall är det ofta nödvändigt att göra en säker uppskattning av de maximala fördröjningarna, även om det innebär att den slutliga uppskattningen av WCET blir mer konservativ och inte lika exakt.

Hur bedömer man schemaläggbarheten och exekveringstid för periodiska uppgifter i realtidssystem?

I realtidssystem där flera periodiska uppgifter ska exekveras på en processor är det avgörande att säkerställa att alla uppgifter kan slutföras inom sina deadlines. En viktig metod är att analysera och beräkna processorutnyttjandet, det vill säga den andel av processorns tid som är reserverad för att köra dessa uppgifter. För två uppgifter med perioder och exekveringstider, till exempel T1 med period 4 och exekveringstid 2, och T2 med period 7 och exekveringstid 3, beräknas utnyttjandet som summan av kvoten exekveringstid över period för varje uppgift, vilket ger en indikator på hur mycket processorns kapacitet som används.

En viktig aspekt är att jämföra detta utnyttjande med kända gränser för schemaläggbarhet, såsom den som ges av Rate Monotonic Scheduling (RMS). RMS garanterar att uppgifter kan schemaläggas utan deadline-överskridanden om den totala processorbelastningen är under en viss teoretisk gräns, som beräknas med formeln n(2^(1/n) -1), där n är antalet uppgifter. Om utnyttjandet överstiger denna gräns finns risk att vissa uppgifter inte hinner exekveras i tid.

Hyperperioden är en annan central parameter, definierad som det minsta gemensamma multipel av perioderna för alla uppgifter. Den anger den tidsperiod efter vilken schemat upprepas identiskt, vilket gör det möjligt att analysera systemets beteende över en cykel som täcker alla möjliga kombinationer av uppgiftsscheman.

Rate Monotonic Scheduling prioriterar uppgifter baserat på kortast period först och förutsätter att processorn kan preemittera pågående exekvering för att hantera högprioriterade uppgifter som anländer. Det är därför möjligt att stegvis analysera schemat över hyperperioden och identifiera eventuella deadline-missar. Om en uppgift inte hinner exekveras innan nästa instans ska starta innebär det ett schemaläggningsfel. Jämförelser kan även göras med Earliest Deadline First (EDF), en algoritm som prioriterar uppgifter efter närmaste deadline och kan utnyttja processorn mer effektivt i vissa fall.

I system med multipla processorer kan list-schemaläggningsalgoritmer användas för att fördela uppgifter utifrån prioritet och exekveringstid, och för att minimera total exekveringstid och undvika flaskhalsar. Att ta hänsyn till exekveringstid och prioritet är avgörande för att dessa algoritmer ska ge effektiva scheman.

För att fullt ut förstå schemaläggningens komplexitet bör man beakta att verkliga system ofta innehåller dynamiska element, såsom varierande exekveringstider, oregelbundna ankomster och externa störningar, vilket kräver robusta algoritmer och anpassningsbara lösningar. Dessutom är det väsentligt att ta hänsyn till kostnader för preemtion och kontextbyte, som påverkar processorbelastningen och därmed schemaläggbarheten. Att analysera och förstå dessa faktorer är grundläggande för att kunna designa realtidssystem som är både effektiva och pålitliga.

Vilka system bör implementeras med FPGA och varför?

FPGAs (Field-Programmable Gate Arrays) är en typ av hårdvaruplattform som möjliggör att användaren kan programmera kretsar och logik direkt på hårdvarunivå. Detta ger stor flexibilitet och snabbhet för att utföra komplexa operationer parallellt och med mycket låg latens. Men inte alla system är lämpade för att använda FPGA:er. Det är viktigt att förstå när och varför man bör använda FPGA i olika applikationer för att optimera prestanda och kostnad.

I vissa applikationer, som till exempel ett eldledningssystem på en jagare, kan FPGA vara särskilt användbart. Eldledningssystem kräver hög precision och snabb reaktionsförmåga, eftersom det handlar om att ta emot och bearbeta realtidsdata för att kunna fatta beslut snabbt. Här skulle FPGA:er kunna ersätta eller komplettera traditionella mikroprocessorer genom att erbjuda parallell bearbetning och extremt låg latens, vilket kan vara avgörande i stridssituationer.

För dörrsäkerhetssystem är användningen av FPGA mer tveksam. Dessa system tenderar att vara enklare och kräver inte den komplexa databehandling eller de högsta prestandakraven. Istället kan traditionella mikroprocessorer eller till och med enkla digitala logikkretsar vara tillräckliga för att hantera grundläggande säkerhetsfunktioner som att registrera kort, låsa upp dörrar och aktivera larm. FPGA skulle inte ge några signifikanta fördelar i detta fall, med tanke på systemets relativt låga krav på beräkningskapacitet och prestanda.

När det gäller hissystem i höghus finns det också överväganden kring FPGA-användning. Hissar är komplexa system som kräver en mängd olika sensorer och styrkomponenter för att säkerställa att de fungerar korrekt och säkert. FPGA kan användas för att optimera processer som signalbearbetning från sensorer, motorstyrning och säkerhetsåtgärder. Men här skulle det kunna vara mer kostnadseffektivt att använda mer traditionella lösningar baserade på mikrokontroller och digital logik, där behovet av hög parallellbearbetning inte är lika uttalat. FPGA:er skulle i detta fall främst användas där det finns ett behov av högre flexibilitet och snabbare databehandling, till exempel för att optimera trafikflödet i byggnader med många våningar eller för att bearbeta flera sensorers data samtidigt.

I den här diskussionen är det tydligt att beslutet om att använda FPGA beror på de specifika kraven i varje system. FPGA är användbart när det finns behov av extremt snabb parallell bearbetning, hög anpassningsbarhet eller när det finns en starkt realtidsberoende applikation. För enklare system med lägre krav på beräkningskapacitet kan traditionell mikroprocessorlogik eller digitala kretsar vara ett mer kostnadseffektivt alternativ.

För att förstå när FPGA är den bästa lösningen är det viktigt att känna till både de tekniska fördelarna och nackdelarna med dessa enheter. FPGA:er erbjuder flexibilitet och kan anpassas till en mängd olika användningsområden, men de är också mer komplexa att programmera och kan vara dyrare att implementera och underhålla. För användning i applikationer där snabb bearbetning är avgörande, som i militära system eller avancerad robotik, kan FPGA vara oumbärliga. Däremot, för enklare uppgifter eller där kostnadseffektivitet är högre prioriterat, bör andra teknologier övervägas.

Förutom att välja rätt hårdvara är det också avgörande att förstå hur systemets sensorer och aktorer kommer att samverka med styrsystemet. Digitala och analoga ingångar är vanliga i inbäddade system, och varje typ av ingång kräver specifika tekniska lösningar för att säkerställa korrekt datainläsning och bearbetning. Till exempel kan digitala ingångar, som knapptryck eller switchar, behöva pull-up eller pull-down motstånd för att skapa tydliga logiska nivåer. För att hantera analoga signaler kan analoga till digitala omvandlare (ADC) användas för att översätta sensorutgångar till digitala värden som kan bearbetas av processorn.

Ytterligare tekniska utmaningar uppstår när man hanterar störningar från omvärlden, såsom elektriskt brus som kan påverka signalöverföringen. Här kan opto-isolatorer eller mekaniska reläer användas för att isolera känslig elektronik från störande faktorer. I vissa system kan det också vara nödvändigt att kompensera för fenomen som "key bounce", där mekaniska kontakter inte ger ett rent ON/OFF-signal utan istället leder till flera onödiga event.

För att sammanfatta, när man väljer mellan FPGA och andra teknologier är det avgörande att förstå systemets specifika krav på bearbetningshastighet, komplexitet, och kostnad. FPGA erbjuder en hög grad av flexibilitet och parallell bearbetning, men inte alla applikationer kräver dessa funktioner. Att förstå och hantera systemets ingångar, utgångar, och externa störningar är lika viktigt för att bygga effektiva och pålitliga inbäddade system.

Hur designprocessen för inbäddade system skiljer sig från traditionell mjukvaruutveckling

Designen av inbäddade system kräver en mer omfattande och mångfacetterad process än traditionell mjukvaruutveckling. Dessa system kombinerar både hårdvara och mjukvara, vilket innebär att de har ett bredare spektrum av ingångs- och utgångsmetoder samt användningsområden. För att hantera dessa komplexiteter har vi utvecklat en utvidgad version av den klassiska vattenfallsmodellen, som nu innehåller sex steg: kravinsamling, kravanalys, design, prototyp, implementering/testning, och integration/testning.

I nästa steg, kravanalys, omvandlas de informella kraven från föregående steg till ett formellt kravdokument som senare kommer att ligga till grund för design, implementering och testning av systemet. Denna analys är mer komplicerad än för mjukvara, eftersom inbäddade system ofta har fler användningssätt. Till exempel, en bro kan normalt vara programmerad att höja och sänka sina brospann vid passage av båtar, men under månadsinspektioner eller vid underhåll kan detta beteende behöva förändras. Därför måste kravanalysen ta hänsyn till olika användarscenarier, tidsspecifika krav (som att känna igen en båt inom en viss tidsram) och samordning mellan olika moduler i systemet. I vissa fall kan det även finnas icke-funktionella krav, som när ett miljömonitoreringssystem i en skog inte får störa det lokala djurlivet.

Designsteget skapar en komplett design för systemet som uppfyller de krav som definierats i föregående steg. Här kombineras både mjukvara och nödvändig hårdvara, vilket gör designen mer omfattande. Designteamet använder ofta modelleringsverktyg för att skapa detaljerade representationer av systemets funktioner, där både övergripande och specifika detaljer beskrivs. Modellerna måste ta hänsyn till hur olika delar av systemet samverkar, hanterar fel, återhämtar sig från störningar och interagerar med den omgivande miljön.

Under prototypsteget byggs och testas prototyper av systemet för att säkerställa att designen möter alla krav. Prototyper kan bygga på simulerade eller emulerade komponenter för delar av systemet som ännu inte är tillverkade, och de testas både i labbmiljöer och på den verkliga installationsplatsen. Dessa prototyper gör det möjligt för intressenter att ge feedback och identifiera fel i designen innan produkten är färdig. Att fånga fel tidigt i denna fas är betydligt billigare än att rätta till dem längre fram i processen.

I implementerings- och testfasen byggs de slutliga komponenterna för systemet och testas individuellt och i kombination med andra delar av systemet. Det kan handla om att tillverka tryckta kretskort eller integrerade kretsar och att programmera dessa komponenter. Enheterna testas både som enskilda delar och som en helhet. Exempelvis skulle en diskmaskin styras av en processorenhet som testas först i isolation, sedan tillsammans med reläer och lysdioder, och slutligen i den verkliga diskmaskinen.

Det sista steget, integration och testning, innebär att det kompletta systemet installeras på den avsedda användningsplatsen, såsom en bro eller en diskmaskin. Här utsätts systemet för verkliga förhållanden som inte kan simuleras i ett labb, som vibrationer och förändringar i temperatur och fuktighet. Vid behov justeras sensorer, motorer och andra mekanismer för att optimera systemets funktion. Slutliga justeringar görs också för att säkerställa att systemet fungerar felfritt i den verkliga användningen.

Förutom själva designprocessen finns det många andra faktorer som påverkar att ett inbäddat system tas till marknaden. Detta inkluderar planering av tillverkningsprocessen, lagring av komponenter och den faktiska leveransen av den färdiga produkten. För att designa ett effektivt inbäddat system är det därför avgörande att förstå den övergripande processen och de unika utmaningar som skiljer sig från traditionell mjukvaruutveckling.