I IoT-världen kan begreppet "sak" verka självklart, men det bär på en mycket bredare betydelse än bara fysiska objekt. Visst, de flesta "saker" i IoT är fysiska – som fordon, apparater, människor, djur och tillverkningslinjer. Men i många fall omfattar IoT även virtuella saker. Ett exempel på detta är kod som körs på en processor, vilket kan betraktas som en sak som identifierar sig själv, mäter sin egen prestanda och kan påverka andra saker, som att styra en trådlös modul för att spara energi. Andra exempel på virtuella saker inkluderar aktiemarknaden och till och med väderprognoser.

För ingenjörer som arbetar med inbäddade system är det viktigt att förstå bredden av de saker deras system kan interagera med i framtiden. En sak kan vara enkel och bara identifiera sig själv, eller den kan vara mer sofistikerad och utföra komplexa operationer. Dessa kan sträcka sig från att mäta och rapportera miljöförhållanden, till att aktivera kontroller som påverkar miljön eller fatta intelligenta beslut baserade på analys av omgivningen. En sak kan vara mycket komplex, som ett helt inbäddat system, och bestå av andra saker som dess delar.

Sakerna i IoT kan struktureras i ett hierarkiskt system, vilket inom AI-fältet kallas ISA-hierarki (IS-A). Ett exempel på detta är en ambulans, som är en typ av nödfordon och därmed en fordonstyp. En bår kan också betraktas som ett nödfordon i vissa sammanhang. En hälsoövervakningssystem som kan kalla på hjälp vid en nödsituation, kan behöva kommunicera med en ambulans eller en bår beroende på omständigheterna. För att kunna fatta sådana beslut krävs det en viss nivå av intelligens, antingen inbyggd i systemet eller tillgänglig via externa mekanismer för förfrågningar.

På samma sätt kan individuella objekt bestå av andra saker som delar, ett så kallat HASA-förhållande i AI. En bil är en sak. Den har ett styrsystem, som i sig är en annan sak. Samarbete mellan olika saker i IoT kan kräva förståelse för denna struktur, på ett sätt som liknar ISA-förhållandet som nämns ovan. Varje typ av sak har sina egna data, som kan vara digitala eller analoga och kan ge diskreta mätningar, såsom aktuell temperatur, eller strömmande former, som video.

En annan aspekt av saker i IoT är deras livslängd. Precis som människor föds och dör saker. Saker som sänder data till omvärlden kommer att ha en form av beständighet genom historiska data som lagras i olika förråd, såsom molntjänster. Saker kan också komma in och ut ur Internet-anslutning. Mobila saker kan lämna områden med Internetåtkomst, och batteridrivna saker kan få sina batterier slut och bytas ut. Att förlora kommunikationen med en sak betyder inte nödvändigtvis att den har "dött".

För att vara en del av IoT måste varje sak ha ett namn för att kunna identifieras och lokaliseras. Industrin har implementerat standarder för att namnge objekt och ett Object Naming Service (ONS), som är en förlängning av det redan etablerade Domain Naming Service (DNS) på Internet. I många fall kommer saker att kommunicera med varandra direkt utan behov av att söka efter en kommunikationsväg. Till exempel kan två bilar som närmar sig varandra känna igen varandra så fort de kommer inom räckhåll för sina respektive trådlösa kommunikationssystem.

I andra fall kan ett system behöva använda ONS för att hitta ett objekt som det försöker upprätta en länk med. Ett exempel på detta kan vara basstationen i ett system för att övervaka djurmigration, som måste använda en locator-tjänst för att koppla upp sig mot en nod som är fäst vid ett djur som rör sig, på samma sätt som mobiltelefonssystem söker upp ett nummer som ringts. Här kommer IPv6 att spela en avgörande roll, eftersom IPv4 endast kan hantera cirka 4,3 miljarder adresser, medan antalet uppkopplade saker redan har överstigit denna gräns och kommer att fortsätta växa.

