Använda e-pappersdisplayer för att indikera allvarliga fel och äventyrad säkerhet i kritiska IoT-noder

IoT- och IIoT-noder används i allt säkrare system där säkerheten hos nätverket som helhet är viktigare än funktionaliteten hos de enskilda enheterna i det nätverket. Detta innebär att om en IoT-nod upptäcker att den kan ha utsatts för angrepp, eller om ett irreparabelt firmwarefel skulle inträffa, kan den säkraste åtgärden vara att noden slås av så snart som det är praktiskt möjligt för att skydda noden och nätverket från potentiellt farliga konsekvenser.

Men när noden är avstängd går allt flyktigt minnesinnehåll förlorat. Att lagra felsökningsdata i icke-flyktigt minne som EEPROM eller Flash tar tid och kraft, vilket ökar risken för potentiell skada. Dessutom kan systemet ha äventyrats till en punkt där avläsningen av data vid uppstart inte levererar tillförlitlig data om uppstartssekvensen också har äventyrats.

Den här artikeln förklarar hur e-pappersdisplayer (EPD) enkelt kan kopplas till en IoT- eller IIoT-nod för att visa det senast kända felet, vilket ger en visuell indikation på orsaken till avstängningshändelsen så att tekniker kan vidta lämpliga åtgärder. Sedan ges exempel på e-pappersdisplayer från Pervasive Displays och Display Visions och diskuterar hur dessa displayer kan kopplas till en microcontroller och konfigureras för att tillhandahålla diagnostikinformation samtidigt som drar mycket lite eller ingen ström.

IoT- och IIoT-noder med hög säkerhet

Det vilar allt mer på konstruktörerna av IoT- och IIoT-noder att få alltmer sofistikerade säkerhetsmetoder på plats, för att garantera önskad funktion på värdmicrocontrollern. I allmänhet finns det tre typer av säkerhetshot som måste pareras:

1. Ett fel på microcontrollerns firmware
2. Ogiltig inmatad data från sensorer, knappsatser, seriell kringutrustning eller andra externa enheter
3. Åtgärder från en illvilliga externa aktörer

Ett microcontrollers firmwarefel kan uppstå av flera anledningar: kodfel i installerad firmware, ogiltiga beräkningar som leder till ett fel eller, i extremt sällsynta fall, ett maskinvarufel på microcontrollern. Välskriven firmware upptäcker vanligtvis detta genom att noga rensa ingångsdata med underrutiner och funktioner. I extrema fall där firmware är låst eller loopad kommer en watchdog-timeout återställa firmware genom att vektorera till en felkontrollerande underrutin eller genomföra en hård reset av microcontrollern.

I händelse av ogiltig inmatad data, till exempel om en extern sensor fungerar felaktigt eller är manipulerad, kan data utanför förväntade intervall ge resultat som det inte har tagits höjd för i applikationskoden. Om exempelvis omgivningstemperatursensorn i ett kontrollrum med människor felaktigt registrerar 250 ° F kan detta vara ett sensorfel eller skadlig manipulation. En slarvig firmwareprogrammerare kanske inte har kodat rätt för den höga temperaturavläsningen, vilket kan leda till något så trivialt som felaktig dataloggning eller något så allvarligt som att ge en inkräktare tillgång till ett säkert område eller så kritiskt som ett fel i en styralgoritmberäkning som kan leda till utrustningsfel eller allvarlig personskada. De potentiella negativa resultaten är många.

Med illasinnande externa aktörer förhåller det sig annorlunda, då dessa kan ha för avsikt att få IoT-noden att haverera. Fel som beror av hackningsförsök kan upptäckas av säkerhetsrutiner som ett intrång; de kan dock också dölja sig som firmwarefel eller ogiltig extern ingångsdata. Exemplet med en omgivningstemperaturavläsning på 250 °F kan orsakas av en skadlig aktör som testar firmware-beteende vid ett så högt värde med avsikt att testa en intrångsmetod. Exempelvis kan dörrarna automatiskt låsas upp om en avläsning på 120 °C omgivningstemperatur felaktigt klassas som en brand.

Reagera på firmwarefel

