När man utvecklar inbyggda system är det avgörande att se till att deras beteende är förutsägbart och att systemet reagerar korrekt på de inmatade signalerna. En av de mest använda metoderna för att beskriva och testa sådana system är med hjälp av tillståndsmaskiner (FSMs). Tillståndsmaskiner, som är modeller av hur ett system reagerar på olika inputs, används för att förutsäga och styra ett systems beteende genom att definiera ett antal tillstånd och övergångar mellan dessa.

Testning av en FSM innebär att man simulerar systemets beteende under olika scenarier, vilket gör det möjligt att identifiera möjliga fel och ofullständiga övergångar. Ett exempel på detta är en brokontroll FSM som styr hur en bro öppnas och stängs när båtar passerar. Vid simulering eller genomgång av dessa scenarier kan man upptäcka brister i modellen, såsom felaktiga tillstånd eller felaktiga övergångar mellan tillstånd.

Anta att en enskild båt passerar utan att det finns trafik på bron. FSM:en kommer då att gå från ett tillstånd som förbereder bron för öppning, till ett tillstånd där bron är helt öppen. När båten har passerat och vill återuppta trafiken, går FSM:en till tillståndet där bron stängs och marktrafiken återupptas. Detta skulle vara korrekt beteende om alla villkor och åtgärder definieras korrekt i FSM:en. Däremot, om två båtar passerar, kan systemet felaktigt anta att bron ska stängas efter att den första båten har passerat, vilket inte är korrekt. En noggrann genomgång av detta scenario avslöjar en brist i FSM-modellen: det måste finnas ett tillstånd efter att den första båten har passerat som kontrollerar om fler båtar är på väg.

För att effektivt testa en FSM måste man inte bara kontrollera tillståndens sekvenser, utan även noggrant analysera de villkor som styr övergångarna mellan tillstånden. Till exempel, om villkoret "trafik på bron rensad" inte är korrekt implementerat, kan systemet visa fel beteende, som att trafikljusen för marktrafiken förblir röda efter att bron har stängts.

För att säkerställa att FSM:en fungerar som avsett krävs en noggrann granskning av alla scenarier, där varje tillståndsövergång och varje åtgärd analyseras för att kontrollera att de sker exakt vid rätt tidpunkt och under rätt omständigheter. Vid simulering eller genomgång måste varje enskilt villkor och åtgärd analyseras för att se till att systemet agerar på det sätt som det är tänkt.

En FSM måste också vara deterministisk för att säkerställa att systemet beter sig på samma sätt varje gång en viss inmatning inträffar. Ett deterministiskt beteende innebär att varje inmatning resulterar i en unik övergång till ett nytt tillstånd. Detta innebär att systemet kommer att reagera på ett förutsägbart sätt, vilket är nödvändigt för att upprätthålla systemets tillförlitlighet.

Men det finns också icke-deterministiska tillståndsmaskiner. Dessa kan ha flera möjliga övergångar för samma input och kan vara användbara i teoretiska modeller eller under den inledande designfasen, där man vill undersöka olika alternativ. Det är dock viktigt att förstå att för det slutliga implementerade systemet bör icke-determinism tas bort, eftersom systemet då skulle bli oförutsägbart.

En annan aspekt av tillståndsmaskiner som är särskilt viktig i inbyggda system är tidsaspekten. Många system har realtidskrav, där felaktig tidsberäkning kan leda till katastrofala resultat. Till exempel, i ett system för kollisionsförebyggande i bilar, måste sensorer snabbt upptäcka ett hinder och bromssystemen måste reagera på mycket kort tid för att förhindra en kollision. Om systemet inte uppfyller dessa tidskrav, kan det leda till allvarliga konsekvenser. Å andra sidan finns det även tidskrav som påverkar användarupplevelsen, som att en bankautomat ska kunna ge ut pengar inom en viss tidsram, för att undvika att användaren blir frustrerad.

När man designar en FSM för ett inbyggt system måste tidshantering inkluderas. Detta kan göras genom att systemet håller reda på tiden och definierar övergångarna på grundval av tidsintervall. I senare faser av designen måste klockan implementeras för att säkerställa att systemet agerar på rätt sätt inom de tidsramar som definieras i kravspecifikationen.

För att sammanfatta, när man arbetar med tillståndsmaskiner är det viktigt att tänka på både funktionalitet och noggrannhet i systemets beteende. En FSM måste vara deterministisk för att säkerställa förutsägbart och tillförlitligt beteende. Genom noggrant test och simulering kan man upptäcka brister och säkerställa att varje övergång mellan tillstånd och varje åtgärd fungerar korrekt. Vid designen av inbyggda system, särskilt när tidsfaktorer spelar en avgörande roll, måste tidshantering och realtidskrav beaktas för att säkerställa att systemet fungerar effektivt och korrekt.

När behövs ett operativsystem i inbyggda system?

