Krótki wpis na temat tego, że nazwa RTOS sama w sobie może być myląca/niedokładna.

Skupmy się na nazwie samej w sobie - “real-time operating system”. Jeśli byłaby to rozmowa kwalifikacyjna na dzień dobry otworzyłyby się możliwości na zadanie dwóch pytań:

  • czym jest “system”
  • czym jest “real-time”

Część “system” potraktuję trochę po macoszemu - skupmy się na tym czym jest “real-time”, a bardziej o co w nim chodzi - czyli zadania jakie mają być wykonane mają wyznaczony swój deadline, którego przekroczenie jest “zagrożeniem” i tu płynnie przechodzimy do podziału na:

  • soft real-time - gdzie zagrożeniem jest coś “błachego”/niekrytycznego np. chwilowe zawieszenie animacji na ekranie, lag w odgrywanym dźwięku (oczywiście odbije się to jakoś na user experience i z biznesowego punktu widzenia może to być bardzo niechciane)
  • hard real-time - gdzie przekroczenie deadline może spowodować uszkodzenie całego systemu/zagrożenie życia np. sterowanie manipulatorami, które kontroluje pozycję wszystkich przegubów robota, sterowanie samochodami jak autopilot tesli itp, zadziałanie wyłącznika jakiegoś robota/maszyny przemysłowej itp

Jaką wartość będą miały te czasy - to drugorzędna kwestia - mogą to być zarówno milisekundy jak i sekundy, czy minuty - zależy od urządzenia i wymagań.

Więc kontynuując - RTOS bazując na jego nazwie powinien nam zapewniać to, że nasze taski wykonają się w określonym czasie - mamy więc przykładowe zadanie, gdzie od momentu wykrycia anomalii w sygnale wejściowym do wysterowania zewnętrznego urządzenia może minąć maksymalnie 10ms i wykonanie jest zamknięte w obrębie jednego taska. Sprawdźmy więc np. w FreeRTOSie gdzie jest parametr do przypisania jaki ma być maksymalny czas wykonania danego taska i tu “niespodzianka” nie znajdziemy tam czegoś takiego.

Załóżmy, że mamy aplikację, którą przetestowaliśmy, że mieści się z wykonaniem w tym deadline i kontynuujemy dalej development rozbudowująć algorytm detekcji anomalii zwiększając jego złożoność obliczeniową lub dochodzą nowe funkcjonalności/taski w tym samym czasie - możemy być pewni, że w końcu przekroczymy ten czas i jak ma się do tego RTOS? Nie zapewni magicznie większej ilości zasobów do wykonania obliczeń, więc wtedy urządzenie nie będzie już “real-time” (bez zmiany założeń co do tego czasu).

RTOS jeśli chodzi o zależności czasowe zapewnia jedną rzecz i moim zdaniem powinna znaleźć się w nazwie - jest to DETERMINISTYCZNOŚĆ. Za całą resztę odpowiada użytkownik.

  • RTOS nie wyliczy czasu trwania tasków/czy spełniają wymogi - jest to odpowiedzialność użytkownika.
  • RTOS nie przydzieli sam priorytetów do tasków - jest to odpowiedzialność użytkownika.

RTOS może tylko (i aż) zapewnić to, że jeśli użytkownik dokona obliczeń dotyczących najgorszych czasów wykonywania tasków to NIE ZOSTANĄ ONE PRZEKROCZONE - system zachowa się zawsze w zaplanowany/deterministyczny sposób.

Banalny przykład - aplikacja z 5 taskami, gdzie 4 są na niskim priorytecie, a wspomniana wcześniej reakcja na wykrycie anomalii to task nr. 5 z wyższym priorytetem. W takim przypadku możemy być pewni, że RTOS zadba o to, że w momencie wykrycia i uruchomienia tego tasku - tylko on będzie miał przydzielony czas MCU. Jeśli sprofilujemy wykonanie tego taska i wyznaczymy najdłuższy czas uruchomienia - RTOS gwarantuje, że go nie przekroczymy. Nie będzie sytuacji, że task o niższym priorytecie przejmie czas MCU.

Innymi słowami - RTOS zapewnia to, że możemy przewidzieć, a bardziej zaplanować jak zachowa się nasze urządzenia w konkretnych warunkach, ale wszystkie profilowania/obliczenia/zaprojektowanie architektury/komunikacji są po naszej stronie.

Czy takie obliczenia są łatwe? Niestety jest bardzo złożony temat, należy uwzględnić tam między innymi:

  • podstawowe sprofilowania worst-case-time dla aplikacji w taskach
  • czasy wykonywania przerwań - które mają większy priorytet niż taski aplikacji (w tym przerwanie z tickiem RTOSa)
  • dla tasków o niższych priorytetach - możliwość wywłaszczenia ich przez taski o wyższym priorytecie/a nawet możliwość zagłodzenia
  • dla tasków o wyższych priorytetach - mechanizmy odwrócenia i dziedziczenia priorytetów (można doczytać o misji Pathfindera)
  • należy uwzględnić czas na operacje RTOSa
  • dodatkowym tematem jest podejście do alokacji pamięci/deterministyczne mechanizmy alokacjacji jeśli jest używana

Dla złożonych systemów będzie to sporo pracy, jednak po wyliczeniu tego wszystkiego mamy pewność, że RTOS zachowa się DETERMINISTYCZNIE zgodnie z obliczeniami. Można jeszcze posłużyć się toolami do tracowania - przykład użycia w tym wpisie: https://www.embedownik.pl/posts/002.html. Samo wrzucenie RTOSa/oparcie aplikacji o RTOSa nie jest gwarancją, że urządzenie jest “real-timowe” - RTOS może być wykorzystany źle i czasem już samo uruchomienie tracowania może pozwolić to zobrazować.

Stąd jeśli zamiast “real-time operating system” nazwą byłoby wprost “deterministic operating system” mielibyśmy w niej jawnie to co on zapewnia, bez tego całego wywodu czym jest “real-time”.

Jeszcze trochę offtopu o definicji - sama w sobie definicja RTOSa jest dość “płynna” - jest wiele różnych - podobnie jak definicji czym jest “architektura oprogramowania”.

Core tego wpisu powstał już dawno na wcześniejszego bloga po naprawie firmwaru w urzadzeniu, które “było oparte o RTOSa”, ale stety/niestety działało bez spełniania żadnych założeń czasowych, a w międzyczasie przeglądając stare prezentacje o embedded znalazłem osobę która ma dokładnie to samo przemyślenie :) W prezentacji tłumaczy to o wiele lepiej niż ja w tym wpisie, w konteście RT Linuxa - bardzo polecam: https://www.youtube.com/watch?v=4UY7hQjEW34.