Oavsett felkällan måste microcontrollerns firmware vara felintolerant för IoT- och IIoT-noder där hög säkerhet krävs. Alla fel måste tas hänsyn till i koden och fångas upp. Ingångar till underrutiner och funktioner måste rensas och all sensoringångsdata valideras. Watchdog-timers måste programmeras med avsikt att detektera låst eller loopad kod som tar för lång tid baserat på en känd körtid.

När ett fast programvarufel upptäcks i en IoT- eller IIoT-nod med hög säkerhet, oavsett om felet är oavsiktligt eller medvetet, måste firmware fånga händelsen så snart som möjligt. Vanliga åtgärder inkluderar försök att kompensera för felet. För en sensor som inte fungerar som den ska, kan den inbyggda programvaran ha ett "halt läge" för den sensorn för att kompensera för dåliga data tills den kan bytas ut. En firmware-rutin som returnerar felaktiga resultat kan återinitieras. Ofta skickas en felkod över nätverket för att meddela nätverksvärden om problemet.

I vissa IoT- eller IIoT-noder med hög säkerhet finns det emellertid en speciell kategori av funktionsstörningar för vilka det inte kan eller inte bör finnas kompensation eller motåtgärder. Detta kan inkludera fysisk upptäckt, interna kontrollsummafel, vissa inbyggda självtestfel (BIST) och eventuella fel som kan orsakas av komprometterad firmware eller ett hackat system. För dessa högsäkerhetssituationer kan det enda alternativet vara att stänga av noden omedelbart och säkert. Nätverksvärden kommer att bestämma att noden har stängts av när den inte svarar på nätverksförfrågningar. Om noden slås av utan att skicka en felrapport till värden och om noden ignorerar nätverkskommandon för att starta om, är det en indikation på att ett allvarligt fel har inträffat och att en tekniker måste skickas för att fysiskt undersöka noden för orsaken.

Men när noden har stängts av raderas allt flyktigt minne och statusdata omedelbart. Detta gör diagnos av orsaken till avstängningen mycket svår, om inte omöjlig. Alternativt, innan du stänger av noden, kan diagnostiska data lagras i icke-flyktigt minne, såsom EEPROM eller flashminne. Problemet är att det tar tid att skriva till dessa typer av minne, under vilken noden måste förbli aktiv och eventuellt resultera i ytterligare skador.

Diagnostisera dödliga fel med e-papper

EPD: er drar mycket lite ström och kan användas för att lagra och visa fel- och diagnosinformation precis innan noden slås av. När noden är avstängd kan EPD bibehålla sin visningsbild utan ström i dagar eller veckor. Informationen på skärmen ger tekniker en visuell indikation på orsaken till avstängningen, så att de kan bestämma om det är säkert att slå på IoT-noden eller om den ska tas bort från nätverket för detaljerad analys.

Ett exempel på en EPD som är lämplig för att visa diagnostisk information är Pervasive Displays ' E2271CS091 EPD-modul. Den gränssnitt till vilken kompatibel mikrokontroller som helst med ett SPI-seriellt gränssnitt och har en 2,71 tum (in.) Skärm med hög kontrast (Figur 1).

Figur 1: E2271CS091 EPD-modulen har en kontrast på 2,71 tum med en upplösning på 264 x 176 pixlar. Den har en bred betraktningsvinkel och gränssnitt till alla kompatibla mikrokontroller med ett SPI-gränssnitt. (Bildkälla: Pervasive Displays)

E2271CS091 EPD-modulen använder en aktiv matris-tunnfilmtransistor (TFT) -skärm med en naturlig upplösning på 264 x 176 pixlar vid 117 punkter per tum (dpi). Detta gör att skärmen kan innehålla mycket information för att hjälpa tekniker vid diagnostik. Antireflexskärmen har en bred betraktningsvinkel på nästan 180˚, vilket möjliggör enkel visning av skärmen på ovanliga monteringsplatser. EPD kräver en 3,0 volt strömförsörjning.

