Inom Internet of Things (IoT) representerar olika nivåer en hierarki av funktioner som möjliggör datainsamling, kommunikation, bearbetning och beslutstagande i distribuerade system. Den första nivån, ofta kallad "Level 1" eller kantnivån, består av enskilda enheter, så kallade edge nodes, som kan vara allt från enkla mikrochip-sensorer till hela fordon eller större system. Dessa enheter har förmågan att generera data och reagera på meddelanden från kommunikationsnivån. De kan också utföra lokala omvandlingar, exempelvis att konvertera en analog temperaturmätning till en digital värde som är lättare att tolka. I denna nivå finns inga ytterligare restriktioner; en nod kan agera självständigt eller som svar på en extern kommando.

Nivå 2, kommunikationsnivån, hanterar både vertikal och horisontell dataöverföring. Vertikalt sköts utbyte av data mellan kantnivån och högre nivåer, samt kommunikation mellan olika kantnoder. Horisontellt sköts transporten av data över olika nätverksprotokoll, routing, säkerhet och tillförlitlighet. Denna nivå inkluderar dock inte intern kommunikation inom en enhet, som exempelvis en CAN-buss i en bil, utan är fokuserad på nätverkskommunikation mellan enheter och system. Modellen bygger på befintliga nätverksprotokoll men medvetandegör att framväxten av nya enhetstyper kan kräva nya kommunikationsparadigm.

Nivå 3, fog computing, är ansvarig för lokal bearbetning och analys av data för att möjliggöra snabba beslut nära källan. Här sker aggregering av data, filtrering av irrelevanta data och sammansättning av information från olika källor för att skapa meningsfulla insikter. Exempelvis kan en temperatursensor i ett rum fatta beslut om att aktivera en luftkonditionering utan att involvera högre nivåer, medan en sammantagen temperaturökning i en byggnad kan kräva mer omfattande åtgärder som att kontakta underhåll eller räddningstjänst, vilket fog computing kan hantera. Detta nivåval av bearbetning nära källan minskar latens och minskar nätverksbelastning.

Nivåerna 4 till 7 handlar om lagring, långsiktig analys och mänsklig interaktion. Nivå 4 och 5 tar hand om datalagring och transformation av information för effektiv arkivering, ofta i distribuerade databaser eller molntjänster. Nivå 6 sysslar med avancerad dataanalys och tillämpningar som ofta drivs av maskininlärning eller annan komplex bearbetning. Nivå 7 inkluderar mänsklig inblandning och beslutsfattande baserat på analyser på de lägre nivåerna. För den som designar inbyggda system är dessa högre nivåer av intresse främst som kontext för hur genererade data kan komma att användas, snarare än som direkt påverkan på systemdesign.

Modellen är främst logisk snarare än fysisk. Många moderna system har integrerade kommunikationsmoduler, såsom trådlös nätverksfunktionalitet, som suddar ut gränserna mellan nivåerna. Till exempel kan en enkel sensor med trådlös uppkoppling ha både nivå 1- och nivå 2-funktioner. Om noden också innehåller datalagring och analysfunktioner kan den även innefatta nivå 3-egenskaper. Denna flexibilitet möjliggör modulär programvaruarkitektur där känslighet och styrning hanteras i separata moduler från kommunikationshantering och datalagring.

Inbyggda system är ofta hierarkiska med sub-system som själva kan betraktas som separata nivå 1-enheter. Kommunikation mellan sådana sub-moduler kan betraktas som intern kommunikation från det övergripande systemets perspektiv men som nivå 2-kommunikation sett ur ett nätverksperspektiv. Denna mångfacetterade struktur ställer krav på säkerhet och integritet, och begränsning av sub-modulers kommunikation utanför systemet kan vara avgörande för att säkra hela lösningen.

Utöver dessa arkitekturmodeller finns referenser som INTEL:s IoT-modell som kompletterar förståelsen med fokus på affärsplanering och dataflöde inom ett företag. Den betonar vikten av att dataflöden och säkerhet ska genomsyra alla nivåer, och att utvecklare behöver verktyg för att designa och implementera funktioner på varje nivå. Den påminner också om att data ofta delas med tredje part, men att kontroll och säkerhet måste bevaras strikt inom organisationen.

Det är viktigt att förstå att IoT-system är mycket mer än bara sammankopplade enheter; de är komplexa ekosystem med olika nivåer av datainsamling, bearbetning och beslutstagande. Varje nivå har sin egen roll och krav, och de samverkar för att möjliggöra snabba och säkra beslut nära källan såväl som omfattande analyser på högre nivåer. För att skapa robusta och skalbara IoT-lösningar måste designers och ingenjörer beakta hela denna hierarki och dess samverkan, samt integrera säkerhetsaspekter genom hela systemet.

Hur kan vi säkerställa att en brokontrollsystem uppfyller alla krav genom formell verifikation och validering?

