ハードリアルタイム、ソフトリアルタイム、ファームリアルタイムの違いは何ですか？

リアルタイムのさまざまな概念の定義を読みました。ハードリアルタイムシステムとソフトリアルタイムシステムに提供されている例は私にとって意味があります。しかし、しっかりとしたリアルタイムシステムの実際の説明や例はありません。上記のリンクによると：

会社：不定期の締め切りミスは許容できますが、システムのサービス品質を低下させる可能性があります。結果の有用性は、締切後はゼロです。

ハードリアルタイムとハードリアルタイムまたはソフトリアルタイムの間に明確な違いはありますか。その違いを示す良い例はありますか？

コメントの中で、チャールズは私に新しいタグのためにタグウィキを提出するように頼みました。私が提供した「ファームリアルタイムシステム」の例会社リアルタイムタグは牛乳供給システムでした。システムが有効期限後に牛乳を供給する場合、牛乳は「役に立たない」と見なされます。牛乳なしでシリアルを食べることは許容できますが、体験の質は低下します。

これは、最初に定義を読んだときに頭に浮かんだアイデアです。私はずっと良い例を探しています、そしておそらくそれについての私の概念を改善する会社のリアルタイムのより良い定義を探しています。

ハードリアルタイムとは、すべての締め切りに確実に間に合わなければならないことを意味します。この要件を持つシステムはほとんどありません。いくつかの例は、核システム、ペースメーカーなどのいくつかの医療アプリケーション、多数の防衛アプリケーション、航空電子工学などです。

会社/ソフトリアルタイムシステムは、いくつかの期限を逃す可能性がありますが、あまりに多くの時間を逃すと、最終的にパフォーマンスが低下します。良い例は、コンピューターのサウンドシステムです。数ビットを見逃しても大したことはありませんが、見逃しすぎると、最終的にシステムが劣化します。地震センサーも同様です。少数のデータポイントを見逃しても大した問題ではありませんが、データを理解するにはそれらのほとんどをキャッチする必要があります。さらに重要なことは、正しく機能しなければ誰も死ぬことはないということです。

ペースメーカーでさえ患者を殺すことなく少しだけオフにできるので、線はぼやけていますが、それは一般的な要点です。

暑いところと暖かいところの違いのようなものです。本当の格差はありませんが、それを感じるときあなたはそれを知っています。

ハードリアルタイム

ハードリアルタイムの定義は、任意のシステム障害であることを期限を逃したと見なします。このスケジューリングは、タイミングの制約に適合しないと生命や財産が失われるミッションクリティカルなシステムで広く使用されています。

例：

• センサーの故障により一連のシステムエラーが発生した後、エールフランスフライト447が海に墜落しました。パイロットは、古い計器の測定値に応答している間に航空機を失速させました。12人の乗組員全員と216人の乗客が殺された。

• 優先順位の逆転によりシステムが再起動したときに、火星パスファインダー宇宙船はほとんど失われました。優先度の低いタスクによってブロックされたため、優先度の高いタスクは時間どおりに完了しませんでした。問題は修正され、宇宙船は無事着陸しました。

• インクジェットプリンタには、用紙の特定の部分に正確な量のインクを付着させるための制御ソフトウェアを備えたプリントヘッドがあります。締め切りに間に合わなかった場合、印刷ジョブは台無しになります。

しっかりしたリアルタイム

しっかりリアルタイムの定義は、まれに逃した締め切りが可能になります。これらのアプリケーションでは、十分な間隔があけられている限り、システムはタスクの失敗に耐えることができますが、タスクの完了の値がゼロに低下するか、不可能になります。

例：

• ロボットの組立ラインを備えた製造システムで、締め切りがないと、部品が正しく組み立てられない。台無しにされた部品が品質管理によって捕らえられるほど頻繁ではなく、あまりコストがかからない限り、生産は継続されます。

