Wróć

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

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.
Opublikowano: 2020-11-18

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ć:

  • Awaria oprogramowania układowego mikrokontrolera
  • Nieprawidłowe dane wejściowe z czujników, klawiatur, szeregowych urządzeń peryferyjnych lub innych urządzeń zewnętrznych
  • 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.

Strona: 1/2
https://jm.pl/pl/rocktouch-opis-strony/
https://jm.pl/pl/rocktouch-opis-strony/