Systemy Operacyjne Czasu Rzeczywistego
Obecny wpis ma po części związek z wpisem poprzednim – odnosi się bowiem do systemów sterowania.
System operacyjny – jaki jest każdy widzi. Czytając ten wpis każdy z Was ma z nim kontakt i właśnie z niego korzysta (chyba, że ktoś wydrukował sobie moje wypociny, ale wierzyć mi się w to nie chce ;) ). System jest to zorganizowany zbiór obiektów wzajemnie od siebie zależnych stanowiących jednostkę. Co to jest więc System Czasu Rzeczywistego, który wspomniany został w tytule wpisu? Jak mówi definicja IEEE/ANSI jest to system komputerowy, w którym obliczenia wykonywane są w sposób współbieżnie z otoczeniem w celu sterowania, nadzorowania lub terminowego reagowania na zdarzenia występujące w tym systemie. Najistotniejsze z mojego punktu widzenia jest właśnie terminowe wykonanie zadania, czyli wypracowanie odpowiedzi (najczęściej sygnału sterującego) na bodźce. Typ systemu operacyjnego czasu rzeczywistego zależy od czasu wykonywania zadania – rozróżniamy 3 typy: Soft RTS (miękkie wymagania czasowe – zadania wykonywane tak szybko jak to możliwe jednak bez ustalonego dokładnego limitu czasowego), Hard RTS (twarde wymagania czasowe – konieczność zmieszczenia się w określonym czasie, po jego minięciu wygenerowany sygnał nie jest do niczego potrzebny), Firm RTS (solidne wymagania czasowe – wraz z upływem czasu generacji sygnału dane te są coraz mniej użyteczne).
Gdzie wykorzystywane są Systemy Operacyjne Czasu Rzeczywistego?
Nie – nie jest to Windows, na którym obecnie pracujecie. Jeśli korzystacie z Linuxa nie cieszcie się – Wy również nie korzystacie z SOCR. Gdzie więc można znaleźć taki system – np. w rakiecie przeciwlotniczej (Hard RTS). Ale to nie wszystko. Pomimo, że większość z was nie pilotuje F‑16, to większość z was może mieć do czynienia z SOCR na co dzień. Gdzie? Chociażby w odtwarzaczu DVD – oczywiście tu nie muszą być spełniane wymagania HARD RTS, a brak odpowiedzi w ustalony czasie nie ciągnie za sobą tak poważnych konsekwencji.
Czym różnią się systemy używane w standardowych desktopach od systemów deterministycznych czasowo? Przede wszystkim te pierwsze pracują zdarzeniowo, co może prowadzić do przeciążenia wynikającego z napływania zbyt dużej ilości danych. SOCR pracują w „rytm zegara” niwelując przez to zagrożenie przeciążenia, mieć wysoką wydajność i małe zapotrzebowanie na zasoby. Musi również umożliwiać wykonywanie procesów wielowątkowych, które powinny charakteryzować się priorytetami. Bardzo istotną kwestią są również przerwania i kwestia wywłaszczania. Jeśli jądro jest przystosowane do obsługi wywłaszczania to proces o najwyższym priorytecie „dostaje procesor na własność” natomiast każdy inny proces jest wtedy przerywany. Dokładnie o wywłaszczaniu przeczytać można np. w wikipedii.
Architektura
Istnieją trzy główne typy architektury SOCR: typowy, monolityczny, z mikrojądrem. Każdą z nich opiszę przy innej okazji, teraz chciałbym zająć się konkretnym rozwiązaniem.
QNX Neutrino.
Komercyjny system stanowiący lwią część rynku. Wykorzystywany w najróżniejszych gałęziach, często spotykany w samochodach takich marek jak BMW, Fiat, Ford, Saab, Volkswagen głównie do obsługi systemów bezpieczeństwa (np. ABS, ESP). System ten jest również stosowany do obsługi wbudowanych systemów głośnomówiących (około 50% wszystkich takich zestawów jest obsługiwana właśnie przez QNX’a). Jest to zdaniem wielu najlepszy i najbardziej zaawansowany i przyszłościowy system operacyjny czasu rzeczywistego realizujący solidne wymagania czasowe. Czym zasłużył sobie na to miano? Przede wszystkim wykorzystaniem architektury mikrojądra, dzięki czemu zawieszenie się jednego procesu (aplikacji) nie oznacza restartu system – system wydziedzicza w takim przypadku „uszkodzony” proces, zwalnia jego pamięć a sam działa dalej. Oczywiście są i wady takie rozwiązania (mianowicie mowa o startach czasu wynikających z przełączania kontekstu zadania). Model mikrojądra przedstawiony jest na rysunku poniżej
Ale to tylko jedna z zalet tego systemu, występująca przecież w wielu innych systemach operacyjnych. Zatrzymując się jednak jeszcze na chwilę przy jądrze systemu, warto zwrócić uwagę na jego wagę. Dla przykładu jądro standardowego systemu UNIX zajmuje około 700kB, ile więc zajmuje jądro systemu spełniającego najbardziej rygorystyczne wymagania czasowe? Całe 8kB! System dzięki wbudowanym mechanizmom w prosty sposób umożliwia komunikowanie się pomiędzy odległymi procesami tak, jakby były one „zamknięte” w jednym komputerze, a dzięki zastosowaniu rozbudowanych możliwością definiowania priorytetów umożliwia wyselekcjonowanie i obsłużenie najbardziej krytycznych zdarzeń w systemie. Sam QNX znajduje zastosowanie nie tylko w samochodach, ale przede wszystkim w automatyce przemysłowej, tworzenia systemów SCADA czy jako platforma baz danych. Nawiasem mówiąc bardzo ciekawą pracę dyplomową pisze dla QNX właściciel tech-bloga.
Windows CE
Oczywiście Microsoft nie odpuścił tak prężnie rozwijającego się rynku i sam również posiada system operacyjny czasu rzeczywistego. Windows CE spełnia miękkie wymagania czasu rzeczywistego, lecz istnieje zagrożenie w postaci zastosowania kolejki LIFO do obsługi zdarzeń. Sam system posiada architekturę modułową i potężne jądro (w porównaniu z jądrem QNX’a) o wielkości 1MB. Sam Windows CE był początkowo projektowany dla urządzeń przenośnych, na których wykorzystywany jest do dziś, lecz nie przewidziano w nim obsługi czasu rzeczywistego. Dopiero w drugiej wersji Microsoft zdecydował się zaimplementować mechanizmy do obsługi czasu rzeczywistego, co rozszerzyło możliwości jego zastosowania. Obecnie Microsoft wydaje również inne wersje swoich produktów oparte o Windows CE – np. Windows Automotive (stosowany przemyśle samochodowym), PocketPC, Windows Mobile (od wersji 2003 do wersji 6.0). Pełna lista systemów opartych o jądro Windows CE przedstawiona jest poniżej.
RTLinux
Na polu bitwy nie mogło zabraknąć Linuxa. Wersja ta powstała jako akademicki projekt, a głównym jej autorem jest Victor Yodaiken. Do jej uruchomienia niezbędne są źródła odpowiedniej wersji ze strony projektu oraz odpowiadająca im łata na jądro. Twórcy podeszli do sprawy w dość ciekawy sposób – stwierdzili oni, że połączenie na jednym komputerze dwóch systemów – normalnego, zdarzeniowego oraz systemu czasu rzeczywistego stworzy dla użytkownika potężne narzędzia. Owa współbieżność dwóch systemów nie jest realizowana na zasadzie wirtualizacji - zwykłe jądro Linuksa jest traktowane wtedy jako podrzędny proces jądra czasu rzeczywistego, który wysyła polecenia do jądra zwykłego gdy żaden proces czasu rzeczywistego nie jest wykonywany. Oczywiście sprawa ta wymagała „drobnej” modyfikacji obsługi przerwań w systemie ?. RTLinux spełnia twarde wymagania czasowe
KURT
Linux, a raczej łatka na niego, który zamienia go w system spełniający solidne wymagania czasowe. Wymieniam go raczej z ciekawości, bo nigdy nie miałem z nim doczynienia.
Po co to wszystko?
Jak już wspomniałem, w świecie znajduje się szerokie zastosowanie dla systemów czasu rzeczywistego. Oprócz odtwarzaczy DVD, czy rakiet bardzo znane jest ich zastosowanie w przemyśle samochodowym. ABS, ESP, czy system poduszek powietrznych – muszą być zarządzane przez system czasu rzeczywistego. Oprócz tego systemy takie przydają się również podczas projektowania systemów sterowania. Za ich pomocą możemy zasymulować działanie modelu tak, jak zachowywał by się on w rzeczywistości, biorąc pod uwagę ich dynamikę w czasie. Przy odrobinie wiedzy (i pieniędzy) możemy zbudować np. model jakiegoś procesu i jego sterowanie za pomocą sterownika PLC zaprogramowanego językiem drabinkowym (opisanym w poprzednim wpisie). Wszystko oczywiście możemy wizualizować za pomocą SCADy – np. programu InTouch. Ale o tym może innym razem ;)