Różnice między twardym czasem rzeczywistym, miękkim czasem rzeczywistym i twardym czasem rzeczywistym?

Hard Real-Time

Definicja hard real-time uważa, że każdy niedotrzymany termin jest awarią systemu. Planowanie to jest szeroko stosowane w systemach o znaczeniu krytycznym, w których brak zgodności z ograniczeniami czasowymi powoduje utratę życia lub mienia.

Przykłady:

• Lot Air France 447 rozbił się o ocean po awarii czujnika spowodowanej serią błędów systemu. Piloci zatrzymali samolot podczas reaguję na przestarzałe odczyty przyrządów. Zginęło 12 członków załogi i 216 pasażerów.

• Sonda Mars Pathfinder została prawie utracona, gdy odwrócenie priorytetu spowodowało ponowne uruchomienie systemu. Zadanie o wyższym priorytecie nie zostało ukończone na czas z powodu zablokowania przez zadanie o niższym priorytecie. Problem został rozwiązany i statek kosmiczny wylądował pomyślnie.

• Drukarka Atramentowa posiada głowicę drukującą z oprogramowaniem sterującym do nanoszenia odpowiedniej ilości tuszu na konkretna część artykułu. Jeśli termin zostanie pominięty, zadanie drukowania zostanie zrujnowane.

Firma W Czasie Rzeczywistym

Definicja firmy w czasie rzeczywistym pozwala na rzadko niedoszłe terminy. W tych aplikacjach system może przetrwać niepowodzenia zadań tak długo, jak są one odpowiednio rozmieszczone, jednak wartość wykonania zadania spada do zera lub staje się niemożliwe.

Przykłady:

• Systemy produkcyjne z linie montażowe robotów, w których brak terminu skutkuje nieprawidłowym montażem części. Dopóki zniszczone części są na tyle rzadkie, że mogą zostać złapane przez kontrolę jakości i nie są zbyt kosztowne, produkcja trwa.

• Cyfrowy dekoder kablowy dekoduje znaczniki czasu, kiedy ramki muszą pojawić się na ekranie. Ponieważ ramki są wrażliwe na kolejność czasową, niedotrzymany termin powoduje jitter, obniżając jakość usług. Jeśli pominięta ramka stanie się później dostępna, spowoduje to tylko więcej jittera, aby go wyświetlić, więc jest bezużyteczny. Widz może nadal korzystać z programu, jeśli jitter nie występuje zbyt często.

Soft Real-Time

Definicja soft real-time pozwala na często niedoszłe terminy, a tak długo, jak zadania są wykonywane terminowo, ich wyniki nadal mają wartość. Ukończone zadania mogą mieć wartość rosnącą do terminu i wartość malejącą po nim.

Przykłady:

• Stacje pogodowe posiadają wiele czujników do odczytu temperatury, wilgotności, prędkości wiatru itp. Odczyty powinny być odbierane i przesyłane w regularnych odstępach czasu, jednak czujniki nie są zsynchronizowane. Nawet jeśli odczyt z czujnika może być wczesny lub późny w porównaniu z innymi, może być ważny, o ile jest wystarczająco blisko.

• Konsola gier wideo uruchamia oprogramowanie dla silnika gry. Istnieje wiele zasobów, które muszą być dzielone między swoje zadania. W tym samym czasie zadania muszą być wykonane zgodnie z harmonogramem gry, aby grać poprawnie. Tak długo, jak zadania są całkowicie relatywnie na czas gra będzie przyjemna, a jeśli nie może to tylko trochę opóźnić.

^{Siewert: Systemy wbudowane w czasie rzeczywistym i Komponenty.
Liu & Layland: algorytmy planowania do Wieloprogramowania w trudnym środowisku czasu rzeczywistego.
Marchand & Silly-Chetto: dynamiczne planowanie miękkich Zadań Aperiodycznych i okresowych zadań z Pominięciami.}

Po przeczytaniu strony wikipedii i innych stron dotyczących obliczeń w czasie rzeczywistym. Wyciągnąłem następujące wnioski:

1> dla twardego systemu czasu rzeczywistego, Jeśli system nie dotrzyma terminu, nawet gdy system zostanie uznany za nieudany.