När det gäller skala handlar det om en mycket större mängd enheter och data i IoT än vad som behövs för individuella inbäddade system. Estimaten för antalet IoT-enheter som är anslutna till Internet 2020 talar om upp till 50 miljarder enheter, och denna siffra förväntas fortsätta växa, eventuellt fördubbla sig varje några år. För de flesta inbäddade system är antalet enheter däremot mycket mer begränsat. Till exempel kan ett biövervakningssystem bestå av fem eller sex sensorer, medan ett större system för att övervaka och kontrollera ett stort jordbruksområde kan bestå av hundratals eller tusentals enheter. Denna skillnad i skala är avgörande för ingenjörer att förstå när de designar sina system.

Skalan inom IoT påverkar också nätverksstrukturen. I IoT förväntas miljarder enheter kommunicera på nätverket, och dessa enheter kommer att använda ett brett spektrum av nätverksprotokoll. Detta står i stark kontrast till ett enskilt inbäddat system där nätverksstrukturen och protokollet är definierade och fasta. I IoT kan man dock anta att ett inbäddat system, som designades för att kommunicera med andra system inom sitt eget ekosystem, i framtiden kommer att behöva kommunicera med externa enheter som det inte förutsett under designprocessen. Ingenjörer bör överväga denna möjlighet och antingen välja att inte tillåta sådan kommunikation eller tillhandahålla "hängslen" genom vilka framtida kommunikation kan implementeras.

Hur kan tidsinställningar och tillståndsinvarians användas i FSM-modeller för att skapa robusta och flexibla system?

I en FSM (Finite State Machine) kan tidsinställningar och tillståndsinvarians användas för att skapa system som reagerar korrekt på olika tidsberoende händelser och undviker oönskade sidoreaktioner. Detta är särskilt viktigt i komplexa system där flera processer behöver samordnas samtidigt. En central komponent för att implementera sådana funktioner är klockan, som ofta baseras på en intern klocka i bearbetningselementet (CPU eller annan hårdvara). För att möjliggöra exakt tidshantering kan man använda sig av programmerbara timers eller andra tidsrelaterade funktioner som tillhandahålls av hårdvaran.

För vissa system, som FPGA:er (Field Programmable Gate Arrays), kan det vara nödvändigt att implementera egna timerfunktioner och klockstyrning om inte dessa funktioner finns inbyggda. I ett sådant scenario måste varje timer definieras och hanteras genom variabler som representerar tidens gång. Dessa variabler uppdateras enligt systemets interna klocka, vilket gör att varje timer kan justeras oberoende av andra.

En timer i en FSM definieras av ett atomärt timervillkor, vilket uttrycks som en jämförelse mellan två timer-variabler eller en timer-variabel och en konstant. Till exempel kan villkoret "x > 3" eller "(x - y) < 10" användas för att kontrollera om en viss tidpunkt har uppnåtts. Ett sådant villkor kan integreras i en övergångslogik för att bestämma om och när en övergång mellan tillstånd ska ske.

För att öka flexibiliteten i FSM-modellen kan man använda en tillståndsinvarians – en booleanuttryck som representerar en kombination av olika atomära timervillkor. Detta gör att övergångar kan definieras för att ske när den sammansatta tillståndsinvariansen blir falsk. För att förhindra icke-determinism är det avgörande att säkerställa att det bara finns en övergångsregel vars villkor blir sann när tillståndsinvariansen blir falsk, vilket garanterar att exakt en övergång sker.

Exempel på användning av tidsfunktioner i FSM:

Exempel 1: Enkel tidsfördröjning

Anta att ett system behöver en fördröjning på exakt tre minuter för att stoppa in- och utgående trafik vid en bro. För att implementera detta sätts en timer (Otimer) på tre minuter när en båt detekteras. Samtidigt kan en annan timer (Ctimer) sättas på fem minuter för att övervaka hur länge en båt tar på sig att passera under bron. När Ctimer når noll kan en övergång definieras för att stänga brospanet.

