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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

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

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

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

多くのセーフティクリティカルなアプリケーションに使用されるシステムは、フライバイワイヤ航空機やアンチロックブレーキの制御など、リアルタイムである必要があります。これらは両方とも、迅速で正確な機械的応答を必要とします。[4]

歴史

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

ミニコンピューター、特に1970年代以降、 DOG(デジタルオンスクリーングラフィック)スキャナーなどの専用組み込みシステムに組み込まれると、受信データやデータなどのオペレーティングシステムとの重要な相互作用に対する低遅延の優先度駆動型応答の必要性が高まりました。GeneralRDOS(リアルタイムディスクオペレーティングシステム)とバックグラウンドおよびフォアグラウンドスケジューリング備えたRTOS、およびDigitalEquipmentCorporationRT-11この時代からの日付。バックグラウンド-フォアグラウンドスケジューリングにより、フォアグラウンドタスクを実行する必要がない場合に優先度の低いタスクのCPU時間を許可し、フォアグラウンド内で優先度の最も高いスレッド/タスクに絶対的な優先度を与えました。リアルタイムオペレーティングシステムは、タイムシェアリングマルチユーザー業務にも使用されます。たとえば、Data General Business BasicはRDOSのフォアグラウンドまたはバックグラウンドで実行でき、ダム端末を介して対話する人々により適したものにするために、スケジューリングアルゴリズムに追加の要素を導入します