• デジタルケーブルセットトップボックスは、画面にフレームを表示する必要がある場合のタイムスタンプをデコードします。フレームは時間順序に敏感であるため、期限を逃すとジッターが発生し、サービス品質が低下します。失われたフレームが後で利用可能になった場合、それはそれを表示するためにより多くのジッターを引き起こすだけなので、それは役に立たない。ジッタが頻繁に発生しない場合でも、視聴者はプログラムを楽しむことができます。

ソフトリアルタイム

ソフトリアルタイムの定義は、頻繁に逃した締め切りを可能にし、そして限り、タスクがタイムリーに実行されるよう、その結果が価値を持ち続けます。完了したタスクは、期限までに価値が増加し、それを過ぎると価値が減少する可能性があります。

例：

• 気象ステーションには、温度、湿度、風速などを読み取るための多くのセンサーがあります。読み取り値は定期的に取得して送信する必要がありますが、センサーは同期​​していません。センサーの測定値は他のセンサーと比較して早いか遅いかもしれませんが、それが十分に近い限り、関連性があります。

• ビデオゲームコンソールは、ゲームエンジンのソフトウェアを実行します。タスク間で共有する必要がある多くのリソースがあります。同時に、ゲームを正しくプレイするには、スケジュールに従ってタスクを完了する必要があります。タスクが完全に時間通りに完了している限り、ゲームは楽しいでしょう。

^{Siewert：リアルタイム組み込みシステムおよびコンポーネント。
Liu＆Layland：ハードリアルタイム環境でのマルチプログラミングのスケジューリングアルゴリズム。
Marchand＆Silly-Chetto：ソフト非周期タスクとスキップのある定期タスクの動的スケジューリング}

ウィキペディアのページやその他のリアルタイムコンピューティングに関するページを読んだ後。私は以下の推論を行いました：

1> ハードリアルタイムシステムの場合、システムに障害が発生したと見なされても、システムが期限を満たさない場合。

2> 会社のリアルタイムシステムの場合、システムが期限に間に合わない場合でも（おそらく複数の要求に対して）、システムは失敗したとは見なされません。また、その特定の要求の期限が過ぎると、要求に対する応答（クエリへの応答、タスクの結果など）は無意味になります（結果の有用性は、その期限の後はゼロです）。架空の例としては、嵐の予測システムがあります（到着前に嵐が予測された場合、システムはその仕事を完了し、イベントがすでに発生した後、または発生したときに予測は価値がありません）。

3> ソフトリアルタイムシステムの場合、システムが期限に間に合わない場合でも（おそらく複数の要求に対して）、システムは失敗したとは見なされません。ただし、この場合、リクエストの結果は、期限後の結果にとって価値のない値ではなく、ゼロではなく、期限後に時間が経過するにつれて低下します。例：オーディオビデオのストリーミング。

これは、非常に役立つリソースへのリンクです。

いくつかの大災害をハードリアルタイムの定義に関連付けることは一般的ですが、これは関係ありません。ハードリアルタイムの制約が満たされない場合は、システムが壊れていることを意味します。何かが「壊れた」とラベル付けされたときの結果の重大度は、定義にとって重要ではありません。

会社とソフトは、単一の締め切りに間に合わなかった場合、自動的に壊れていると宣言されません。

ハードリアルタイムの適切な例として、リンクしたページから：

Atari 2600やCinematronicsベクターグラフィックスなどの初期のビデオゲームシステムは、グラフィックスとタイミングハードウェアの性質上、ハードリアルタイム要件がありました。

ビデオ生成ループ内の何かが単一の期限を過ぎた場合、ディスプレイ全体にグリッチが発生し、まれであっても耐えられません。それは壊れたシステムであり、あなたは払い戻しのために店にそれを取り戻すでしょう。だから、リアルタイムは難しいです。

明らかに、どのシステムも処理できない状況の影響を受ける可能性があるため、定義を期待される動作条件内に制限する必要があります。安全が重要なアプリケーションでは、ひどい条件を計画する必要があることに注意してください（「クーラントが蒸発した」、「ブレーキが故障した」が、まれに「太陽が爆発した」）。

