Systemy Czasu Rzeczywistego (SCR) Podstawy inżynierii oprogramowania oraz inżynierii systemów sterowania czasu rzeczywistego (wybrane zagadnienia) Politechnika Gdańska Wydział Elektrotechniki i Automatyki Kierunek: Automatyka i Robotyka Studia stacjonarne I stopnia: rok II, semestr IV Opracowanie: dr inż. Tomasz Rutkowski Katedra Inżynierii Systemów Sterowania 1
Oprogramowanie Inżynieria oprogramowania 2
Oprogramowanie Oprogramowanie to programy komputerowe, dokumentacja która jest z nimi związana oraz dane konfiguracyjne Koszty wytworzenia oprogramowania można określić na 60% przedsięwzięcia, przy czym 40% stanowią koszty testowania Ewolucja oprogramowania może przewyższyć koszty jego wytworzenia Koszty zmian oprogramowania wykorzystywanego przez dłuższy czas mogą znacznie przewyższyć koszty jego wytworzenia Inżynierowie oprogramowania pracują w sposób systematyczny i uporządkowany skuteczny sposób na tworzenie oprogramowania wysokiej jakości 3
Inżynierią oprogramowania Inżynieria oprogramowania obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej (od zera lub rozszerzenie i modyfikacja już istniejącego oprogramowania) do jego bieżącej pielęgnacji 4
Różnica pomiędzy inżynierią oprogramowania a informatyką Informatyka obejmuje teorie i podstawowe zasady działania komputerów Inżynieria oprogramowania obejmuje praktyczne problemy związane z tworzeniem oprogramowania Pożytecznym jest aby inżynier oprogramowania znał teorie informatyczne, z drugiej strony nie zawsze (w obecnej chwili) nadają się one do praktycznej (rzeczywistej) implementacji 5
Podstawowe czynności procesu tworzenia systemu oprogramowania Analiza wymagań klienta Celem jest zrozumienie i opisanie wymagań klienta co do planowanego sytemu. Wynikiem jest opracowanie specyfikacji wymagań. Dlaczego klient potrzebuje systemu? Specyfikacja systemu Celem jest opracowanie ogólnej definicji systemu, który będzie spełniał zadane wymagania. Wynikiem jest opracowanie specyfikacji systemu. Jaki system jest potrzebny klientowi? Projektowanie Celem jest dostarczenie abstrakcyjnego rozwiązania specyfikowanego systemu. Rozwiązanie to stanowi jedynie logiczny (abstrakcyjny) opis działania systemu. Wynikiem jest opracowanie dokumentacji projektowej. Jak specyfikowany system ma być wykonany? Programowanie Celem jest przetłumaczenie projektu systemu z zastosowaniem konkretnego języka programowania. Wynikiem jest opracowanie programu wykonywalnego. 6
Podstawowe modele procesów tworzenia systemu oprogramowania Model kaskadowy W tym modelu podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są odrębnymi fazami procesu. Model typu V Model V wyodrębnia wyraźnie dwa etapy związane z różnymi poziomami abstrakcji. Pierwszy zawiera analizę wymagań, specyfikację, projektowanie i programowanie, drugi związany jest z analizą i testowaniem. Szybkie prototypowani W tym podejściu buduje się prototyp systemu, na podstawie szeregu testów można ocenić wymagania formułowane dla systemu. Dopiero w drugim oddzielnym kroku buduje się system. Model przyrostowy (ewolucyjny) W tym modelu czynności specyfikowania, projektowania i zatwierdzania przeplatają się. Tworzenie oprogramowania polega na jego iteracyjnym tworzeniu (rozwijaniu) od najprostszej bazowej wersji. 7
Model kaskadowego procesu tworzenia systemu oprogramowania - Definiowanie wymagań, specyfikacja Projektowanie Programowanie Testowanie i integracja Działanie i pielęgnacja 8
Model kaskadowego procesu tworzenia systemu oprogramowania - problemy Następnej fazy nie powinno się rozpoczynać, jeśli poprzednia się nie zakończy Koszty opracowania i akceptacji dokumentów są wysokie i dlatego iteracje są również kosztowne oraz wymagają powtarzania wielu prac Wadą modelu kaskadowego jest zawarty w nim nieelastyczny podział na rozłączne etapy Model kaskadowy powinien być używany jedynie wówczas, gdy wymagania są jasne i zrozumiałe 9
Model V procesu tworzenia systemu oprogramowania - Potrzeby Produkt Analiza wymagań Testowanie operacyjne Dekompozycja systemu Integracja systemu Specyfikacja Testy oprogramowania Projekt wstępny Testy integracyjne Projekt szczegółowy Testy modułów Programowanie 10
Model V procesu tworzenia systemu oprogramowania - zalety Zwiększa możliwości zarządzania procesem rozwijania systemu przez polepszeni widoczności odpowiednich poziomów Pozwala lepiej zrozumieć zależności odpowiednich opisów systemów i ich wykorzystanie w etapach położonych na tych samych poziomach abstrakcji 11
Model szybkiego prototypowania procesu tworzenia systemu oprogramowania Wymagania Projektowanie Konstrukcja Testowanie Budowanie prototypu Specyfikacja Projektowanie Programowanie Testowanie Integracja Budowanie systemu 12
Model szybkiego prototypowania procesu tworzenia systemu oprogramowania Budowanie prototypu ma głównie na celu eksperymentowanie z tymi wymaganiami użytkownika, które są niejasne 13
14 Wymagania Specyfikacja Projektowanie Programowanie Testowanie Integracja Użytkowanie Wymagania Specyfikacja Projektowanie Programowanie Testowanie Integracja Użytkowanie Wymagania Specyfikacja Projektowanie Programowanie Testowanie Integracja Użytkowanie Model przyrostowy (ewolucyjny) procesu tworzenia systemu oprogramowania
Model przyrostowy (ewolucyjny) procesu tworzenia systemu oprogramowania Problemy Proces nie jest widoczny System ma złą strukturę Konieczne mogą być specjalne narzędzia i techniki Stosowanie W wypadku systemów małych lub średnich z krótkim czasem życia podejście ewolucyjne jest najlepsze W wypadku dużych systemów o długim czasie życia wady tworzenia ewolucyjnego ujawniają się jednak z całą ostrością 15
System Inżynieria Systemów 16
System przykładowa definicja (ogólna) Definicja: System jest to zorganizowany zbiór obiektów (podsystemów), które są od siebie zależne i stanowią pewną częściowo zamkniętą (względem relacji zależności) jednostkę. 17
Cechy Systemu System jest to celowo zorganizowany zbiór obiektów (podsystemów, komponentów), które ze sobą współpracują aby osiągnąć określony cel Duże systemy są zazwyczaj przeznaczone do rozwiązywania złożonych (skomplikowanych) zadań Poprawne działanie każdego z komponentów systemu zależy od funkcjonowania kilku innych komponentów (podsystemów) Złożone zależności między komponentami systemu oznaczają, że system jest czymś więcej niż tylko sumą swoich części (komponentów) składowych System musi być trwały 18
Cechy Systemu Systemy nie są niezależnymi bytami i istnieją w pewnym środowisku Środowisko ma wpływ na funkcjonowanie i efektywność systemu np. system kontroli lotów składa się z tysięcy obiektów (komponentów) programowych, sprzętowych oraz użytkowników, przy czym użytkownik podejmuje decyzję na podstawie informacji otrzymanej z systemu 19
Inżynieria Systemów obejmuje: specyfikowanie, projektowanie, implementowanie, weryfikowanie, wdrażanie Inżynieria Systemów i pielęgnację systemów, postrzeganych jako całość (sprzęt i oprogramowanie). Inżynieria Systemów wymaga dużego wysiłku koordynacyjnego: wzajemne związki pomiędzy obiektami (komponentami) wymóg rozumienia innych dziedzin inżynierii (np.. chemicznej, mechanicznej, środowiskowej, elektronicznej, systemów sterowania, oprogramowania ) 20
Proces inżynierii systemów Definicja wymagań Likwidacja systemu Projektowanie systemu Ewolucja systemu Tworzenie podsystemów sprzęt oprogramowanie Ocena i akceptacja Instalacja systemu Integracja systemu 21
Modelowanie systemu W procesie określania wymagań oraz projektowania systemu musi powstać model systemu w postaci zbioru komponentów systemu i wzajemnych związków między nimi, np.: diagram blokowy schemat technologiczny Często wykorzystuje się UML (ang. Unified Modeling Language), który jest zunifikowanym, standardowym językiem służącym do modelowania różnego rodzaju systemów (NIE TYLKO informatycznych!!!) 22
Inżynieria systemów, inżynieria oprogramowania a komputerowe systemy sterowania 23
Różnica pomiędzy inżynierią oprogramowania a inżynieria systemów Inżynieria systemów komputerowych obejmuje wszystkie aspekty tworzenia i ewolucji systemów komputerowych, w których oprogramowanie odgrywa zasadniczą rolę. Inżynierowie systemów uczestniczą w czynnościach prowadzących do specyfikacji sytemu i zdefiniowania jego architektury sprzętowej i programowej. Inżynieria oprogramowania obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej (od zera lub rozszerzenie i modyfikacja już istniejącego oprogramowania) do jego bieżącej pielęgnacji. Przy czym oprogramowanie jest powiązane z architekturą sprzętową systemu. Inżynierowie oprogramowania uczestniczą w czynnościach prowadzących do specyfikacji sytemu i zdefiniowania jego architektury programowej i sprzętowej. Problemy inżynierii systemów są podobne do problemów inżynierii oprogramowania. 24
Definicja za IEEE/ANSI: System Czasu Rzeczywistego - definicja za standardem IEEE/ANSI System czasu rzeczywistego jest to system komputerowy, w którym obliczenia są wykonywane współbieżnie z procesem zewnętrznym (otoczenie) w celu sterowania, nadzorowania lub terminowego reagowania na zdarzenia występujące w tym procesie (otoczeniu). Komputerowy System Sterowania: przemysłowa sieć informatyczna, urządzenie sterowania cyfrowego, przemysłowa bazy danych, system operacyjne czasu rzeczywistego 25
System Czasu Rzeczywistego i Sterowanie Inżynieria Systemów Sterowania Inżynieria Oprogramowania Systemy Czasu Rzeczywistego Systemy Czasu Rzeczywistego + Oprogramowanie Inżynieria Systemów Komputerowych Komputerowe Systemy Sterowania 26
System Czasu Rzeczywistego - model bodziec-reakcja 27
System Czasu Rzeczywistego - model bodziec-reakcja (odpowiedź) Na podstawie otrzymanego bodźca system musi wygenerować odpowiednią reakcję Bodźce mogą mieć charakter synchroniczny, asynchroniczny lub mieszany (co ma wpływ na wybór typu systemu sterującego czasu rzeczywistego) Zachowanie systemu czasu rzeczywistego można zdefiniować poprzez: zidentyfikowanie i zestawienie bodźców, które może otrzymać odpowiednie odpowiedzi skojarzone z danymi bodźcami czasu, w którym należy przetworzyć dane bodźce 28
System Czasu Rzeczywistego - model bodziec-reakcja (odpowiedź) Detektor Detektor Detektor Detektor System Sterujący Czasu Rzeczywistego Efektor Efektor Efektor Efektor 29
System Czasu Rzeczywistego - model bodziec-reakcja (odpowiedź) Detektor Bodziec Sterowanie detektorem Przetwarzanie danych (odpowiednie obliczenia) Sterowanie efektorem Reakcja Efektor 30
System Czasu Rzeczywistego - model bodziec-reakcja (odpowiedź) Z każdym rodzajem detektora kojarzy się proces sterowania detektorem Procesy przetwarzania danych wyznaczają oczekiwaną odpowiedź na bodźce otrzymane przez system Procesy sterowania efektorami zarządzają działaniem efektorów Model w przedstawionej postaci umożliwia szybkie odbieranie danych od detektorów (zanim będą gotowe następne dane wejściowe), późniejsze ich przetwarzanie i reagowanie przez efektory 31
System Czasu Rzeczywistego - podstawowe wymogi projektowe Część procesu projektowania systemu polega na podjęciu decyzji, które funkcje systemu będą zaimplementowane przez oprogramowanie, a które przez sprzęt (np. związane z ograniczeniami czasowymi) Proces projektowania systemu może więc zarówno obejmować projektowanie odpowiedniego sprzętu jak i projektowanie oprogramowania czasu rzeczywistego 32
System Czasu Rzeczywistego - podstawowe kroki procesu projektowania 1. Zidentyfikować bodźce, które system musi przetwarzać oraz skojarzone z nimi reakcje 2. Dla każdego bodźca i związanej z nim reakcji zidentyfikować wymagania czasowe, które dotyczą przetwarzania zarówno bodźca, jak i reakcji 3. Pogrupować bodźce i reakcje w kilku procesach współbieżnych 33
System Czasu Rzeczywistego - podstawowe kroki procesu projektowania 4. Dla każdego bodźca i reakcji zaprojektować algorytmy do przeprowadzania koniecznych obliczeń (projekty algorytmów często trzeba opracować we wczesnej fazie procesu, aby poznać ilość przetwarzania i czas potrzebny do wykonania niezbędnych obliczeń) 5. Zaprojektować system szeregujący, który zapewni, że procesy będą uruchamiane w odpowiednich chwilach, tak by spełnić ograniczenia czasowe 6. Zintegrować system pod kontrolą modułu wykonawczego 34
Modelowanie systemu model maszyny stanowej (automat skończony) 35
Model maszyny stanowej Służy do opisywania zachowania systemu dynamicznego, gdy reaguje on na wewnętrzne lub zewnętrzne zdarzenia (bodźce) Model maszyny stanowej zawiera skończoną liczbę stanów i skończoną liczbę przejść pomiędzy tymi stanami, które następują w wyniku odpowiednich zdarzeń Model w postaci diagramu obrazuje maszynę stanową w postaci grafu złożonego Modele maszyn stanowych są integralna częścią metod projektowania systemów czasu rzeczywistego (głównie modelowanie zachowania systemów interaktywnych typu bodziec-reakcja) 36
Model maszyny stanowej Stan obiektu zestaw wszystkich wartości atrybutów oraz aktualnych powiązań danego obiektu z innymi obiektami, zmianę aktualnego stanu na inny może spowodować zajście pewnego zdarzenia. Zdarzenie to specyfikacja zjawiska, które zachodzi w czasie i przestrzeni, w maszynie stanowej i jest wystąpieniem bodźca, który może uruchomić przejście między stanami. Zdarzeniami mogą być sygnały, wywołania, upływ czasu i zmiana stanu. Przejście to związek między dwoma stanami, wskazujący, że obiekt znajdujący się w pierwszym stanie wykona pewne akcje i przejdzie do drugiego stanu, zawsze gdy zajdzie określone zdarzenie i będą spełnione określone warunki. 37
Model maszyny stanowej - przykład układu przełącznika kolorowych świateł Klasyczny algorytm blokowy BT1 Zdarzenie przyciśnięcie przycisku w przód BT2 Zdarzenie przyciśnięcie przycisku w tył Źródło: [2] 38
Model maszyny stanowej - przykład układu przełącznika kolorowych świateł Klasyczny algorytm blokowy Automat skończony BT1 Zdarzenie przyciśnięcie przycisku w przód BT2 Zdarzenie przyciśnięcie przycisku w tył Źródło: [2] 39
Model maszyny stanowej - przykład układu przełącznika kolorowych świateł Stan Przejście Zdarzenie Źródło: [2] 40
Model maszyny stanowej - przykład układu przełącznika kolorowych świateł Stany i warunki przejścia Macierz przejść Źródło: [2] 41
Model maszyny stanowej Przykładowa realizacja w języku C 42
UML UML jest zunifikowanym, standardowym językiem graficznym służącym do modelowania różnego rodzaju systemów za pomocą diagramów i słów (NIE TYLKO systemów informatycznych!!!) Wysoki poziom abstrakcji UML gwarantuje całkowitą niezależność od platformy i języka implementacji UML definiuje szereg diagramów podzielonych na dwie główne kategorie strukturalne i zachowania o różnym przeznaczeniu Każdy diagramów UML opisuje analizowany system pod innym kątem, z innej perspektywy jak i na różnym poziomie abstrakcji 43
UML UML 2.5 44
Przykład 2 45
Prosty wojownik mini-sumo SCR 2015 46
Prosty wojownik mini-sumo SCR 2015 47
Prosty wojownik mini-sumo Zastanówmy się jakie są: -bodźce? - detektory? -efektory? -reakcje? 48
Model maszyny stanowej - prosty wojownik mini-sumo Atak wykrycie krawędzi ringu przeciwnik bezpośrednio przed pojazdem Ucieczka od krawędzi ringu (dohyo) manewr oddalający od krawędzi ringu wykrycie krawędzi ringu wykrycie krawędzi ringu Poszukiwanie przeciwnika nie wykryto przeciwnika wykryto przeciwnika Namierzenie przeciwnika 49
Model maszyny stanowej - opis stanów prostego wojownika mini-sumo STAN OPIS PROPOZYCJE AKCJI (REAKCJI) Ucieczka od krawędzi ringu (dohyo) Poszukiwanie przeciwnika Stan w który wchodzi pojazd gdy jeden z czujników sygnalizuje wykrycie krawędzi ringu (dohyo) czujnik białej linii. Pojazd powinien podjąć akcje związaną z utrzymaniem się na ringu, np.: skierowanie pojazdu do środka ringu. Stan w którym podejmowane są akcje mające na celu zlokalizowanie przez pojazd przeciwnika na ringu. Pojazd powinien podjąć akcje związaną ze skanowaniem swojego otoczenia w celu wykrycia przeciwnika (sygnał z radaru) np.: jazda przed siebie z cykliczną zmianą kierunku czy jazda po łukach. jeżeli wykryto krawędź ringu z tyłu pojazdu: jazda do przodu przejście do stanu Poszukiwania przeciwnika jeżeli wykryto krawędź ringu z tyłu pojazdu: wyznaczenie kierunku obrotu pojazdu (w lewo czy w prawo) wykonanie pełnego obrotu o 180 (zawracanie) przejście do stanu Poszukiwania przeciwnika realizacja dostępnych algorytmów pozwalających wykrycie przeciwnika: jazda przed siebie z cykliczną zmianą kierunku ruchu jazda po łukach jeżeli wykryto krawędź ringu to przejdź do stanu Ucieczki od krawędzi ringu jeżeli wykryto przeciwnika w bezpośrednim otoczeniu pojazdu to przejdź do stanu Namierzania przeciwnika Namierzenie przeciwnika Atak Stan w którym pojazd wykrył przeciwnika w swoim otoczeniu (sygnał z radaru). Pojazd powinien podjąć akcje mające na celu zwrócenie się przodem do przeciwnika. Stan w którym przeciwnik został zlokalizowany i znajduje się bezpośrednio z przodu pojazdu (sygnał z radaru). Pojazd powinien ruszyć przed siebie z pełną mocą silników by wypchnąć przeciwnika z ringu. jeżeli przeciwnik zlokalizowany z prawej strony to obrót w prawo jeżeli przeciwnik zlokalizowany z lewej strony to obrót w lewo jeżeli przeciwnik zlokalizowany z tyłu to pełen obrotu o 180 jeżeli przeciwnik zlokalizowany bezpośrednio przed pojazdem to przejdź do stanu Atak jeżeli wykryto krawędź ringu to przejdź do stanu Ucieczki od krawędzi ringu w przeciwnym wypadku przejdź do stanu Poszukiwania przeciwnika jazda do przodu z pełną mocą silników jeżeli wykryto krawędź ringu to przejdź do stanu Ucieczki od krawędzi ringu 50
Model maszyny stanowej - przykład fragmentu programu w C dla prostego wojownika mini-sumo Atak Namierzanie przeciwnika Poszukiwanie przeciwnika 51
Przykład 3 52
Model maszyny stanowej - opis stanów prostej kuchenki mikrofalowej Stan Opis Oczekiwanie Kuchenka czeka na dane wejściowe. Wyświetlacz pokazuje aktualną godzinę. Połowa mocy Pełna moc Ustawienie czasu Niegotowy Gotowy Działanie Moc kuchenki ustawiono na 500 watów. Wyświetlacz pokazuje napis Połowa mocy. Moc kuchenki ustawiono na 1000 watów. Wyświetlacz pokazuje napis Pełna moc. Czas trwania gotowania jest ustawiany na wartość wprowadzoną przez użytkownika. Wyświetlacz pokazuje wybrany czas gotowania i jest aktualizowany w miarę wprowadzania danych. Kuchenka nie może działać ze względów bezpieczeństwa. Wewnętrzne światło kuchenki jest włączone. Wyświetlacz pokazuje napis Niegotowy. Kuchenka jest gotowa do działania. Wewnętrzne światło jest wyłączone. Wyświetlacz pokazuje napis Gotowy. Kuchenka działa. Wewnętrzne światło jest włączone. Wyświetlacz odlicza zmniejszający się czas pozostały do zakończenia gotowania. Po zakończeniu brzęczyk włącza się na 5 sekund. Światło kuchenki jest wtedy włączone. Wyświetlacz pokazuje napis Gotowanie zakończone w czasie działania brzęczka. Źródło: [3] 53
Model maszyny stanowej - opis działania prostej kuchenki mikrofalowej Notacja UML Sprawdzenie do: sprawdź stan Działanie OK Czas Gotowanie do: praca generatora Awaria talerza obrotowego Alarm do: wyświetlaj zdarzenie Awaria źródła fal Koniec czasu Wykonano do: włącz brzęczek na 5 sekund Niegotowy Otworzono drzwiczki Oczekiwanie Zatrzymaj Źródło: [3] 54
Model maszyny stanowej - prosta kuchenka mikrofalowa Pełna moc Pełna moc do: ustaw moc = 1000 Notacja UML Połowa mocy Oczekiwanie do: wyświetlaj godzinę Połowa mocy Pełna moc Połowa mocy do: ustaw moc = 500 Stoper Stoper Ustawienie czasu do: odczytaj liczbę Exit: ustaw czas Otworzono drzwiczki Niegotowy do: wyświetlaj Czekam Zamknięto drzwiczki Liczba Zamknięto drzwiczki Początek Działanie do: podgrzewanie Otworzono drzwiczki Gotowy do: wyświetlaj Gotowy Zatrzymaj Oczekiwanie do: wyświetlaj godzinę Źródło: [3] 55
Model maszyny stanowej - opis bodźców dla prostej kuchenki mikrofalowej Bodziec Połowa mocy Pełna moc Stoper Liczba Otworzono drzwiczki Zamknięto drzwiczki Początek Zatrzymaj Opis Użytkownik nacisnął przycisk Połowa mocy Użytkownik nacisnął przycisk Pełna moc Użytkownik nacisnął przycisk Stoper Użytkownik nacisnął przycisk z liczbą Przełącznik drzwiowy jest niezamknięty Przełącznik drzwiowy jest zamknięty Użytkownik nacisnął przycisk Początek Użytkownik nacisnął przycisk Zatrzymaj Źródło: [3] 56
Model maszyny stanowej - opis reakcji dla prostej kuchenki mikrofalowej Reakcja Opis?? 57
Przykład 4 58
Modelowanie systemu - prosty system antywłamaniowy Detektory ruchu Detektory drzwiowe Centralka alarmu Syrena Syntezator mowy Automat dzwoniący Zewnętrzne centrum monitoringu Źródło: [3] 59
Model maszyny stanowej - bodźce/reakcje prostego systemu antywłamaniowego Bodziec/reakcja Wymagania czasowe Przerwanie zanik Przełączenie na zasilanie zapasowe musi być ukończone po najwyżej zasilania 50ms Alarm drzwiowy Alarm okienny Detektor ruchu Sygnał dźwiękowy Włączenie świateł Każdy detektor drzwiowy musi być odpytywany dwa razy na sekundę Każdy detektor okienny musi być odpytywany dwa razy na sekundę Każdy detektor ruchu powinien być odpytywany dwa razy na sekundę Sygnał dźwiękowy musi być włączony po upływie najwyżej 1 sekundy od alarmu wywołanego przez detektor Światła powinny być włączone po upływie najwyżej 1/2 sekundy od alarmu wywołanego przez detektor Komunikacja Wezwanie policji przez telefon należy rozpocząć po upływie najwyżej 2 sekund od alarmu wywołanego przez detektor Syntezator mowy Komunikat z syntezatora powinien być dostępny po upływie najwyżej 4 sekund od alarmu wywołanego przez detektor Źródło: [3] 60
Architektura procesowa prostego systemu antywłamaniowego 10 Hz 10 Hz 10 Hz Źródło: [3] Proces detektorów ruchu Proces detektorów drzwiowych Proces detektorów okiennych Stan detektorów 200 Hz Stan detektorów Stan detektorów Proces monitorowania budynku System alarmowy Przerwanie braku zasilania Proces przełączania zasilania Kontroler budynku System alarmowy Numer pokoju Proces systemu alarmowego Numer pokoju System alarmowy Proces komunikacyjny Komunikat alarmowy Proces sygnalizacji Proces sterowania Numer pokoju Proces syntezatora dźwiękowej światłami mowy 61
Przykład 5 62
Zbiornik w procesie technologicznym Zbiornik w procesie technologicznym (przykład z poprzedniego wykładu ) 63
Bibliografia: [1] T. Szmuc, G.Motet(2000). Specyfikacja i projektowanie oprogramowania systemów czasu rzeczywistego. Uczelniane Wydawnictwa Naukowo-Dydaktyczne, Kraków. [2] Elektronika praktyczna 1/2010. [3] I. Sommervill(2003). Inżynieria oprogramowania. WNT. 64
Dziękuję za uwagę!!! 65