Wykorzystanie wyświetlaczy e-Paper do sygnalizacji błędów krytycznych oraz naruszeń zabezpieczeń w węzłach IoT o znaczeniu krytycznym

Węzły Internetu rzeczy (IoT) oraz przemysłowego Internetu rzeczy (IoT) są stosowane w coraz bezpieczniejszych systemach, gdzie bezpieczeństwo i zabezpieczenia sieci jako całości jest ważniejsze od funkcjonowania poszczególnych urządzeń w tej sieci. Oznacza to, że jeżeli węzeł IoT wykryje naruszenie bezpieczeństw lub gdy wystąpi niemożliwy do usunięcia błąd oprogramowania układowego, najbezpieczniejszym działaniem może być wyłączenie zasilania węzła tak szybko, jak to praktycznie możliwe, w celu ochrony węzła i sieci przed potencjalnie groźnymi konsekwencjami.

Jednakże po wyłączeniu zasilania węzła, cała zawartość pamięci ulotnej jest tracona. Zapisanie danych debugowania w pamięci nieulotnej, takiej jak EEPROM lub flash, wymaga czasu i zasilania, co zwiększa ryzyko potencjalnych szkód. Dodatkowo ingerencja w system mogła nastąpić w takim miejscu, że ponowny odczyt danych po włączeniu zasilania może nie zapewniać zaufanych danych, jeżeli nastąpiło również naruszenie sekwencji włączania zasilania.

Niniejszy artykuł opisuje łatwy sposób podłączania wyświetlaczy e-Paper (EPD) do węzłów IoT oraz IIoT w celu wyświetlenia ostatniego znanego błędu i wizualnego określenia przyczyny wyłączenia zasilania, dzięki którym technicy mogą podjąć odpowiednie działania. Podano również przykłady wyświetlaczy e-Paper oferowanych przez firmy Pervasive Displays oraz Display Visions, a także omówiono sposób współpracy tych wyświetlaczy z mikrokontrolerami i konfiguracji do wyświetlania informacji diagnostycznych przy braku zasilania lub minimalnym poborze mocy.

Węzły silnych zabezpieczeń IoT oraz IIoT

Na projektantach węzłów IoT oraz IIoT spoczywa coraz większa odpowiedzialność za wdrożenie coraz bardziej wyrafinowanych metod zabezpieczeń gwarantujących prawidłowe działanie mikrokontrolerów hosta. Generalnie istnieją trzy rodzaje zagrożeń dla bezpieczeństwa, przed którymi należy się zabezpieczyć:

1. Awaria oprogramowania układowego mikrokontrolera
2. Nieprawidłowe dane wejściowe z czujników, klawiatur, szeregowych urządzeń peryferyjnych lub innych urządzeń zewnętrznych
3. Szkodliwe działania osób

Awaria oprogramowania układowego mikrokontrolera może wystąpić z różnych powodów: błędy kodowania w zainstalowanym oprogramowaniu układowym; nieprawidłowe obliczenia skutkujące awarią; a w skrajnych przypadkach awaria sprzętowa mikrokontrolera. Dobrze napisane oprogramowanie układowe zwykle jest w stanie to wykryć dzięki szybkiej kontroli danych wejściowych dla podprocedur i funkcji. W skrajnych przypadkach, gdy oprogramowanie układowe zostało zablokowane lub działa w pętli, limit czasowy układu nadzorującego przywróci działanie oprogramowania układowego poprzez przekierowanie do podprocedury kontroli błędów lub wykonanie twardego resetowania mikrokontrolera.

W przypadku nieprawidłowych danych wejściowych, na przykład pochodzących z uszkodzonego czujnika zewnętrznego lub zmienionych w nieuprawniony sposób, dane spoza zakresu mogą nie być traktowane właściwie przez kod aplikacji. Na przykład: jeżeli czujnik temperatury otoczenia w sterowni, gdzie przebywają ludzie wskaże wartość 120°C, może to oznaczać usterkę czujnika lub złośliwą, nieautoryzowaną ingerencję. Lekkomyślny twórca oprogramowania układowego mógł nie zaprogramować odpowiednio ewentualności tak wysokich odczytów temperatur, co może prowadzić do tak trywialnych konsekwencji, jak rejestrowanie nieprawidłowych danych, tak poważnych, jak dostęp intruzów do obszarów zabezpieczonych, a nawet tak krytycznych jak błędy w obliczeniach algorytmów sterujących mogące prowadzić do awarii sprzętu lub poważnych obrażeń ciała. Możliwe są liczne negatywne konsekwencje.