Verifikation och validering är grundläggande processer när man utvecklar och verifierar system som styr kritiska infrastrukturer, som till exempel brokontrollsystem. I detta avsnitt undersöker vi en metod för att säkerställa att systemet uppfyller sina krav genom en formell verifikationsmetod, som ofta inkluderar en induktiv bevisprocess. Induktionsbevis är en teknisk metod för att bevisa att ett system alltid kommer att uppfylla vissa egenskaper under alla möjliga förhållanden, baserat på dess design och de regler som styr dess funktion.

I ett finit tillståndsmaskinsystem (FSM) eller Petri-nätmodell, kan varje tillstånd S ha en associerad egenskap P som ska vara sann när systemet befinner sig i detta tillstånd. För att bevisa att P alltid gäller när systemet är i tillstånd S, bevisar vi två saker: För det första, att P är sann när S nås för första gången, och för det andra, att om P är sann när systemet är i tillstånd S, så kommer P även att vara sann nästa gång S nås. Genom att kombinera dessa två bevis kan vi garantera att P alltid håller i S.

I vårt exempel använder vi en modifierad FSM för brokontroll, där systemet styr barriärer och brospänn vid passage av båtar. Vi förenklar exemplet genom att inte använda en hierarkisk FSM, men vi inkluderar ändå flera olika scenarier som kan uppstå, inklusive tidkrav som är nödvändiga för att säkerställa att säkerhetsprotokoll följs korrekt. Till exempel, när en båt upptäcks, ska barriärerna på marken sänkas inom 10 sekunder. Om detta inte inträffar inom den angivna tidsramen, måste båten stanna och polisen ska kontaktas. Brospannet får inte höjas förrän polisen har anlänt, blockerat marktrafiken och rensat eventuella bilar och fotgängare från bron.

Om barriärerna däremot sänks inom de 10 sekunderna, ska marktrafiken rensas från bron inom 90 sekunder. Om detta inte sker inom tidsgränsen måste båten stanna, och brooperatören ska undersöka vad problemet är. Först när bron är rensad och säkrad, får brospannet höjas och båten kan få signalen att fortsätta sin färd.

Ett brokontrollsystem kräver noggrann tidskoordination och säkerställande av att alla säkerhetsåtgärder vidtas innan några ytterligare steg kan tas. För att kunna bevisa att dessa krav hålls, måste man ta hänsyn till olika faktorer, som den maximala hastigheten för båtar, båtens stopp- och starttider, samt hur långt borta från bron sensorerna för båtarna är.

För att konkretisera detta kan vi titta på en tänkt situation där brospannet måste börja höjas minst 30 sekunder innan en båt når bron. Beviset för att denna egenskap håller för designen kräver en kombination av världskunskap (t.ex. båtens hastighet på floden), systemkunskap (t.ex. hur lång tid det tar för barriärerna att sänkas) och den tidsinformation som finns i FSM-modellen. Antag att båten upptäcks minst 150 sekunder innan den når bron, att den kan stanna inom 5 sekunder efter signal och att piloten omedelbart reagerar på stopp-signalen. Då kan vi bevisa att båten alltid är minst 30 sekunder bort från bron när tillstånd P4 nås.

Genom att analysera de tre möjliga vägarna från tillstånd P1 till P4 kan vi bevisa att varje väg resulterar i att båten är tillräckligt långt från bron. För exempelvis väg 1 (P1-P3-P4) innebär detta att när P3 nås har minst 140 sekunder återstått, vilket innebär att båten är minst 50 sekunder från bron när tillstånd P4 nås.

En annan metod för att bevisa konjekturen är att använda bakåtresonemang. Här skulle man börja från tillstånd P4 och arbeta bakåt för att förstå hur systemet kan nå P4, med samma tidsanalyser som i framåtbevisningen, men med omvänd ordning på beräkningarna.

En viktig del av processen är också att identifiera potentiella motexempel. Om en komponent i modellen, som signalen för att stoppa båten, inte fungerar korrekt, kan vi konstruera ett motexempel som visar att konjekturen inte håller. Ett exempel kan vara om barriärerna inte sänks som de ska, vilket leder till att polisen inte kan hinna fram i tid och båtens passage försenas eller till och med orsakar en olycka.

En annan viktig aspekt är validering – att säkerställa att systemet faktiskt uppfyller kundens och användarens krav. Validering handlar om att kontrollera den externa funktionaliteten och säkerställa att systemet lever upp till sina krav, inte bara på pappret utan också i praktiken. Ett system som inte uppfyller dessa krav kan aldrig anses vara fullt fungerande, även om det tekniskt sett har genomgått verifikation.

För att få en heltäckande bild av systemets tillförlitlighet, är det därför viktigt att både verifikation och validering genomförs parallellt, för att säkerställa att varje del av systemet fungerar korrekt under alla tänkbara förhållanden.

Hur man använder uppgiftsgrafer och linjär programmering för att optimera hårdvaruimplementeringar

