Badania naukowe

Przykładem zastosowań systemów czasu rzeczywistego mogą być przedmioty
codziennego użytku: pralki, kuchenki, aparaty fotograficzne, a także systemy nawigacji (samoloty, satelity, rakiety) czy sterowania zakładami przemysłowymi, np. elektrownie.

Tomasz Szmuc, Radosław Klimek

 Nie tak rzadko spotykamy się z sytuacją, gdy pewnemu pojęciu przypisywane mogą być różne znaczenia i konotacje, w zależności od dziedziny zainteresowania i obszaru badania. Takim przykładem może być pojęcie czasu rzeczywistego. Inaczej będzie się ono kojarzyć teologowi, odmiennie humaniście, inaczej może matematykowi, a jeszcze inaczej informatykowi. Na gruncie informatyki pojęcie to jest dobrze rozpoznane, a systemy czasu rzeczywistego stanowią trudną i specyficzną dziedzinę informatyki. Tematem niniejszego artykułu są zagadnienia związane z czasem rzeczywistym i systemami czasu rzeczywistego w obszarze zainteresowania informatyki, tak jak są one tutaj widziane. Celem artykułu jest zapoznanie czytelnika z tymi zagadnieniami na poziomie popularnym, jednak bez pominięcia istoty tych zagadnień z naukowego punktu widzenia.
Informatyka zajmuje się, ujmując to w dużym uproszczeniu, metodami, narzędziami i systemami automatycznego przetwarzania informacji. Na przetwarzanie składa się wiele zagadnień pokrewnych, takich jak na przykład algorytmy obliczeniowe, metody i sposoby przechowywania danych, architektura i organizacja obliczeń, a także inne. Oczywiście, zawsze warto dodać, że obliczenia wykonywane są najczęściej, co wymuszane jest oczekiwaniem efektywności, za pomocą komputerów, które z kolei są praktyczną realizacją pewnej czysto teoretycznej koncepcji matematycznej, zwanej maszyną Turinga.

Każdy proces obliczeniowy wymaga weryfikacji ze względu na poprawność obliczeń, tzn. zagwarantowanie rzeczywistego uzyskania zaplanowanych wyników, w tym także niedopuszczenie do sytuacji zablokowania się systemu obliczeniowego. Uzyskiwanie takiej gwarancji odbywa się zazwyczaj na dwa, leżące na przeciwległych biegunach, sposoby. Pierwszy związany jest z formalnym (i pozawykonawczym) dowodzeniem poprawności systemu. Drugi z kolei polega na przygotowaniu odpowiednich – reprezentujących zarówno typowe, jak i nietypowe – zestawów danych i sprawdzeniu, jak system zachowuje się w takich okolicznościach. Każda z tych dróg postępowania, będących zresztą samymi w sobie zagadnieniami bardzo złożonymi, ma swoje wady i zalety, co więcej, ma swoich gorących zwolenników i zdecydowanych przeciwników. Żaden z tych aspektów nie jest jednak przedmiotem artykułu, a wątek ten będzie już tylko zakończony stwierdzeniem, iż chociaż wydaje się, że metody te sytuowane są zazwyczaj na przeciwnych biegunach postępowania, to powinny być raczej traktowane jako komplementarne.

ROZMYCIE ZACHOWANIA

Poprawność w sensie zwykłego (klasycznego) systemu obliczeniowego nie jest jednak wystarczająca w przypadku systemu czasu rzeczywistego. System taki musi nie tylko poprawnie wykonywać obliczenia, co jest warunkiem sine qua non, ale dodatkowo także nadążać za zdarzeniami zachodzącymi w otaczającym świecie rzeczywistym, które mogą mieć bardzo różne i co więcej, za każdym razem odmienne dla tych samych zestawów danych, odwzorowania na osi czasowej. Tak więc, na typowe oczekiwanie poprawności nakładane są dodatkowo różne wymagania związane z czasem, które w systemach klasycznych byłyby praktycznie nieistotne. Te dodatkowe wymagania, to np. terminowość obliczeń (dostarczania wyników), nieprzerwane i ciągłe działanie czy czasem nawet synchroniczne (pulsacyjne) dostarczanie danych.

