リアルタイムコンピューティング

リアルタイムコンピューティング（RTC）は、イベントからシステム応答までなど、「リアルタイム制約」の対象となるハードウェアおよびソフトウェアシステムを指すコンピュータサイエンス用語です。^[1]リアルタイムプログラムは、指定された時間制約（多くの場合「期限」と呼ばれます）内での応答を保証する必要があります。^[2]

「リアルタイム」という用語は、シミュレーションでは、シミュレーションのクロックが実際のクロックと同じ速度で実行されることを意味するためにも使用されます。

リアルタイム応答は、多くの場合、ミリ秒単位、場合によってはマイクロ秒単位であると理解されています。リアルタイムで動作するように指定されていないシステムは、通常、標準または予想される応答時間が示されることはあっても、任意の時間枠内での応答を保証することはできません。リアルタイム処理は、イベントに関連する指定された期限内に完了しない場合は失敗します。期限は、システム負荷に関係なく、常に守られる必要があります。

リアルタイムシステムは、「データを受信し、処理し、その時点で環境に影響を与えるのに十分な速さで結果を返すことによって環境を制御する」システムと説明されています。^[3]「リアルタイム」という用語は、プロセス制御およびエンタープライズシステムで「大幅な遅延なし」を意味するために使用されます。

リアルタイム ソフトウェアでは、同期プログラミング言語、リアルタイム オペレーティング システム(RTOS)、リアルタイム ネットワークの 1 つ以上が使用されることがあります。これらはそれぞれ、リアルタイム ソフトウェア アプリケーションを構築するための重要なフレームワークを提供します。

多くの安全性が極めて重要なアプリケーションに使用されるシステムは、フライ・バイ・ワイヤ航空機の制御やアンチロックブレーキなど、即時かつ正確な機械的応答を必要とするリアルタイムである必要があります。 ^[4]

リアルタイムという用語は、現実世界のプロセスが実際のプロセスと同じ速度でシミュレートされる初期のシミュレーションでの使用に由来しています (曖昧さを避けるために、現在はリアルタイム シミュレーションと呼ばれています)。アナログ コンピューターは、ほとんどの場合、リアルタイムよりもはるかに速いペースでシミュレーションを実行できましたが、この状況も認識および考慮されなければ、遅いシミュレーションと同じくらい危険になる可能性があります。

特に 1970 年代以降、ミニコンピュータがDOG ( Digital on-screen graphic ) スキャナなどの専用の組み込みシステムに組み込まれると、重要な受信データとのやり取りに対する低遅延の優先度主導型応答の必要性が高まり、バックグラウンド/フォアグラウンド スケジューリングを備えたData GeneralのRDOS (Real-Time Disk Operating System)や RTOS 、 Digital Equipment CorporationのRT-11などのオペレーティング システムはこの時代にさかのぼります。バックグラウンド/フォアグラウンド スケジューリングでは、フォアグラウンド タスクを実行する必要がない場合に優先度の低いタスクに CPU 時間を割り当て、フォアグラウンド内では優先度が最も高いスレッド/タスクに絶対的な優先度を与えました。リアルタイム オペレーティング システムは、タイム シェアリングマルチユーザー タスクにも使用されました。たとえば、Data General Business Basic はRDOS のフォアグラウンドまたはバックグラウンドで実行でき、ダム ターミナルを介してやり取りするユーザーに適したスケジューリング アルゴリズムに追加の要素を導入しました。

