ハードリアルタイム、ソフトリアルタイム、およびファームリアルタイムの違いは？
リアルタイムのさまざまな概念 の定義を読んでおり、ハードリアルタイムシステムとソフトリアルタイムシステムに提供されている例は理にかなっています。しかし、堅実なリアルタイムシステムの実際の説明や例はありません。上記のリンクによると：
会社：まれなデッドラインミスは許容されますが、システムのサービス品質が低下する可能性があります。結果の有用性は、締め切り後はゼロです。
堅実なリアルタイムとハードまたはソフトなリアルタイムの明確な区別はありますか？その区別を示す良い例はありますか？
コメントでは、チャールズは、新しいタグのタグwikiを提出するように頼みました。 firm-real-time タグに提供した「ファームリアルタイムシステム」の例は、ミルクサービングシステムでした。有効期限後にシステムが牛乳を配達する場合、牛乳は「役に立たない」と見なされます。牛乳なしで穀物を食べることは許容できますが、体験の質は低下します。
これは、最初に定義を読んだときに頭の中で形成したアイデアです。私はもっと良い例を探しており、おそらくリアルタイムのより良い定義を探しています。
ハードリアルタイムとは、すべての期限を絶対に守らなければならないことを意味します。この要件を持つシステムはほとんどありません。いくつかの例は、核システム、ペースメーカーなどの医療アプリケーション、多数の防衛アプリケーション、航空電子工学などです。
ファーム/ソフトリアルタイムシステムは、いくつかの期限を逃す可能性がありますが、あまりにも多くの期限を逃すと、最終的にパフォーマンスが低下します。良い例は、コンピューターのサウンドシステムです。いくつかのビットを見逃すと、大したことはないが、あまり多くを見逃すと、最終的にシステムを劣化させることになります。地震センサーも同様です。いくつかのデータポイントを見逃しても大したことはありませんが、データの意味を理解するにはそれらのほとんどをキャッチする必要があります。さらに重要なことは、正しく動作しない場合、誰も死ぬことはありません。
ペースメーカーでさえ患者を殺さずに少しだけ離れることができるため、この線はあいまいです。しかしそれは一般的な要点です。
暑さと暖かさの違いのようなものです。本当の格差はありませんが、それを感じるとき、あなたはそれを知っています。
ハードリアルタイム
hard real-timeの定義は、期限の遅れをシステム障害と見なします。このスケジューリングは、タイミングの制約に準拠しないと生命や財産が失われるミッションクリティカルなシステムで広く使用されます。
例：
センサーの誤作動が一連のシステムエラーを引き起こした後、エールフランス航空447便が海にcrash落しました。パイロットは、時代遅れの計器の測定値に応答しながら、航空機を失速させました。 12人の乗組員全員と216人の乗客が死亡しました。
優先順位の逆転によりシステムが再起動されたため、Mars Pathfinder宇宙船はほぼ失われました。優先度の低いタスクによってブロックされたため、優先度の高いタスクは時間どおりに完了しませんでした。問題は修正され、宇宙船は着陸に成功しました。
インクジェットプリンターには、用紙の特定の部分に正しい量のインクを付着させるための制御ソフトウェアを備えたプリントヘッドがあります。締め切りに間に合わない場合、印刷ジョブは台無しになります。
しっかりしたリアルタイム
firm real-timeの定義により、まれに期限を逃すことがあります。これらのアプリケーションでは、十分な間隔が空けられている限り、システムはタスクの失敗に耐えることができますが、タスクの完了の値はゼロになるか、不可能になります。
例：
ロボットの組立ラインを使用した製造システムでは、期限を守らないと、部品が不適切に組み立てられます。破損した部品が品質管理にとらわれるほど頻繁ではなく、コストがかかりすぎない限り、生産は継続されます。
デジタルケーブルセットトップボックスは、フレームを画面に表示する必要があるときのタイムスタンプをデコードします。フレームは時間順序に敏感であるため、期限を逃すとジッタが発生し、サービス品質が低下します。失われたフレームが後で利用可能になった場合、表示するジッタが増えるだけなので、役に立たないでしょう。ジッターが頻繁に発生しなくても、視聴者はプログラムを楽しむことができます。
ソフトリアルタイム
soft real-timeの定義により、頻繁に期限に間に合わず、タスクがタイムリーに実行されている限り、結果に価値があり続けます。完了したタスクは、期限までに値が増加し、期限を過ぎると値が減少する場合があります。
例：
気象ステーションには、温度、湿度、風速などを読み取るためのセンサーが多数あります。読み取り値は定期的に取得して送信する必要がありますが、センサーは同期していません。センサーの読み取り値は、他のセンサーに比べて早い場合も遅い場合も、十分に近い限り関連性があります。
ビデオゲームコンソールは、ゲームエンジン用のソフトウェアを実行します。タスク間で共有する必要のある多くのリソースがあります。同時に、ゲームを正しくプレイするためのスケジュールに従ってタスクを完了する必要があります。タスクが完全に比較的時間通りに行われている限り、ゲームは楽しいものになり、そうでない場合は少し遅れるだけです。
Siewert：リアルタイム組み込みシステムおよびコンポーネント。
Liu＆Layland：ハードリアルタイム環境でのマルチプログラミングのスケジューリングアルゴリズム。
Marchand＆Silly-Chetto：ソフト非周期タスクとスキップ付き周期タスクの動的スケジューリング。
ウィキペディアのページやリアルタイムコンピューティングに関する他のページを読んだ後。私は次の推論をしました：
1>Hard real-time systemの場合、システムが失敗したと見なされてもシステムが期限に間に合わない場合.
2>リアルタイムシステムの場合、システムが期限に間に合わない場合、場合によっては複数回（複数の要求の場合）、システムに障害が発生したとは見なされません。また、その特定の要求の期限が過ぎると、要求に対する応答（クエリへの応答、タスクの結果など）は価値がなくなります（結果の有用性はゼロになりますその締め切り）。架空の例としては、暴風雨予報システムがあります（嵐が到着前に予測される場合、システムはその仕事を完了し、イベントが既に発生した後、または発生しているときの予測は価値がありません）。
3>ソフトリアルタイムシステムの場合、システムが期限に間に合わない場合でも、おそらく複数回（つまり、複数のリクエストの場合）、システムに障害が発生したとは見なされません。ただし、この場合、リクエストの結果は無期限ではありません期限後の結果の値はゼロではなく、むしろ時間が経過するにつれて低下します締め切り。例：ストリーミングオーディオビデオ。
ここ は非常に役立つリソースへのリンクです。
いくつかの大災害をハードリアルタイムの定義と関連付けることは一般的ですが、これは関係ありません。厳しいリアルタイム制約を満たさないということは、単にシステムが壊れていることを意味します。何かに「壊れた」というラベルが付けられた場合の結果の重大度は、定義にとって重要ではありません。
確固たるソフトは、単一の締め切りに間に合わなかった場合、自動的に壊れていると宣言されることはありません。
ハードリアルタイムの公正な例については、リンクしたページから：
Atari 2600やCinematronicsのベクターグラフィックスなどの初期のビデオゲームシステムには、グラフィックスとタイミングハードウェアの性質のため、厳しいリアルタイム要件がありました。
ビデオ生成ループ内の何かが1つの期限を逃した場合、ディスプレイ全体に不具合が発生し、まれであったとしても耐えられません。それは壊れたシステムになり、返金のために店に持ち帰ります。そのため、リアルタイムは困難です。
明らかに、どのシステムも処理できない状況にさらされる可能性があるため、定義を予想される動作条件内に制限する必要があります。安全性が重要なアプリケーションでは、人々はひどい状態（「クーラントが蒸発した」）を計画しなければならないことに注意してくださいブレーキが故障した」が、めったに「太陽が爆発した」）。
そして、「誰もが見ている間に」暗黙の動作状態が時々あることを忘れないでください。あなたがルールを破るのを誰も見なかった場合（または彼らが誰にも話さない前に彼らが火事で死んだ場合）、そしてあなたが事実の後にあなたがルールを破ったことを誰も証明できないなら、それはあなたがルールを破らなかったのと同じようなものです！
さまざまな種類のリアルタイムシステムタイプを区別する最も簡単な方法は、質問に答えることです。
（期限後の）システム応答の遅延は依然として有用ですか？
そのため、この質問に対する回答に応じて、システムは次のカテゴリのいずれかに含まれます。
- ハード：いいえ、遅延応答はシステム障害と見なされます
これは、締め切りを逃すとシステムが使用できなくなる場合です。たとえば、車のエアバッグシステムを制御するシステムは、クラッシュを検出し、バッグを急速に膨張させる必要があります。プロセス全体にかかる時間は、およそ0.5秒です。したがって、たとえばシステムが1秒の遅延で反応する場合、結果は致命的である可能性があり、車がすでにクラッシュした後にバッグを膨らませてもメリットはありません。
- 会社：いいえ、ただし、システムの障害の場合、遅延した回答は必要ありません
これは、締め切りに間に合わない場合は許容範囲ですが、サービスの品質に影響する場合です。簡単な例として、ビデオ暗号化システムを考えます。通常、暗号化のパスワードはserver（ビデオヘッドエンド）で生成され、顧客のセットトップボックスに送信されます。このプロセスは、通常、セットトップボックスが暗号化されたビデオフレームの受信を開始する前にpasswordを受信するように同期する必要があります。この場合、セットトップボックスはまだパスワードを受信していないため、フレームをデコードできないため、遅延によりビデオの不具合が発生する可能性があります。この場合、サービス（映画、面白いサッカーの試合など）は、期限を守らないと影響を受ける可能性があります。この場合、同じパスワードで暗号化されたフレームが既にグリッチを引き起こしているため、パスワードを遅延して受信することは役に立ちません。
- ソフト：はい、ただしシステムサービスは低下しています
ウィキペディアの説明から、結果の有用性は期限後に低下します。つまり、システムから応答を期限外に取得することはエンドユーザーにとっては依然として有用ですが、期限に達するとその有用性は低下します。この場合の簡単な例は、部屋（または建物）の温度を自動的に制御するソフトウェアです。この場合、システムが温度センサーの読み取りに多少の遅延がある場合、温度の変化が激しい場合の反応が少し遅くなります。ただし、最後には変更に反応し、それに応じて温度を調整して、たとえば一定に保つようにします。そのため、この場合、遅延反応は有用ですが、システムのサービス品質を低下させます。
ソフトリアルタイムが最も理解しやすく、期限が過ぎても結果が得られた場合でも、結果は有効と見なされます。
例：Webブラウザー-特定のURLを要求します。ページの読み込みに時間がかかります。システムがページを提供するのに予想以上の時間がかかる場合、取得されたページは無効とは見なされません。システムのパフォーマンスが限界に達していないとだけ言います（システムのパフォーマンスが低下しました！）。
ハードリアルタイムシステムでは、期限後に結果が得られた場合、システムは完全に失敗したと見なされます。
例：ロボットがライントレースなどのジョブを実行する場合。障害物がそのパス上にあり、ロボットがこれを処理しない場合プログラムされた期限内の情報（ほぼ瞬時！）、ロボットはそのタスクで失敗したと言われます（ロボットシステムも完全に破壊される可能性があります！）。
リアルタイムの確認システムでは、プロセス実行の結果が期限の後に来る場合、その結果を破棄しますが、システムは失敗したとは見なされません。
例：敵の位置監視またはその他のタスクのための衛星通信。衛星が定期的にフレームを送信する地上のコンピューターステーションが過負荷になり、現在のフレーム（パケット）が時間内に処理されず、次のフレームが起動した場合、現在のパケット（期限を逃したパケット）は重要ではありません処理が行われたか（または半分行われたか、ほぼ行われたか）がドロップ/破棄されます。しかし、地上コンピュータは完全に故障したとは呼ばれていません。
「ソフトリアルタイム」を定義するには、「ハードリアルタイム」と比較するのが最も簡単です。以下では、「リアルタイムの確認」という用語が「ソフトリアルタイム」についての誤解を構成していることがわかります。
何気なく話すと、ほとんどの人は暗黙のうちに、情報やイベントを「リアルタイム」と見なす非公式のメンタルモデルを持っています。
•認識された通貨に関連する可能性のある遅延（遅延）が発生した場合、またはその程度
•つまり、情報またはイベントが満足のいく満足のいく価値を持つ時間枠内。
「ハードリアルタイム」にはさまざまなアドホック定義がありますが、そのメンタルモデルでは、ハードリアルタイムは「if」という用語で表されます。具体的には、リアルタイムアクション（タスクなど）に完了期限があると仮定すると、すべてのタスクが完了するイベントの満足できる満足できる値は、すべてのタスクが期限を満たす特別な場合に限定されます。
ハードリアルタイムシステムは、アプリケーションとシステムおよび環境に関するすべてが静的であり、アプリオリに知られているという非常に強い仮定を立てます。たとえば、どのタスク、定期的、到着時間、期間、期限、獲得したリソースの競合や全体的なシステムの時間的進化はありません。航空機の飛行制御システムまたは自動車のブレーキシステムおよびその他の多くの場合、これらの仮定は通常満たされ、すべての期限が満たされます。
このメンタルモデルは、ハードリアルタイムとソフトリアルタイムの両方を網羅するのに十分な意図的かつ非常に有用であり、ソフトは「その程度まで」という言い回しに対応しています。たとえば、タスク完了イベントが次善の場合に最適ではないが許容可能な値を持っているとします。
- 締め切りに間に合わないタスクは10％以下
- または20％を超えるタスクはありません
- または、すべてのタスクの平均遅延が15％を超えない
- または、すべてのタスクの最大遅延が10％未満
これらはすべて、非常に多くのアプリケーションでのソフトリアルタイムの一般的な例です。
放課後に子供を迎えに行くシングルタスクアプリケーションを検討してください。おそらく実際の締め切りはありませんが、代わりにそのイベントがいつ発生するかに基づいて、あなたとあなたの子供にとって何らかの価値があります。早すぎるとリソース（時間など）が浪費され、遅すぎると、お子様が放っておかれ、潜在的に害を及ぼす（または少なくとも不便な）可能性があるため、マイナスの価値があります。
静的なハードリアルタイムの特殊なケースとは異なり、ソフトリアルタイムは、タスクとシステムに関する最小限の必要なアプリケーション固有の仮定のみを行い、不確実性が予想されます。子供を迎えに行くには、学校まで車で行く必要があり、その時間は天候や交通状況などに応じて動的に変化します。システムを過剰にプロビジョニングしたくなるかもしれません最悪の場合は運転時間）ですが、これもリソースを浪費しています（あなたの時間、家族の車を占有し、他の家族による使用を拒否する可能性があります）.
この例は、リソースの浪費という点ではコストがかかるようには見えませんが、他の例を検討してください。すべての軍事戦闘システムはソフトリアルタイムです。たとえば、目標の機動として更新されたミサイルを使用して敵の地上車両に航空機攻撃を実行することを検討してください。コース更新タスクを完了するための最大の満足度は、ターゲットに対する直接的な破壊的な攻撃によって達成されます。しかし、この結果を確実にするためにリソースを過剰に提供しようとする試みは、通常非常に高価であり、不可能な場合もあります。この場合、ミサイルがターゲットに接近して無効化できるほど十分に満足しているとは限りません。
明らかに、戦闘シナリオには、リソース管理で対処しなければならない非常に多くの可能性のある動的な不確実性があります。ソフトリアルタイムシステムは、産業オートメーションなどの多くの民間システムでも非常に一般的ですが、軍事システムは、満足できる満足のいく値を達成するための最も危険で緊急のシステムです。
リアルタイムシステムの要は「予測可能性」です。ハードリアルタイムの場合は、予測可能性の1つの特別な場合にのみ関心があります。つまり、タスクがすべて期限を満たし、最大値がそのイベントによって達成されるということです。その特別なケースは「決定論的」という名前です。
さまざまな予測可能性があります。決定論的（決定論）は、予測可能性スペクトルの1つのエンドポイント（最大予測可能性）です。もう1つのエンドポイントは、最小の予測可能性です（最大の非決定性）。スペクトルのメトリックとエンドポイントは、選択した予測可能性モデルの観点から解釈する必要があります。これらの2つのエンドポイント間のすべてが予測不可能な度合い（=非決定性の度合い）です。
ほとんどのリアルタイムシステム（つまり、ソフトシステム）には、たとえばタスクの完了時間、したがってそれらのイベントから得られる値の非決定的な予測可能性があります。
一般的に（理論上）、予測可能性、したがって許容できる満足のいく値は、必要に応じて決定論的エンドポイントに近づけることができますが、物理的に不可能または過度に高価な価格で（戦闘またはおそらく学校からあなたの子供を拾います）。
ソフトリアルタイムでは、アプリケーション固有の確率モデル（一般的な頻度モデルではなく）の選択が必要であるため、イベントレイテンシと結果値について推論するための予測可能性モデルが必要です。
上記の許容可能な値を提供するイベントのリストに戻って、次のような非決定的なケースを追加できます。
- 5％を超えて期限を逃すタスクがない確率は0.87を超えます。 （そこに表現されているスケジューリング基準の数に注意してください。）
ミサイル防衛アプリケーションでは、戦闘では常に攻撃が防御よりも有利であるという事実を考えると、次の2つのリアルタイムコンピューティングシナリオのどちらを好むでしょうか。
すべての敵性ミサイルの完全な破壊は非常にありそうもないか不可能なので、防御リソースを割り当てて、最も標的となる（たとえば、ターゲットに基づいた）敵性ミサイルが正常に傍受される確率を最大にします（傍受カウントが近いため）敵対ミサイルをコース外に移動できます）;
これは、静的ではなく動的であり、従来のリアルタイムの概念や手法は適用されないため、リアルタイムコンピューティングの問題ではないことを訴え、静的なハードリアルタイムよりも難しいように聞こえるので、興味がない。
リアルタイムコンピューティングコミュニティでのソフトリアルタイムに関するさまざまな誤解にもかかわらず、ソフトリアルタイムは非常に一般的で強力ですが、ハードリアルタイムと比較すると複雑になる可能性があります。ここに要約されているソフトリアルタイムシステムには、リアルタイムコンピューティングコミュニティ以外での長い使用実績があります。
OPの質問に直接回答するには：
ハードリアルタイムシステムは、確定的な保証を提供できます。最も一般的には、すべてのタスクが期限を満たし、割り込みまたはシステムコールの応答時間が常にx未満であるなどです。非常に強い仮定が行われ、重要なことはすべて静的であり、アプリオリに知られています（一般的に、ハードリアルタイムシステムに対するこのような保証は、かなり単純な場合を除き、未解決の研究課題です
ソフトリアルタイムシステムは決定論的な保証を行いません。アプリケーション固有の基準に従って、現在の動的な状況下で実行可能な、可能な限り分析的に指定され達成された確率的適時性と適時性の予測可能性を提供することを目的としています。
明らかにハードリアルタイムは、ソフトリアルタイムの単純で特殊なケースです。明らかに、ソフトリアルタイムの分析的非決定論的保証は提供するのが非常に複雑な場合がありますが、ほとんどのリアルタイムケースは動的ではないため、最も一般的なリアルタイムケース（戦闘などの最も危険で安全性が重要なケースを含む）では必須です静的。
「Firm real-time」は、「soft real-time」の不明確な特殊ケースです。 「ソフトリアルタイム」という用語が適切に理解され、使用されている場合、この用語は不要です。
私のWebサイトreal-time.orgで、リアルタイム、ハードリアルタイム、ソフトリアルタイム、予測可能性、決定論、および関連するトピックについて、より詳細な議論をしています。
シリアルポートからデータを入力するタスクを考えます。新しいデータが到着すると、シリアルポートがイベントをトリガーします。ソフトウェアがそのイベントを処理するとき、新しいデータを読み取って処理します。シリアルポートには、着信データ（MSP432に2、TM4C123に16）を保存するためのハードウェアがあり、バッファがいっぱいになり、さらにデータが到着すると、新しいデータは失われます。このシステムは、ハード、ファーム、またはソフトのリアルタイムですか？
ハードリアルタイムです。応答が遅れると、データが失われる可能性があるためです。
マイクから音を入力し、音データを操作し、スピーカーにデータを出力する補聴器を考えます。通常、システムのジッターは小さく制限されていますが、補聴器内の他のタスクにより、一部のデータが遅れ、スピーカーでノイズパルスが発生することがあります。このシステムは、ハード、ファーム、またはソフトのリアルタイムですか？
リアルタイムの確認であるため、知覚可能なエラーが発生しますが、その影響は無害であり、エクスペリエンスの品質を大きく変えることはありません。
データをプリンターに出力するタスクを考えてください。プリンターがアイドル状態になると、プリンターはイベントをトリガーします。ソフトウェアがそのイベントを処理すると、プリンタにさらにデータが送信されます。このシステムは、ハード、ファーム、またはソフトのリアルタイムですか？
ソフトリアルタイムは、応答が速いほど良くなりますが、システムの値（帯域幅は1秒あたりに印刷されるデータの量）は待ち時間とともに減少します。
UTAustinX：UT.RTBN.12.01xリアルタイムBluetoothネットワーク
リアルタイム-計算結果を使用して外部プロセスをタイムリーに制御、監視、または応答できるようにするために、外部プロセスが発生する実際の時間に計算が実行されるシステムまたは操作モードに関する用語マナー。 [IEEE規格610.12.1990]
私はこの定義が古いこと、非常に古いことを知っています。ただし、IEEE（Institute of Electrical and Electronics Engineers）による最新の定義は見つかりません。
たぶん、定義に誤りがあります。
私の経験から、ハードウェアとソフトウェアに依存するものとして2つを分離します。
ハードウェア駆動の割り込みを処理するために200ミリ秒がある場合、それが得られます。そこに300msのコードを挿入すると、システムは破損せず、開発もされていません。完了する前に切り替えられます。コードが機能しないか、目的に合わない。多くのシステムでは、処理期間が明確に定義されています。ビデオ、通信など.
applicationをリアルタイムで記述している場合、これはsoftと見なすことができます。時間が足りなくなったら、次回は負荷を減らしたいと思うかもしれません。OSを調整したり、メモリを追加したり、ハードウェアをアップグレードしたりできます。オプションがあります。
UXの観点から見ることは役に立ちません。シュコダは故障しても壊れないかもしれませんが、BMWは確実に壊れます。
定義は長年にわたって、用語を損なうまで拡大しました。現在「ハード」リアルタイムと呼ばれているのは、以前は単にリアルタイムと呼ばれていたものです。そのため、（片側の締め切りではなく）タイミングウィンドウが欠落しているシステムでは、不正なデータや不正な動作がリアルタイムで発生する可能性があります。その特性のないシステムは、非リアルタイムと見なされます。
それは、非リアルタイムシステムでは時間が重要ではないということではなく、そのようなシステムのタイミング要件が根本的に不正確な結果にならないことを意味します。
ハードリアルタイムシステムは優先度スケジューリングのプリエンプティブバージョンを使用するため、重要なタスクはすぐにスケジュールされますが、ソフトリアルタイムシステムは優先度スケジューリングの非プリエンプティブバージョンを使用します。追加の遅延を引き起こすタスク。したがって、ハードリアルタイムシステムではタスクの期限が厳密に守られますが、ソフトリアルタイムシステムではそれほど厳しく処理されません。