Exempel 2: Föregripande av tillståndsinvarians
Det är också möjligt att övergå från ett tillstånd innan tillståndsinvariansen blir falsk. Detta kan vara användbart om det finns ett behov av att reagera på externa händelser innan systemet uppfyller den förväntade tidsfördröjningen. Till exempel, i ett system där bron öppnas för att släppa igenom en båt, kan en extern signal (t.ex. upptäckt av en ny båt) orsaka en övergång till ett nytt tillstånd innan den definierade väntetiden har passerat.

Exempel 3: Tidsberoende händelser
I andra fall kan det vara användbart att definiera olika tidsgränser för olika övergångar. I ett system som hanterar vägtrafik på en bro, kan olika timer användas för att ge tid för fordon och fotgängare att lämna bron innan den höjs. Om trafiken inte rensats på en viss tid (t.ex. 10 sekunder), kan ett alarm utlösas. En sådan systemfunktion kan implementeras med hjälp av timers som kontrollerar att de olika tidsgränserna uppfylls innan övergångar sker.

Hierarkiska FSM:er

För mer komplexa system är det ofta fördelaktigt att använda hierarkiska FSM:er, där ett tillstånd i sig är en egen FSM. Detta gör det möjligt att skapa modulära system som kan hantera parallella processer på ett effektivt sätt. I ett sådant scenario kan tillståndsdiagrammet bli mycket enklare att hantera genom att vissa detaljer abstraheras bort i övergripande tillstånd, vilket gör det enklare att förstå systemets övergripande funktionalitet.

Ett exempel på en hierarkisk FSM är ett system där bron är uppdelad i flera moduler: en för att hantera trafiken på marken, en för att kontrollera spans, och en för att hantera säkerhetssystem som ljus och larm. Om ett av dessa moduler är tillräckligt komplext kan den representeras som en egen FSM inuti det övergripande tillståndet för bron, vilket gör det möjligt att analysera den specifika funktionen utan att behöva bry sig om de detaljerade funktionerna hos de andra systemen.

Hierarkiska tillstånd kan också underlätta hanteringen av olika samtidiga processer, eftersom det gör det möjligt att definiera övergångar på flera nivåer. Detta kan vara särskilt viktigt i system där flera aktiviteter behöver hanteras parallellt, till exempel i ett embedded system för en bil eller en bro.

Sammanfattning
För att skapa robusta och flexibla FSM-modeller som kan hantera tidsberoende händelser är det viktigt att noggrant definiera och kontrollera timer och tillståndsinvarians. Genom att använda atomära timervillkor och booleanska uttryck för att styra övergångar kan komplexa tidsberoende funktioner implementeras på ett effektivt sätt. Hierarkiska FSM:er erbjuder dessutom en metod för att hantera komplexa, parallella system och skapa modulära lösningar som är lämpliga för embedded systems.

Hur kan analys av räckvidd i plats-/övergångsnät avslöja ineffektivitet och säkerställa korrekt systemdesign?

Att analysera plats-/övergångsnät innebär inte enbart att säkerställa att systemet fungerar enligt sin specifikation, utan också att identifiera möjliga ineffektiviteter, felbeteenden och flaskhalsar i själva konstruktionen. Detta kräver ett ingående studium av hur övergångar kan avfyras i olika ordningar och hur dessa ordningar påverkar systemets tillstånd. Nondeterminism i valet av övergångsordning kan leda till oönskat beteende, särskilt när flera övergångar kan ske samtidigt utan att de konflikterar. För att fånga dessa variationer används räckviddsgrafen, som illustrerar alla tillstånd som är nåbara från ett givet utgångstillstånd.

Kapacitetsfunktionen K i ett sådant nät bör motsvara verkliga begränsningar i systemet. I en bilfabrik kan exempelvis stationen där dörrar monteras ha ett lagerutrymme som är strikt begränsat – det får inte antas vara oändligt. På samma sätt gäller i datorsystem där kommunikation sker via meddelandeköer att varje kö har en fast maximal längd. Att tilldela oändlig kapacitet (ω) till platser är ett vanligt nybörjarmisstag. Trots att modellen tillåter det, bör varje försök göras för att fastställa realistiska värden. Genom simuleringar eller noggranna genomgångar kan rimliga tidskrav och kapacitetsbehov identifieras.

