26

リアルタイム OS が期限を逃さずに期限を守れるのはなぜですか? それとも、これは単なる神話 (締め切りに遅れないということ) ですか? それらは通常の OS とどう違うのでしょうか? また、通常の OS が RTOS になるのを妨げるものは何ですか?

4

12 に答える 12

31

締め切りに間に合うかどうかは、作成するアプリケーションの機能です。RTOS は、締め切りに間に合わせるのに役立つ機能を提供するだけです。また、大きなメイン ループで「ベア メタル」(oa RTOS) でプログラムして、締め切りに間に合わせることができます。

また、より汎用的な OS とは異なり、RTOS で実行されるタスクとプロセスのセットは非常に限られていることに注意してください。

RTOS が提供する機能の一部:

  • 優先度ベースのスケジューラ
  • システムクロック割り込みルーチン
  • 確定的な動作

優先度ベースのスケジューラ

ほとんどの RTOS では、個々のタスク/プロセスに対して 32 から 256 の可能な優先順位があります。スケジューラは、最も優先度の高いタスクを実行します。実行中のタスクが CPU を放棄すると、次に優先度の高いタスクが実行されます...

システムで最も優先度の高いタスクは、次の時点まで CPU を使用します。

  • 完了するまで実行されます (つまり、自発的に CPU を放棄します)。
  • 優先度の高いタスクの準備が整うと、元のタスクは新しい (優先度の高い) タスクによって横取りされます。

開発者として、締め切りが守られるようにタスクの優先順位を割り当てるのはあなたの仕事です。

システム クロック割り込みルーチン

RTOS は通常、時間に敏感な操作を実行できる何らかのシステム クロック (500 μS から 100 ms の範囲) を提供します。1 ミリ秒のシステム クロックがあり、50 ミリ秒ごとにタスクを実行する必要がある場合、通常、「50 ミリ秒で目を覚ます」と言うことができる API があります。その時点で、タスクは RTOS がウェイクアップするまでスリープ状態になります。

目が覚めただけでは、その時間に正確に実行できるとは限らないことに注意してください。優先順位次第です。優先度の高いタスクが現在実行されている場合は、遅れる可能性があります。

確定的な動作

RTOS は、タスクが 10 個であろうと 100 個であろうと、コンテキストを切り替えたり、次に優先度の高いタスクを決定したりするのに時間がかからないようにするために多大な努力を払っています...

一般に、RTOS 操作は O(1) になろうとします。

RTOS における決定論的動作の主な領域の 1 つは、割り込み処理です。割り込みラインが通知されると、RTOS はすぐに正しい割り込みサービス ルーチンに切り替え、遅延なく割り込みを処理します (現在実行中のタスクの優先度に関係なく)。

ほとんどのハードウェア固有の ISR は、プロジェクトの開発者によって作成されることに注意してください。RTOS は、シリアル ポート、システム クロック、ネットワーク ハードウェアの ISR を既に提供している可能性がありますが、特殊なもの (ペースメーカー信号、アクチュエータなど) は RTOS の一部ではありません。

これは全体的な一般化であり、他のすべてと同様に、多種多様な RTOS 実装があります。一部の RTOS では動作が異なりますが、上記の説明は既存の RTOS の大部分に適用できます。

于 2009-02-11T13:37:06.873 に答える
3

RTOS で注意すべき最も重要なパラメータは、低レイテンシと時間決定論です。これは、特定のポリシーとトリックに従うことで快適に実行されます。

一方、GPOS では、許容可能なレイテンシーとともに、重要なパラメーターは高スループットです。時間決定論のために GPOS をあてにすることはできません。

RTOS には、GPOS のプロセス/スレッドよりもはるかに軽いタスクがあります。

于 2012-12-15T06:02:43.120 に答える
2

典型的な RTOS のソースを読むと役立つ場合があります。そこにはいくつかのオープンソースの例があり、次のリンクは少し簡単な検索で得られました。

十分に文書化され、ソース コード形式で入手でき、操作が簡単な商用 RTOS はµC/OS-IIです。それは教育的使用のための非常に寛容なライセンスを持っており、そのソースは、実際の実装をサンプルコードとして使用して動作理論を説明する本にバインドすることができます. この本は、Jean Labrosse によるMicroC OS II: The Real Time Kernelです。

私は何年にもわたっていくつかのプロジェクトで µC/OS-II を使用してきましたが、お勧めできます。

于 2009-04-28T07:39:59.220 に答える
2

締め切りに間に合うということではなく、通常の OS にはそのような締め切りがないのに対し、締め切りが固定されているということです。

通常の OS では、タスク スケジューラはあまり厳密ではありません。つまり、プロセッサは毎秒非常に多くの命令を実行しますが、そうでない場合もあります。たとえば、優先度の高いタスクを実行できるようにするために、タスクがプリエンプトされる場合があります (長時間実行される場合もあります)。RTOS では、プロセッサは常に同じ数のタスクを実行します。

さらに、通常、タスクの完了には時間制限があり、その後に失敗が報告されます。これは、通常の OS では発生しません。

明らかに、説明すべき詳細はもっとたくさんありますが、上記は RTOS で使用される重要な設計側面の 2 つです。

于 2009-02-11T12:14:32.890 に答える
2

RTOS は、重要なイベントのタイミングを保証できるように設計されています。たとえば、ハードウェアの割り込み処理や、必要なときにスリープ状態のプロセスをウェイクアップするなどです。

この正確なタイミングにより、プログラマーは、OS が別の非効率的なタスクでビジー状態になったために数十ミリ秒後ではなく、(たとえば) ペースメーカーが必要なときに正確にパルスを出力することを確認できます。