Uppgiftsgrafer är ett kraftfullt verktyg för att förstå och optimera systemdesign, särskilt när man arbetar med inbäddade system. De erbjuder en visuell representation av alla uppgifter som måste genomföras inom ett visst system, och de hjälper till att identifiera de bästa sätt att implementera dessa uppgifter på olika hårdvaruplattformar. Uppgiftsgrafer ger både en översikt över uppgifternas beroenden och hur dessa uppgifter kan delas upp, grupperas eller mappas till hårdvara och mjukvara.

En uppgiftsgraf kan till exempel visa att vissa uppgifter bör implementeras på samma plattform, som när en uppgift som att "sänka barriären" kräver att samma fysiska enhet används som en annan uppgift, till exempel att "höja barriären". Å andra sidan kan det vara fördelaktigt att separera andra uppgifter om de inte är direkt relaterade till varandra. Till exempel kan uppgiften att "låta larmet ljuda" och uppgiften att "sänka barriären" ha olika krav på hårdvaran och kan implementeras på olika enheter beroende på hur systemet är uppbyggt.

Uppgiftsgrafen kan också ge insikter om uppgifter som vanligtvis inte ses som relaterade men som ändå kan implementeras på samma plattform. Om uppgifter som "höja brospannet", "sänka brospannet" och "känna av båtens passage" exempelvis sker i sekvens och inte kräver andra uppgifter, kan det vara klokt att slå samman dessa uppgifter i en enda modul, även om de initialt inte verkar relatera till varandra. Detta kan resultera i en annan lösning än den som först tänktes, där sensorn för båtens passage kanske fysiskt var åtskild från motorstyrningen.

En annan viktig aspekt av uppgiftsgrafer är att de kan inkludera realtidskrav, kommunikationsflöden och resursanvändning, vilket är avgörande för att kunna planera och mappa uppgifter på rätt sätt. Genom att annotera uppgiftsnoder med information om delade resurser eller realtidskrav, kan man få en tydligare bild av när och hur olika uppgifter kan utföras på samma plattform utan att överskrida systemets kapacitet.

Att analysera och dela upp uppgifter är en viktig del av processen för att optimera implementationen. Genom att exempelvis identifiera uppgifter som kan utföras parallellt, kan man dela upp en uppgift i flera delar som kan köras samtidigt på olika hårdvaruenheter. Detta kan ge större flexibilitet vid mappning av uppgifter till specifik hårdvara. Vidare kan man ibland sammanfoga uppgifter om de är mycket nära relaterade, vilket eliminerar behovet av att byta mellan uppgifter och minskar kommunikationskostnaderna.

En annan analysmetod är att använda heltalslinjär programmering (ILP) för att hitta de mest effektiva lösningarna för att mappa uppgifter till hårdvara och mjukvara. Denna metod kan hjälpa till att optimera systemdesign genom att identifiera de bästa tilldelningarna av uppgifter till specifika komponenter, samtidigt som man beaktar alla tekniska och resursmässiga begränsningar. Genom att formulera uppgifterna och deras beroenden som matematiska ekvationer och ojämlikheter, kan man använda ILP för att hitta en lösning som minimerar kostnader som energiförbrukning, minnesanvändning eller responstid.

ILP-modellen använder vanligtvis binär beslutsvariabler för att representera om en uppgift ska implementeras på en viss plattform, som en FPGA eller en mikroprocessor. Genom att analysera dessa variabler tillsammans med uppgiftens realtidskrav och hårdvarubegränsningar, kan man hitta den mest effektiva lösningen för systemet. Om det inte går att hitta en lösning som uppfyller alla krav kan det indikera att det föreslagna systemet behöver justeras, till exempel genom att välja mer kraftfull hårdvara eller genom att förändra uppgifternas uppdelning.

För att effektivt utnyttja uppgiftsgrafer och ILP i systemdesign är det viktigt att förstå att denna process är kreativ snarare än algoritmisk. Det handlar om att balansera olika faktorer och prioritera lösningar som bäst uppfyller de specifika kraven för systemet, snarare än att följa en strikt uppsättning regler.

När man arbetar med uppgiftsgrafer och ILP, är det också viktigt att ta hänsyn till den övergripande arkitekturen av systemet och de realtidskrav som ställs på det. För exempelvis inbäddade system som styr fysiska processer, måste man noggrant överväga hur uppgifter interagerar med fysiska enheter och hur dessa interaktioner påverkar systemets responsivitet och effektivitet. Detta innebär att designen måste vara flexibel nog för att kunna anpassas till förändringar i både tekniska krav och operativa förhållanden.

Vad kännetecknar integralkalkylens fundament i en variabel och dess kopplingar till kontinuitet och approximation?
Hur Blockchain Kan Förenkla Processer och Skapa Tillit Mellan Intressenter och Konsumenter
Hur ska man tänka vid lösning av problem och abstrahera i datorprogrammering?