初期のパーソナルコンピュータは、リアルタイムコンピューティングに使用されることがありました。他の割り込みを非アクティブ化できるため、定義されたタイミングでハードコードされたループが可能になり、割り込みレイテンシが低いため、リアルタイムオペレーティングシステムを実装して、ユーザーインターフェイスとディスクドライブにリアルタイムスレッドよりも低い優先順位を与えることができました。これらと比較して、 Intel CPU (8086..80586) のプログラマブル割り込みコントローラは非常に大きなレイテンシを生成し、Windowsオペレーティングシステムはリアルタイムオペレーティングシステムではなく、ネイティブマシン言語を使用せずにプログラムがCPUを完全に乗っ取って独自のスケジューラを使用し、すべての割り込みWindowsコードをバイパスすることもできません。ただし、 Java Real Timeなど、さまざまなオペレーティングシステムで高級言語でリアルタイム機能を提供するコーディングライブラリがいくつか存在します。モトローラ68000やその後継ファミリのメンバー (68010、68020、ColdFireなど)などの後のマイクロプロセッサも、産業用制御システムの製造業者に人気を博しました。このアプリケーション領域は、リアルタイム制御がプロセスのパフォーマンスと安全性の面で真の利点を提供する領域です。^{[引用が必要]}

操作の完全な正確さが論理的な正確さだけでなく、それが実行される時間にも依存する場合、システムはリアルタイムであると言われます。 ^[5]リアルタイムシステムとその期限は、期限を守れなかった場合の結果によって分類されます。^[6]

• 厳しい – 期限を守れないのはシステム全体の障害です。
• 厳格 – まれに期限を守れなくても許容できますが、システムのサービス品質が低下する可能性があります。期限を過ぎると、結果の有用性はゼロになります。
• ソフト - 期限を過ぎると結果の有用性が低下し、システムのサービス品質が低下します。

したがって、ハード リアルタイム システムの目標は、すべての期限を守ることですが、ソフト リアルタイム システムの目標は、アプリケーション固有の基準を最適化するために、期限の特定のサブセットを守ることとなります。最適化される特定の基準はアプリケーションによって異なりますが、一般的な例としては、守られる期限の数を最大化すること、タスクの遅延を最小化すること、期限を守る優先度の高いタスクの数を最大化することなどが挙げられます。

ハード リアルタイム システムは、イベントに厳格な期限内に反応することが必須である場合に使用されます。このような強力な保証は、一定の時間内に反応しないと、特に周囲の物理的な損傷や人命の脅威など、何らかの形で大きな損失が発生するシステムで必要になります (ただし、厳密な定義では、期限を守れないとシステムの障害になるだけです)。ハード リアルタイム システムの例をいくつか示します。

• 自動車の エンジン制御システムは、遅延信号によってエンジンの故障や損傷が発生する可能性があるため、ハードリアルタイムシステムです。
• 心臓ペースメーカーなどの医療システム。ペースメーカーの役割は単純ですが、人命に危険を及ぼす可能性があるため、このような医療システムは通常、徹底したテストと認証を受ける必要があり、そのためには、故障の可能性が低い、またはあり得ないことを証明できる保証を提供するために、ハードリアルタイムコンピューティングが必要になります。
• 産業用プロセス コントローラー (組立ラインの機械など)。機械が遅れると、組立ライン上のアイテムが機械の手の届かないところを通過してしまう (製品がそのまま残ってしまう) か、ロボットを間違ったタイミングで起動することで機械または製品が損傷する可能性があります。障害が検出されると、どちらの場合も組立ラインが停止し、生産が遅くなります。障害が検出されないと、欠陥のある製品が生産を終えるか、生産の後の段階で損傷を引き起こす可能性があります。
• ハード リアルタイム システムは、通常、組み込みシステムで物理ハードウェアと低レベルで対話します。Atari 2600やCinematronicsベクター グラフィックスなどの初期のビデオ ゲーム システムでは、グラフィックスとタイミング ハードウェアの性質上、ハード リアルタイム要件がありました。
• ソフトモデムは、ハードウェア モデムをコンピュータのCPU上で実行されるソフトウェアに置き換えます。ソフトウェアは、出力する次のオーディオ データを生成するために、数ミリ秒ごとに実行する必要があります。そのデータが遅れると、受信側モデムの同期が失われ、同期が再確立されるまでの長い中断が発生したり、接続が完全に失われたりします。
• 多くの種類のプリンタには、厳しいリアルタイム要件があります。たとえば、インクジェットプリンタ(プリントヘッドがページを横切るときに、インクが適切なタイミングで塗布される必要があります)、レーザー プリンタ(回転ドラムをビームがスキャンするときに、レーザーが適切なタイミングで作動される必要があります)、ドット マトリックス プリンタやさまざまなタイプのライン プリンタ(印刷機構が目的の出力に揃うときに、インパクト機構が適切なタイミングで作動される必要があります) などです。これらのいずれかに障害が発生すると、出力が欠落するか、出力がずれることになります。