I monteringslinjer, som exemplet med dörrmontering visar, är varje plats och övergång en del av ett större nätverk. Dörrar tillförs från ett större lager, som i sin tur fylls på från dörrproduktion. Genom att studera hela nätverket – hur snabbt dörrar produceras, flyttas och används – kan man uppskatta vilka kapaciteter som krävs, om flaskhalsar uppstår och hur olika scenarios påverkar flödet. Justeringar kan göras för att uppnå ett så smidigt och effektivt förlopp som möjligt.

Ett centralt begrepp i denna analys är räckvidd. Ett tillstånd (en markering M) är nåbart om det kan erhållas från ett givet starttillstånd (M₀) genom en följd av giltiga övergångar. M är alltid nåbart från sig självt. Ett nytt tillstånd M′, erhållet genom att avfyra en möjlig övergång i M, är också nåbart. Den mängd tillstånd som är nåbara från M utgörs av den transitiva slutningen av denna process. Om inga platser har oändlig kapacitet (ω) är mängden nåbara tillstånd ändlig, även om den i praktiken kan vara mycket stor.

Definitionen av räckvidd kräver att mängden nåbara tillstånd är den minsta möjliga mängden som uppfyller villkoren ovan. Detta förhindrar att man felaktigt antar att alla möjliga tillstånd är nåbara, vilket i praktiken inte stämmer. Två övergångar t₁ och t₂ som är oberoende av varandra – deras för- och eftermängder överlappar inte – kommer att uppvisa den så kallade diamant-egenskapen: oavsett i vilken ordning de avfyras leder de till samma tillstånd. Detta är avgörande för att identifiera parallelliserbara processer i nätet.

Att generera hela mängden nåbara tillstånd kan ske genom simulering, men om denna mängd är oändlig måste simuleringen avbrytas vid en rimlig punkt. Ett konkret exempel visas i en robotmodell där två robotar interagerar i ett monteringsscenario. Sekvenserna T1 T2 T3 T4 och T4 T1 T2 T3 leder båda till samma markering, vilket visar diamant-egenskapen i praktiken. Trots att det finns 1024 möjliga markeringar i teorin, är endast 28 faktiskt nåbara från starttillståndet.

Genom analys av räckviddsgrafen kan man identifiera ineffektiva arbetsmönster. Exempelvis kan en robot avvakta tills en annan är helt färdig innan den påbörjar sitt arbete – en uppenbar ineffektivitet. Dessa mönster visualiseras tydligt i grafen och bör beaktas i systemets slutliga design.

Om simuleringen för att generera alla nåbara tillstånd inte avslutas kan det tyda på en allvarlig brist i designen. Ett verkligt system bör inte ha ett oändligt antal tillstånd. Ett nät där varje plats har en övre gräns för antal markörer, oberoende av avfyrningssekvens, säkrar att antalet tillstånd förblir ändligt. Detta är en grundförutsättning för att modellen ska vara hanterbar och realistisk.

För att göra analysen fullständig måste man ta hänsyn till följande: hur parallella övergångar samverkar, om och när systemet kan nå ett dödläge, samt huruvida det finns sekvenser som leder till oönskade tillstånd även om de tekniskt är nåbara. Att förstå skillnaden mellan möjlig och meningsfull räckvidd är avgörande för en robust systemkonstruktion. Slutligen bör varje kapacitetsgräns ses som en designparameter – inte bara en teknisk begränsning – vilket innebär att valda kapaciteter måste förankras i realistiska krav, inte i modellörens bekvämlighet.

Hur man beräknar stationära lösningar för stokastiska Hamiltonsystem
Hur omställning av läkemedel kan påverka neurodegenerativa sjukdomar
Hur kan matematisk modellering och simulering förklara frysning av överkylda vattendroppar i olika miljöer?