そして、時々暗黙の「誰かが見ている間」の動作状態があることを忘れないでください。あなたがルールを破ったのを誰も見なかった場合（または、彼らがルールを破ったが、誰かに告げる前に彼らは火を死なせた場合）、誰もあなたがその事実の後であなたがルールを破ったことを証明できない場合、それはあなたがルールを破らなかった場合と同じです！

さまざまな種類のリアルタイムシステムタイプを区別する最も簡単な方法は、質問に答えることです。

遅延したシステム応答（締め切り後）はまだ役に立ちますか？

したがって、この質問に対する回答に応じて、システムは次のカテゴリのいずれかに含まれる可能性があります。

1. ハード：いいえ、および回答の遅延はシステム障害と見なされます

これは、締め切りを逃すとシステムが使用できなくなる場合です。たとえば、自動車のエアバッグシステムを制御するシステムは、クラッシュを検出し、バッグを急速に膨張させる必要があります。プロセス全体の実行時間は、25分の1秒程度です。したがって、たとえばシステムが1秒間の遅延で反応した場合、結果は致命的となる可能性があり、車がすでにクラッシュした場合にバッグを膨らませてもメリットはありません。

2. 会社：いいえ、ただし、回答の遅延はシステム障害ではありません

これは、締め切りに間に合わなくても許容できる場合ですが、サービスの品質に影響します。簡単な例として、ビデオ暗号化システムを考えます。通常、暗号化のパスワードはサーバー（ビデオヘッドエンド）で生成され、顧客のセットトップボックスに送信されます。通常、セットトップボックスがパスワードを受け取るように、このプロセスを同期する必要があります暗号化されたビデオフレームの受信を開始する前に。この場合、まだパスワードを受け取っていないためセットトップボックスがフレームをデコードできないため、遅延が原因でビデオの不具合が発生する可能性があります。この場合、サービス（映画、面白いサッカーの試合など）は、締め切りに間に合わないことによって影響を受ける可能性があります。この場合、パスワードを遅延して受け取ることは、同じで暗号化されたフレームがすでにグリッチを引き起こしているため、役に立ちません。

3. ソフト：はい、ただしシステムサービスは低下しています

ウィキペディアの説明にあるように、結果の有用性は締め切り後に低下します。つまり、システムからの応答を期限外に取得することは、エンドユーザーにとって依然として有用ですが、期限に達した後は、その有用性が低下します。この場合の簡単な例は、部屋（または建物）の温度を自動的に制御するソフトウェアです。この場合、システムに温度センサーの読み取りに遅延があると、急激な温度変化に反応するのが少し遅くなります。ただし、最終的には変化に反応し、それに応じて温度を調整して、たとえば一定に保つことになります。したがって、この場合は遅延反応が役立ちますが、システムのサービス品質が低下します。

ソフトリアルタイムで結果が期限後に得られたとしても、結果はまだ有効であると考えられた、理解するのが最も簡単です。

例： Webブラウザー-特定のURLを要求するため、ページのロードに時間がかかります。システムがページを提供するのに予想以上の時間がかかる場合、取得したページは無効とは見なされず、システムのパフォーマンスがマークに達していなかったと言えます（システムのパフォーマンスが低下しました！）。

では、ハードリアルタイム結果が期限後に得られた場合、システム、システムが完全に失敗したと考えられています。

例：ロボットがライントレースなどのジョブを実行している場合。そのパスに障害が発生し、ロボットがこの情報をプログラムされた期限内に（ほとんど瞬時に）処理しない場合、ロボットは失敗したと言われます。 （ロボットシステムも完全に破壊される可能性があります！）

でしっかりリアルタイムプロセス実行の結果は、締切後に来る場合、システム、我々はその結果を破棄しますが、システムが失敗してきたためにと呼ばれていません。

例：敵の位置監視やその他のタスクのための衛星通信。衛星がフレームを定期的に送信する地上コンピュータステーションが過負荷で、現在のフレーム（パケット）が時間内に処理されず、次のフレームが表示される場合、現在のパケット（期限を逃したパケット）は問題ではありません。処理が完了したか（または半分完了したかほぼ完了したか）は、ドロップ/破棄されます。しかし、地上コンピュータは完全に故障したとは呼ばれていません。