マルチタスクシステムのコンテキストでは、スケジューリングポリシーは通常、優先度駆動型です（プリエンプティブスケジューラ）。状況によっては、これらはハードリアルタイムパフォーマンスを保証できます（たとえば、タスクのセットとその優先度が事前にわかっている場合）。レートモノトニックなどの他のハードリアルタイムスケジューラもありますが、これはタスクをスケジュールするために追加の情報、つまりタスクの実行時間に関する上限または最悪のケースの見積もりを必要とするため、汎用システムでは一般的ではありません。このようなハードリアルタイムタスクをスケジュールするための特定のアルゴリズム（たとえば、最も早い期限を優先する）は、コンテキスト切り替えのオーバーヘッドを無視すると、システム負荷が100%未満の場合に十分です。^[7]アダプティブパーティションスケジューラなどの新しいオーバーレイスケジューリングシステムは、ハードリアルタイムアプリケーションと非リアルタイムアプリケーションが混在する大規模システムの管理を支援します。

ファームリアルタイムシステムはより漠然と定義されており、分類によってはファームリアルタイムシステムが含まれず、ハードリアルタイムシステムとソフトリアルタイムシステムのみを区別しています。ファームリアルタイムシステムの例をいくつか示します。

• 前述のハードリアルタイムとして説明した組立ラインマシンは、代わりに確固たるリアルタイムと考えることができます。期限を守れなかった場合、対処が必要なエラーが発生します。部品を不良品としてマークしたり、組立ラインから排出したりする機械があるかもしれませんし、オペレータが問題を修正できるように組立ラインを停止することもあります。ただし、これらのエラーがまれにしか発生しない限り、許容される可能性があります。

ソフト リアルタイム システムは、通常、同時アクセスの問題や、変化する状況に応じて接続された多数のシステムを最新の状態に保つ必要性を解決するために使用されます。ソフト リアルタイム システムの例:

• 民間航空機の飛行計画を維持および更新するソフトウェア。飛行計画は適度に最新の状態に維持する必要がありますが、数秒の遅延で動作できます。
• ライブオーディオビデオシステムも通常はソフトリアルタイムです。遅れて再生されるオーディオフレームは、短いオーディオグリッチを引き起こす可能性があります（また、後続のすべてのオーディオがそれに応じて遅れ、オーディオが通常よりも遅く再生されているという認識を引き起こす可能性があります）が、これは、無音、静的、前のオーディオフレーム、または推定データを再生し続けるよりも良い場合があります。遅れたビデオフレームは通常、視聴者にとってさらに混乱を引き起こしません。システムは、ワークロード予測と再構成方法を使用して、将来的に動作を継続し、回復することもできます。^[8]
• 同様に、ビデオゲームは、特に目標フレームレートを満たそうとするときに、ソフトリアルタイムになることが多い。次の画像はプレイヤーからの入力に依存するため事前に計算することができず、そのため、ビデオのフレームを生成するために必要なすべての計算を、そのフレームが表示される前に実行できる時間はごくわずかである。期限に間に合わなかった場合、ゲームは低いフレームレートで続行される。ゲームによっては、これがグラフィックスにのみ影響する場合があり（ゲームプレイは通常の速度で続行される）、またはゲームプレイ自体が遅くなる場合がある（古い第3世代および第4世代のコンソールでは一般的だった）。

