PREEMPT_RT w embedded Linux: kiedy pomaga dotrzymać terminów?
PREEMPT_RT warto rozważyć, gdy urządzenie z Linuxem spóźnia się z ważnym zadaniem, a przyczyną jest oczekiwanie na jego uruchomienie przez system. Może pomóc ograniczyć takie opóźnienia. Samo włączenie tej opcji nie gwarantuje jednak czasu reakcji całego urządzenia ani jego bezawaryjności. Przed decyzją o wdrożeniu potrzebne są wymaganie czasowe, pomiar na docelowym sprzęcie i sprawdzenie, gdzie powstaje zwłoka.
Dla osoby odpowiedzialnej za produkt ma to praktyczne znaczenie. Innego rozwiązania wymaga spóźniony pomiar, innego wolne wyświetlenie już zebranych danych. Jeśli zlecenie brzmi tylko „zwiększyć niezawodność przez PREEMPT_RT”, dostawca może poprawić wynik testu systemu, pozostawiając problem użytkownika bez zmian.
Najpierw ustal, co ma wydarzyć się na czas
Wymaganie powinno opisywać początek i koniec mierzonej czynności. Czy chodzi o czas od sygnału czujnika do ustawienia wyjścia, od rozpoczęcia pomiaru do zapisania wyniku, czy od naciśnięcia przycisku do reakcji ekranu? Dopiero potem można ustalić dopuszczalny czas i warunki, w których ma być dotrzymany.
Zapisz również skutek spóźnienia. Może nim być pomiar do powtórzenia, odrzucenie wyniku albo przerwanie pracy stanowiska. Zespół potrzebuje tej informacji, żeby dobrać obsługę błędu i zakres testów. Ochrona ludzi wymaga osobnej oceny całego urządzenia; wybór jądra nie zastępuje tego procesu.
Średni czas reakcji nie wystarczy, jeżeli pojedyncze przekroczenie terminu psuje proces. Wtedy raport powinien pokazać także największe zaobserwowane opóźnienie, liczbę przekroczeń i warunki testu. Największa wartość z pomiaru opisuje przebadaną próbę, a nie gwarantowaną granicę na cały okres eksploatacji.
Co zmienia PREEMPT_RT
Jądro Linux zarządza dostępem programów do procesora i sprzętu. PREEMPT_RT pozwala przerwać większą część jego pracy, aby wcześniej uruchomić zadanie, któremu nadano wyższy priorytet. Zmienia również obsługę przerwań i blokad między zadaniami. Nie wszystkie fragmenty jądra stają się przerywalne - ten zakres opisuje dokumentacja PREEMPT_RT.
PREEMPT_RT jest w głównej linii Linux od wersji 6.12, na obsługiwanych architekturach. Trzeba go jednak włączyć w konfiguracji. Nadal rozwijane są dodatkowe łatki RT; dobór wersji i ustawień opisuje przewodnik projektu Real-Time Linux.
Dla zamawiającego ważniejsze od samej instalacji jest potwierdzenie, że wybrana konfiguracja współpracuje ze sterownikami i rzeczywiście poprawia wykonanie potrzebnego zadania. Kryteria odbioru powinny opisywać wynik pracy urządzenia, a nie tylko potwierdzenie „uruchomiono jądro RT”.
Gdzie sama zmiana jądra nie wystarczy
Reakcja urządzenia obejmuje więcej niż pracę systemu operacyjnego. Znaczenie mają także dostęp do pamięci, połączenia z podzespołami i firmware, czyli oprogramowanie niskiego poziomu. Dokumentacja sprzętowych ograniczeń czasu rzeczywistego wyjaśnia, dlaczego te elementy mogą wprowadzać opóźnienia.
Jeżeli aplikacja czeka na odpowiedź z zewnętrznej usługi, zmiana sposobu przydzielania czasu procesora nie usunie tego oczekiwania. Jeżeli zbyt długo trwa samo obliczenie, trzeba zmierzyć czas jego wykonania. PREEMPT_RT może być częścią rozwiązania, ale nie powinien zastępować rozpoznania przyczyny.
Warto też pozostawić możliwość zachowania obecnego systemu. Gdy spełnia wymagania w uzgodnionych warunkach, dodatkowa zmiana jądra potrzebuje konkretnego uzasadnienia. Jeśli natomiast wybrane zadanie musi działać także podczas restartu Linuxa, należy rozważyć osobny układ sterujący. To decyzja o podziale odpowiedzialności między elementy urządzenia, z własnym kosztem komunikacji, testowania i utrzymania.
Przykład: stanowisko pomiarowe spóźnia się podczas eksportu
Załóżmy, że stanowisko zbiera dane z czujnika, pokazuje wynik na ekranie i pozwala operatorowi eksportować wcześniejsze pomiary. Podczas eksportu część nowych pomiarów kończy się po wymaganym terminie i trzeba je powtarzać. To hipotetyczny przykład, nie opis wdrożenia ani wynik testu PREEMPT_RT.
Najpierw zespół sprawdza, czy zadanie pomiarowe za późno dostaje czas procesora, czy zatrzymuje się później: przy odczycie czujnika, obliczeniu albo zapisie danych. Pomocne może być oddzielenie zapisu raportu od czynności pomiarowej. Włączenie RT jest uzasadnioną próbą wtedy, gdy diagnoza wskazuje opóźnienia, na które ta zmiana może wpłynąć.
Odbiór obejmuje jednoczesny pomiar i eksport na docelowym urządzeniu. Oprócz terminowości trzeba sprawdzić poprawność i kompletność wyników oraz to, czy operator nadal może obsługiwać urządzenie. Lepszy czas uzyskany kosztem pomijania danych nie rozwiązuje problemu. Z kolei wolniejszy eksport może być dopuszczalny, jeśli firma świadomie przyjmie taki warunek i użytkownik widzi jego postęp.
Jakiego dowodu oczekiwać przed wdrożeniem
Test narzędziem cyclictest pomaga ocenić opóźnienia uruchamiania testowych zadań. Nie mierzy całej drogi od czujnika do zakończonej czynności urządzenia. Zespół może też użyć rtla timerlat, aby diagnozować opóźnienia i zachować ślad po przekroczeniu wybranego progu. Wyniki tych narzędzi uzupełniają test aplikacji.
Poproś o porównanie obecnej i proponowanej wersji przy tych samych scenariuszach. Raport powinien wskazywać sprzęt, wersje oprogramowania, konfigurację, obciążenie i czas trwania prób. Uwzględnij czynności, które urządzenie naprawdę wykonuje równolegle, oraz warunki jego eksploatacji. Sprawdź także zachowanie po przekroczeniu terminu: czy błąd jest widoczny i czy niekompletny wynik nie trafia dalej jako poprawny.
Koszt wdrożenia obejmuje diagnostykę, ewentualne zmiany aplikacji lub sterowników, stanowisko testowe i późniejsze sprawdzanie aktualizacji. Ustal, kto utrzymuje wybraną wersję, powtarza testy po zmianach i przygotowuje powrót do poprzedniej wersji, jeśli aktualizacja pogorszy działanie.
Dobre zlecenie zaczyna się więc od konkretnej czynności i warunku odbioru: „pomiar ma kończyć się w ustalonym czasie również podczas eksportu, a przekroczenie musi być wykryte”. Taki zapis pozwala ocenić, czy PREEMPT_RT rozwiązuje problem produktu i jaki zakres prac jest rzeczywiście potrzebny.