「ソフトリアルタイム」を定義するには、「ハードリアルタイム」と比較するのが最も簡単です。以下では、「確定リアルタイム」という用語が「ソフトリアルタイム」についての誤解を構成していることがわかります。

気軽に言えば、ほとんどの人は暗黙のうちに情報やイベントを「リアルタイム」と見なす非公式のメンタルモデルを持っています

•認識された通貨に関連している可能性のある遅延（レイテンシ）が発生している場合、またはその程度の場合

•すなわち、情報またはイベントがそれらに対して許容できる満足のいく価値を持つ時間枠内。

「ハードリアルタイム」にはさまざまなアドホック定義がありますが、そのメンタルモデルでは、ハードリアルタイムは「if」という用語で表されます。具体的には、リアルタイムのアクション（タスクなど）に完了期限があると仮定すると、すべてのタスクが完了するイベントの許容できる満足できる値は、すべてのタスクが期限を満たしているという特別な場合に限定されます。

ハードリアルタイムシステムは、アプリケーション、システム、および環境に関するすべてが静的であり、事前に知られているという非常に強力な仮定を行います。リソースの競合はなく、全体としてシステムの時間発展もありません。航空機の飛行制御システムや自動車のブレーキシステムなど、多くの場合、これらの前提条件を満たせば、すべての期限が満たされます。

このメンタルモデルは、ハードリアルタイムとソフトリアルタイムの両方を網羅するのに十分なほど、意図的かつ非常に有用に一般化されています。ソフトは、「その範囲まで」というフレーズで対応できます。たとえば、次の場合にタスク完了イベントに最適ではないが許容できる値があるとします。

• タスクの10％以下が期限に間に合わない
• または、どのタスクも20％を超える遅延はありません
• または、すべてのタスクの平均遅延が15％以下である
• または、すべてのタスクの最大遅延が10％未満

これらはすべて、非常に多くのアプリケーションにおけるソフトリアルタイムケースの一般的な例です。

放課後に子供を迎えに行くというシングルタスクアプリケーションを検討してください。それにはおそらく実際の締め切りはありませんが、代わりに、そのイベントがいつ発生したかに基づいて、あなたとあなたの子供には何らかの価値があります。早すぎるリソース（時間など）の無駄遣いであり、遅すぎると、子供が一人にされ、危害を及ぼす可能性がある（または少なくとも不便な）可能性があるため、マイナスの値になります。

静的なハードリアルタイムの特殊なケースとは異なり、ソフトリアルタイムは、タスクとシステムについて、アプリケーション固有の必要最小限の仮定のみを行い、不確実性が予想されます。子供を迎えに行くには、学校まで車で行く必要があります。そのための時間は、天候や交通状況などに応じて動的になります。最悪の場合の運転時間）ですが、これもリソースを浪費しています（時間、および家族用車両を占有しているため、他の家族による使用を拒否している可能性があります）。

その例は、リソースの浪費という点ではコストがかかるとは思われないかもしれませんが、他の例を検討してください。すべての軍事戦闘システムはソフトリアルタイムです。たとえば、目標の操縦として、更新されたミサイルを使用して敵の地上車両に航空機攻撃を行うことを検討してください。コース更新タスクを完了するための最大の満足度は、ターゲットに対する直接の破壊的ストライキによって達成されます。しかし、この結果を確実にするためにリソースを過剰にプロビジョニングする試みは、通常、非常に高額であり、不可能でさえあります。この場合、ミサイルがターゲットに近づき、それを無効にすることができれば、満足度は低くなりますが十分満足できます。

明らかに、戦闘シナリオには、リソース管理で対応しなければならない、非常に多くの動的な不確実性があります。ソフトリアルタイムシステムは、産業用オートメーションなどの多くの民間システムでも非常に一般的ですが、軍事用システムは、許容できる満足のいく価値を達成するために最も危険で緊急なシステムであることは明らかです。