Systemy czasu rzeczywistego charakteryzują się jeszcze jednym bardzo istotnym czynnikiem, a mianowicie współbieżnością obliczeń. Współbieżność związana jest z logicznym, ale też i nieuchronnie fizycznym podziałem całego systemu obliczeniowego na fragmenty mniejsze, z których każdy jest odpowiedzialny funkcjonalnie za inne zadania. Przykładem mógłby tu być klasyczny system rezerwacji miejsc z wyróżnionym modułem zapytania do systemu, dokonywania rezerwacji miejsc (zapis do bazy danych), modułem księgowym czy sporządzania raportów. Ze współbieżnością związana jest często także wielodostępność, polegająca na możliwości jednoczesnego uruchomienia wielu identycznych funkcjonalnie procesów. W systemie rezerwacji miejsc mogą to być poszczególne (identyczne) stanowiska obsługi klientów. Są to wszystko zagadnienia bardzo istotne i, aczkolwiek nie leżące w centrum zainteresowania informatyki czasu rzeczywistego, to jednak mające na nią wyraźny wpływ poprzez skomplikowanie dziedziny rozważań. Skalę trudności niech scharakteryzuje jeszcze tylko zwrócenie uwagi na różne odmiany architektur aplikacji typu klient-serwer, a także głośne ostatnio za sprawą aplikacji internetowych architektury trójwarstwowe.

Systemy czasu rzeczywistego charakteryzują się więc współbieżnością i uwarunkowaniami czasowymi. Wymaganie współbieżności wynika z konieczności ogólnej gotowości do obsługi wielu jednocześnie pojawiających się, w dowolnych momentach czasowych, zdarzeń, natomiast uwarunkowania czasowe precyzują, w jakim czasie (momencie lub przedziale czasowym) poszczególne odpowiedzi systemu powinny być przesyłane do otoczenia, którym może być sterowany proces, urządzenie wykonawcze, klienci bankomatu itp. System czasu rzeczywistego składa się zatem z wielu (często wielu setek) współbieżnych procesów, co znacznie utrudnia analizę zachowania takiego systemu, gdyż jego dynamika zależy od zachowania wszystkich wspomnianych procesów, zarówno rozpatrywanych z osobna, jak i w całości, dodatkowo z nałożonymi ograniczeniami czasowymi. Powoduje to rozmycie zachowania, gdyż nie możemy określić dokładnie jednego stanu następnego (może być ich bardzo wiele), co z kolei jest w oczywistej opozycji do wymagania dokładnego spełniania wymagań czasowych.

SPECYFIKA I ZŁOŻONOŚĆ

Systemy czasu rzeczywistego mogą pełnić rolę podrzędną (usługową) względem innego systemu (obliczeniowego), ale mogą także same nadzorować inne obiekty. Sam czynnik czasowy ma charakter jakościowy – każdorazowo różna kolejność zdarzeń świata zewnętrznego ma wpływ na zachowania i reakcje systemu, a także ilościowy – reakcja systemu zależy od czasu upływającego, pozostałego do pewnego wyznaczonego momentu czasowego. Specyfika systemów czasu rzeczywistego, to, z jednej strony, zależność od otoczenia, ale również oczywista tylko tutaj przewidywalność poprzez narzucenie pewnych decyzji i działań, jako skutek postulatu terminowości i punktualności.

