Bezpieczeństwo w systemach autonomicznych

| Prezentacje firmowe Mikrokontrolery i IoT

Coraz większa popularność technologii sztucznej inteligencji (AI) i uczenia maszynowego (ML), będącego podstawą wielu nowoczesnych systemów elektronicznych, zwiększają zapotrzebowanie na inteligentniejsze systemy bezpieczeństwa. Jednocześnie potrzeby rynku przesuwają się z oszczędności kosztów na wygodę i bezpieczeństwo użytkowników. Wymaga to implementacji w aplikacjach warstwy bezpieczeństwa funkcjonalnego (FuSa), składającej się z koprocesora bezpieczeństwa z zaufanymi kontrolerami linii wejścia/wyjścia. Oba te bloki współpracują ze sobą w celu ochrony systemu. Do realizacji takiej funkcjonalności nadają się nowe mikrokontrolery, które stanowią serce dzisiejszej nowej generacji systemów autonomicznych.

Bezpieczeństwo w systemach autonomicznych

Funkcje bezpieczeństwa i specyfikacje

Koprocesory bezpieczeństwa realizują zaimplementowany model ML, który przetwarza zewnętrzne strumienie danych, w tym audio i wideo, informacje o otoczeniu i działaniach operatora. W zależności od potrzeb może być konieczne przetwarzanie jednoczesne wszystkich strumieni danych. Aby wydajność tego procesu była satysfakcjonująca, takie strumienie danych muszą pochodzić z zaufanych źródeł.

Co równie ważne, koprocesory bezpieczeństwa muszą ufać wiernemu odwzorowaniu stanów wyjściowych, które generują dla silników, przekaźników, wskaźników i innych elementów wykonawczych. Główny procesor systemu powinien także móc polegać na danych z kontrolerów wejścia/wyjścia, aby podejmować trafne, szybkie decyzje w przypadku awarii.

Mikrokontrolery jako koprocesory bezpieczeństwa

W omawianym aspekcie można wyróżnić cztery główne standardy branżowe. Wszystkie są obsługiwane przez kompletne ekosystemy programistyczne dostępne dla 8- i 32-bitowych mikrokontrolerów:

  • ISO262: obejmujący aplikacje dotyczące integralności bezpieczeństwa samochodowego (ASIL) w zastosowaniach motoryzacyjnych,
  • IEC 61508 definiujący poziomy nienaruszalności bezpieczeństwa (SIL) w zastosowaniach przemysłowych,
  • IEC 60730 opisujący normy bezpieczeństwa funkcjonalnego dla sprzętu gospodarstwa domowego,
  • IEC 60730 określający bezpieczeństwo funkcjonalne wyrobów medycznych.

Środowisko (ekosystem) narzędzi programistycznych wymaga realizacji dwóch ważnych zagadnień. Pierwsze z nich dotyczy trzymania się odpowiedniej praktyki kodowania podczas tworzenia oprogramowania, także podczas kompilacji programu do kodu maszynowego. Problem ten rozwiązuje się za pomocą kompilatorów bezpieczeństwa funkcjonalnego, które mają certyfikaty zgodności z normami bezpieczeństwa funkcjonalnego ISO lub IEC wydane przez organizacje takie jak TÜV SÜD, czyli międzynarodowe akredytowane instytucje testujące. Drugą funkcją jest szczegółowa analiza tego, jaki kod został wykonany, a jaki został pominięty podczas typowego cyklu testowego. Wymaga to dostępności wtyczki pokrywającej kod (coverage plug-in).

Jak działa to zapewnienie bezpieczeństwa?

Podstawowa interakcja ze światem zewnętrznym odbywa się poprzez warstwy sprzętowe, realizujące obsługę interfejsów do czujników i elementów wykonawczych przez mikrokontrolery obsługujące technologię Edge FuSa (rys. 1). Kluczowe funkcje obejmują:

 
Rys. 1. Autonomiczne funkcje bezpieczeństwa w 8-bitowych mikrokontrolerach

Wykrywanie zaników napięcia (Brown Out Detect, BOD). Bardzo niewiele urządzeń ma doskonałe zasilacze, a sprzęt taki jak kuchenki mikrofalowe lub drukarki laserowe, że wywołać krótkotrwałe zaniki zasilania. Elektronarzędzia dużej mocy często aktywują bezpieczniki w instalacji, wywołując awarie. Systemy elektroniczne a zwłaszcza urządzenia autonomiczne muszą wiedzieć, że ich zasilanie uległo awarii, zanim nastąpi jego zanik, po to, aby można było włączyć zasilanie rezerwowe lub ustawić bezpieczne stany na liniach danych i wyjściowych i potem zapewnić kontrolowane wyłączenie.