リアルタイムシステムの要は、「予測可能性」です。ハードリアルタイムのケースは、予測可能性の特別な1つのケースのみに関心があります。つまり、タスクはすべて期限に達し、そのイベントによって可能な最大値が達成されます。その特別なケースは「決定論的」と名付けられています。

予測可能性の範囲があります。決定論的（決定論的）は、予測可能性スペクトルの1つのエンドポイント（最大予測可能性）です。もう1つのエンドポイントは、最小の予測可能性（最大の非決定性）です。スペクトルのメトリックとエンドポイントは、選択した予測可能性モデルの観点から解釈する必要があります。これらの2つのエンドポイント間のすべてが予測不能度（=非決定性度）です。

ほとんどのリアルタイムシステム（つまり、ソフトシステム）には、たとえば、タスクの完了時間、したがってそれらのイベントから得られた値の非決定的な予測可能性があります。

一般に（理論的には）、予測可能性、したがって許容できる満足のいく値は、必要に応じて決定論的なエンドポイントに近づけることができますが、物理的に不可能または非常に高価な価格（戦闘またはおそらく子供を学校から迎えに行くこと）。

ソフトリアルタイムには、アプリケーション固有の確率モデル（一般的な頻出モデルではない）を選択する必要があるため、イベントのレイテンシと結果の値を推論するための予測可能性モデルが必要です。

許容値を提供する上記のイベントのリストに戻って、次のような非決定的なケースを追加できます。

• タスクが期限を5％以上超えない確率は0.87を超えます。（そこに表現されているスケジューリング基準の数に注意してください。）

ミサイル防衛アプリケーションでは、戦闘では常に攻撃よりも防御に勝るという利点があるため、次の2つのリアルタイムコンピューティングシナリオのどちらをお勧めしますか。

• すべての敵ミサイルが完全に破壊される可能性は非常に低いか、または不可能であるため、防御リソースを割り当てて、最も脅威的な（たとえば、そのターゲットに基づいた）敵ミサイルの迎撃が成功する可能性を最大化する敵のミサイルをコース外に移動させることができます）;

• これは静的ではなく動的であるため、リアルタイムコンピューティングの問題ではなく、従来のリアルタイムの概念と手法は適用されず、静的なハードリアルタイムよりも難しいように聞こえるため、興味はありません。 。

リアルタイムコンピューティングコミュニティにおけるソフトリアルタイムに関するさまざまな誤解にもかかわらず、ソフトリアルタイムは、ハードリアルタイムに比べて複雑になる可能性がありますが、非常に一般的で強力です。ここで要約したソフトリアルタイムシステムには、リアルタイムコンピューティングコミュニティ以外で長い間使用されてきた実績があります。

OPの質問に直接回答するには：

ハードリアルタイムシステムは、決定論的な保証を提供できます。最も一般的には、すべてのタスクが期限を満たし、割り込みまたはシステムコールの応答時間が常にx未満になるなどです。非常に強力な仮定が行われ、正しい場合のみ重要なすべてのものは静的であり、事前に知られている（一般に、ハードリアルタイムシステムに対するそのような保証は、かなり単純な場合を除いて、未解決の研究問題です）

ソフトリアルタイムシステムは確定的な保証を行いません。これは、アプリケーション固有の基準に従って、現在の動的な状況で実現可能な、分析的に指定され達成された確率的な適時性と適時性の予測可能性を可能な限り提供することを目的としています。

明らかにハードリアルタイムは、ソフトリアルタイムの単純な特別なケースです。明らかにソフトリアルタイムの分析的非決定的保証は提供が非常に複雑になる可能性がありますが、ほとんどのリアルタイムケースは動的ではないため、最も一般的なリアルタイムケース（戦闘などの最も危険な安全上重要なケースを含む）では必須です静的。

「ファームリアルタイム」は、「ソフトリアルタイム」の明確に定義されていない特殊なケースです。「ソフトリアルタイム」という用語が適切に理解され使用されている場合、この用語は不要です。

私のWebサイトreal-time.orgで、リアルタイム、ハードリアルタイム、ソフトリアルタイム、予測可能性、決定論、および関連トピックについて、より詳細ではるかに正確な議論をしています。