2> dla firmowego systemu czasu rzeczywistego , nawet jeśli system nie dotrzyma terminu, prawdopodobnie więcej niż jeden raz (tj. dla wielu żądań), system nie jest uważany za zawiedziony. Również odpowiedzi na wnioski (odpowiedzi na zapytanie, wynik zadania, itp.) są bezwartościowe po upływie terminu dla danego żądania (użyteczność wyniku wynosi zero po jego terminie ). Hipotetycznym przykładem może być system prognozowania burzy (jeśli burza jest przewidywana przed przybyciem, to system wykonał swoją pracę, przewidywanie po zdarzeniu już miało miejsce lub kiedy się dzieje nie ma wartości).

3> dla miękkiego systemu czasu rzeczywistego , nawet jeśli system nie spełnia termin, prawdopodobnie więcej niż jeden raz (tj. w przypadku wielu żądań), system nie jest uważany za zawiedziony. Ale w tym przypadku wyniki żądań nie są bezwartościowe wartość dla wyniku po jego terminie, nie jest równa zeru, raczej ulega degradacji w miarę upływu czasu po upływie terminu. Np.: Streaming audio-video.

Tutaj {[20] } jest link do zasobu, który był bardzo pomocny.

Popularne jest kojarzenie jakiejś wielkiej katastrofy z definicją twardego czasu rzeczywistego, ale to nie ma znaczenia. Każde niepowodzenie w spełnieniu twardego ograniczenia w czasie rzeczywistym oznacza po prostu, że system jest uszkodzony. Powaga wyniku, gdy coś jest oznaczone jako "zepsute", nie jest istotna dla definicji.

Firma i miękka po prostu nie mogą być automatycznie uznane za złamane w przypadku niedotrzymania jednego terminu.

Dla przykładu twardego czasu rzeczywistego, ze strony Ty linked:

Wczesne systemy gier wideo, takie jak Atari 2600 i grafika wektorowa Cinematronics, miały trudne wymagania w czasie rzeczywistym ze względu na charakter grafiki i sprzętu taktującego.

Jeśli coś w pętli generowania wideo przegapiło tylko jeden termin, cały wyświetlacz uległby usterce, co byłoby nie do zniesienia, nawet jeśli byłoby to rzadkie. To byłby zepsuty system i zabierałbyś go do sklepu po zwrot pieniędzy. Więc trudno w czasie rzeczywistym.

Oczywiście każdy system może być narażony na sytuacje, z którymi nie może sobie poradzić, dlatego konieczne jest ograniczenie definicji do tego, że mieści się ona w oczekiwanych warunkach pracy-zauważając, że w krytycznych dla bezpieczeństwa zastosowaniach ludzie muszą planować straszne warunki ("chłodziwo wyparowało"," hamulce zawiodły", ale rzadko"słońce eksplodowało").

I nie zapominajmy, że czasami jest ukryty" gdy ktoś patrzy " warunek operacyjny. Jeśli nikt nie widzi łamiesz zasady (a jeśli tak, ale giną w ogniu, zanim komukolwiek o tym powiesz) i nikt nie udowodni, że złamałeś zasady po fakcie, to jest tak jakby to samo, jakbyś nigdy nie złamał zasad!

Najprostszym sposobem rozróżnienia różnych typów systemów czasu rzeczywistego jest odpowiedź na pytanie:

Czy opóźniona odpowiedź systemu (po terminie) jest nadal przydatna czy nie?

Więc w zależności od odpowiedzi na to pytanie, Twój system może być zaliczony do jednej z następujących kategorii:

1. Hard: nie, a opóźnione odpowiedzi są uważane za awarię systemu

Tak jest w przypadku, gdy brakuje ślepa linia spowoduje, że system będzie bezużyteczny. Na przykład system kontrolujący system poduszek powietrznych samochodu powinien wykryć awarię i szybko napompować torbę. Cały proces trwa mniej więcej jedną dwudziestą piątą sekundy. Tak więc, jeśli system na przykład zareaguje z 1 sekundą opóźnienia, konsekwencje mogą być śmiertelne i nie będzie żadnej korzyści, gdy worek napompowany, gdy samochód już się rozbił.

1. Firma: nie, ale opóźnione odpowiedzi nie są konieczne awaria systemu

Tak jest w przypadku, gdy brak terminu jest tolerowany, ale wpłynie to na jakość usługi. Jako prosty przykład rozważ system szyfrowania wideo. Zwykle hasło szyfrowania jest generowane na serwerze (Głowica wideo) i wysyłane do dekodera klienta. Proces ten powinien być zsynchronizowany, więc zwykle dekoder odbiera hasło przed rozpoczęciem odbierania zaszyfrowanych ramek wideo. W takim przypadku opóźnienie może prowadzić do usterki wideo, ponieważ dekoder nie jest w stanie dekodować ramek, ponieważ nie otrzymał jeszcze hasła. W takim przypadku na serwis (film, ciekawy mecz piłkarski itp.) może wpłynąć nie dotrzymanie terminu. Odbieranie hasła z opóźnieniem w tym przypadku nie jest przydatne, ponieważ ramki zaszyfrowane tym samym już spowodowały usterki.

