Aby zdefiniować „miękki czas rzeczywisty”, najłatwiej jest porównać to z „trudnym czasem rzeczywistym”. Poniżej zobaczymy, że termin „firma w czasie rzeczywistym” stanowi nieporozumienie dotyczące „miękkiego czasu rzeczywistego”.
Mówiąc od niechcenia, większość ludzi ma nieformalny model mentalny, który traktuje informacje lub wydarzenie jako „w czasie rzeczywistym”
• jeśli lub w zakresie, w jakim jest to dla nich widoczne z opóźnieniem (latencją), które może być związane z jego postrzeganą walutą
• tj. W ramach czasowych, w których informacja lub wydarzenie ma dla nich zadowalającą wartość.
Istnieje wiele różnych definicji ad hoc „trudnego czasu rzeczywistego”, ale w tym modelu mentalnym trudny 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 wykonania, akceptowalnie zadowalająca wartość zdarzenia, w którym wszystkie zadania są ukończone, jest ograniczona do specjalnego przypadku, gdy wszystkie zadania dotrzymują terminów.
Twarde systemy czasu rzeczywistego przyjmują bardzo mocne założenie, że wszystko w aplikacji, systemie i środowisku jest statyczne i znane a priori - np. Które zadania są okresowe, ich czas przybycia, ich okresy, terminy, które wygrały nie ma konfliktów zasobów i ogólnie ewolucji systemu w czasie. W systemie sterowania lotem samolotu czy samochodowym układzie hamulcowym i wielu innych przypadkach te założenia można zwykle spełnić, aby dotrzymać wszystkich terminów.
Ten model mentalny jest celowo i bardzo użytecznie na tyle ogólny, że obejmuje zarówno twardy, jak i miękki czas rzeczywisty - miękki jest dostosowywany przez wyrażenie „w takim stopniu, w jakim”. Załóżmy na przykład, ż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 opóźnione o więcej niż 20%
- czyli średnia opieszałość wszystkich zadań nie przekracza 15%
- lub maksymalne opóźnienie wszystkich zadań jest mniejsze niż 10%
Są to typowe przykłady miękkich przypadków czasu rzeczywistego w wielu aplikacjach.
Rozważ jedno zadanie polegające na odbieraniu dziecka po szkole. To prawdopodobnie nie ma faktycznego terminu, zamiast tego istnieje pewna wartość dla Ciebie i Twojego dziecka na podstawie tego, kiedy to wydarzenie ma miejsce. Zbyt wczesne marnowanie zasobów (takich jak czas) i zbyt późne marnowanie zasobów ma jakąś negatywną wartość, ponieważ Twoje dziecko może zostać pozostawione samo i potencjalnie narażone na niebezpieczeństwo (lub przynajmniej niewygodne).
W przeciwieństwie do statycznego, twardego, specjalnego przypadku czasu rzeczywistego, miękki czas rzeczywisty tworzy tylko minimalne niezbędne założenia specyficzne dla aplikacji dotyczące zadań i systemu i oczekuje się niepewności. 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 ulec pokusie, aby nadmiernie zaopatrzyć swój system (tj. Pozwolić, aby to, co masz nadzieję, było w najgorszym przypadku czas prowadzenia pojazdu), ale znowu jest to marnowanie zasobów (twojego czasu i zajmowania pojazdu rodzinnego, być może odmawiania używania go innym członkom rodziny).
Ten przykład może nie wydawać się kosztowny, biorąc pod uwagę zmarnowane zasoby, ale rozważ inne przykłady. Wszystkie wojskowe systemy bojowe działają łagodnie w czasie rzeczywistym. Na przykład rozważ wykonanie ataku lotniczego na wrogi pojazd naziemny przy użyciu pocisku kierowanego z aktualizacjami w trakcie manewru celu. Maksymalną satysfakcję z wykonania zadań aktualizacji kursu zapewnia bezpośrednie niszczycielskie uderzenie w cel. Jednak próba nadmiernego przydzielenia zasobów w celu upewnienia się co do takiego wyniku jest zwykle zbyt kosztowna, a nawet może być niemożliwa. W takim 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ą zostać uwzględnione przez zarządzanie zasobami. Miękkie systemy czasu rzeczywistego są również bardzo powszechne w wielu systemach cywilnych, takich jak automatyka przemysłowa, chociaż oczywiście systemy wojskowe są najbardziej niebezpieczne i najpilniejsze, aby osiągnąć zadowalającą wartość.
Podstawą systemów czasu rzeczywistego jest „przewidywalność”. Trudny przypadek czasu rzeczywistego jest zainteresowany tylko jednym szczególnym przypadkiem przewidywalności - tj. Tym, że wszystkie zadania dotrzymają terminów, a maksymalna możliwa wartość zostanie osiągnięta przez to wydarzenie. Ten szczególny przypadek nazywa się „deterministyczny”.
Istnieje szerokie spektrum przewidywalności. Deterministyczny (determinizm) to jeden punkt końcowy (maksymalna przewidywalność) w spektrum przewidywalności; drugim punktem końcowym jest minimalna przewidywalność (maksymalna niedeterminizm). Metrykę widma i punkty końcowe należy interpretować pod kątem wybranego modelu przewidywalności; wszystko pomiędzy tymi dwoma punktami końcowymi to stopnie nieprzewidywalności (= stopnie niedeterminizmu).
Większość systemów czasu rzeczywistego (a mianowicie miękkich) ma niedeterministyczną przewidywalność, na przykład czasu realizacji zadań, a tym samym wartości uzyskanych z tych zdarzeń.
Ogólnie (w teorii) przewidywalność, a zatem akceptowalnie zadowalająca wartość, można uczynić tak blisko deterministycznego punktu końcowego, jak to konieczne - ale za cenę, która może być fizycznie niemożliwa lub nadmiernie droga (jak w walce, a może nawet w odebranie dziecka ze szkoły).
Miękki czas rzeczywisty wymaga specyficznego dla aplikacji wyboru modelu prawdopodobieństwa (nie powszechnego modelu częstego), a tym samym modelu przewidywalności dla wnioskowania o opóźnieniach zdarzeń i wynikowych wartościach.
Wracając do powyższej listy zdarzeń, które zapewniają akceptowalną wartość, teraz możemy dodać przypadki niedeterministyczne, takie jak
- prawdopodobieństwo, że żadne zadanie nie przekroczy swojego terminu o więcej niż 5% jest większe niż 0,87. (Zwróć uwagę na liczbę wyrażonych tam kryteriów planowania).
W zastosowaniu do obrony przeciwrakietowej, biorąc pod uwagę fakt, że w walce ofensywa zawsze ma przewagę nad obroną, który z tych dwóch scenariuszy obliczeniowych w czasie rzeczywistym wolałbyś:
ponieważ idealne zniszczenie wszystkich wrogich pocisków jest bardzo mało prawdopodobne lub niemożliwe, przydziel swoje środki obronne, aby zmaksymalizować prawdopodobieństwo, że jak najwięcej najbardziej zagrażających (np. w oparciu o ich cele) pocisków wroga zostanie pomyślnie przechwyconych (liczy się przechwycenie bliskie, ponieważ może przesunąć wrogi pocisk z kursu);
narzekać, że nie jest to problem z obliczeniami w czasie rzeczywistym, ponieważ jest dynamiczny, a nie statyczny, a tradycyjne koncepcje i techniki czasu rzeczywistego nie mają zastosowania i brzmi to trudniej niż statyczne trudne w czasie rzeczywistym, więc nie jesteś tym zainteresowany .
Pomimo różnych nieporozumień dotyczących miękkiego czasu rzeczywistego w społeczności komputerów czasu rzeczywistego, miękki czas rzeczywisty jest bardzo ogólny i potężny, choć potencjalnie złożony w porównaniu z trudnym czasem rzeczywistym. Miękkie systemy czasu rzeczywistego, jak tutaj podsumowano, mają długą historię udanego użytkowania poza społecznością komputerów czasu rzeczywistego .
Aby bezpośrednio odpowiedzieć na pytanie OP:
Twardy system czasu rzeczywistego może zapewnić deterministyczne gwarancje - najczęściej wszystkie zadania dotrzymają terminów, czas reakcji na przerwanie lub wywołanie systemowe będzie zawsze mniejszy niż x itd. - JEŚLI I TYLKO JEŚLI bardzo mocne założenia zostaną przyjęte i są poprawne, wszystko, co ma znaczenie, jest statyczne i znane a 'priori (generalnie 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 określonej analitycznie i osiągniętej probabilistycznej terminowości i przewidywalności terminowości, które są wykonalne w obecnych dynamicznych warunkach, zgodnie z kryteriami specyficznymi dla aplikacji.
Oczywiście trudny czas rzeczywisty to prosty, specjalny przypadek miękkiego czasu rzeczywistego. Oczywiście miękkie, niedeterministyczne zapewnienia analityczne w czasie rzeczywistym mogą być bardzo złożone, ale są obowiązkowe w najczęstszych przypadkach w czasie rzeczywistym (w tym w najbardziej niebezpiecznych przypadkach krytycznych dla bezpieczeństwa, takich jak walka), ponieważ większość przypadków w czasie rzeczywistym nie jest dynamiczna. statyczny.
„Firmowy czas rzeczywisty” to źle zdefiniowany specjalny przypadek „miękkiego czasu rzeczywistego”. Nie ma potrzeby używania tego terminu, jeśli termin „miękki czas rzeczywisty” jest rozumiany i używany właściwie.
Mam bardziej szczegółowe, znacznie bardziej precyzyjne omówienie czasu rzeczywistego, trudnego czasu rzeczywistego, miękkiego czasu rzeczywistego, przewidywalności, determinizmu i powiązanych tematów na mojej stronie real-time.org.