Jesień LinuksowaLinux - Real-Time w systemach wbudowanych

Transkrypt

1 Jesień Linuksowa Linux - Real-Time w systemach wbudowanych marcin@bis-linux.com 13 padziernika 2012 Jesień LinuksowaLinux - Real-Time w systemach wbudowanych

2 O mnie GNU/Linux (administracja, programowanie) Embedded Linux szkolenia, konsulting, wsparcie techniczne przemysłowe zastosowania systemu Linux (Real-Time)

3

4 Ogólny trend w systemach Embedded Linux (i open-source) jest coraz częściej wykorzystywany w systemach wbudowanych. Sprzęt zdolny do uruchamiania Linuksa jest coraz tańszy (procesory, pamięci). Linux wspiera dużo sprzętu i protkołów. Kod tworzony pod Linuksa jest z reguły re-używalny.... koszt systemu, brak vendor lock-in. Coraz więcej tego typu aplikacji musi działać w czasie rzeczywistym.

5 System sterowania Przykładowy system oparty na projekcie TNKernel Projekt Open-Source rozwijany głównie przez jednego człowieka (plus zainteresowane nim firmy). Elegancko zaprojektowany, przejrzysty kod. Przetestowany na wielu wdrożeniach. Problem - Klient zamawia: pobieranie logów przez FTP zdalne sterowanie urządzeniem ładniejsze ikonki Zbyt trudne do zrealizowania (w rozsądnym czasie). Te rzeczy mamy z pudełka w Linuksie! - sprawdźmy, czy się nadaje.

6 Co oznacza Real-Time? Definicja książkowa : Poprawność wykonania operacji zależy nie tylko od tego, czy wykonała się bez błędów i zwróciła poprawny rezultat, ale także od czasu (górnego ograniczenia) w jakim operacja się zakończyła.

7 Co oznacza Real-Time? Definicja praktyczna : System RT, to taki, w którym da się udowodnić, że każda wymagana operacja zakończy się w określonym czasie. W idealnym przypadku jest to dowód matematyczny. Niestety przy złożoności współczesnych systemów jest to niewykonalne, a nawet jeżeli, to istnieje ryzyko popełnienia błędu podczas dowodzenia. W praktyce stosuje się zestaw testów. System, który przejdzie takie testy określne w specyfikacji lub powstające podczas jego tworzenia, jest określany jako system czasu rzeczywistego.

8 Real-Time vs. Real-Fast Linux jest zaprojektowany jako system demokratyczny zasoby są przydzielane według potrzeb na przykład: planista zapobiega zagłodzeniu procesu Zazwyczaj determinizm nie jest brany pod uwagę liczy się maksymalna wydajność (throughput)

9 Real-Time vs. Real-Fast, cd... Większośc warstw i algorytmów jest złożona.

10 Praktyczny test

11 Wzorcowy układ

12 Wzorcowy układ Wejście jest wzbudzane sygnałem i system reaguje zmieniając stan wyjścia. W tym przypadku są to PIN-y GPIO. Sytuacja niczym się nie różni od wzbudzania wejścia przy pomocy innego (wewnętrznego mechanizmu). To jest timera lub przerwania z urządzenia (kamera).

13

14

15

16 Realizacja w procedurze obsługi przerwania

17 Realizacja w procedurze obsługi przerwania

18 Dodajemy obciążenie $ cat /proc/loadavg / odczyt danych z karty SD: cat /dev/mmcblk0p1 > /dev/null wysyłanie danych ASCII na terminal podłączony przez port szeregowy: cat /dev/zero od -v wysyłanie do badanego systemu dużej ilości pakietów IP (ICMP): ping -f <adres urządzenia> Uwaga!: te testy nie poddają systemu obciążeniom występującym podczas rzeczywistej pracy.

19 Realizacja w procedurze obsługi przerwania - obciążenie

20 Podstawowe pojęcia.

21

22 Deadline Punkt w czasie, w którym dana akcja ma nastąpić (np. reakcja na zmianę stanu wejścia). Hard Real-Time - operacja zawsze musi zakończyć się w określonym czasie. Wynik operacji zakończonej później - nie nadaje się do wykorzystania (awaria już nastąpiła). Soft Real-Time - okazjonalnie operacja może zakończyć się po ustalonym czasie (błąd nie jest krytyczny dla operacji) - na przykład zgubiona ramka obrazu.

23 Latency Czas pomiędzy momentem w którym akcja miała wystąpić, a momentem w którym w rzeczywistości wystąpiła. W idealnym przypadku (taki system nie istnieje) - opóźnienia byłyby zerowe. W rzeczywistości komputer potrzebuje pewnego czasu na ustabilizowanie i przetworzenie sygnałów ze sprzętu, oprogramowanie wprowadza własne opóźnienia itp.