1. Soft: Tak, ale usługa systemu jest zdegradowana

Jak z Wikipedii opis użyteczność wyniku pogarsza się po jego terminie . Oznacza to, że uzyskanie odpowiedzi z systemu poza terminem jest nadal przydatne dla użytkownika końcowego, ale jego przydatność zmniejsza się po osiągnięciu terminu. Prostym przykładem w tym przypadku jest oprogramowanie, które automatycznie kontroluje temperaturę pomieszczenia (lub budynku). W takim przypadku, jeśli system ma pewne opóźnienia odczytu czujników temperatury, będzie trochę powolny, aby reagować na brukowe zmiany temperatury. Jednak na końcu będzie reagować na zmianę i odpowiednio dostosowywać temperaturę, aby utrzymać ją na przykład na stałym poziomie. Tak więc w tym przypadku opóźniona reakcja jest przydatna, ale pogarsza jakość usług systemu.

A soft real time jest najłatwiejszy do zrozumienia, w którym nawet jeśli wynik zostanie uzyskany po upływie terminu, wyniki są nadal uważane za ważne.

przykład: przeglądarka internetowa - żądamy określonego adresu URL, ładowanie strony zajmuje trochę czasu. Jeśli system zajmie nam więcej niż oczekiwano czasu na dostarczenie nam strony, uzyskana strona nie jest uważana za nieprawidłową, mówimy tylko, że wydajność systemu nie była zgodna z wartością (system dał niskie wydajność!).

W systemie hard real time , jeśli wynik zostanie uzyskany po upływie terminu, uznaje się, że system nie powiódł się całkowicie.

przykład: W przypadku robota wykonującego jakąś pracę, np. śledzenie linii itp. Jeśli na jego drodze pojawi się przeszkoda, a robot nie przetworzy tej informacji w zaprogramowanym terminie (prawie natychmiast!), mówi się, że robot zawiódł w swoim zadaniu (system robotów może również zostać całkowicie zniszczony!).

In firm real time system, jeśli wynik wykonania procesu nastąpi po upływie terminu, odrzucamy ten wynik, ale system nie jest określany jako nieudany.

przykład: komunikacja satelitarna do monitorowania pozycji wroga lub innego zadania. Jeśli naziemna stacja komputerowa, do której satelity wysyłają ramki okresowo jest przeciążona, a bieżąca ramka (pakiet) nie jest przetwarzana w czasie i pojawia się następna ramka, bieżący pakiet (ten, który przegapił termin) nie ma znaczenia, czy przetwarzanie zostało wykonane (lub w połowie lub prawie) jest odrzucane / odrzucane. Ale komputer naziemny nie jest określany jako całkowicie zawiedziony.

Aby zdefiniować "miękki czas rzeczywisty", najłatwiej porównać go z " twardym czasem rzeczywistym."Poniżej zobaczymy, że termin" firm real-time "stanowi nieporozumienie na temat" soft real-time."

Mówiąc swobodnie, większość ludzi pośrednio ma nieformalny model mentalny, który uważa informację lub wydarzenie za "czas rzeczywisty"

• Jeśli, lub w takim zakresie, w jakim jest to dla nich oczywiste z opóźnieniem (latencją), które może być związane z postrzeganą walutą

* tzn. w czasie ramka, że informacja lub zdarzenie ma dla nich zadowalającą wartość.

Istnieje wiele różnych definicji ad hoc "twardego czasu rzeczywistego", ale w tym modelu mentalnym twardy czas rzeczywisty jest reprezentowany przez termin "jeśli". W szczególności, zakładając, że działania w czasie rzeczywistym (takie jak zadania) mają terminy realizacji, akceptowalnie zadowalająca wartość zdarzenia, że wszystkie zadania ukończone, jest ograniczona do szczególnego przypadku, że wszystkie zadania spełniają swoje terminy.