Värdmikrokontrollern skickar data till EPD via ett SPI-gränssnitt på bildskärmens 24-stifts bandkontakt. SPI-datakommunikationen är bara ett sätt, från värdmikrokontrollern till EPD. Den enda kommunikationen från EPD till värdmikrokontrollern är en ”enhets upptagen” stift på bandkontakten, vilket förenklar gränssnittet kraftigt och ökar förtroendet för de diagnostiska data som visas.

Om ett fel eller hackförsök upptäcks, och om felet är tillräckligt allvarligt för att kräva en avstängning av noden, måste felet först fångas av firmware, vakthund eller annan metod. Kontrollen måste sedan överföras till felloggningsrutinen som skickar data till EPD. Denna rutin för felloggning bör vara den högsta prioriterade uppgiften för att förhindra avbrott eller korruption av data. För maximal tillförlitlighet rekommenderas att felloggningsrutinen är helt oberoende, utan anrop till externa underrutiner eller funktioner. Helst bör felloggningsrutinen vara i permanent skrivskyddad Flash för att garantera kodens integritet, även efter firmwareuppdateringar.

Innan EPD:n uppdateras med feldatan, bör värdmicrocontrollerna först skicka ett mjukt återställningskommando över SPI-gränssnittet till EPD:n för att rensa displayen. Den skickar sedan den svartvita visningsinformationen i en serie bytesekvenser, där varje bit i en byte representerar en pixel på EPD:n. När sekvensen är klar kan felloggningsrutinen stänga av microcontrollern. Olika tillverkare av microcontrollers har olika sätt att stänga av sig, eftersom detta är beroende av arkitektur och tillverkare. I vissa situationer, och grundat på säkerhetsskäl, kan tillverkaren ha ett odokumenterat sätt att stänga av microcontrollern, som endast är tillgängligt på begäran. Alternativt kan en extern krets användas för att avbryta strömmen till microcontrollern; detta ökar dock systemets komplexitet, vilket minskar tillförlitligheten. Därför är firmwarekontrollerad avstängning av microcontrollern.

För att underlätta användning av EPD:er, erbjuder Pervasive Displays EPD-expansionssatsen B3000MS034 (figur 2). Den har ett expanssionskort med en kontakt för en 24-stifts EPD, samt kontaktdon för andra Pervasive Display EPD som kräver 40-stifts och 26-stifts kontakter. Expansionskortet är kompatibelt med Texas instruments utvecklings- och utvärderingssatser LaunchPad, men kan också användas med andra utvecklingssatser. En 20-stifts bryggkabel kan anslutas till den rätvinkliga 20-stifts huvudkontakten, som när den löds på expansionskortet låter styrsignaler till EPD:n övervakas under utvecklingsfasen.

Figur 2: Expansionssatsen för Pervasive Displays E2271CS091 EPD-modul innehåller en 24-stifts kontakt på expansionskortet för displayens 24-stifts bandkabel. Den innehåller också en bryggkabel och en rätvinklig 20-stifts huvudkontakt. (Bildkälla: Pervasive Displays)

Ett annat EPD-alternativ är Display Visions EA EPA20-A (Figur 3).

Bild 3: Display Visions EA EPA20-A EPD är en 172x72-skärm som kan bibehålla displaystatusen utan ansluten ström. (Bildkälla: Display Visions)

Denna EPD har en 172 x 72 gråskärm och använder också ett SPI-gränssnitt för kommunikation med en värdmicrocontroller. EPD har extremt låg effekt, vilket kräver en enda 3,3 volts strömförsörjning och den drar endast 40 milliwatt (mW) under bildväxling på displayen. Display Visions EA EPA20-A EPD kan också bibehålla displayvisningen när ingen ström dras.

Slutsats

IoT- och IIoT-noder med hög säkerhet måste ibland stängas av som svar på ett dödligt firmwarefel eller upptäckt hot. Detta kan leda till förlust av all flyktig data, inklusive intern status för värdmicrocontrollern. Status- och diagnostikdata kan dock skickas till en ansluten EPD före avstängningen och visas i dagar eller veckor. Detta ger tekniker den information de behöver för att fastställa orsaken till avstängningen och om nödvändigt vidta framtida försiktighetsåtgärder för att skydda och säkra noden och nätverket.