24 Jitter Wariancja opóźnienia (poprzedniej wartości). Czas pomiędzy wystąpieniem przerwania (zgłoszeniem przez sprzęt) a uruchomieniem procedury jego obsługi nie jest stały. Jego zmienność jest równie groźna jak duże opóźnienie (na przykład uniemożliwia wykorzystanie systemu do akwizycji danych).

25 Predictability Przewidywalność. Oznacza wiedzę na temat tego ile czasu zajmie operacja (na przykład procedura obsługi przerwania). Teoria algorytmów zajmuje się określaniem złożoności obliczeniowej poszczególnych metod. W szczególności aby system był przewidywalny, konieczne jest używanie algorytmów działających w stałym czasie (niezależnym od ilości danych).

26 Worst Case Ze względu na zmienność rzeczywistych systemów (nie da się zbudować systemu idealnego), głównym polem naszych zainteresowań pozostaje najgorszy możliwy przypadek. System będzie działał w sposób przewidywalny jeżeli będziemy znać jego opóźnienie w najgorszym możliwym przypadku.

27 W Linuksie: Oddzielamy logikę od mechanizmów

28

29

30

31 Userspace - obciążenie

32 Userspace - obciążenie

33 Jak z Linuksa zrobić system Real-Time? Przy pomocy rozwiązań Open-Source

34 1 Metody oparte na mikrojądrze: RTLinux - pierwsza implementacja. RTAI - najmniejsze możliwe opóźnienia. Adeos - nanokernel. Xenomai - oparty o Adeos - łatwe portowanie kodu z innych systemów RT. 2 Próba ulepszenia Linuksa: RT PREEMPT

35 Mikrojądro

36 I-Pipe (Adeos) Kontroluje przerwania sprzętowe (wszystkie) Kontroluje przerwanai software-owe (syscall) Przydziela je do poszczególnych domen.

37 $ cat /proc/ipipe/xenomai Handling ([A]ccepted, [G]rabbed, Sticky [W]ired, [D]iscarded) +--- Locked +-- Exclusive +- Virtual [IRQ] 38: W..X. 418: W...V [Domain info] id=0x58454e4f priority=topmost $ cat /proc/ipipe/linux 0: A... 1: A priority=100

38 Xenomai - architektura

39 Xenomai i RTAI Obydwa projekty mają wiele wspólnego. RTAI - ma dostarczać systemu o jak najmniejszych opóźnieniach. Xenomai - ma zapewniać kompatybilność z API klasycznych RTOS-ów. RTAI - jest projektem akademickim - rozwój przebiega dość chaotycznie (skokowo). Xenomai - ma większą bazę użytkowników.

40 RTAI - LinuxCNC Praktyczna demonstracja możliwości RTAI. Ubuntu (LiveCD) + RTAI + Aplikacje GUI Język G Wizualizacja Sterowniki Programowalne PLC

41 LinuxCNC

42 LinuxCNC

43 RT PREEMPT

44 Skąd się biorą opóźnienia?

45 Od wersji dostępna jest możliwość włączenia wywłaszczania kodu jądra. Kernel Features ---> Preemption Model (Preemptible Kernel ()) --> ( ) No Forced Preemption (Server) ( ) Voluntary Kernel Preemption (Desktop) (X) Preemptible Kernel (Low-Latency Desktop) To nadal nie jest RT!

46 RT-Preempt Łaty pozwalające na uruchamianie wątków czasu rzeczywistego, rozwijane są w oddzielnym projekcie: Są one sukcesywnie włączane do jądra. Kernel Features ---> Preemption Mode (Complete Preemption ()) ---> (X) Complete Preemption (Real-Time) -*- Thread Softirqs -*- Thread Hardirqs

47 Przerwania w wątkach 1 Standardowa obsługa przerwań 2 Obsługa przerwań w wątkach

48 Obciążenie

49 Obciążenie

50 Jądro z łatą RT PREEMPT nie sprawia, że system staje się RT. Trzeba skorzystać z: POSIX RT-API i dopiero aplikacje napisane z jego użyciem będą działały w reżimie czasu rzeczywistego!

51 Wsparcie dla POSIX RT API w Linuksie Standard IEEE b - POSIX.1b. Najważniejsze deterministyczne mechanizmy programowania w systemach czasu rzeczywistego określone w standardzie, to: Planowanie uruchamiania procesów (API planisty, pozwalające zdefiniować na stałe priorytet procesu oraz klasę zaszeregowania). Blokowanie pamięci (w celu uniemożliwienia jej zeswapowana). Kolejki komunikatów. Pamięć współdzielona. Sygnały czasu rzeczywistego. Semafory. Timery (CLOCK MONOTONIC). AIO - nieblokujące operacje odczytu i zapisu danych, oraz kontroli zleceń

52 Aplikacja sterująca procesem przemysłowym

53

54

55

56 KONIEC