Twarde systemy czasu rzeczywistego sprawiają, że bardzo silne założenia, że wszystko o aplikacji, systemie i środowisku jest statyczne i znane a ' priori-np., które zadania, że są okresowe, ich czasy przybycia, ich okresy, ich terminy, że nie będą miały konfliktów zasobów, i ogólnie ewolucja czasu systemu. W systemie sterowania lotem statku powietrznego lub samochodowym układzie hamulcowym i wielu innych przypadkach założenia te mogą być zazwyczaj spełnione, aby dotrzymać wszystkich terminów.

This mental model jest celowo i bardzo użyteczny na tyle ogólny, aby objąć zarówno twardy, jak i miękki czas rzeczywisty-miękki jest akceptowany przez frazę "do tego stopnia, że". Na przykład, załóżmy, że zdarzenie zakończenia zadania ma nieoptymalną, ale akceptowalną wartość, jeśli

• nie więcej niż 10% zadań nie dotrzymuje terminów
• lub żadne zadanie nie jest więcej niż 20% spóźnione
• lub średnia spóźnienie wszystkich zadań jest nie więcej niż 15%
• lub maksymalna opieszałość wszystkich zadań jest mniejsza niż 10%

Są to typowe przykłady miękkich przypadków w czasie rzeczywistym w wielu aplikacjach.

Rozważ jedno-zadaniową aplikację polegającą na odebraniu dziecka po szkole. To prawdopodobnie nie ma rzeczywistego terminu, zamiast tego istnieje pewna wartość dla Ciebie i Twojego dziecka w oparciu o to, kiedy to wydarzenie ma miejsce. Zbyt wcześnie marnuje zasoby (takie jak Twój czas) , a zbyt późno ma pewną negatywną wartość, ponieważ twoje dziecko może zostać pozostawione w spokoju i potencjalnie zagrożone (lub przynajmniej niewygodne).

W przeciwieństwie do specjalnego przypadku statycznego twardego czasu rzeczywistego, soft real-time sprawia, że tylko minimalne niezbędne założenia specyficzne dla aplikacji dotyczące zadań i systemu, a niepewności są oczekiwane. Aby odebrać dziecko, musisz jechać do szkoły, a czas na to jest dynamiczny w zależności od pogody, warunków drogowych itp. Możesz pokusić się o nadmierną rezerwację systemu (tj. pozwolenie na to, co masz nadzieję, jest najgorszym czasem jazdy), ale znowu jest to marnowanie zasoby (twój czas i zajmowanie pojazdu rodzinnego, ewentualnie odmawianie korzystania przez innych członków rodziny).

Ten przykład może nie wydawać się kosztowny pod względem zmarnowanych zasobów, ale rozważ inne przykłady. Wszystkie wojskowe systemy walki są miękkie w czasie rzeczywistym. Na przykład rozważ przeprowadzenie ataku samolotu na wrogi pojazd naziemny za pomocą rakiety naprowadzanej z aktualizacjami do niego jako manewru celu. Maksymalna satysfakcja z wykonania zadań aktualizacji kursu jest osiągana przez bezpośredni destrukcyjne uderzenie w cel. Ale próba nadmiernej podaży zasobów, aby mieć pewność tego wyniku, jest zwykle zbyt kosztowna, a nawet może być niemożliwa. W tym przypadku możesz być mniej, ale wystarczająco zadowolony, jeśli pocisk uderzy wystarczająco blisko celu, aby go wyłączyć.

Oczywiście scenariusze walki mają wiele możliwych dynamicznych niepewności, które muszą być dostosowane do zarządzania zasobami. Miękkie systemy czasu rzeczywistego są również bardzo powszechne w wielu systemach cywilnych, takich jak automatyka przemysłowa, choć oczywiście militarne są najbardziej niebezpieczne i pilne, aby osiągnąć zadowalającą wartość w.

Kluczem systemów czasu rzeczywistego jest " przewidywalność."Trudny przypadek czasu rzeczywistego jest zainteresowany tylko jednym szczególnym przypadkiem przewidywalności-to znaczy, że wszystkie zadania będą spełniać swoje terminy i maksymalna możliwa wartość zostanie osiągnięta przez to zdarzenie. Ten szczególny przypadek nazywa się " deterministycznym."

Istnieje spektrum przewidywalność. Determinizm (determinizm) to jeden punkt końcowy (maksymalna przewidywalność) na widmie przewidywalności; drugi punkt końcowy to przewidywalność minimalna (Maksymalny niedeterminizm). Metryczne i końcowe punkty widma muszą być interpretowane w kategoriach wybranego modelu przewidywalności; wszystko między tymi dwoma punktami końcowymi jest stopniami nieprzewidywalności (=stopniami niedeterminizmu).