O specyfice i złożoności systemów czasu rzeczywistego może także świadczyć problem języków programowania zorientowanych na ten obszar zainteresowania. Oczywista konieczność uwzględnienia w wytwarzanym kodzie (programie) sytuacji, gdy pewne zdarzenie, pomimo oczekiwania na nie, nie ma jednak miejsca, np. nie nadchodząca wiadomość z odczytanymi (nowymi) wynikami innych, współbieżnie wykonywanych obliczeń, nie znajduje bezpośredniego odzwierciedlenia w powszechnie dostępnych językach programowania. Tymczasem system czasu rzeczywistego nie może doprowadzić, w oczekiwaniu na wystąpienie zdarzenia, do zawieszenia się i musi zawsze podjąć odpowiednie, zaplanowane działania, z uwzględnieniem bądź to pozytywnego, bądź negatywnego scenariusza. Większość języków programowania nie uwzględnia w swoich możliwościach konstrukcyjnych w sposób szczególny takich sytuacji, gdyż praktycznie nie występują one w klasycznych systemach obliczeniowych. Większość języków programowania wykorzystuje się do zagadnień czasu rzeczywistego zazwyczaj dopiero po dołączeniu specjalnych, dedykowanych bibliotek oprogramowania. Jedynym wyjątkiem jest tu język programowania Ada95, język, co należy podkreślić, ogólnego przeznaczenia, zaprojektowany jednak z niezwykłą starannością i kulturą informatyczną, w którym przewidziano wiele sytuacji typowych dla systemów czasu rzeczywistego. (Na marginesie można zauważyć, że język ten nazwano na cześć Ady Augusty Lovelace, jedynej córki znanego poety romantycznego lorda George’a Byrona. Ada Lovelace uchodzi za pierwszą w świecie programistkę-programistę, jako asystentka Charlesa Babbage’a, twórcy maszyn uważanych dzisiaj za pierwowzory współczesnych komputerów.)

TWARDE, MIĘKKIE I MIESZANE

Dziedzina zastosowań systemów czasu rzeczywistego jest doprawdy ogromna. Świadczyć o tym mogą już najprostsze systemy, często określane w informatyce czasu rzeczywistego mianem wbudowanych, stanowiące elementy większej całości i realizujące część jego istotnych, a nieraz kluczowych, funkcji. Dobrym przykładem zastosowań mogą być przedmioty codziennego użytku: pralki, kuchenki, aparaty fotograficzne, a także systemy bardziej złożone i dużej skali, np. systemy nawigacji (samoloty, satelity, rakiety) czy sterowania zakładami przemysłowymi (np. elektrownie), jak również systemy dowodzenia i nadzoru. Co więcej, obszar zastosowań ciągle ulega powiększeniu, o czym mogą świadczyć np. zastosowania telekomunikacyjne, m.in. towarzysząca nam już w sposób powszechny telefonia komórkowa. Wszystko to powoduje, że dziedzina systemów czasu rzeczywistego wypracowała i wypracowuje własne narzędzia, modele i metody, stanowiąc prawdziwe wyzwania dla naukowców i inżynierów.

Wymagania czasowe formułowane w różny sposób, również względem stopnia ich spełnialności, pozwalają na wprowadzenie podstawowej klasyfikacji systemów czasu rzeczywistego. Systemy takie dzielimy na systemy o twardych (ang. hard real-time) oraz miękkich (ang. soft real-time) wymaganiach czasowych. W pierwszym przypadku oczekujemy, aby wszystkie ograniczenia czasowe w systemie zostały spełnione. Zwróćmy uwagę, że budując taki system musimy wykazać jego poprawność z ograniczeniami czasowymi już na etapie projektowania – faza eksploatacji jest w sposób oczywisty na to zbyt późna, a tzw. zawieszenie systemu w oczekiwaniu na jakieś przeterminowane zdarzenie jest po prostu niedopuszczalne. Przykładem systemów o twardych wymaganiach czasowych mogą być np. systemy sterowania elektrowniami czy, ogólnie, zakładami produkcyjnymi albo też poszczególnymi urządzeniami usytuowanymi w ważnych miejscach, np. samolotach czy innych środkach transportu (wysuw podwozia w samolocie, system ABS w samochodzie itp.). W systemach czasu rzeczywistego o miękkich wymaganiach czasowych dopuszczalne jest sporadyczne przeterminowanie zdarzeń, mówimy więc tutaj raczej o wymaganiach czasowych spełnialnych statystycznie. Warto zwrócić uwagę, że fakt mniejszych oczekiwań względem terminowości zdarzeń nie ułatwia bynajmniej fazy dowodzenia poprawności w trakcie budowania systemu, o ile go nawet nie utrudnia. Przykładem systemu o miękkich wymaganiach czasowych są systemy rezerwacji miejsc, gdzie w przypadku pojedynczych żądań możliwe jest opóźnienie.

