リアルタイムコンピューティング(RTC)は、例えばイベントからシステム応答までの時間など、「リアルタイム制約」を受けるハードウェアおよびソフトウェアシステムを表すコンピュータサイエンスの用語です。[ 1 ]リアルタイムプログラムは、指定された時間制約(しばしば「デッドライン」と呼ばれる)内で応答することを保証する必要があります。[ 2 ]
シミュレーションにおいて「リアルタイム」という用語は、シミュレーション内の時計が実際の時計と同じ速度で動作することを意味する場合にも使用されます。
リアルタイム応答とは、多くの場合、ミリ秒単位、場合によってはマイクロ秒単位の応答時間を指します。リアルタイム動作が明記されていないシステムは、通常、いかなる時間枠内でも応答を保証することはできませんが、標準的な応答時間や想定される応答時間は示される場合があります。リアルタイム処理は、イベントに対する指定された期限内に完了しない場合、失敗します。期限は、システムの負荷に関係なく、常に遵守されなければなりません。
リアルタイムシステムは、「データを受信し、処理し、その時点で環境に影響を与えるのに十分な速さで結果を返すことによって環境を制御する」システムとして説明されています。[ 3 ]「リアルタイム」という用語は、プロセス制御およびエンタープライズシステムでは「大きな遅延なし」という意味で使用されます。
リアルタイムソフトウェアは、同期プログラミング言語、リアルタイムオペレーティングシステム(RTOS)、リアルタイムネットワークなど、以下の要素のうち1つ以上を使用する場合があります。これらのそれぞれが、リアルタイムソフトウェアアプリケーションを構築するための重要なフレームワークを提供します。
多くの安全性が重要な用途で使用されるシステムは、リアルタイムである必要があり、例えばフライバイワイヤ航空機の制御やアンチロックブレーキなどでは、即時かつ正確な機械的応答が求められます。[ 4 ]
リアルタイムという用語は、初期のシミュレーションで用いられていたことに由来します。そこでは、現実世界のプロセスが実際のプロセスと同じ速度でシミュレートされていました(現在では曖昧さを避けるためにリアルタイムシミュレーションと呼ばれています)。アナログコンピュータは、多くの場合、リアルタイムよりもはるかに速い速度でシミュレートすることが可能でした。この状況は、認識され考慮されない場合、遅いシミュレーションと同様に危険なものになりかねません。
ミニコンピュータ、特に1970年代以降に登場したミニコンピュータは、 DOG(デジタルオンスクリーングラフィック)スキャナなどの専用組み込みシステムに組み込まれるようになり、受信データとの重要なやり取りに対して低遅延で優先度駆動型の応答を行う必要性が高まりました。Data GeneralのRDOS(リアルタイムディスクオペレーティングシステム)や、バックグラウンドおよびフォアグラウンドスケジューリングを備えたRTOS 、 Digital Equipment CorporationのRT-11などのオペレーティングシステムはこの時代に登場しました。バックグラウンド/フォアグラウンドスケジューリングでは、フォアグラウンドタスクを実行する必要がないときに優先度の低いタスクにCPU時間を割り当て、フォアグラウンド内では最も優先度の高いスレッド/タスクに絶対的な優先度を与えました。リアルタイムオペレーティングシステムは、マルチユーザーのタスクをタイムシェアリングするためにも使用されました。たとえば、Data General Business BasicはRDOSのフォアグラウンドまたはバックグラウンドで実行でき、ダム端末を介して操作するユーザーにより適したスケジューリングアルゴリズムに要素を追加しました。
初期のパーソナルコンピュータは、リアルタイムコンピューティングに使用されることがありました。他の割り込みを無効化できる機能により、タイミングが定義されたハードコードされたループが可能になり、割り込みの遅延が少なかったため、リアルタイムオペレーティングシステムを実装することができ、ユーザーインターフェイスとディスクドライブの優先度をリアルタイムスレッドよりも低くすることができました。これらと比較すると、Intel x86ファミリーCPUのプログラマブル割り込みコントローラは非常に大きな遅延を生成し、Windowsオペレーティングシステムはリアルタイムオペレーティングシステムではなく、ネイティブマシン語を使用せずにプログラムがCPUを完全に制御して独自のスケジューラを使用することも許可していません。つまり、すべての割り込みWindowsコードをバイパスすることはできません。しかし、さまざまなオペレーティングシステム上で高水準言語でリアルタイム機能を提供するコーディングライブラリがいくつか存在します。たとえば、Real-time Javaなどです。Motorola 68000とその後のファミリーメンバー(68010、68020、ColdFireなど)などの後期のマイクロプロセッサも、産業用制御システムのメーカーに人気がありました。この応用分野は、リアルタイム制御がプロセス性能と安全性の面で真に有利な点をもたらす分野の一つである。
システムの完全な正しさが、その論理的な正しさだけでなく、実行される時間にも依存する場合、そのシステムはリアルタイムであると言われます。 [ 5 ]リアルタイムシステムとその期限は、期限を過ぎた場合の結果によって分類されます。[ 6 ]
したがって、ハードリアルタイムシステムの目標はすべての期限を確実に守ることですが、ソフトリアルタイムシステムの目標は、アプリケーション固有の基準を最適化するために、特定の期限のサブセットを満たすことになります。最適化される具体的な基準はアプリケーションによって異なりますが、典型的な例としては、期限を満たすタスクの数を最大化すること、タスクの遅延を最小化すること、優先度の高いタスクが期限を満たす数を最大化することなどが挙げられます。
ハードリアルタイムシステムは、イベントに対して厳密な期限内に反応することが不可欠な場合に使用されます。このような強力な保証は、一定時間内に反応しないと何らかの形で大きな損失、特に周囲環境への物理的な損傷や人命の危険が生じるようなシステムに求められます(ただし、厳密な定義では、期限を過ぎた場合、それはシステムの失敗を意味します)。ハードリアルタイムシステムの例をいくつか挙げます。
マルチタスクシステムのコンテキストでは、スケジューリング ポリシーは通常、優先度駆動型 (プリエンプティブスケジューラ) です。状況によっては、これらはハード リアルタイム パフォーマンスを保証できます (たとえば、タスクのセットとその優先度が事前にわかっている場合)。レート モノトニックなどの他のハード リアルタイム スケジューラもありますが、タスクをスケジュールするために追加の情報 (タスクの実行時間の上限または最悪の場合の見積もり) が必要なため、汎用システムでは一般的ではありません。このようなハード リアルタイム タスクをスケジュールするための特定のアルゴリズムが存在し、たとえば、アーリーデッドライン ファースト (Earliest Deadline First)などがあります。これは、コンテキスト スイッチングのオーバーヘッドを無視すれば、システム負荷が 100% 未満の場合で十分です。[ 7 ]適応型パーティション スケジューラなどの新しいオーバーレイ スケジューリング システムでは、ハード リアルタイム アプリケーションと非リアルタイム アプリケーションが混在する大規模システムの管理に役立ちます。
厳密なリアルタイムシステムは定義がより曖昧であり、ハードリアルタイムシステムとソフトリアルタイムシステムのみを区別する分類では、厳密なリアルタイムシステムは含まれません。厳密なリアルタイムシステムの例をいくつか挙げます。
ソフトリアルタイムシステムは、通常、同時アクセスの問題や、変化する状況に応じて複数の接続システムを最新の状態に保つ必要性を解決するために使用されます。ソフトリアルタイムシステムの例をいくつか挙げます。
リアルタイムデジタル信号処理(DSP)プロセスでは、解析(入力)サンプルと生成(出力)サンプルは、処理遅延に関係なく、同じサンプルセットを入力および出力するのにかかる時間内に連続的に処理(または生成)できます。 [ 9 ]これは、処理が無限の時間継続する場合でも、処理遅延に制限がある必要があることを意味します。オーバーヘッドを含むサンプルあたりの平均処理時間は、サンプリング周期(サンプリングレートの逆数)以下です。これは、サンプルが大きなセグメントにグループ化されてブロックとして処理されるか、個別に処理されるか、また、入力バッファと出力バッファが長いか短いか、または存在しないかの基準です。
音声DSPの例を考えてみましょう。2.00秒の音声を分析、合成、または処理するのに2.01秒かかる場合、それはリアルタイムではありません。しかし、1.99秒で済む場合は、リアルタイムDSP処理であるか、リアルタイムDSP処理にすることができます。
日常生活でよくある例えとして、スーパーマーケットのレジで列に並んで待つことが挙げられます。列が際限なくどんどん長くなっていく場合、レジ処理はリアルタイムではありません。列の長さが一定で、顧客が列に並ぶのと平均して同じ速さでサービスを受けられるのであれば、その処理はリアルタイムです。レジ処理をリアルタイムにできないと、スーパーマーケットは顧客を失うことになります。したがって、この処理がリアルタイムであることは、根本的に重要なのです。
入力データの流れに追いつけず、出力が入力からどんどん遅れていくような信号処理アルゴリズムは、リアルタイムとは言えません。一方、無制限の時間で動作するプロセスにおいて、出力の遅延(入力に対する相対的な遅延)が制限されている場合、たとえスループットの遅延が非常に長くても、その信号処理アルゴリズムはリアルタイムです。
ライブイベントのサポートなどで必要とされるようなライブ信号処理には、リアルタイム信号処理は必要ではあるが、それだけでは十分ではない。ライブオーディオデジタル信号処理には、リアルタイム動作と、ステージモニターやインイヤーモニターを使用するパフォーマーにとって許容範囲内であり、パフォーマーを直接見ている観客にもリップシンクエラーとして気づかれないような、スループット遅延の十分な制限の両方が必要である。ライブリアルタイム処理における許容可能なレイテンシーの制限は調査と議論の対象となっているが、6~20ミリ秒と推定されている。[ 10 ]
リアルタイムの双方向通信における遅延が300ミリ秒未満(往復遅延、つまり一方向の遅延の2倍)であれば、会話中の不要な「通話オーバー」を避けるため「許容範囲内」とみなされます。
リアルタイムコンピューティングは、高性能コンピューティングと誤解されることがありますが、これは正確な分類ではありません。[ 11 ]例えば、科学シミュレーションを実行する巨大なスーパーコンピュータは、印象的なパフォーマンスを発揮するかもしれませんが、リアルタイム計算を実行しているわけではありません。逆に、アンチロックブレーキシステムのハードウェアとソフトウェアが、必要な期限を満たすように設計された後は、それ以上のパフォーマンス向上は必須ではなく、有用でもありません。さらに、ネットワークサーバーがネットワークトラフィックで高負荷状態にある場合、応答時間は遅くなる可能性がありますが、(ほとんどの場合)タイムアウト(期限に達する)前に成功します。したがって、このようなネットワークサーバーはリアルタイムシステムとはみなされません。時間的な障害(遅延、タイムアウトなど)は通常小さく、区画化されており(影響は限定的)、壊滅的な障害ではありません。FTSE 100指数などのリアルタイムシステムでは、制限を超える速度低下は、そのアプリケーションのコンテキストでは壊滅的とみなされることがよくあります。リアルタイムシステムにおいて最も重要な要件は、高いスループットではなく、安定した出力である。
チェスプログラムなど、一部のソフトウェアはどちらのカテゴリにも分類されます。例えば、制限時間のあるトーナメントでプレイするように設計されたチェスプログラムは、一定の期限までに指し手を決めなければ負けてしまうため、リアルタイム計算です。一方、指し手を決めるまで無制限に実行できるチェスプログラムはリアルタイム計算ではありません。しかし、どちらの場合も高いパフォーマンスが求められます。トーナメントチェスプログラムは、割り当てられた時間内に多くの処理を実行できればできるほど、指し手はより良くなり、制約のないチェスプログラムは、実行速度が速ければ速いほど、指し手を早く決められるようになります。この例は、リアルタイム計算とその他の計算の本質的な違いも示しています。トーナメントチェスプログラムは、割り当てられた時間内に次の指し手を決めなければ負けてしまいます。つまり、リアルタイム計算として失敗していることになります。一方、もう一方のシナリオでは、期限を守る必要はないと想定されています。高性能とは、一定時間内に実行される処理量を指し、リアルタイムとは、利用可能な時間内に処理を完了させ、有用な出力を得る能力を指します。
電気通信およびコンピューティングにおける「ニアリアルタイム」または「ニアリーリアルタイム」(NRT)という用語は、イベントの発生と、表示やフィードバック、制御などの目的で処理されたデータを使用するまでの、自動データ処理またはネットワーク伝送によって生じる時間遅延を指します。たとえば、ニアリアルタイム表示は、イベントや状況を、処理時間を差し引いた現在の時刻に、ライブイベントの時刻とほぼ同じ時刻に表示します。[ 12 ]
「ニアリアルタイム」と「リアルタイム」の区別はやや曖昧で、状況に応じて定義する必要があります。この用語は、重大な遅延がないことを意味します。[ 12 ]多くの場合、「リアルタイム」と表現される処理は、「ニアリアルタイム」と表現する方がより正確です。
ニアリアルタイムとは、音声や動画の遅延リアルタイム伝送も指します。これにより、大きな動画ファイル全体のダウンロードを待つことなく、ほぼリアルタイムで動画を再生できます。互換性のないデータベースでも、共通のフラットファイルにエクスポート/インポートすることで、もう一方のデータベースがスケジュールに基づいてインポート/エクスポートできるデータにアクセスし、共通データを「ニアリアルタイム」で同期/共有できます。
リアルタイムシステムの設計を支援する方法はいくつか存在し、その一例として、システムの並行構造を表現する古くからある非常に成功した手法であるMASCOTが挙げられる。その他の例としては、 HOOD、リアルタイムUML、AADL、Ravenscarプロファイル、リアルタイムJavaなどがある。
適切なA/V同期制限が設定されており、映画で許容される範囲は±22msです。ATSCによると、ビデオの範囲は最大15msのリードタイムと約45msのラグタイムです。
[...] リアルタイム設計で考慮すべき問題点を指摘するのに役立つと思われる一連のメモ。