Złośliwie działający intruz różni się tym, że może mieć umyślny zamiar spowodowania awarii węzła IoT. Awaria spowodowana próbą ataku może zostać wykryta przez procedury zabezpieczeń jako naruszenie, jednak może również być zamaskowana jako awaria oprogramowania układowego lub nieprawidłowe wejściowe dane zewnętrzne. Na przykład: odczyt temperatury 120°C może być spowodowany przez złośliwie działającego intruza, który testuje zachowanie oprogramowania układowego przy tak wysokim odczycie, z zamiarem przetestowania metody włamania. Przykładowo wykrycie temperatury otoczenia 120°C może zostać błędnie zinterpretowane jako pożar i spowodować automatyczne odblokowanie drzwi.

Reagowanie na awarie oprogramowania układowego

Bez względu na źródło błędu, oprogramowanie układowe mikrokontrolera węzłów silnych zabezpieczeń IoT oraz IIoT nie może tolerować usterek. Bezwzględnie wszystkie usterki muszą być odpowiednio uwzględnione w kodach i pułapkach. Dane wejściowe dla podprocedur i funkcji muszą być poddawane szybkiej kontroli, a wszystkie dane wejściowe z czujników muszą podlegać walidacji. Czasomierze układów nadzorujących muszą być zaprogramowane do wykrywania zablokowanych lub działających w pętli kodów, których wykonywanie trwa zbyt długo w stosunku do znanego czasu wykonywania.

W przypadku wykrycia awarii oprogramowania układowego w węźle silnych zabezpieczeń IoT lub IIoT, bez względu na to, czy usterka ma przyczynę przypadkową, czy umyślną, oprogramowanie układowe musi jak najszybciej umieścić to zdarzenie w pułapce. Powszechnie stosowane są próby skompensowania usterki. W przypadku uszkodzonego czujnika, który stale wykracza poza zakres, oprogramowanie układowe może posiadać tryb awaryjny dla tego czujnika, który kompensuje nieprawidłowe dane do czasu wymiany czujnika. Podprocedury oprogramowania układowego zwracające nieprawidłowe wyniki mogą być ponownie inicjowane. Często w sieci wysyłany jest kod błędu, który informuje hosta sieciowego o problemie.

Jednak w niektórych węzłach silnych zabezpieczeń IoT lub IIoT występuje specjalna kategoria usterek, dla których nie może lub nie powinna zachodzić kompensacja ani środki zaradcze. Może to obejmować wykrywanie ingerencji fizycznej, błędy wewnętrznych sum kontrolnych, niepowodzenia niektórych wbudowanych autotestów (BIST) lub dowolne inne usterki, które mogą być spowodowane przez narażone oprogramowanie układowe lub zaatakowany system. W sytuacji silnych zabezpieczeń, jedyną opcją może być natychmiastowe i bezpieczne wyłączenie zasilania węzła. Host sieciowy wykryje, że zasilanie węzła zostało wyłączone, gdy przestanie on odpowiadać na żądania sieciowe. Jeżeli zasilanie węzła zostanie wyłączone bez wysyłania raportu o błędzie do hosta, oraz gdy węzeł ignoruje polecenia sieciowe ponownego uruchomienia, sygnalizuje to wystąpienie krytycznej awarii i konieczność wysłania technika celem fizycznego sprawdzenia przyczyny w węźle.

Jednakże po wyłączeniu zasilania węzła, wszystkie dane statusu oraz pamięci ulotnej są natychmiast wymazywane. To sprawia, że zdiagnozowanie przyczyny wyłączenia jest trudne, a nawet niemożliwe. Opcjonalnie, przed wyłączeniem węzła dane diagnostyczne mogą zostać zapisane w pamięci nieulotnej, na przykład typu EEPROM lub flash. Problem polega na tym, że zapis do pamięci tego typu wymaga czasu, a węzeł musi wtedy pozostawać aktywny, co może prowadzić do dalszych szkód.