Oprócz systemów o twardych lub miękkich wymaganiach czasowych dopuszcza się także istnienie systemów mieszanych (ang. firm real-time), gdzie poszczególne wymagania czasu rzeczywistego mogą mieć zarówno charakter twardy, jak i miękki. W przypadku systemów czasu rzeczywistego szczególnie żądamy, aby działały one nieprzerwanie od momentu ich zainicjowania do fazy usuwania. Również to wymaganie wpływa istotnie na sposób konstrukcji oprogramowania – rozbudowana obsługa tzw. wyjątków, czyli akcji podejmowanych w przypadku wykrycia stanów awaryjnych. Wszystkie wymienione cechy, które należą do podstawowych, definiują specyfikę i odrębność systemów czasu rzeczywistego, należących do wydzielonego i dobrze określonego obszaru współczesnej informatyki.

WZRASTA RANGA

Problematyka systemów czasu rzeczywistego jest przedmiotem badania wielu krajowych ośrodków naukowych. Doczekała się także konferencji naukowej, będącej miejscem spotkania i prezentacji osiągnięć zarówno badaczy, jak i przedstawicieli przemysłu. Konferencja pod nazwą Systemy Czasu Rzeczywistego ma już ugruntowaną pozycję i zyskuje na znaczeniu. Ma ona charakter wędrujący, tzn. organizowana jest rokrocznie przez różne krajowe ośrodki naukowe. Ostatnie dwie edycje konferencji, VII oraz VIII, zostały zorganizowane przez Katedrę Automatyki AGH, kolejno w Krakowie oraz w Krynicy. Dokładne informacje o poszczególnych edycjach (SCR 2000 oraz SCR ‘01) można znaleźć w witrynach internetowych http://galaxy.uci.agh.edu.pl/~scr2000  oraz http://galaxy.uci.agh.edu.pl/~scr01  , które po zakończeniu konferencji stanowią także miejsce umieszczania informacji o charakterze archiwalnym.
Cała konferencja trwa łącznie trzy i pół dnia. W pierwszym dniu wygłaszane są tzw. wykłady zaproszone dla zainteresowanych uczestników – w obu latach udało się stworzyć bardzo interesujący program tych wykładów, które po zakończeniu konferencji wydawane są drukiem. W kolejne dni wygłaszane są przyjęte i wydrukowane w materiałach konferencyjnych referaty. Każdy z nich oceniany jest przez dwóch niezależnych i anonimowych recenzentów, zawsze pochodzących z innego ośrodka niż sam autor. Warto zauważyć, że obie edycje konferencji cieszyły się dużą liczbą zarówno zgłoszonych referatów – nie wszystkie mogły być przyjęte – jak i aktywnych uczestników. O wzrastającej randze konferencji może świadczyć także fakt, że obie edycje wsparła Motorola Polska Software Center, a w ostatnim roku także Komitet Badań Naukowych.

Dr hab. inż. Tomasz Szmuc, prof. AGH, informatyk, i dr inż. Radosław Klimek pracują w Katedrze Automatyki na Wydziale Elektrotechniki, Automatyki, Informatyki i Elektroniki Akademii Górniczo-Hutniczej w Krakowie.

Komentarze