Inbyggda system utan behov av schemaläggning och trådar kan vara mycket enkla att utveckla, där programmering av gränssnitt för in- och utdata samt radiosignaler är ganska okomplicerad. Dessa system kräver oftast bara räknare för tidshantering, och själva programvaran består i huvudsak av rak kod med några avbrottshanterare. I sådana fall skulle ett kommersiellt operativsystem inte tillföra något mervärde, då det stöd som behövs kan utvecklas internt och är begränsat till specifika funktioner. Ett typiskt exempel på detta kan vara styrsystem för hushållsapparater, så länge dessa inte är internetanslutna.

Dock, även små inbyggda system kan komma att behöva funktioner där ett operativsystem verkligen är användbart. Ta exempelvis en bils instrumentpanel. Detta system innefattar en mängd olika uppgifter: att visa information på olika skärmar, övervaka GPS-signaler, kontrollera radioinställningar, samt att kommunicera med och monitorera motor-, broms- och andra viktiga system. Många av dessa uppgifter är självständiga processer eller trådar som kräver periodisk uppdatering, vilket innebär att de måste schemaläggas, ofta med olika prioriteringar och perioder.

För att GPS-interfacet ska kunna uppdatera bilens position kontinuerligt måste det anropas med regelbundna mellanrum flera gånger per sekund, medan motor- och bromssystemens status kanske måste kontrolleras med längre mellanrum, men med en egen period. Vissa delar av systemet kan också generera avbrott, till exempel om bilen tappar trådlös anslutning. I sådana här fall blir det snabbt uppenbart att ett operativsystem inte bara underlättar utvecklingen utan även gör systemet mer robust, särskilt när det gäller att hantera ett stort antal samtidiga och oberoende uppgifter, både periodiska och sporadiska.

Multikärniga processorer, som är vanliga i moderna system, kräver också ett operativsystem för att effektivt hantera de olika processorkärnorna. Ett beprövat och stabilt operativsystem kan dessutom minska utvecklingstiden och göra systemen mer pålitliga, vilket gör det möjligt att snabbare ta systemet från utvecklingsfas till slutgiltig produkt.

När man väljer ett operativsystem för ett inbyggt system, finns det flera faktorer som måste beaktas. För det första, kostnaden: det kan vara en engångsavgift eller licensavgift per användning. Om operativsystemet inte innehåller alla nödvändiga funktioner, kan det bli nödvändigt att utveckla de saknade delarna in-house, vilket ökar de totala utvecklingskostnaderna. Flexibilitet är en annan viktig aspekt; kan systemet upprätthållas och utökas inom ramen för det valda operativsystemet, eller kommer framtida versioner att behöva funktioner som går utöver operativsystemets kapabiliteter?

Utrymme är en annan kritisk fråga. Ett inbyggt system kan ha mycket begränsat minne och programlagring. Till exempel, ett 8051-chip kan ha begränsad programlagring på mellan 4K och 8K. Vissa operativsystem, som TinyOS, kan vara små nog att rymmas inom sådana begränsningar, medan mer avancerade system kanske inte får plats. Det är också viktigt att tänka på tillgången till debuggningsverktyg. Inbyggda system kräver ofta exakt tidmätning för att säkerställa att realtidskrav uppfylls, vilket innebär att det behövs specifika verktyg som kan räkna maskincykler under kodens exekvering.

När man arbetar med inbyggda system, kan det också vara viktigt att kunna konfigurera operativsystemet så att det bara inkluderar de funktioner som faktiskt behövs. Detta kan vara särskilt användbart för att hålla programvarans storlek minimal och optimera prestanda. En fördel med vissa operativsystem är att de erbjuder gränssnitt för att välja exakt vilka funktioner och enheter som ska ingå, vilket gör det möjligt att skräddarsy systemet för specifika behov.

I slutändan kan ett operativsystem i ett inbyggt system antingen vara väldigt enkelt – som vid användning av en polling-loop eller avbrottshantering – eller mycket mer komplext, beroende på systemets krav. I det första fallet består huvudkontrollen av en loop som kontrollerar enheter vid regelbundna intervall. I det andra fallet kan systemet gå i viloläge och endast väckas upp vid ett specifikt avbrott.

Det är också viktigt att förstå att valet mellan att använda ett inbyggt operativsystem eller skapa ett eget kan bero på applikationens komplexitet och kraven på realtidsbehandling. Realtidsoperationer är vanliga i inbyggda system, och systemen måste kunna hantera olika tidskrav, exempelvis synkronisering mellan enheter och exakt tidsstämpling av data.

Förutom dessa tekniska överväganden måste en systemutvecklare också beakta långsiktiga faktorer, såsom den framtida skalbarheten för systemet, behovet av att uppdatera eller utöka funktioner och den potentiella komplexiteten som kan uppstå med nya versioner av operativsystemet.

Hur säkerställer man systemets pålitlighet genom diversifierade monitorer och beräkningar?
Hur kan isbildning och avisning på rotorblad hos rotorcraft modelleras och förutsägas?
Hur kan man optimera representationer inom evolverande system för att maximera prestation och beteendemångfald?
Hur symboler styr våra handlingar och relationer
Hur separata FSM:er gör det enklare att hantera komplexa scenarier och användningsfall