リアルタイムデジタル信号処理（DSP）プロセスでは、分析された（入力）サンプルと生成された（出力）サンプルは、処理遅延とは無関係に、同じサンプルセットを入力および出力するのにかかる時間で連続的に処理（または生成）できます。^[9]これは、処理が無制限に続く場合でも、処理遅延を制限する必要があることを意味します。つまり、オーバーヘッドを含むサンプルあたりの平均処理時間は、サンプリング周期（サンプリングレートの逆数）以下です。これは、サンプルが大きなセグメントにグループ化されてブロックとして処理されるか、個別に処理されるか、および入力バッファと出力バッファが長いか、短いか、存在しないかの基準です。

オーディオ DSP の例を考えてみましょう。2.00 秒のサウンドを分析、合成、または処理するのに 2.01秒かかるプロセスは、リアルタイムではありません。ただし、1.99 秒かかる場合は、リアルタイム DSP プロセスであるか、リアルタイム DSP プロセスにすることができます。

よくある人生の例え話は、食料品店でレジ待ちの列に並んでいるようなものです。列が無限に漸近的に長くなれば、レジのプロセスはリアルタイムではありません。列の長さが限られており、顧客が「処理」されて出力される速度が平均して入力される速度と同じ速さであれば、そのプロセスはリアルタイムです。食料品店は、レジのプロセスをリアルタイムにできない場合、廃業するか、少なくともビジネスを失う可能性があります。したがって、このプロセスがリアルタイムであることが根本的に重要です。

入力データの流れに追いつけず、出力が入力よりどんどん遅れていく信号処理アルゴリズムは、リアルタイムではありません。ただし、無制限の時間にわたって動作するプロセスに関して、出力の遅延 (入力に対する相対的な遅延) が制限されている場合、スループットの遅延が非常に長い場合でも、その信号処理アルゴリズムはリアルタイムです。

リアルタイム信号処理は、ライブイベントのサポートに求められるようなライブ信号処理には必要ですが、それだけでは十分ではありません。ライブオーディオのデジタル信号処理には、リアルタイム操作と、ステージモニターやインイヤーモニターを使用するパフォーマーが許容できるスループット遅延と、パフォーマーを直接見ている観客がリップシンクエラーとして気付かない程度の十分なスループット遅延制限の両方が必要です。ライブのリアルタイム処理の遅延の許容限界は調査と議論の対象ですが、6〜20ミリ秒と推定されています。^[10]

会話中の望ましくない「トークオーバー」を回避するために、300 ミリ秒未満の リアルタイム双方向通信遅延（「往復」または一方向遅延の 2 倍）は「許容可能」であると見なされます。

リアルタイムコンピューティングは、高性能コンピューティングであると誤解されることがあるが、これは正確な分類ではない。^[11]たとえば、科学シミュレーションを実行する大規模なスーパーコンピュータは印象的なパフォーマンスを発揮するかもしれないが、リアルタイムコンピューティングを実行しているわけではない。逆に、アンチロックブレーキシステムのハードウェアとソフトウェアが、要求される期限を満たすように設計されれば、それ以上のパフォーマンス向上は必須ではなく、有用でさえない。さらに、ネットワークサーバーがネットワークトラフィックで高負荷になっている場合、応答時間は遅くなることがあっても、（ほとんどの場合）タイムアウトする（期限に達する）前には成功します。したがって、そのようなネットワークサーバーはリアルタイムシステムとは見なされません。一時的な障害（遅延、タイムアウトなど）は通常小さく区分化されており（影響が限定的）、壊滅的な障害ではありません。FTSE 100 Indexなどのリアルタイムシステムでは、限界を超えた速度低下は、そのアプリケーションのコンテキストでは壊滅的であると見なされることが多い。リアルタイム システムの最も重要な要件は、高いスループットではなく、一貫した出力です。