Diagnozowanie błędów krytycznych z użyciem papieru elektronicznego

Wyświetlacze e-Paper (EPD) zużywają bardzo mało energii i mogą być wykorzystywane do przechowywania i wyświetlania informacji o błędach i diagnostyce tuż przed wyłączeniem zasilania węzła. Po wyłączeniu zasilania węzła, wyświetlacz EPD może przechowywać wyświetlany obraz bez zasilania przez całe dnie lub tygodnie. Informacje na wyświetlaczu stanowią dla techników wizualne wskazówki dotyczące przyczyny wyłączenia, umożliwiając im podjęcie decyzji, czy włączenie zasilania węzła IoT jest bezpieczne, czy też należy go odłączyć od sieci celem szczegółowej analizy.

Przykładowym urządzeniem e-Paper nadającym się do wyświetlania informacji diagnostycznych jest moduł EPD E2271CS091 firmy Pervasive Displays. Współpracuje on ze wszystkimi zgodnymi mikrokontrolerami za pośrednictwem interfejsu SPI, posiada wyświetlacz o przekątnej 2,71 cala i wysokim kontraście (ilustracja 1).

Ilustracja 1: Moduł EPD E2271CS091 posiada wyświetlacz o przekątnej 2,71 cala, wysokim kontraście i rozdzielczości 264 x 176 pikseli. Charakteryzuje się on szerokim kątem widzenia i łączy się z kompatybilnymi mikrokontrolerami za pośrednictwem interfejsu SPI. (Źródło ilustracji: Pervasive Displays)

Moduły EPD E2271CS091 wykorzystują wyświetlacze z aktywną matrycą tranzystorów cienkowarstwowych (TFT) o rozdzielczości natywnej 264 x 176 pikseli, 117 punktów na cal (dpi). Dzięki temu wyświetlacz zawiera dużo informacji przydatnych technikom w diagnostyce. Ekran posiada powłokę przeciwodblaskową i charakteryzuje się szerokim kątem widzenia niemal 180˚, co ułatwia odczyt wyświetlaczy zainstalowanych nawet w nietypowych miejscach. Wyświetlacz EPD wymaga zasilania o napięciu 3,0V.

Mikrokontroler hosta wysyła dane do wyświetlacza EPD za pośrednictwem interfejsu SPI i 24-wtykowego złącza taśmowego wyświetlacza. Komunikacja danych SPI przebiega tylko jednokierunkowo od mikrokontrolera do wyświetlacza EPD. Jedyna komunikacja wyświetlacza EPD z powrotem do mikrokontrolera hosta odbywa się za pośrednictwem wtyku zajętości urządzenia na złączu taśmowym, co znakomicie upraszcza interfejs i zwiększa poziom ufności dla wyświetlanych danych diagnostycznych.

W przypadku wykrycia błędu lub próby ataku, jeżeli błąd jest na tyle poważny, że wymaga wyłączenia węzła, błąd musi być w pierwszej kolejności umieszczony w pułapce przez oprogramowanie układowe, układ nadzorujący lub inną metodę. Sterowanie musi zostać następnie przekazane do procedury rejestrowania błędów, która wysyła dane do wyświetlacza EPD. Ta procedura rejestrowania błędów musi być zadaniem o najwyższym priorytecie, aby zapobiec jej przerwaniu lub uszkodzeniu danych. Dla zapewnienia maksymalnej niezawodności, zaleca się, aby procedura rejestrowania błędów była całkowicie autonomiczna, bez odwołań do zewnętrznych podprocedur lub funkcji. W idealnym przypadku procedura rejestrowania błędów powinna znajdować się w pamięci flash trwale chronionej przed zapisem, aby zagwarantować integralność kodu nawet po aktualizacji oprogramowania układowego.

