Mariusz Rudnicki mariusz.rudnicki@eti.pg.gda.pl PROGRAMOWANIE SYSTEMÓW CZASU RZECZYWISTEGO CZ.1
Przedmiot PSCR Przedmiot PSCR Wykład do połowy semestru Laboratorium od połowy semestru Projekt Zaliczenie w formie pisemnej Ocena końcowa: średnia ważona z zaliczenia części wykładowej i projektu (50% + 50%). 2/36
Zagadnienia Podstawowe pojęcia Architektury systemów czasu rzeczywistego Procesy, wątki Szeregowanie wątków Synchronizacja wątków 3/36
Zagadnienia cd. Komunikacja IPC Komunikaty Pulsy Komunikacja zadań RT z zadaniami non- RT Przerwania Programowanie sprzętu 4/36
System czasu rzeczywistego to taki, w którym wynik przetwarzania nie zależy tylko i wyłącznie od jego logicznej poprawności, ale również od czasu, w jakim został osiągnięty. Jeśli nie są spełnione ograniczenia czasowe, mówi się, że nastąpił błąd systemu. 5 /36
Tryb przetwarzania w czasie rzeczywistym jest takim trybem, w którym programy przetwarzające dane napływające z zewnątrz, są zawsze gotowe, a wynik ich działania jest dostępny nie później niż po zadanym czasie. Moment nadejścia kolejnych danych może być losowy (asynchroniczny) lub ściśle określony (synchroniczny). 6 /36
System czasu rzeczywistego jest systemem interaktywnym, który utrzymuje ciągły związek z asynchronicznym środowiskiem, np. środowiskiem, które zmienia się bez względu na system, w sposób niezależny od niego. 7 /36
Oprogramowanie czasu rzeczywistego odnosi się do systemu lub trybu działania, w którym przetwarzanie jest przeprowadzane na bieżąco, w czasie wystąpienia zewnętrznego zdarzenia, w celu użycia rezultatów przetwarzania do kontrolowania lub monitorowania zewnętrznego procesu. 8 /36
System czasu rzeczywistego odpowiada w sposób przewidywalny (w określonym czasie) na bodźce zewnętrzne napływające w sposób nieprzewidywalny. 9 /36
System mikrokomputerowy działa w czasie rzeczywistym, jeżeli wypracowane przez ten system decyzje są realizowane w tempie obsługiwanego procesu. Inaczej mówiąc, system działa w czasie rzeczywistym, jeżeli czas reakcji systemu jest niezauważalny przez proces (decyzja jest wypracowana we właściwym czasie). 10 /36
Klasyfikacja systemów czasu rzeczywistego Hard real-time systems Soft real-time systems Firm real-time systems 11 /36
Hard real-time systems rygorystyczne (twarde) gwarantują terminowe wypełnienie zadań krytycznych. ograniczenie opóźnień w systemie; przechowywanie danych w pamięci o krótkim czasie dostępu; pamięć pomocnicza minimum lub jej brak; ograniczona do brak pamięci wirtualnej; niemożliwa współpraca podziałem czasu. z systemami z 12 /36
Soft real-time systems łagodne (miękkie), mniej rygorystyczne w kwestii terminowości wykonywanych zadań. Zadania wykonywane są tak szybko jak to możliwe ale nie muszą zakończyć się w określonym czasie. Przekroczenie czasu powoduje negatywne skutki, ale nie są one katastrofalne. Łagodne traktowanie wymagań dotyczących czasu rzeczywistego umożliwia godzenie ich z systemami innych rodzajów np. z systemami z podziałem czasu. 13 /36
Firm real-time systems solidne, są kombinacją twardych i miękkich wymagań czasowych. Często w praktyce definiuje się krótki czas reakcji, którego spełnienie wymagane jest miękko i dłuższy czas reakcji, który powinien być spełniony twardo. Fakt przekroczenia terminu dostarczenia wyniku, powoduje jego całkowitą nieprzydatność (brak korzyści), nie ma też żadnej groźby związanej z takim przypadkiem. 14 /36
Pożądane cechy Systemu Czasu Rzeczywistego: ciągłość działania; zależność od otoczenia; współbieżność; przewidywalność; punktualność; 15 /36
ciągłość działania: system pracuje nieprzerwanie oczekując na bodźce zewnętrzne z otoczenia; zależność od otoczenia: system musi być rozpatrywany w kontekście otoczenia, jego działanie uzależnione jest od bodźców napływających z otoczenia; współbieżność: otoczenie systemu zazwyczaj składa się z wielu współbieżnie działających podsystemów, generujących bodźce, które muszą być równocześnie obsłużone przez system SCR stąd wymagana jest współbieżna struktura systemu SCR; 16 /36
przewidywalność: pomimo współbieżności, na zewnątrz system musi zachowywać się deterministycznie (reakcja na pochodzące z otoczenia przypadkowe bodźce powinna być zgodna z założonymi wymaganiami); punktualność: odpowiedzi systemu (reakcje na bodźce z otoczenia) powinny być obliczane wg zaprojektowanych algorytmów i dostarczane do otoczenia w odpowiednich momentach czasu. 17 /36
Studium przypadku: ograniczenia czasowe są koniecznością, a nie spełnienie ich prowadzi w najgorszym przypadku do nieodwracalnych i zazwyczaj tragicznych skutków; w innych sytuacjach czas wykonania jest mniej krytyczny i dopuszcza się pewne odstępstwa. 18 /36
real-time system system in real time real-time system: gwarantuje czas reakcji systemu, co nie jest tożsame z szybką reakcją systemu; system in real time: Oznacza pozorne wrażenie realności szybkie reakcje na bodźce z otoczenia (np. symulator lotu). 19 /36
Programowanie SCR programista patrzy na SCR jako na zbiór współbieżnych zadań wymieniających informacje z otoczeniem i pomiędzy sobą; w związku z powyższym programowanie SCR obejmuje następujące dziedziny: programowanie wielowątkowe; komunikacja i synchronizacja w systemach współbieżnych; współdzielenie zmiennych, przesyłanie komunikatów, współdzielenie zasobów, 20 /36
Programowanie SCR cd. synchronizacja czasowa zadań, szeregowanie, obsługa przerwań, wydajność, niezawodność, odporność na błędy (wyjątki). 21 /36
Specyfika programowanie SCR: definiowanie spójnych części, realizujących obsługę zdarzeń pojawiających się w otoczeniu zadań (aktywowanych zdarzeniami lub upływem czasu); konieczność istnienia mechanizmów synchronizacji i wymiany informacji pomiędzy zadaniami; konieczność określenia dla zadań priorytetu oraz możliwość wywłaszczania zadania; 22 /36
Specyfika programowanie SCR cd.: możliwość uzależnienia działania systemu od czasu i innych zdarzeń zachodzących w otoczeniu; możliwość definiowania procedur obsługi dla nietypowych (np. procesowych) operacji I/O; istnienie mechanizmów umożliwiających konstruowanie oprogramowania o podwyższonej niezawodności (np. obsługa wyjątków). 23 /36
Architektury SCR Klasyczna struktura SCR Wszystkie moduły współdzielą tą samą przestrzeń pamięci, tworząc jeden duży program. 24 /36
Architektury SCR Klasyczna struktura SCR zalety: pojedyncza przestrzeń adresowa łatwa komunikacja pomiędzy zadaniami proste współdzielenie zasobów wady: pojedyncza przestrzeń adresowa brak mechanizmów ochrony pamięci utrudniony rozwój i testowanie 25 /36
Architektury SCR Monolityczna struktura SCR Jądro zawiera oprócz własnej funkcjonalności, również wszystkie sterowniki, co powoduje złożoność procesu wytwarzania i debugowania. Aplikacje są procesami umieszczonymi w chronionej pamięci powodując, że jądro jest chronione przed wpływem aplikacji użytkownika i aplikacje są chronione na wzajem. 26 /36
Architektury SCR Monolityczna struktura SCR zalety: aplikacje uruchamiają się w wydzielonej przestrzeni adresowej wykorzystanie mechanizmów ochrony pamięci wady: sterowniki w przestrzeni adresowej jądra utrudniony rozwój i testowanie 27 /36
Architektury SCR Architektura mikrojądra System operacyjny zawiera mikrojądro i zbiór współpracujących procesów. Procesy są odseparowane od jądra, więc w przypadku awarii oprogramowania, nie mają one wpływu na jądro. 28 /36
Architektury SCR Architektura mikrojądra komunikacja IPC Procesy systemowe i użytkownika komunikują się ze sobą wykorzystując mechanizmy komunikacji IPC Inter-Process Communication. Oprogramowanie systemowe i aplikacyjne tworzą spójny system. 29 /36
Architektury SCR Przykłady procesów: Sterowniki dysków; Stos sieciowy; Sterowniki znakowe; Elementy interfejsu graficznego; Sterowniki magistral; Demony systemowe. 30 /36
Architektury SCR Zalety i wady architektury z mikrokernelem: Zalety: elastyczność i niezawodność łatwość konfiguracji i rekonfiguracji łatwość debugowania łatwość wytwarzania oprogramowania skalowalność systemu 31 /36
Architektury SCR Zalety i wady architektury z mikrokernelem: Wady - koszty: więcej przełączeń kontekstu; więcej kopiowanych danych. 32 /36
Architektury SCR Architektura dwóch systemów pod kontrolą jądra systemu RT pracuje jądro systemu non- RT RT Core runs the Linux kernel as a idle thread (the lowest priority thread). 33 /36
Architektury SCR Koncepcja RT Linuxa: odseparowanie zadań RT; wyspecyfikowanie i poprawienie modułów Linuxa, które mogłyby powodować problemy w czasie realizacji zadań krytycznych; dostarczanie zaawansowanych usług i dużej wydajności, w przypadku średnim, przez system ogólnego przeznaczenia z gwarancją terminowości wykonywania zadań krytycznych. 34 /36
Architektury SCR RT Linux zadania krytyczne: zadania wykonywane w przestrzeni adresowej RT Core są priorytetowane przez schedulera tego jądra. Umieszczone są we wspólnej przestrzeni adresowej, bez ochrony pamięci. 35 /36
Architektury SCR RT Linux zadania krytyczne: Zalety: szybsze przełączanie kontekstu brak konieczności zmiany rejestru bazowego jednostki zarządzającej pamięcią MMU i czyszczenia bufora TLB - Translation Lookaside Buffer; bezpośrednie współdzielenie danych bez konieczności stosowania skomplikowanych mechanizmów komunikacji międzyprocesowej; Wady: rozbudowany mechanizm komunikacji zadań RT z zadaniami non-rt; błędy w zadaniach krytycznych mogą powodować awarię całego systemu;s 36 /36