多くのチェス プログラムなど、一部の種類のソフトウェアは、どちらのカテゴリにも当てはまります。たとえば、クロック付きのトーナメントでプレイするように設計されたチェス プログラムは、特定の期限までに動きを決定する必要があり、そうでない場合はゲームに負けるため、リアルタイム計算です。一方、動かす前に無制限に実行できるチェス プログラムはリアルタイム計算ではありません。ただし、どちらの場合も、高いパフォーマンスが望まれます。トーナメント チェス プログラムが割り当てられた時間内に実行できる作業が多いほど、動きが良くなり、制約のないチェス プログラムの実行速度が速いほど、早く動けるようになります。この例は、リアルタイム計算と他の計算の本質的な違いも示しています。トーナメント チェス プログラムが割り当てられた時間内に次の動きを決定しないと、ゲームに負けます (つまり、リアルタイム計算としては失敗します)。一方、他のシナリオでは、期限に間に合わせる必要はないと想定されています。高性能とは、与えられた時間内に実行される処理の量を示すものですが、リアルタイムとは、利用可能な時間内に処理を完了して有用な出力を生成する能力のことです。

電気通信とコンピューティングにおける「ニアリアルタイム」または「ほぼリアルタイム」（NRT）という用語は、自動データ処理またはネットワーク伝送によって、イベントの発生と、表示、フィードバック、制御などの目的で処理されたデータの使用との間に生じる時間遅延を指します。たとえば、ニアリアルタイムの表示は、処理時間を差し引いた現在の時刻に存在したイベントまたは状況を、ライブイベントの時刻とほぼ同じ時間として表示します。^[12]

「ニアリアルタイム」と「リアルタイム」という用語の区別はやや曖昧であり、状況に応じて定義する必要があります。この用語は、大きな遅延がないことを意味します。^[12]多くの場合、「リアルタイム」と表現される処理は、より正確には「ニアリアルタイム」と表現されます。

ニア リアルタイムは、音声とビデオの遅延リアルタイム伝送も意味します。これにより、大きなビデオ ファイル全体のダウンロードを待たずに、ほぼリアルタイムでビデオ画像を再生できます。互換性のないデータベースは、他のデータベースがスケジュールに基づいてインポート/エクスポートできる共通のフラット ファイルにエクスポート/インポートできるため、共通のデータを互いに「ニア リアルタイム」で同期/共有できます。

リアルタイム システムの設計を支援する方法はいくつかありますが、その 1 つがMASCOTです。これは、システムの並行構造を表現する古い方法ですが非常に効果的です。その他の例としては、 HOOD、Real-Time UML、AADL、Ravenscar プロファイル、Real-Time Javaなどがあります。

• バーンズ、アラン; ウェリングス、アンディ (2009)、『リアルタイムシステムとプログラミング言語(第 4 版)』、Addison-Wesley、ISBN 978-0-321-41745-9
• Buttazzo, Giorgio (2011)、「ハードリアルタイムコンピューティングシステム：予測可能なスケジューリングアルゴリズムとアプリケーション」、ニューヨーク、ニューヨーク：Springer、ISBN 9781461406761– Googleブックス経由。
• Liu, Jane WS (2000)、『リアルタイムシステム』、ニュージャージー州アッパーサドルリバー：Prentice Hall。
• タイムクリティカルコンピューティングシステムの国際ジャーナル

• IEEE リアルタイムシステム技術委員会
• Euromicro リアルタイムシステム技術委員会
• リアルタイムシミュレーションとは何か、どこで、なぜ
• Johnstone, RL「RTOS - リアルタイム宇宙飛行制御のための OS/360 の拡張」(PDF)。Bitsavers 。2023年2 月 24 日閲覧。
• Coyle, RJ; Stewart, JK (1963 年 9 月)。「リアルタイム プログラミング システムの設計」。Computers and Automation . XII (9)。メリーランド州シルバー スプリング: Datatrol Corporation: 26–34。[...] リアルタイム設計で考慮すべき問題領域を指摘するメモ集。