Przed zaktualizowaniem wyświetlacza EPD o dane błędów, mikrokontroler hosta powinien wcześniej wysłać do wyświetlacza EPD polecenie miękkiego resetu za pośrednictwem interfejsu SPI w celu wyczyszczenia wyświetlacza. Następnie wysyłane są czarno-białe informacje wyświetlania jako seria sekwencji bajtowych, w których każdy bit w bajcie reprezentuje jeden piksel na wyświetlaczu EPD. Po zakończeniu sekwencji, procedura rejestrowania błędów może wyłączyć mikrokontroler. Różni producenci mikrokontrolerów stosują różne metody wyłączania i są one uzależnione od architektury i producenta. W niektórych sytuacjach oraz ze względów bezpieczeństwa, producent może oferować nieudokumentowane sposoby wyłączania mikrokontrolera, dostępne tylko na zamówienie. Opcjonalnie można zastosować zewnętrzny obwód, który odłącza zasilanie mikrokontrolera, jednakże zwiększa to złożoność systemu, co z kolei obniża niezawodność. Z tego względu preferowane jest sterowanie wyłączaniem mikrokontrolera przez oprogramowanie układowe.

Aby wspomóc projektowanie z użyciem wyświetlaczy EPD, firma Pervasive Displays oferuje zestaw rozszerzeń EPD B3000MS034 (ilustracja 2). Posiada on płytkę rozszerzeń ze złączem dla 24-wtykowego wyświetlacza EPD oraz złączami dla innych wyświetlaczy EPD firmy Pervasive Displays, które wymagają złączy 40-wtykowych i 26-wtykowych. Płytka rozszerzeń jest kompatybilna z zestawami rozwojowymi i ewaluacyjnymi Texas Instruments LaunchPad, jednak może być używana również z innymi zestawami rozwojowymi. 20-wtykowy kabel łączący można podłączyć do 20-wtykowego złącza listwowego 90˚, które po przylutowaniu do płytki rozszerzeń pozwala na monitorowanie sygnałów dostarczanych do wyświetlacza EPD na etapie rozwojowym.

Ilustracja 2: Zestaw rozszerzeń dla modułu EPD E2271CS091 firmy Pervasive Displays zawiera 24-wtykowe złącze na płytce rozszerzeń, przeznaczone dla 24-wtykowego kabla taśmowego wyświetlacza. Zawiera on również kabel łączący oraz 20-wtykowe złącze listwowe 90˚. (Źródło ilustracji: Pervasive Displays)

Inną możliwą opcją jest wyświetlacz EPD EA EPA20-A firmy Display Visions (ilustracja 3).

Ilustracja 3: Wyświetlacz EPD EA EPA20-A firmy Display Visions posiada rozdzielczość 172 x 72 i podtrzymuje wyświetlany status bez podłączonego zasilania. (Źródło ilustracji: Display Visions)

Wyświetlacz EPD posiada ekran monochromatyczny 172 x 72 i również wykorzystuje interfejs SPI do komunikacji z kontrolerem hosta. Wyświetlacz EPD pobiera bardzo niewielką moc, wymagając pojedynczego zasilania 3,3V i zużywa zaledwie 40mW mocy podczas zmiany wyświetlania. Wyświetlacz EPD EA EPA20-A firmy Display Visions podtrzymuje wyświetlane informacje przy braku zasilania.

Podsumowanie

Czasami zachodzi potrzeba wyłączenia zasilania węzłów silnych zabezpieczeń IoT oraz IIoT w odpowiedzi na krytyczny błąd oprogramowania układowego lub wykryte zagrożenie. Może to skutkować utratą wszystkich danych z pamięci ulotnej, w tym danych o statusie wewnętrznym mikrokontrolera hosta. Dane diagnostyczne i dotyczące statusu mogą jednak zostać wysłane do podłączonego wyświetlacza EPD przed wyłączeniem, który może je wyświetlać przez całe dni lub tygodnie. Dostarcza to technikom informacji niezbędnych do ustalenia przyczyny wyłączenia i zastosowania środków zapobiegawczych w przyszłości, jeśli to konieczne dla ochrony i zabezpieczenia węzła oraz sieci.