+スターの公開アカウントをフォローして、エキサイティングなコンテンツを見逃さないようにしましょう
素材ソース | インターネット
RTOS は組み込み開発において重要な役割を果たしますが、どのような場合に RTOS を使用する必要があるのでしょうか?
■ リアルタイム オペレーティング システムが必要になるのは、具体的にどのような場合ですか?
ほとんどの組み込みプロジェクトは依然としてリアルタイム オペレーティング システムを必要としますか? 今日の高性能プロセッサの速度と、Linux、Windows、およびその他の汎用オペレーティング システム (GPOS) 用のライブ パッチの利用可能性を考慮すると、これは良い質問です。
答えは組み込みデバイスの性質にあります。これらのデバイスは通常、数千、場合によっては数百万のユニットで生産され、ユニットあたりのハードウェア コストが 1 ドル削減されただけでも、メーカーは少額の財産を節約できます。言い換えれば、これらのデバイスには数百万ヘルツのプロセッサのコストを支払う余裕はありません（冷却はもちろんのこと）。
たとえば、自動車テレマティクス市場では、一般的な 32 ビット プロセッサは約 600 MHz で動作しますが、これはデスクトップやサーバーで一般的に使用されているプロセッサよりもはるかに低いです。このような環境では、ローエンドのハードウェアから非常に高速で予測可能な応答時間を引き出すように設計されたリアルタイム オペレーティング システムには、大きな経済的利点があります。
リアルタイム オペレーティング システムは、コストの削減に加えて、特に複数のアクティビティがシステムのリソースをめぐって競合する場合に、多くのコンピューティング上の問題を解決しやすくするサービスを提供します。たとえば、ユーザーが入力にすぐに応答することを期待している (または応答する必要がある) システムを考えてみましょう。リアルタイム オペレーティング システムを使用すると、開発者は、より重要なアクティビティ (ユーザーのセキュリティを保護するための操作など) を最初に実行する必要がない限り、ユーザーが開始した操作が他のシステム アクティビティよりも優先されることを保証できます。
また、ライブ ビデオを表示するデバイスなど、サービス品質 (QoS) 要件を満たす必要があるシステムも考慮してください。デバイスのコンテンツ配信の一部がソフトウェアに依存している場合、ユーザーが許容できないと考える速度でフレームのドロップが発生し、デバイスの信頼性が低くなります。しかし、リアルタイム オペレーティング システムを使用すると、開発者はソフトウェア プロセスの実行順序を正確に制御し、適切かつ一貫したレートで再生が行われることを保証できます。
■ リアルタイム OS は不公平です
組み込み業界では、リアルタイムの「ハード」タイムの必要性が依然として一般的です。問題は、リアルタイム オペレーティング システムには何があり、GPOS にはできないことがあるのか、また、一部の GPOS に対する現在のリアルタイム拡張機能はどの程度役立つのか、それらは妥当なリアルタイム オペレーティング システムのパフォーマンスを提供できるのかということです。
タスクのスケジュール設定から始めましょう。GPOS では、スケジューラは通常、「公平な」ポリシーを使用してスレッドとプロセスを CPU にディスパッチします。このような戦略では、デスクトップおよびサーバー アプリケーションに必要な全体的な高いスループットを実現できますが、優先度が高く時間重視のスレッドが優先度の低いスレッドよりも前に実行されることは保証されません。
たとえば、GPOS は、優先度の高いスレッドに割り当てられた優先度を下げたり、システム内の他のスレッドとの公平性を確保するためにスレッドの優先度を動的に調整したりすることがあります。したがって、優先度の高いスレッドが優先度の低いスレッドによってプリエンプトされる可能性があります。さらに、ほとんどの GPOS には無制限のスケジューリング遅延があります。システム内のスレッドが多いほど、GPOS が実行スレッドをスケジュールするのにかかる時間が長くなります。これらの要因により、優先順位の高いスレッドが期限に間に合わなくなる可能性があります。高速CPU。
さらに、優先度の高いスレッドは、当然、優先度の高いスレッドによってプリエンプトされない限り、必要な処理を完了するまで中断されずに実行できます。優先度ベースのプリエンプティブ スケジューリングとして知られるこのアプローチにより、他の多くのスレッドが CPU 時間を競合している場合でも、優先度の高いスレッドが期限を守ることができます。
より実践的なOS開発技術を学びたい場合は、世界トップクラスの機器メーカーのRTOS開発上級専門家が編成したカーネル、BSP、および IDE をサポートし、実際の開発ボードを使用してケースの練習操作を支援します。詳細については、ポスターをクリックしてください。
■ プリエンプティブ カーネル
ほとんどの GPOS では、OS カーネルはプリエンプティブルではありません。したがって、優先度の高いユーザー スレッドは、カーネル呼び出しをプリエンプトすることはできませんが、呼び出しがシステム内の最も優先度の低いプロセスによって行われた場合でも、呼び出し全体が完了するまで待機する必要があります。さらに、ドライバーまたはその他のシステム サービス (通常はカーネル呼び出しで実行される) がクライアント スレッドに代わって実行カットを実行すると、通常、すべての優先度情報が失われます。この動作により、予測できない遅延が発生し、重要なアクティビティが時間通りに完了できなくなる可能性があります。
一方、リアルタイム オペレーティング システムでは、カーネル操作はプリエンプティブルです。GPOS と同様に、プリエンプションは時間ウィンドウ内では発生しない可能性があります。適切に設計されたリアルタイム オペレーティング システムでは、時間ウィンドウは非常に短く、通常は数百ナノ秒程度です。さらに、リアルタイム オペレーティング システムでは、プリエンプション レイテンシーと割り込みが無効になる時間に上限が設けられており、この上限により、開発者は最悪の場合のレイテンシーを決定できます。
一貫した予測可能性と重要なアクティビティのタイムリーな完了を実現するには、リアルタイム オペレーティング システムのカーネルが可能な限りシンプルかつ洗練されている必要があります。このシンプルさを実現する最善の方法は、実行パスが短いサービスのみを含むカーネルを設計することです。作業集約的な操作 (プロセスの読み込みなど) をカーネルから除外し、それらを外部のプロセスまたはスレッドに割り当てることで、RTOS 設計者は、カーネルを通る最長の非プリエンプティブル コード パスに上限を設けることができます。
一部の GPOS では、カーネルによってある程度のプリエンプションが追加されます。ただし、プリエンプションが発生する可能性が低い時間間隔は、一般的なリアルタイム オペレーティング システムよりもはるかに長いため、そのようなプリエンプション間隔の長さは、システム内のモジュール (ネットワークなど) の最も長いクリティカル セクションによって決まります。 GPOS カーネル。さらに、プリエンプティブル GPOS カーネルは、クライアントがドライバーまたは他のシステム サービスを呼び出すときに発生する優先順位情報の損失など、無限の遅延を引き起こす可能性のあるその他の状況を処理しません。
■ 優先順位の逆転を避ける
GPOS では、さらにはリアルタイム オペレーティング システムでも、優先順位の低いスレッドが誤って優先順位の高いスレッドによる CPU へのアクセスを妨げる可能性があり、この状況を優先順位逆転と呼びます。無限の優先順位逆転が発生すると、重要な期限を逃す可能性があり、システムの異常な動作から完全な障害に至るまでの影響が生じます。残念ながら、優先順位の逆転はシステム設計時に見落とされることがよくあります。1997 年 7 月のマーズ エクスプローラー プロジェクトなど、優先順位逆転の例は数多くあります。
一般に、優先度の逆転は、優先度の異なる 2 つのタスクがリソースを共有し、優先度の高いタスクが優先度の低いタスクからリソースを取得できない場合に発生します。限られた時間間隔を超えてこの状況が発生するのを防ぐために、リアルタイム オペレーティング システムは、優先順位の継承や優先順位のキャップ エミュレーションなど、GPOS では利用できないメカニズムの選択を提供できます。両方のメカニズムを正確に評価することは不可能なので、優先順位の継承の例に焦点を当てましょう。。
まず、タスクの同期がどのようにしてブロッキングにつながるのか、そしてブロッキングがどのようにして優先度の逆転につながるのかを考慮する必要があります。タスク 1 とタスク 2 の 2 つのタスクが実行中で、タスク 1 の優先度が高いとします。タスク 1 は実行の準備ができているが、タスク 2 がそのアクティビティを完了するまで待機する必要がある場合、タスク 2 はブロックされます。このブロックは同期が原因である可能性があります。たとえば、タスク 1 とタスク 2 はロックまたはセマフォによって制御されるリソースを共有し、タスク 1 はタスク 2 がリソースのロックを解除するのを待っています。または、タスク 2 が現在使用しているサービスをタスク 1 が要求していることが原因である可能性があります。
ブロックすると、タスク 1 が待機している条件が発生するまでタスク 2 を実行できます (たとえば、タスク 2 が両方のタスクで共有されるリソースのロックを解除する)。この時点で、タスク 1 の実行が開始されます。タスク 1 が待機しなければならない合計時間は、ブロッキング係数と呼ばれます。タスク 1 が時間制約のいずれかを満たす必要がある場合、このブロック係数はパラメータ (スレッド数やシステム入力など) によって変更することはできません。言い換えれば、ブロッキング係数は制限される必要があります。
次に、3 番目のタスクであるタスク 3 を紹介します。このタスク 3 は、タスク 2 よりも優先度が高く、タスク 1 よりも低くなります (図 1 を参照)。タスク 2 の実行中にタスク 3 を実行する準備ができている場合、タスク 2 がプリエンプトされ、タスク 3 がブロックされるか完了するまでタスク 2 は再度実行できなくなります。もちろん、この新しいタスクによりタスク 1 のブロック係数が増加します。つまり、タスク 1 の実行がさらに遅延します。プリエンプションによってもたらされる遅延の合計は、優先順位の逆転です。
図 1 タスク 1 はタスク 2 がアクティビティを完了するのを待っており、そのときにタスク 3 がタスク 2 をプリエンプトします。この新しいタスクにより、タスク 1 の実行がさらに遅れます。
実際、複数のタスクがこの方法でタスク 2 をプリエンプトすることができ、チェーン ブロッキングと呼ばれる効果が作成されます。この場合、タスク 2 が無期限にプリエンプトされる可能性があり、無限の優先度逆転が発生し、タスク 1 が期限を守れなくなる可能性があります。
ここで優先度の継承が登場します。シナリオに戻って、同期中にタスク 2 をタスク 1 の優先順位で実行すると、タスク 3 はタスク 2 をプリエンプトできなくなり、優先順位の逆転が回避されます (図 2 を参照)。
図 2 タスク 2 はタスク 1 のより高い優先度を継承するため、タスク 3 がタスク 2 をプリエンプトすることはできません。タスク 3 がタスク 1 の実行を遅らせることはなくなりました。
■ パーティションスケジューラ
多くのシステムでは、リソースの可用性を確保することが重要です。たとえば、重要なサブシステムの CPU サイクルが奪われると、そのサブシステムによって提供されるサービスがユーザーに利用できなくなります。たとえば、サービス拒否 (DoS) 攻撃では、悪意のあるユーザーが、優先度の高いプロセスの処理を必要とするリクエストをシステムに大量に送信する可能性があります。このプロセスにより CPU が過負荷になり、他のプロセスの CPU サイクルが中断され、ユーザーがシステムを利用できなくなる可能性があります。
プロセス枯渇の原因はセキュリティの脆弱性だけではありません。多くの場合、システムにソフトウェア機能を追加すると、システムが「限界点」に達し、既存のアプリケーションが大量の CPU 時間を消費する可能性があります。タイムリーに実行されているアプリケーションまたはサービスが、期待どおりまたは要求どおりに応答しなくなりました。歴史的に、この問題に対する唯一の解決策は、ハードウェアを改造するか、ソフトウェアを再コーディング (または再設計) するかのいずれかでしたが、どちらも不人気な選択肢でした。これらの問題を解決するには、システム設計者は、プロセスまたはスレッドが他のプロセスまたはスレッドが必要とする CPU サイクルを独占しないように、ハードウェアまたはソフトウェアを通じて CPU 操作を強制するパーティショニング スキームを必要とします。リアルタイム オペレーティング システムはすでに CPU、メモリ、その他のコンピューティング リソースへの集中アクセスを提供しているため、CPU パーティション操作を実行するにはリアルタイム オペレーティング システムが最適です。
一部のリアルタイム オペレーティング システムは、固定パーティション スケジューラを提供します。このスケジューラを使用すると、システム設計者はタスクをグループまたはパーティションに分割し、CPU 時間の割合を各パーティションに割り当てることができます。このアプローチを使用すると、特定のパーティション内のタスクは、パーティションの静的に定義されたパーセンテージを超える CPU 時間を消費することはありません。たとえば、パーティションに CPU の 30% が割り当てられているとします。その後、そのパーティション内のプロセスがサービス拒否攻撃の標的になったとしても、消費される CPU 時間は 30% にすぎません。この割り当てられた制限により、他のパーティションが可用性を維持できるようになります。たとえば、ユーザー インターフェイス (リモート端末など) がアクセス可能な状態を維持できるようになります。したがって、オペレータはリセット スイッチを押すことなく、システムにアクセスして問題のトラブルシューティングを行うことができます。
ただし、このアプローチには問題があります。スケジューリング アルゴリズムは固定されているため、他のパーティションに割り当てられた CPU サイクルを、それらのパーティションが割り当てられたサイクルを使用しない場合でも、パーティションが使用することはできません。このアプローチでは CPU サイクルが無駄になり、システムがピーク要求を処理できなくなります。その結果、システム設計者は、より高価なプロセッサを使用したり、より遅いシステムを許容したり、システムがサポートできる機能の数を制限したりする必要があります。
■ アダプティブパーティショニング
アダプティブ パーティショニングと呼ばれる別のパーティショニング スキームは、より動的なスケジューリング アルゴリズムを提供することで静的パーティショニングの欠点に対処します。静的パーティショニングと同様に、アダプティブ パーティショニングを使用すると、システム設計者はプロセスまたはプロセスのグループ用に CPU サイクルを予約できます。したがって、設計者は、1 つのサブシステムまたはパーティションの負荷が他のサブシステムの可用性に影響を与えないようにすることができます。ただし、静的手法とは異なり、アダプティブ パーティショニングでは、CPU サイクルを、あまり使用されていないパーティションから、CPU が完全に負荷されている場合にのみ適用される、追加の処理時間のパーティショニング バジェットの恩恵を受けることができるパーティションに動的に再割り当てできます。したがって、システムは、スケジューリング動作を変更することなく、ピーク スケジューリング アプリケーションを処理できます。さらに、設計者はパーティションを動的に再構成してシステムのパフォーマンスを最適化できます。二科アカデミーの車載OS技術研修に参加し、より実践的な技術を学びます。記事末尾のQRコードを読み取ってご登録ください。
■「デュアル」コア
Linux、Windows、およびさまざまな種類の Unix を含む GPOS には、これまで説明したリアルタイム メカニズムが一般的に欠けています。このギャップを埋めるために、GPOS ベンダーは多数のライブ拡張機能とパッチを開発しました。たとえば、GPOS が専用のリアルタイム コア上のタスクとして実行されるデュアルコア アプローチがあります (図 4 を参照)。したがって、これらのタスクは、GPOS を実行する必要がある場合に GPOS をプリエンプトし、作業が終了した場合にのみ CPU を GPOS に引き渡すことができます。
残念ながら、リアルタイム カーネルで実行されているタスクは、GPOS の既存のシステム サービス (ファイル システム、ネットワークなど) を限定的にしか利用できません。実際、リアルタイム タスクが GPOS からサービスを要求した場合、そのタスクは同じ優先順位の処理要件に従い、リソース保証の利点を享受しながら 100% の使用率を達成します。
同様に重要なことは、再設計やコードの変更を必要とせずに、適応型パーティショニングを既存のシステムの上にオーバーレイできることです。システム設計者は、既存の POSIX ベースのアプリケーションをパーティション内で簡単に起動でき、リアルタイム オペレーティング システム スケジューラにより、各パーティションが割り当てられたバジェットを確実に受け取ることができます。各パーティション内で、各タスクは優先度ベースのプリエンプション ルールに従ってスケジュールされます。
図 3 アダプティブ パーティショニングにより、システムに未使用の CPU サイクルが存在しない限り、優先度の高いタスクが割り当てられた CPU パーセンテージを超えて消費するのを防ぎます。たとえば、タスク E と F は割り当てられた残りの CPU サイクルを必要としないため、タスク A と D はパーティション 3 に割り当てられた時間内で実行できます。
GPOS プロセスの決定的な動作を妨げる問題。したがって、GPOS 用に同様のサービスがすでに存在する場合でも、新しいドライバーとシステム サービスをリアルタイム カーネル専用に作成する必要があります。さらに、リアルタイム カーネルで実行されているタスクは、ほとんどの GPOS が通常の非リアルタイム プロセスに提供する強力な MMU で保護された環境の恩恵を受けることができません。代わりに、カーネル空間では保護されずに実行されます。したがって、一般的なコーディング エラー (C ポインタの破損など) を含むリアルタイム タスクは、致命的なカーネル エラーにつながる可能性があります。リアルタイムを必要とするほとんどのシステムは高い信頼性も必要とするため、これは問題です。さらに問題を複雑にしているのは、デュアルコア アプローチの実装ごとに異なる API が使用されていることです。ほとんどの場合、GPOS 用に作成されたサービスはリアルタイム カーネルに簡単に移植できず、あるベンダーのリアルタイム拡張機能用に作成されたタスクは別のベンダーの拡張機能では実行できない場合があります。
図 4 一般的なデュアルコア実装では、GPOS は別のリアルタイム コアで最も優先度の低いタスクとして実行されます。
これらのソリューションは、GPOS がリアルタイム動作をサポートできるようにすることが実際に困難であることと、その範囲が膨大であることを示しています。これは、「リアルタイム オペレーティング システムは優れており、GPOS は悪い」という問題ではありません。Linux、Windows、さまざまな UNIX などの GPOS はすべて、デスクトップまたはサーバーのオペレーティング システムとして適切に動作します。ただし、車載テレマティクス ユニット、医療機器、リアルタイム制御システム、連続メディア アプリケーションなど、設計されていない決定論的な環境に強制的に導入されると、不十分になります。
■ オペレーティング システムのアプリケーション固有の要件を拡張する
決定論的な環境での短所が何であっても、それらを使用することには利点があります。
これらの利点には、広く使用されている API のサポートや Linux のオープン ソース モデルのサポートが含まれます。オープンソースを使用すると、開発者はオペレーティング システム コンポーネントをアプリケーション固有のニーズに合わせて調整できるため、トラブルシューティングにかかる時間を大幅に節約できます。リアルタイム オペレーティング システムのベンダーは、これらの利点を無視することはできません。POSIX API (Linux やさまざまな Unix で使用されているのと同じ API) を幅広くサポートすることは、重要な最初のステップです。組み込み開発者の特定のニーズと設計上の課題を満たすために、十分に文書化されたソース コードとカスタム ツールキットを提供する場合も同様です。
リアルタイム オペレーティング システムのアーキテクチャも影響します。たとえば、マイクロカーネル設計に基づくリアルタイム オペレーティング システムでは、他のアーキテクチャに比べてオペレーティング システムのカスタマイズが根本的に簡単に実装できます。マイクロカーネル リアルタイム オペレーティング システムでは、カーネル自体には、基本的なオペレーティング システム サービス (シグナル、タイマー、スケジューリングなど) の少数のセットのみが存在します。他のすべてのコンポーネント (ドライバー、ファイル システム、プロトコル スタック、アプリケーション) は、独立したメモリ保護されたプロセスとしてカーネルの外部で実行されます (図 5 を参照)。実際、このような拡張機能はユーザー空間プログラムとして、標準のソースレベルのツールや技術を使用してデバッグできるため、標準アプリケーションと同じくらい簡単に開発できます。
図 5 マイクロカーネル リアルタイム オペレーティング システムでは、システム サービスが標準のユーザー空間プロセスとして実行されるため、オペレーティング システムのカスタマイズ タスクが簡素化されます。
たとえば、デバイス ドライバーがプロセス コンテナーの外部にあるメモリにアクセスしようとすると、オペレーティング システムは責任のあるプロセスを特定し、エラーの場所を示し、ソース レベルのデバッグ ツールで表示できるプロセス ダンプ ファイルを作成できます。ダンプ ファイルには、データ項目の内容や関数呼び出し履歴などの診断情報に加え、問題の原因となっているソース コードをデバッガーが特定するために必要なすべての情報を含めることができます。
このアーキテクチャは、障害の分離と回復も強化します。ドライバー、プロトコル スタック、またはその他のシステム サービスに障害が発生した場合でも、他のサービスやオペレーティング システム カーネルを中断することなく障害を復旧できます。実際、Software Oversight はそのようなイベントを継続的に監視し、システム全体をリセットしたり、ユーザーを一切関与させたりすることなく、問題のあるサービスを動的に再起動できます。同様に、ドライバーやその他のサービスは、システムをシャットダウンせずに動的に停止、開始、またはアップグレードできます。
これらの利点を見逃してはなりません - リアルタイム パフォーマンスに対する最大の混乱は、スケジュールされていないシステムの再起動です! ソフトウェア アップグレードを組み込むための計画的な再起動であっても、制御された方法ではあっても、操作が中断される可能性があります。期限を常に守るために、開発者は、ソフトウェアの不具合やサービスのアップグレードが発生した場合でも、継続的に利用可能なオペレーティング システムを使用する必要があります。
■ 戦略的な決断
リアルタイム オペレーティング システムは、複雑なアプリケーションを予測可能かつ信頼性の高いものにするのに役立ちます。実際、リアルタイム オペレーティング システムの時間の正確な制御により、GPOS では達成できない信頼性が向上します。(GPOS ベースのシステムがタイミング動作が正しくないために正しく動作しない場合、そのシステムは信頼性が低いと合理的に言えます。) ただし、適切な RTO を選択すること自体が複雑な作業になる可能性があります。リアルタイム オペレーティング システムの基礎となるアーキテクチャは重要な基準ですが、他の要素も同様です。これらには次のものが含まれます。
• スケジューリング アルゴリズムの柔軟な選択 - リアルタイム オペレーティング システムは、スケジューリング アルゴリズム (FIFO、ラウンドロビン、散発的スケジューリングなど) の選択をサポートしていますか? 開発者はスレッドごとにアルゴリズムを割り当てることができますか?リアルタイム オペレーティング システムは、システム内のすべてのスレッドに 1 つのアルゴリズムを割り当てることを強制するのでしょうか?
• タイム パーティショニング - リアルタイム オペレーティング システムは、プロセスに CPU サイクルの特定の割合を与えるためのタイム パーティショニングをサポートしていますか? このような保証により、複数の開発チームまたはベンダーのサブシステムを統合する作業が簡素化されます。また、システムがサービス拒否 (DoS) 攻撃やその他の悪意のある攻撃にさらされた場合でも、重要なタスクが利用可能な状態を維持し、期限を守ることも保証します。
• マルチコア プロセッサのサポート - マルチコア プロセッサへの移行機能は、幅広い高性能設計の基礎となっています。リアルタイム オペレーティング システムは、開発者がマルチコア ハードウェアを最大限に活用できるように、選択されたマルチプロセッシング モデル (対称マルチプロセッシング、非対称マルチプロセッシング、バインドされたマルチプロセッシング) をサポートしていますか? システム トレース ツールは、開発者がマルチコア システムのパフォーマンスを診断して最適化できるようにするリアルタイム オペレーティング システム? リソースの競合、過度のスレッド マイグレーション、およびマルチコア設計に共通するその他の問題を強調表示するツールがなければ、マルチコア システムの最適化はすぐに困難になる可能性があります。時間のかかる作業。
• リモート診断用ツール - 多くの組み込みシステムはダウンタイムを許容できないため、リアルタイム オペレーティング システム ベンダーは、システムが提供するサービスを中断することなくシステムの動作を分析できる診断ツールを提供する必要があります。システム分析、アプリケーション分析、メモリ分析のためのランタイム分析ツールを提供するベンダーを探してください。
• オープン開発プラットフォーム - RTOS ベンダーはオープン プラットフォーム (Eclipse など) に基づく開発環境を提供しており、開発者がモデリングやバージョン管理などのためにお気に入りのサードパーティ ツールを「プラグイン」できるようにしていますか? それとも開発環境は独自の技術に基づいているのでしょうか？
• グラフィカル ユーザー インターフェイス - リアルタイム オペレーティング システムがオリジナルのグラフィック ライブラリを使用するか、複数のヒューマン インターフェイス テクノロジ (HTML5、Qt、OpenGL ES など) をサポートし、マルチレイヤー インターフェイス、マルチヘッドなどの高度なグラフィック機能を提供するかどうか。ディスプレイ、高速化された 3D レンダリング、およびリアル ウィンドウ システム? GUI の外観と操作性は簡単にカスタマイズできますか? guisは複数の言語(中国語、韓国語、日本語、英語、ロシア語など)を同時に表示、入力できますか? 2D アプリケーションと 3D アプリケーションは同じ画面を簡単に共有できますか? 標準 API - リアルタイム オペレーティング システムは開発者を独自の API に拘束しますか? それとも、POSIX や OpenGL ES などの標準 API の認定サポートを提供して、他の環境間でのコードの移植性を高めますか? さらに、リアルタイム オペレーティング システムは API を完全にサポートしますか、それとも定義されたインターフェイスのごく一部のみをサポートしますか?
• 標準 API - リアルタイム オペレーティング システムは、開発者を独自の API に拘束しますか? それとも、POSIX や OpenGL ES などの標準 API の認定サポートを提供して、他の環境間でのコードの移植性を高めますか? さらに、リアルタイム オペレーティング システムは API を完全にサポートしますか、それとも定義されたインターフェイスのごく一部のみをサポートしますか?
• デジタル メディア用のミドルウェア – デジタル メディアの柔軟なサポートは、カー ラジオ、医療機器、産業用制御システム、メディア サーバー、そしてもちろん家庭用電化製品を含むさまざまな組み込みシステムの設計要件になりつつあります。システムは、複数のメディア ソース (デバイス、ストリームなど) を処理し、複数のデータ形式を理解し、複数の DRM スキームをサポートする必要がある場合があります。デジタル メディア用に適切に設計されたミドルウェアを提供することで、リアルタイム オペレーティング システム ベンダーは、複数のメディア ソースへの接続、データの整理、適切なデータ処理パスの開始に必要な広範なソフトウェア作業を省略できます。ユーザー インターフェイスやその他のソフトウェア コンポーネントを変更することなく、次世代 iPod などの新しいデータ ソースを柔軟にサポートできるようになります。
リアルタイム オペレーティング システムの選択は、どのプロジェクト チームにとっても戦略的な決定です。RTOS ベンダーが上記の質問に対して明確な回答を提供すれば、現在および将来に最適なものを選択できるようになります。
声明:この記事の内容はインターネットから得たものであり、著作権は元の著者に属します。作品に著作権上の問題がある場合は削除いたしますのでご連絡ください。
------------ 終了 ------------
公式アカウントをフォローして「グループを追加」と返信するとルールに従って技術交流グループに参加でき、「1024」と返信するとさらにコンテンツが閲覧できます。
さらに共有を表示するには、「元のテキストを読む」をクリックしてください。