Poprzednia - Następna

Stworzenie systemu RT - czy to trudne?

RT systemy wykorzystywane są w sytuacjach specyficznych - tam, gdzie przewidywalny czas reakcji jest kwestią istotną, wręcz krytyczną. Wymagania względem RT systemu ściśle zależą od danej sytuacji, a co za tym idzie, różne RT systemy są dobrymi rozwiązaniami różnych sytuacji.

Szeroka gama wymagań względem RT systemów implikuje różne stopnie trudności przy ich implementacji. Stworzenie odpowiedniego RT systemu może być trywialne, lub niezwykle skomplikowane. Pośrednie stopnie trudności oczywiście również wchodzą w grę - nie ma powodu do załamywania rąk, jeśli okaże się, że system który mamy zaimplementować nie jest banalny.


Trywialny real-time system

Komfortowa z punktu widzenia twórcy sytuacja jest taka, gdy system może składać się z pojedynczego zadania (np. działającego okresowo). Pozostaje wtedy implementacja zadania, oraz sprawdzenie, czy procesor potrafi wykonywać to zadanie mieszcząc się w zadanych limitach czasowych. Jeśli nie, pozostaje kupić szybszy, lepszy procesor - przy odpowiedniej mocy procesora system będzie poprawnie działającym systemem RT.

Jak wynika z powyższych rozważań, jednozadaniowy RT system jest systemem prostym. Co jednak ważniejsze - również skutecznym real-time systemem.

Problem pojawia się, gdy trzeba dzielić zasoby - przede wszystkim procesor - pomiędzy kilka konkurujących zadań.


Hard real-time system operacyjny - czemu to trudne?

Kłopot z hard real-time systemami operacyjnymi polega na tym, że aby zapewniać ("ciasną") przewidywalność pesymistycznego czasu reakcji, system operacyjny powinien być:

A ponadto chcielibyśmy, aby pesymistyczny czas reakcji był zoptymalizowany.

Z drugiej strony system operacyjny dąży do zoptymalizowania średniego czasu reakcji, a także zapewnienia ewentualnemu użytkownikowi (w miarę) przyjaznego środowiska.


Przerabianie OS na RTOSa

W niektórych przypadkach, aby uzyskać RTOSa, podejmuje się próby modyfikacji lub wykorzystania istniejących systemów operacyjnych. Obserwuje się dwa główne podejścia do tej kwestii:

  1. Próby balansowania pesymistycznego i średniego czasu reakcji, czyli uszczypliwie mówiąc: "robienie ogólno-zadaniowego systemu operacyjnego a`la real-time".

    Próby optymalizowania dwóch, zasadniczo przeciwstawnych, parametrów rzadko prowadzą do olśniewających rezultatów, a w przypadku systemów operacyjnych prowadzą raczej do soft RTOSów (KURT).

  2. rozbicie systemu na dwa systemy operacyjne - real-time i "zwyczajny" (nie real-time).

    Podejście to wydaje się być często skuteczne, czego przykładem jest choćby RTLinux. Niemniej jednak uważane jest za konserwatywne i potencjalnie ograniczające możliwości końcowego użytkownika.

Aby być uczciwym, należy przyznać, że pierwsze podejście obejmuje również dodawanie cech nie real-time do RTOSa - to podejście prezentuje np. VxWorks.



A tak przy okazji, słowo o Windows

Ewidentnie, Windows systemem RT nie jest. Wprawdzie np. w Windows NT obserwuje się dążenie zarówno do systemu RT, jak i zgodności z POSIXem, niemniej jednak osiągnięcie celu nie wydaje się realne.

Należy jednak wspomnieć, że Windows 9x czy Windows NT mogą, przy użyciu specjalnego oprogramowania, być konwertowane do real-time systemów. Niestety, jedyne co udaje się osiągnąć to soft real-time.


Poprzednia - Stworzenie systemu RT - czy to trudne? - Następna