Podczas Embedded World jednym z często powtarzających się tematów były systemy operacyjne czasu rzeczywistego, czyli RTOSy. Nie zabrakło także Linuxa. W tym wpisie opiszę kilka prezentacji na ten temat.
Jakob Benningo – „42 Reasons Using FreeRTOS Should Scare Developers”
Tytuł prezentacji był trochę click-baitowy. Większość z tych 42 powodów nie była jakaś wielce odkrywcza. Poza tym często nie były to wcale argumenty przeciwko FreeRTOSowi, tylko ogólne informacje dotyczące działania RTOSów.
FreeRTOS wykorzystuje dynamiczną alokację pamięci. Mamy do wyboru kilka różnych strategii alokacji takie jak np. tylko alokacja bez zwalniania, korzystanie z wrapperów na malloc z biblioteki standardowej, czy implementacja alokacji ze zwalnianiem i łączeniem zwolnionych bloków. Od niedawna FreeRTOS umożliwia też statyczną alokację pamięci. o ile nasz system ma długo działać bez restartu, powinniśmy unikać dynamicznej alokacji.
Jeżeli chodzi o performance, to płatne RTOSy często osiągają zdecydowane lepsze wyniki. Autor podpierał się benchmarkiem z THREAD Metric Benchmark Test Suite pokazującym 300% lepszą wydajność płatnego ThreadX od darmowego FreeRTOSa. Jednak benchmark może być trochę tendencyjny, skoro robiła go ta sama firma co system ThreadX.
Ciekawą obserwacją był fakt, iż producenci procesorów w swoich bibliotekach i notach aplikacyjnych często umieszczają przestarzałe wersje FreeRTOSa. Dlatego powinniśmy zawsze ściągać najnowszą wersję bezpośrednio z oficjalnej strony projektu. Jest to szczególnie ważne w dobie IoT i znalezionych luk bezpieczeństwa we FreeRTOSie.
Wybierając RTOS do projektu zespół powinien kierować się wieloma czynnikami. Nie tylko tymi rzucającymi się w oczy jak dostępne funkcje, performance i wcześniejsze doświadczenie developerów z systemem. Powinniśmy również brać pod uwagę np. kwestie prawne (czy mogę użyć kodu open-source w swoim projekcie), portowalność, czy koszty utrzymania. To ostatnie może mieć znaczenie w systemach safety, gdzie mimo, iż program jest darmowy, musimy zapewnić odpowiednią dokumentację i testy. Wtedy często lepszym rozwiązaniem będzie RTOS dedykowany pod safety-critical. W dokonaniu wyboru może nam pomóc tabela w excelu z odpowiednimi cechami RTOSa i ich wagami. Niestety nie znalazłem tego excela na stronie autora. Mam tylko zdjęcie z prezentacji.
Andrew Longhurst – Safety Critical RTOS: Adapting Across Applications
Kolejna prezentacja była prowadzona przez przedstawiciela WITTENSTEIN, czyli firmy rozwijającej SafeRTOSa. Tematem było dostosowanie RTOSa do aplikacji safety-critical. Po pierwsze taki RTOS musi spełniać normy. SafeRTOS wyewoluował z FreeRTOSa, który nie był rozwijany z myślą o systemach safety-critical. Dlatego aby stworzyć SafeRTOSa wzięto API z FreeRTOSa i potraktowano je jako wymagania, a następnie zaimplementowano je od zera zgodnie z V-modelem wykonując wymagane czynności związane z planowaniem, dokumentacją i testowaniem.
Trochę miejsca poświęcono kompilacji RTOSa na docelowy procesor. Nie tylko kod źródłowy musi spełniać odpowiednie standardy, ale również kompilator. Najczęściej popularne kompilatory są uznawane jako „proven in use”. Zakłada się, iż mają wystarczająco dużą bazę użytkowników i są wystarczająco dojrzałe. Nie mając pewności co do kompilatora, musimy przeprowadzić pełne testy zapewniające odpowiedni code coverage MC/DC.
Jean Labrosse – Uncovering Real-Time bugs with specialized RTOS tools
Kolejna prezentacja była prowadzona przez autora systemu operacyjnego Micrum uC/OS. Skupiała się na pokazaniu jak graficzne toole monitorujące pracę RTOSa wspomagają wykrywanie typowych błędów takich jak:
- przepełnienie stosu,
- zagłodzenie wątku,
- deadlock,
- zbyt duże zużycie CPU,
- problemy z sekcjami krytycznymi.
Jeżeli używamy do debugowania takich problemów dedykowanych tooli, możemy zaoszczędzić ogromne ilości czasu. Nie musimy szukać informacji o każdym tasku w podglądzie pamięci w debugerze. Zamiast tego mamy wszystkie liczby na jednym ekranie, a do tego jakieś grafy, oś czasu i inne bajery. Przykłady były na dedykowanym toolu do uC/OS. Istnieją również alternatywne narzędzia jak Percepio Tracealyzer, czy Segger SystemView.
Tego typu narzędzia graficzne pokazują:
- procentowe zużycie CPU każdego wątku,
- zużycie stosu każdego wątku,
- ilość wywołań wątku,
- długość przebywania w sekcji krytycznej,
- ilość wejść do sekcji krytycznej przez każdy wątek,
- wykorzystanie CPU na osi czasu,
- przepływ sterowania między taskami, kolejkami, muteksami itp.
Prezentacja przy okazji może być dobrym wprowadzeniem do typowych problemów w systemach operacyjnych. Mogę ją śmiało polecić jako wprowadzenie do tematu. Szkoda, iż nie mogłem jej nigdzie znaleźć w sieci.
Nicolas McGuire – Using Linux in Safety-Critical Environments: Update on SIL2LinuxMP Project
Ostatnia prezentacja, jaką opiszę dotyczyła Linuxa i próby utworzenia dystrybucji certyfikowanej do wykorzystania w systemach safety. Pracuje nad tym specjalna grupa i autor prezentacji jest właśnie przewodniczącym tej grupy.
Certyfikacja Linuxa jest wielkim wyzwaniem. RTOSy wykorzystywane najczęściej w systemach safety-critical mają zwykle 10k-50k linii kodu. Zwykle powstają też w całości w jednej organizacji pisane przez stosunkowo niewielki zespół programistów. Można więc odpowiednio zarządzać procesem wytwarzania oprogramowania, dokumentować, reviewować, testować, czy certyfikować. Linux jest kompletnym przeciwieństwem takiego systemu. Baza kodu Linuxa jest niemożliwa do ogarnięcia dzięki zwykłego V-modelu. Kod jest liczony w milionach linii, a kontrybutorzy w tysiącach. Normy nie zostały przystosowane do takiego przypadku, dlatego jej zapisy nie nadają się do bezpośredniego zaaplikowania. Trzeba je odnosić do specyficznego kontekstu. Poza tym często są niejednoznaczne, czy ogólnikowe. Na potrzeby certyfikacji Linuxa zaadaptowano pewne techniki z norm lotniczych oraz wykorzystuje się zmienioną wersję V-modelu pasującą do dostosowywania istniejącego oprogramowania.
Postępy grupy pracującej nad Linuxem spełniających SIL2 można śledzić na stronie projektu sil2.osadl.org. Istnieje również projekt skupiający firmy pracujące nad safety-critical Linuxem o nazwie ELISA (Enabling Linux in Safety Applications).
To tyle o ile chodzi o relację z prezentacji o systemach operacyjnych na Embedded World. Prezentacji było znacznie więcej. Była cała ścieżka o embedded linuxie i ścieżka o RTOSach. Prezentacje, na które poszedłem, nie wchodziły za bardzo w szczegóły i ciężko było na nich np. o fragmenty kodu.
