Systemy Czasu Rzeczywistego dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl
Cele przedmiotu Podczas laboratorium zrealizowany zostanie projekt symulujący działanie reaktywnego systemu sterowania o własnościach czasu rzeczywistego oraz jego otoczenia. Większość systemów sterowania realizuje równocześnie kilka zadań odczytywanie wartości czujników, reakcja na zdarzenia zewnętrzne wyznaczanie sterowania przesyłanie danych do urządzeń wyjściowych (siłowników) Najczęściej zadania te realizowane są jako działające współbieżnie wątki lub procesy, dlatego omówione zostaną typowe problemy programowania współbieżnego.
Model formalny Przed przejściem do implementacji zbudowany zostanie jego model formalny w postaci sieci Petriego. Ma on stanowić element dokumentacji projektu. Posłużymy się pakietem Renew pozwalającym na utworzenie modelu oraz symulację jego zachowania (http://www.renew.de) W praktyce symulacja pozwoli na zaobserwowanie wszystkich możliwych ścieżek wykonania systemu i odkrycie niekorzystnych zjawisk: Zakleszczenie Brak żywotności (pewna funkcjonalność jest nieosiągalna) Niemożność powrót do stanu początkowego po zakończeniu pewnego scenariusza działania
Aspekt czasu rzeczywistego Systemy sterowania najczęściej mogą być także zaliczone do grupy określanej jako systemy czasu rzeczywistego, czyli systemów, które mają określone wymagania dotyczące czasu odpowiedzi lub czasu przetwarzania danych: sterowanie polega na próbkowaniu w zadanych interwałach czasowych stanu wejść i obliczaniu sterowania w systemie reaktywnym, sterowanym zdarzeniowo (przez przerwania) reakcja ma nastąpić w zadanym czasie
Platforma? Systemy sterowania są budowane na określonej platformie obejmującej: sprzęt oprogramowanie: System operacyjny (czasu rzeczywistego) Oprogramowanie aplikacyjne Bardzo często rozwój następuje z wykorzystaniem symulatora docelowego systemu operacyjnego (sprzęt nie jest dostępny)
Platforma? Typowe mechanizmy oferowane przez system operacyjny czasu rzeczywistego (lub jego symulator) Możliwość uruchamiania współbieżnych wątków lub zadań Komunikacja pomiędzy zadaniami: Dzielona pamięć (wspólna przestrzeń adresowa) Przesyłanie sygnałów z wykorzystaniem semaforów Przesyłanie wiadomości z wykorzystaniem kolejek komunikatów Synchronizacja i wzajemne wykluczanie Komunikacja z otoczeniem za pośrednictwem przerwań (lub możliwość symulacji tego typu komunikacji) Inne cechy systemów operacyjnych czasu rzeczywistego: Małe zużycie zasobów Duża szybkość działania Przewidywalność Metryki systemu (maksymalne czasy zwłoki podczas obsługi przerwań, czasy przełączeń zadań, itd.)
Platforma Java Projekt ma zostać zrealizowany na platformie Java. Na podstawie doświadczeń z symulatorem systemu operacyjnego VxWorks: większość wykorzystywanych podczas implementacji mechanizmów komunikacji i synchronizacji może zostać zrealizowana w języku Java. Język Java ma bogatszy zestaw mechanizmów programowania współbieżnego niż typowo niskopoziomowe usługi systemów operacyjnych czasu rzeczywistego.
Odwzorowanie elementów Mechanizm systemu operacyjnego czasu rzeczywistego Zadanie Semafor Semafor wzajemnego wykluczania do ochrony zasobów Kolejki komunikatów Komunikat blok pamięci Komunikacja z wykorzystaniem przerwań? Mechanizm języka Java Wątek Semafor (java.util.concurrent) Monitor lub semafor Różne wersje kolejek (tablice, listy, blokujące, nieblokujące, itd.) Dowolny obiekt, aby uniknąć dynamicznej alokacji pamięci można zbudować pulę komunikatów Brak, ale należy zasymulować: na przykład reakcja na przycisk wysyła komunikat do kolejki, dalej zawartość kolejki jest przetwarzana przez wątek..
Platforma Java - zalety Łatwy dostęp, wsparcie dla większości systemów Nie wymaga wyspecjalizowanego sprzętu, brak zabezpieczeń i ograniczeń (licencje) Podobny składniowo do C/C++ Zaimplementowano większość mechanizmów znanych z systemów operacyjnych czasu rzeczywistego (a nawet znacznie więcej) Można zbudować graficzny interfejs uzytkownika Przyjazne IDE Netbeans, Eclipse
Platforma Java - wady Oczekiwana realizacja projektu ma polegać na zastosowaniu wzorców typowych dla programowania aplikacji czasu rzeczywistego: Program wielowątkowy (wielozadaniowy). Liczba wątków ograniczona Logika działania komponentów systemu opisana przez maszyny skończeniestanowe Symulacja otoczenia systemu, w tym elementów mechanicznych (drzwi, silnik, grzałka, palnik, itd.) w postaci wątków. Niestety, można spotkać błędne realizacje, w których: Jest GUI i wszelkie aktywności wykonywane są w wyniku reakcji na akcje użytkownika Brak podziału na komponenty odpowiadające fizycznym obiektom (w tym symulowanym) Brak maszyny skończeniestanowej, logika programu zapisana w postaci zbioru trudnych do śledzenia zmiennych, dodatkowo zakodowana w postaci stanu elementów interfejsu użytkownika.
Przykłady 1 http://pszwed.ia.agh.edu.pl/kssres/skrzyz/index.html
Przykłady 2 http://pszwed.ia.agh.edu.pl/kssres/bankomat/page1.htm
Przykłady 3 http://pszwed.ia.agh.edu.pl/kssres/kociol/proj.html
Przykłady 4 - podobna w konstrukcji praca inżynierska http://zibiteac.ayz.pl/zakopane-aleje-3-go-maja-dolne.html
Dokumentacja Dokumentacja projektu ma zostać sporządzona w języku UML oraz ma zawierać model formalny w postaci sieci Petriego. Wzór opublikowany na stronie.
Etapy realizacji projektu 1 Etap Identyfikacja przypadków użycia Identyfikacja głównych komponentów systemu. Modelowanie z wykorzystaniem sieci Petriego (www.renew.de) Walidacja modelu Opis Przygotowany jest tekstowy opis zawierający scenariusze interakcji aktorów (użytkowników, czujników, siłowników) i systemu Wydzielenie komponentów, które można potraktować, jako działające współbieżnie samodzielne części systemu sterownik, klawiatura, ekran, drukarka, drzwi, silnik, itd.. Sporządzany zostanie model całego systemu w postaci sieci Petriego z tzw. synchronicznymi tranzycjami. W praktyce jest to wykonywalny model komunikujących się maszyn skończeniestanowych Model jest uruchamiany w symulatorze.
Etapy realizacji projektu 1- ilustracja Przypadek użycia Wejście uprawnionego użytkownika Scenariusz główny 1. Użytkownik wkłada kartę do czytnika. 2. System wykrywa obecność karty. Obecność karty sygnalizowana jest przez czytnik. 3. Użytkownik przesuwa kartę. 4. System odczytuje dane. W trakcie przesuwu karty czytnik wysyła do systemu wartości bitów zapisane na ścieżce magnetycznej karty. Czas pomiędzy impulsami 5-200 ms 5. Karta opuszcza czytnik. 6. System wykrywa nieobecność karty i weryfikuje wczytane dane.
Etapy realizacji projektu 2 Etap Model obiektowy Przekształcenie komponentów systemu w klasy Diagram stanu klas Diagramy sekwencji Opis Język UML Główne komponenty systemu zostaną przedstawione jako klasy z metodami odpowiadającymi opisom synchronicznych tranzycji. Na podstawie sieci Petriego zbudowany diagram stanów obiektów. Przejścia pomiędzy stanami mają odbywać się w wyniku wywołania metod lub upływu czasu. Zachowanie systemu przedstawione w postaci diagramu sekwencji
Etapy realizacji projektu 2 ilustracja (analiza wymagań)
Etapy realizacji projektu 3 Etap Projekt systemu Diagram klas Diagram komunikacji (współdziałania, kolaboracji) Diagram stanów obiektów Opis Język UML. Przeniesienie rezultatów analizy obiektowej na daną platformę implementacji. Definiuje klasy (uwzględniające bibliotekę dla danej platformy) Diagram komunikacji pokazuje obiekty składające się na system, ich połączenia oraz wywoływane metody. Z reguły system sterowania, system wybudowany zawiera kilka zadań (wątków) oraz obiektów uczestniczących w komunikacji. Może być przedstawiony w postaci tabeli
Przykład diagramu klas (projekt systemu) Element kluczowy przy przejściu od analizy obiektowej do projektu następuje odwzorowanie wywołań metod w pewien mechanizm komunikacji, zazwyczaj przesłanie komunikatu z sygnaturą metody i jej argumentami.
Przykład diagramu komunikacji (projekt systemu)
Przykład tabeli opisującej diagram stanów Na podstawie tabeli łatwiej zaimplement ować kod (switch-case oraz if)
Etapy realizacji projektu 4 Etap Implementacja Testy Opis Implementujemy klasy występujące na diagramie klas. W metodzie run() wątku implementujemy logikę komponentu opisaną diagramem stanów. Z reguły: Odbieramy komunikat z kolejki W zależności od aktualnego stanu i typu komunikatu zmieniamy stan na nowy i opcjonalnie wykonujemy pewną akcję. Kodowane są tu także zależności czasowe (jeśli komunikat nie nadejdzie w zadanym czasie, to ) Dostarczone są przykłady testów dla wzorcowego projektu
Dlaczego taki zakres? 1 Dla większości współczesnych systemów sterowania nakłady na ich specyfikację to około 50%-70%. Powszechnie jest stosowany język UML. Identyfikacja stanów, modelowanie komponentów systemu w postaci maszyny skończeniestanowej jest podstawową metodą opisu zachowania. Jawna definicja stanów upraszcza weryfikację systemu i czyni projekt bardziej przejrzystym. Wiele systemów ma narzucone wymagania dotyczące ich poprawności. Może być to osiągnięte przez intensywne testy lub zastosowanie metod formalnych.
Dlaczego taki zakres? 2 Zastosowanie metod formalnych polega na zbudowaniu abstrakcyjnego modelu tworzonego systemu z wykorzystaniem jednego z języków modelowania oraz przeprowadzeniu weryfikacji modelu. Może być to pełna weryfikacja (wyliczenie wszystkich stanów i przejść) weryfikacja ograniczona (do pewnej głębokości, w poszukiwaniu błędów) lub symulacja odpowiadająca eksploracji w głąb (stosowana w przypadku złożonych systemów o nieskończonym zbiorze stanów). Sieci Petriego są typowym formalnym językiem opisu systemów współbieżnych i czasu rzeczywistego. Łatwo w nich wyrazić stany i przejścia pomiędzy stanami. W przypadku systemu rozwijanego jako przykład sprawdzony model został w ciągu kilku godzin przeniesiony na platformę implementacji i uruchomiony niemal bez żadnych błędów.
Dlaczego taki zakres? 3 Wybór platformy Java jest pewnym kompromisem W zasadzie projekty mogłyby / powinny być realizowane na porównywalnej platformie symulator systemu operacyjnego czasu rzeczywistego VxVorks. Problemem jest dostęp, licencjonowanie, itp.
Organizacja laboratorium 1 A A A A A A Oddanie projektu B B B B B Egzamin Wątek A typowe zajęcia laboratoryjne Sieci Petriego miejsc i przejść Kolorowane sieci Petriego (Renew) Programowanie współbieżne w języku Java Wykonywane indywidualnie. Udział w zajęciach nie jest oceniany. Cel dostarczenie wzorców jak modelować, jak pisać programy współbieżne w języku Java. Sieci modelujące typowe zagadnienia współbieżności Dodane będą aspekty przetwarzanie danych. W sieciach Renew danymi są obiekty Java. Czas? Programowanie wątków. Monitory. Elementy pakietu java.util.concurrent
Organizacja laboratorium 2 A A A A A A Oddanie projektu B B B B B Egzamin Wątek drugi realizacja projektu Projekty wykonywane w grupach maksymalnie 3-osobowych. Podczas laboratorium konsultowane są kolejne elementy: scenariusze działania systemu, model sieci Petriego, modele UML, implementacja...
Kryteria oceny projektu Element Ogólny opis systemu. Identyfikacja wejść, wyjść oraz głównych komponentów. Scenariusze dla przypadków użycia. Konstrukcja sieci Petriego opisującej zachowanie systemu. Pokazanie symulacji. Analiza obiektowa 0-5 Projekt systemu. Wyznaczenie klas, które będą implementowane. Wybór obiektów aktywnych (wątków). Odwzorowanie metod w mechanizmy komunikacji komunikaty przesyłające sygnatury metod i argumenty, Diagram komunikacji. Diagramy stanów dla obiektów aktywnych. Implementacja 45 Testy 0-5 Udział procentowy 20-25 20-25