リアルタイム-計算結果を使用して外部プロセスをタイムリーに制御、監視、または応答できるようにするために、外部プロセスが発生する実際の時間中に計算が実行されるシステムまたは動作モードに関する用語マナー。[IEEE標準610.12.1990]

私はこの定義が古く、非常に古いことを知っています。しかし、IEEE（Institute of Electrical and Electronics Engineers）による最近の定義はわかりません。

シリアルポートからデータを入力するタスクを考えてみましょう。新しいデータが到着すると、シリアルポートがイベントをトリガーします。ソフトウェアがそのイベントを処理すると、新しいデータが読み取られて処理されます。シリアルポートには、受信データ（MSP432では2つ、TM4C123では16つ）を格納するためのハードウェアがあり、バッファーがいっぱいでさらに多くのデータが到着すると、新しいデータは失われます。このシステムはハード、ハード、またはソフトのリアルタイムですか？

応答が遅れると、データが失われる可能性があるため、リアルタイムは困難です。

マイクから音声を入力し、音声データを操作してスピーカーに出力する補聴器を考えます。システムには通常、限られた小さなジッタがありますが、補聴器の他のタスクが原因で一部のデータが遅れ、スピーカーにノイズパルスが発生することがあります。このシステムはハード、ハード、ソフトのリアルタイムですか？

認識できるエラーを引き起こすため、しっかりとしたリアルタイムですが、影響は無害であり、エクスペリエンスの品質を大幅に変更することはありません。

データをプリンターに出力するタスクを考えてみましょう。プリンターがアイドル状態のとき、プリンターはイベントをトリガーします。ソフトウェアがそのイベントを処理すると、プリンターにさらにデータが送信されます。このシステムはハード、ハード、ソフトのリアルタイムですか？

それは、ソフトリアルタイム速く、より良い回答が、システムの値が（帯域幅が毎秒印刷されたデータの量である）、待ち時間を減少させるため。

UTAustinX：UT.RTBN.12.01xリアルタイムBluetoothネットワーク

おそらく、定義に誤りがあります。

私の経験から、ハードウェアとソフトウェアに依存するものとして2つを分離します。

ハードウェア駆動の割り込みを処理する200msがある場合、それはあなたが得たものです。そこに300msのコードを挿入すると、システムは壊れず、開発されていません。完了する前に切り替えられます。コードが機能しないか、目的に適合していません。多くのシステムには、明確に定義された処理期間があります。ビデオ、テレコムなど

リアルタイムのアプリケーションを作成している場合、これはソフトと考えることができます。時間切れになった場合は、次回の負荷を軽減したい場合は、OSを調整したり、メモリを追加したり、ハードウェアをアップグレードしたりできます。オプションがあります。

UXの観点から見ると役に立ちません。シュコダはグリッチがあっても壊れないかもしれませんが、BMWは間違いなくそうなるでしょう。

定義は何年にもわたって用語の不利益にまで拡大しています。現在「ハード」リアルタイムと呼ばれているのは、以前は単にリアルタイムと呼ばれていたものです。したがって、（片側のタイムデッドラインではなく）タイミングウィンドウが不足しているために不正なデータや不正な動作が発生するシステムは、リアルタイムと見なす必要があります。その特性のないシステムは、非リアルタイムと見なされます。

それは、非リアルタイムシステムでは時間が重要ではないということではありません。それは、そのようなシステムのタイミング要件が根本的に不正確な結果をもたらさないことを意味するだけです。

ハードリアルタイムシステムは優先スケジュールのプリエンプティブバージョンを使用するため、重要なタスクはすぐにスケジュールされますが、ソフトリアルタイムシステムは非プリエンプティブバージョンの優先スケジュールを使用します。これにより、制御がより高い優先度に移る前に現在のタスクを終了できますタスク、追加の遅延を引き起こします。したがって、ハードリアルタイムシステムではタスクの期限が厳しく守られますが、ソフトリアルタイムシステムではそれほど深刻には処理されません。