Detektor BOD zawarty w mikrokontrolerach w sposób ciągły monitoruje napięcie zasilania i reaguje na spadek jego wartości. Voltage Level Monitor (VLM) wyzwala przerwanie w przypadku przekroczenia wybranego potencjału progowego, umożliwiając awaryjne wyłączanie jeszcze przed osiągnięciem progu aktywacji BOD. Gdy napięcie zasilania obniży się jeszcze bardziej, aplikacja pozostanie w trybie reset do czasu przywrócenia napięcia. Możliwe jest również określenie przyczyny zdarzenia BOD, aby zapewnić optymalną reakcję, niekoniecznie polegającą na wyłączeniu wszystkiego, co się da lub wywołaniu resetu.

Timer z watchdogiem okienkowym. Nowoczesne mikrokontrolery wykorzystują watchdogi (specjalne timery) jako podstawy mechanizmu odzyskiwania działania systemu po awarii. Ich zadaniem jest m.in. zakończenie nieskończonych pętli lub stanu ciągłego oczekiwania, z którego nie ma wyjścia poza resetem. Dawniej ustawiało się limit czasu, po którym kod był resetowany i zadaniem programisty było przedłużać odliczanie timera watchdoga tak, aby do resetu w normalnych warunkach pracy nie doszło. To jest niełatwe, stąd wielu programistów po prostu okresowo resetowało stan licznika watchdoga w procedurze obsługi przerwania. Ale jeśli system zawiesił się w taki sposób, że przerwania działały, była to metoda nieskuteczna.

W dużej mierze ten problem rozwiązują watchdogi z okienkiem czasowym, w których licznika stanu nie można resetować zbyt często i za rzadko. Obsługa przez cykliczne przerwanie nie jest tu co do zasady możliwa.

Kontrola sumy CRC. Blok kontroli sumy kontrolnej CRC zapewnia integralność pliku obrazu z kodem programu. CRC zapewnia o wiele większe możliwości wykrycia przekłamań w danych niż zwykła suma kontrolna, którą można łatwo "oszukać". W realizacji praktycznej występuje specjalny blok sprzętowy zawarty w MCU, którego zadaniem jest skanowanie bootloadera w pamięci programu, kodu aplikacji lub całej pamięci Flash. Aplikacja może porównać obliczoną CRC (2 wartości 16-bitowe) z prawidłową wartością zamieszczoną np. na końcu kodu. Jeśli są one zgodne, oznacza to, że kod jest integralny, tj. nie został zmodyfikowany. Negatywny wynik kontroli można skonfigurować tak, aby generował niemaskowalne przerwanie w celu wywołania w kolejności rozwiązania problemu, np. przez wymuszenie pobrania firmware na nowo.

Linie GPIO typu "true input". Dawniej, gdy pin GPIO mikrokontrolera był skonfigurowany jako wyjście, jedynym sposobem sprawdzenia, czy poziom napięcia na odpowiadającym mu pinie (tj. 5 V) odpowiada wartości bitu sterującego (tj. "1"), było użycie dodatkowej linii GPIO skonfigurowanej jako wejście. Za jej pomocą można było odczytać poziom tego napięcia. Pin GPIO skonfigurowany jako wyjście nie mógł odczytać rzeczywistego napięcia, a jedynie wartość, która została na nim zapisana. Stąd wartość "wejściowa" zawsze się zgadzała.

Linie GPIO typu true path mają oddzielną ścieżkę elektryczną do wewnętrznego rejestru Input, który odzwierciedla rzeczywisty poziom logiczny ustawiony na pinie. Chociaż można go odczytać jedynie jako "1" lub "0", nadal taka informacja zwrotna jest użyteczna i pozwala potwierdzić to, co zostało zapisane w rejestrze kontrolnym Output. W stanie normalnym nigdy nie może być różnicy między tymi wartościami. Jeśli pojawi się niezgodność, będzie to oznaczać zwarcie lub przerwę w obwodzie wyjściowym i tym samym konieczność obsługi takiego zdarzenia.

Mikrokontrolery z takimi możliwościami stanowią podstawę kompletnej warstwy FuSa. Funkcjonalność taka będzie zyskiwać w przyszłości na znaczeniu w miarę popularyzacji automatyzacji opartej na sztucznej inteligencji/ ML, nacisku na oszczędności w produkcji i utrzymaniu systemów oraz z uwagi na potrzebę zapewnienia bezpieczeństwa i wygody użytkownikom.

 

Bob Martin, Senior Staff Engineer, Microchip Technology

Microchip
www.microchip.com