通常、本格的な Linux や Windows よりもはるかに単純な OS です。単純なコードの動作を分析して予測するのが簡単だからです。Linux のような本格的な OS が RTOS 環境で使用されるのを止めるものは何もなく、RTOS 拡張機能があります。コード ベースが複雑なため、小さな OS ほど小さなスケールまでタイミングを保証することはできません。

また、RTOS スケジューラは、汎用スケジューラよりも厳密です。長時間実行しており、対話型のユーザーがいないため、スケジューラがタスクの優先度を変更しないことを知っておくことが重要です。ほとんどの OS は、このタイプのプロセスの内部優先度を下げて、インターフェースの遅れが見られない短期的な対話型プログラムを優先します。

于 2009-02-11T12:51:25.343 に答える
0

重要なのはリアルタイムOSではなくリアルタイムアプリケーションです。通常、リアルタイムアプリケーションは予測可能です。多くのテスト、検査、WCET分析、証明などが実行され、特定の状況で期限が守られていることが示されます。

RTOSがこの作業（アプリケーションの構築とRT制約の検証）を行うのに役立つことがあります。しかし、私はリアルタイムアプリケーションが標準のLinuxで実行されており、OSの設計よりもハードウェアの処理能力に依存しているのを見てきました。

于 2009-02-11T12:21:24.340 に答える
0

教科書/インタビューの答えは「決定論的プリエンプション」です。より優先度の高いプロセスが (レディ キューで) 実行する準備ができている場合、または割り込みがアサートされている場合 (通常は CPU/MCU への外部入力)、システムは制限された期間内に制御を転送することが保証されます。

于 2009-11-13T02:59:52.173 に答える
0

実際には、締め切りに間に合うことを保証するものではありません。彼らが真の RTOS にするためにしていることは、締め切り超過を認識して対処する手段を提供することです。「ハード」RT システムは一般に、締め切りに間に合わないことが悲惨であり、何らかのシャットダウンが必要なシステムです。一方、「ソフト」RT システムは、低下した機能を継続することが理にかなっているシステムです。どちらにしても、RTOS では、このようなオーバーランへの応答を定義できます。非 RT OS はオーバーランを検出しません。

于 2009-11-13T03:34:04.500 に答える
0

私は RTOS を使用したことがありませんが、これがその仕組みだと思います。

「ハードリアルタイム」と「ソフトリアルタイム」には違いがあります。Windows のような非 RTOS でリアルタイム アプリケーションを作成できますが、それらは「ソフト」リアルタイムです。

  • アプリケーションとして、O/S に 1 秒あたり 10 回実行するように要求するスレッドまたはタイマーがある場合があります。ほとんどの場合、O/S はそれを実行する可能性がありますが、常に実行されるという保証はありません。できる ... この保証の欠如が、「ソフト」と呼ばれる理由です。O/S が実行できない理由は、別のスレッドがシステムを別のことでビジー状態にしている可能性があるためです。アプリケーションとして、スレッドの優先度をたとえば に上げることができますが、これを行っても、特定の時間に実行されるという保証HIGH_PRIORITY_CLASSを要求するために使用できる API が O/S にまだありません。

  • 「ハード」なリアルタイム O/S には、保証された実行スライスを要求できる API があります (私は想像します)。RTOS がそのような保証を行うことができる理由は、予想よりも時間がかかる/許可されているよりも多くの時間がかかるスレッドを喜んで異常終了させるためです。

于 2009-02-11T12:41:44.337 に答える
0

「基本的に、RTOS の各「タスク」は、有限時間内に終了するようにコーディングする必要があります。」

これは実際には正しいです。RTOS には、アーキテクチャによって定義されたシステム ティック (たとえば 10 ミリ秒) があり、すべてのタスク (スレッド) が特定の時間内に完了するように設計および測定されます。たとえば、オーディオ サンプル レートが 48kHz のリアルタイム オーディオ データの処理では、データを処理しているダウンストリーム タスクでプリバッファが空になる既知の時間 (ミリ秒単位) があります。したがって、RTOS を使用するには、バッファのサイズを正しく設定し、これにかかる時間を推定して測定し、システム内のすべてのソフトウェア レイヤー間のレイテンシを測定する必要があります。その後、締め切りに間に合わせることができます。そうしないと、アプリケーションは締め切りに間に合いません。これには、スタック全体で最悪のケースのデータ処理を分析する必要があり、最悪のケースがわかれば、システムを次のように設計できます。

リアルタイム オペレーティング システム ネットワーク アプリの設計のタイミング図の例は、EE Times のこの記事、 PRODUCT HOW-TO: Improving real-time voice quality in a VoIP-based telephony design http://www.eetimes.com/にあります。 design/embedded/4007619/PRODUCT-HOW-TO-VoIP ベースのテレフォニー設計におけるリアルタイム音声品質の向上

于 2011-07-13T23:39:12.437 に答える
-1

基本的に、RTOS の各「タスク」は、有限時間内に終了するようにコーディングする必要があります。

さらに、カーネルは、特定のことが特定の時間に発生することを保証するために、各タスクに特定の時間を割り当てます。

ただし、これは簡単な作業ではないことに注意してください。仮想関数呼び出しのようなものを想像してみてください。オブジェクト指向では、これらを判断するのは非常に困難です。また、RTOS は優先度に関して慎重にコーディングする必要があります。優先度の高いタスクに x ミリ秒以内に CPU を割り当てる必要がある場合があります。これは、スケジューラの動作方法によっては難しい場合があります。

于 2009-02-11T12:17:00.903 に答える