かつてはMOSテクノロジー6502コモドール64Apple IIで使用)、そして後にモトローラ68000MacintoshAtari STコモドールAmigaで使用)が普及したとき、誰でも自宅のコンピューターをリアルタイムで使用できました。システム。他の割り込みを非アクティブ化する可能性により、定義されたタイミングでハードコードされたループが可能になり、割り込みレイテンシが低いため、リアルタイムオペレーティングシステムの実装が可能になり、ユーザーインターフェイスとディスクドライブの優先度がリアルタイムスレッドよりも低くなりました。これらと比較して、プログラマブル割り込みコントローラーのIntelCPU(8086..80586)は非常に大きな割り込みを生成し、Windowsオペレーティングシステムはリアルタイムオペレーティングシステムではなく、ネイティブマシンを使用せずにプログラムがCPUを完全に引き継いで独自のスケジューラを使用することもできません。言語、したがってすべての中断するWindowsコードを超えています。ただし、 Java Real Timeなど、さまざまなオペレーティングシステムで高水準言語でリアルタイム機能を提供するコーディングライブラリがいくつか存在しますモトローラ68000以降のファミリメンバー(68010、68020など)も、産業用制御システムのメーカーに人気がありました。このアプリケーション領域は、リアルタイム制御がプロセスのパフォーマンスと安全性の点で真の利点を提供する領域です。[[要出典]

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

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

  • 難しい –期限を逃すと、システム全体に障害が発生します。
  • しっかり –まれな期限のミスは許容できますが、システムのサービス品質を低下させる可能性があります。結果の有用性は、期限後はゼロです。
  • ソフト –結果の有用性は期限を過ぎると低下し、それによってシステムのサービス品質が低下します。

したがって、ハードリアルタイムシステムの目標は、すべての期限が確実に満たされるようにすることですが、ソフトリアルタイムシステムの場合、アプリケーション固有の基準を最適化するために、目標は期限の特定のサブセットを満たすようになります。最適化される特定の基準はアプリケーションによって異なりますが、いくつかの典型的な例には、期限に間に合う数の最大化、タスクの遅延の最小化、および期限に間に合う優先度の高いタスクの数の最大化が含まれます。

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

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

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

堅固なリアルタイムシステムはより曖昧に定義されており、一部の分類にはそれらが含まれておらず、ハードリアルタイムシステムとソフトリアルタイムシステムのみが区別されています。しっかりしたリアルタイムシステムのいくつかの例:

  • 代わりに、ハードリアルタイムとして前述した組立ラインマシンは、しっかりしたリアルタイムと見なすことができます。締め切りに間に合わなかった場合でも、対処が必要なエラーが発生します。部品に不良のマークを付けたり、組立ラインから排出したりする機械がある場合や、オペレーターが問題を修正できるように組立ラインを停止する場合があります。ただし、これらのエラーがまれである限り、許容される場合があります。

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

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

デジタル信号処理のリアルタイム

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

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

一般的な例えは、食料品店でのチェックアウトを待つ列または列に並んでいることです。線が漸近的に無制限に長くなる場合、チェックアウトプロセスはリアルタイムではありません。行の長さが制限されている場合、顧客は「処理」され、平均して、入力されているのと同じくらい迅速に出力され、そのプロセスリアルタイムです。食料雑貨店は廃業する可能性があります。または、チェックアウトプロセスをリアルタイムで行うことができない場合は、少なくとも廃業する必要があります。したがって、このプロセスがリアルタイムであることが基本的に重要です。

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

ライブvs.リアルタイム

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

300ミリ秒未満 のリアルタイム双方向通信遅延(「ラウンドトリップ」または単方向遅延の2倍)は、会話での望ましくない「トークオーバー」を回避するために「許容可能」と見なされます。

リアルタイムで高性能

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

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

ほぼリアルタイム

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

「ほぼリアルタイム」と「リアルタイム」という用語の区別はやや曖昧であり、目前の状況に合わせて定義する必要があります。この用語は、重大な遅延がないことを意味します。[12]多くの場合、「リアルタイム」と記述された処理は、「ほぼリアルタイム」とより正確に記述されます。

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

「ほぼリアルタイム」と「リアルタイム」の区別はさまざまであり、遅延は送信のタイプと速度によって異なります。ほぼリアルタイムでの遅延は、通常1〜10秒の範囲です。[13]

設計方法

リアルタイムシステムの設計を支援するためにいくつかの方法が存在します。その一例は、システムの並行構造を表す古いが非常に成功した方法であるMASCOTです。他の例としては、 HOOD、Real-Time UML、AADLRavenscarプロファイルReal-TimeJavaがあります

も参照してください

参照

  1. ^ 「FreeRTOS-小規模な組み込みシステム向けのオープンソースRTOSカーネル-FreeRTOSFAQとは何ですか?」FreeRTOS 2021-03-08を取得
  2. ^ ベンアリ、モルデハイ; 「コンカレントおよび分散プログラミングの原則」、ch。16、Prentice Hall、1990、 ISBN 0-13-711821-X、164ページ 
  3. ^ マーティン、ジェームズ(1965)。リアルタイムコンピュータシステムのプログラミングニュージャージー州エングルウッドクリフ:Prentice-HallInc.p。 4ISBN 978-0-13-730507-0
  4. ^ カント、クリシュナ(2010年5月)。コンピュータベースの産業用制御PHIラーニング。p。356. ISBN 97881203398802015年1月17日取得
  5. ^ シン、カンG .; ラマナサン、パラメスワラン(1994年1月)。「リアルタイムコンピューティング:コンピュータサイエンスとエンジニアリングの新しい分野」(PDF)IEEEの議事録82(1):6–24。CiteSeerX10.1.1.252.3947_ 土井10.1109/5.259423ISSN0018-9219_   
  6. ^ コペッツ、ヘルマン; リアルタイムシステム:分散型組み込みアプリケーションの設計原則、Kluwer Academic Publishers、1997年
  7. ^ Liu、Chang L .; とレイランド、ジェームズW .; 「ハードリアルタイム環境でのマルチプログラミングのためのスケジューリングアルゴリズム」、 Journal of the ACM、20(1):46-61、1973年1月、 http ://citeseer.ist.psu.edu/liu73scheduling.html
  8. ^ Menychtas、Andreas; キリアジス、デモステネス; Tserpes、Konstantinos(2009年7月)。「グリッド環境でQoSプロビジョニングレベルを保証するためのリアルタイム再構成」。次世代コンピュータシステム25(7):779–784。土井10.1016/j.future.2008.11.001
  9. ^ Kuo、Sen M .; リー、ボブH .; とTian、Wenshun; 「リアルタイムデジタル信号処理:実装とアプリケーション」、Wiley、2006年、 ISBN 0-470-01495-4セクション1.3.4:リアルタイムの制約 
  10. ^ Kudrle、Sara; Proulx、Michel; キャリア、パスカル; ロペス、マルコ; etal。(2011年7月)。「放送環境内のA/V同期の問題を解決するためのフィンガープリント」。SMPTEモーションイメージングジャーナル120(5):36–46。土井10.5594/j18059XY適切なA/V同期制限が確立されており、フィルムで許容できると見なされる範囲は+/-22ミリ秒です。ATSCによると、ビデオの範囲は最大15ミリ秒のリードタイムと約45ミリ秒の遅延時間です。
  11. ^ Stankovic、John(1988)、「リアルタイムコンピューティングに関する誤解:次世代システムにとって深刻な問題」、Computer、IEEE Computer Society、vol。21、いいえ。10、p。11、doi10.1109 / 2.7053S2CID 13884580 
  12. ^ a b 「連邦規格1037C:電気通信用語集」its.bldrdoc.gov 2014年4月26日取得
  13. ^ 「リアルタイム、ほぼリアルタイム、およびバッチ処理の違い」正確に。2021-03-24 2021-09-22を取得

さらに読む

外部リンク