Większość systemów czasu rzeczywistego (czyli miękkich) ma niedeterministyczną przewidywalność, dla przykład, z czasów realizacji zadań, a co za tym idzie wartości uzyskane z tych zdarzeń.

Ogólnie (teoretycznie) przewidywalność, a więc akceptowalnie zadowalająca wartość, może być osiągnięta tak blisko deterministycznego punktu końcowego, jak to konieczne-ale za cenę, która może być fizycznie niemożliwa lub nadmiernie kosztowna (jak w walce, a może nawet w odebraniu dziecka ze szkoły).

Soft real-time wymaga specyficznego dla aplikacji wyboru modelu prawdopodobieństwa (nie powszechnego frequentist model), a tym samym model przewidywalności dla rozumowania o opóźnieniach zdarzeń i wynikowych wartościach.

Odwołując się do powyższej listy zdarzeń, które dają akceptowalną wartość, możemy teraz dodać przypadki niedeterministyczne, takie jak

• prawdopodobieństwo, że żadne zadanie nie przekroczy terminu o więcej niż 5%, jest większe niż 0,87. (Zwróć uwagę na liczbę wyrażonych tam kryteriów planowania.)

W aplikacji obrony przeciwrakietowej, biorąc pod uwagę fakt, że w walce atak zawsze ma przewagę nad obroną, który z tych dwóch scenariuszy obliczeń w czasie rzeczywistym wolisz:

• Ponieważ perfekcyjne zniszczenie wszystkich wrogich pocisków jest bardzo mało prawdopodobne lub niemożliwe, przydziel swoje zasoby obronne, aby zmaksymalizować prawdopodobieństwo, że jak najwięcej z najbardziej zagrażających (np. na podstawie ich celów) wrogich pocisków zostanie skutecznie przechwyconych (liczy się bliskie przechwycenie, ponieważ może przenieść wrogi pocisk off-course);

• Narzekaj, że nie jest to problem przetwarzania w czasie rzeczywistym, ponieważ jest dynamiczny zamiast statycznego, a tradycyjne koncepcje i techniki czasu rzeczywistego nie mają zastosowania i brzmi trudniej niż statyczne twarde w czasie rzeczywistym, więc nie jesteś nim zainteresowany.

Pomimo różnych nieporozumień na temat soft real-time w społeczności komputerowej czasu rzeczywistego, soft real-time jest bardzo ogólny i potężny, choć potencjalnie złożony w porównaniu z hard w czasie rzeczywistym. Soft systemy czasu rzeczywistego, jak podsumowano tutaj, mają długą udaną historię użycia poza społecznością komputerów w czasie rzeczywistym.

Aby bezpośrednio odpowiedzieć na pytanie OP:

Twardy system czasu rzeczywistego może zapewnić deterministyczne Gwarancje - najczęściej, że wszystkie zadania będą dotrzymywać terminów, czas przerwania lub reakcji wywołania systemowego będzie zawsze krótszy niż x, itp.- Wtedy i tylko wtedy, gdy przyjęto bardzo silne założenia i są poprawne, że wszystko, co się liczy, jest statyczne i znane a' priori (ogólnie rzecz biorąc, takie gwarancje dla twardych systemów czasu rzeczywistego są otwartym problemem badawczym, z wyjątkiem raczej prostych przypadków) {]}

Miękki system czasu rzeczywistego nie daje deterministycznych gwarancji, ma na celu zapewnienie możliwie najlepszej analitycznie określonej i zrealizowanej probabilistycznej terminowości i przewidywalności terminowości, które są możliwe w obecnych warunkach dynamicznych, zgodnie z kryteriami specyficznymi dla zastosowania.

Oczywiście hard real-time jest prosty specjalny przypadek miękkiego czasu rzeczywistego. Oczywiście analityczne niedeterministyczne zapewnienia soft w czasie rzeczywistym mogą być bardzo złożone, ale są obowiązkowe w najczęstszych przypadkach czasu rzeczywistego (w tym najbardziej niebezpiecznych krytycznych dla bezpieczeństwa, takich jak walka), ponieważ większość przypadków czasu rzeczywistego jest dynamiczna, a nie statyczna.

"Firm real-time" jest źle zdefiniowanym szczególnym przypadkiem "soft real-time"."Nie ma potrzeby stosowania tego terminu, jeśli termin" soft real-time " jest zrozumiały i właściwie używany.

I mam bardziej szczegółowe znacznie bardziej precyzyjne omówienie czasu rzeczywistego, twardego czasu rzeczywistego, miękkiego czasu rzeczywistego, przewidywalności, determinizmu i pokrewnych tematów na mojej stronie internetowej real-time.org.

Real-time-odnoszący się do systemu lub trybu pracy, w którym obliczenia są wykonywane w czasie rzeczywistym, że proces zewnętrzny występuje, w celu, że wyniki obliczeń mogą być używane do sterowania, monitorowania lub odpowiedzi na proces zewnętrzny w odpowiednim czasie. [IEEE Standard 610.12.1990]

Wiem, że ta definicja jest stara, bardzo stara. Nie mogę jednak znaleźć nowszej definicji IEEE (Institute of Electrical and Electronics Engineers).

Być może definicja jest winna.

Z mojego doświadczenia, chciałbym oddzielić te dwa jako zależne od sprzętu i oprogramowania.

Jeśli masz 200ms do obsługi sprzętowego przerwania, to właśnie masz. Wtykasz tam 300ms kodu i system nie jest zepsuty, nie został opracowany. Zostaniesz zamieniony zanim skończysz. Twój kod nie działa lub nie nadaje się do celu. Wiele systemów ma ściśle zdefiniowane okresy przetwarzania. Wideo, telekomunikacja itp.

Jeśli piszesz aplikację w czasie rzeczywistym, można to uznać zasoft . Jeśli zabraknie Ci czasu, możesz mieć nadzieję na mniejsze obciążenie następnym razem, możesz dostroić SYSTEM OPERACYJNY, dodać trochę pamięci lub nawet zaktualizować sprzęt. Masz opcje.

Spojrzenie na to z perspektywy UX nie jest pomocne. Skoda może się nie zepsuć, jeśli się zepsuje, ale BMW na pewno będzie.

Definicja rozszerzyła się na przestrzeni lat ze szkodą dla tego terminu. To, co teraz nazywa się "twardym" czasem rzeczywistym, to to, co kiedyś było po prostu nazywane czasem rzeczywistym. Tak więc systemy, w których brakujące okna czasowe (a nie jednostronne terminy czasowe) spowodowałyby nieprawidłowe dane lub nieprawidłowe zachowanie, powinny być brane pod uwagę w czasie rzeczywistym. Systemy bez tej cechy byłyby uważane za nie-w czasie rzeczywistym.

To nie znaczy, że czas nie jest interesujący w systemach czasu nie rzeczywistego, to po prostu oznacza, że wymagania czasowe w takich systemach nie skutkują zasadniczo błędnymi wynikami.

Rozważ zadanie, które wprowadza dane z portu szeregowego. Po pojawieniu się nowych danych port szeregowy uruchamia Zdarzenie. Gdy oprogramowanie obsługuje to zdarzenie, odczytuje i przetwarza nowe dane. Port szeregowy ma sprzęt do przechowywania przychodzących danych (2 na msp432, 16 na TM4C123) tak, że jeśli bufor jest pełny i przybywa więcej danych, nowe dane są tracone. Czy ten system jest twardy, twardy, czy miękki w czasie rzeczywistym?

Jest to trudne w czasie rzeczywistym , ponieważ jeśli odpowiedź jest spóźniona, dane mogą być zagubieni.

Rozważ aparat słuchowy, który wprowadza dźwięki z mikrofonu, manipuluje danymi dźwiękowymi, a następnie przesyła je do głośnika. System zwykle ma mały i ograniczony jitter, ale czasami inne zadania w aparacie słuchowym powodują spóźnienie niektórych danych, powodując impuls szumu na głośniku. Czy ten system jest twardy, twardy czy miękki w czasie rzeczywistym?

Jest to mocna w czasie rzeczywistym , ponieważ powoduje błąd, który można postrzegać, ale efekt jest nieszkodliwy i nie znacząco zmienić jakość doświadczenia.

Rozważ zadanie, które wysyła dane do drukarki. Gdy drukarka jest bezczynna, drukarka uruchamia Zdarzenie. Gdy oprogramowanie obsługuje to zdarzenie, wysyła więcej danych do drukarki. Czy ten system jest twardy, twardy czy miękki w czasie rzeczywistym?

Jest to soft real time ponieważ im szybciej reaguje tym lepiej, ale wartość systemu (przepustowość to ilość danych drukowanych na sekundę) maleje wraz z opóźnienie.

UTAustinX: UT.RTBN.12.01 X sieci Bluetooth w czasie rzeczywistym