RTOSかRTOSかが問題

私は最近の記事「組み込みシステムの多様な世界とその中のEmboxの場所」 に対するコメントの長いブランチ （残念ながらこれを議論と呼ぶことはできません）によってこの記事を書くよう促されました。 RTOSと組み込みOSを混乱させるためにいくつかの場所で非難されました。RTOSではなくLynxOS、QNX、およびVxWorksと呼びましたが、もちろん私の意見ではそうではありませんでした。 これらのコメントの著者に、「リアルタイムオペレーティングシステム」の概念についてのビジョンを述べる記事を書くよう何度か提案しましたが、何らかの理由で拒否しました。 さて、この用語についての私のビジョンを提示し、RTOSを呼び出すことができるものとできないものについて説明しましょう。 最後に、この質問はEmboxに関してよく聞かれます。

OS RV（RTOS）という用語は、マーケティングの分野を指します！

用語の導入から科学的な方法で始めることを考えましたが、この挑発的な論文が最も歓迎されると決めました。 それでは、なぜRTOS（リアルタイムオペレーティングシステム）という用語がマーケティングを指すのか、より正確にはマーケティング（広告）のスローガンであると主張するのはなぜですか？ すべてがシンプルです。 製品が生産されるとき、それは販売される必要があります。 ただし、オペレーティングシステムのみを販売しようとすると、問題が発生します。 これが市場のポジショニングが救いをもたらす場所です。 たとえば、「私たちは彼らよりも速い」と言うことができます。





しかし、あなたはそれのために裁判所に行くことができます！ そして、そこに証拠を提供する必要があります。 しかし、すべての場合においてあなたがより速いことを証明する方法は？ これは継続的な競争ではありません。 しかし、もちろん、そのような完全に正しくない競争は、通常の市場の位置付けからわずかに外れています。



通常のポジショニングでは、消費者のポートレートを作成し、需要の高い製品の特性を特定し、これらの特性に焦点を合わせます。 さて、またはあなたはユーザーにこれらのニーズを形成します。 たとえば、私たちのプロセッサにはそのような周波数があり、スマートフォンにはNコアプロセッサがあります。



このジャンルの古典はすでに、オペレーティングシステムがユーザーシステムだけでなく、さまざまな技術プロセスを自動モードで制御するためにも必要であると定式化しており、リアルタイムオペレーティングシステムの概念さえ導入しているため、それを使用しないことは罪です。 リアルタイムシステムの概念を紹介するために、古典は時間のある重要なしきい値について言及しました。 つまり、従来のシステムとは異なります。ユーザーが何かを待っている場合、ユーザーは待つことができます。たとえば、タービンの制御などのハードリアルタイムシステムは待つことができません。



したがって、ユーザーに、従来のオペレーティングシステムとは異なり、システムの応答時間を保証するシステムが提供されることを伝えることができます。 当然、それが小さいほど、システムが制御できるさまざまな技術プロセスの数が多くなります。 また、RTOSのさまざまなキーパラメータがキーパラメータとして指定されているテーブルが多数あります。



彼らはどのように受け取られますか？ このプロセスは正直に記述されています！ ここでは、そのようなハードウェアプラットフォームなどのモデルタスクを使用して、効果を適用します。 もちろん、マーケティングは、1μsの反応時間を単純化し、ただ与えることができます。 しかし、私たちはこれを考慮していません。すべてが正直に記述されていると信じています。



しかし、すみません、別のタスクがある場合はどうなりますか？ 10タスク、100タスク？ そして、酔っ払ったプログラマーが割り込みをロックするとしたら？ そして、システム内でプログラマーがタスクに正しく優先順位を付けなかった場合はどうなりますか？



Emboxがリアルタイムでテストに合格した場合がありました。 私たちは座って、これがリアルタイムオペレーティングシステムであることを証明する方法を考えました。 研究所があり、これを望んでいる顧客がいます。 お客様にとってリアルタイムとは、システムの応答時間が1μsであることを意味します。 次の実験が証拠になるかどうかを尋ねます。

• 特定のハードウェアプラットフォームを採用
• GPIO入力の1つに信号を適用します
• プログラムでイベントをキャッチする
• GPIO出力で、プログラムで信号を送ります
• 測定はオシロスコープを使用して行われ、反応時間は入力フロントと出力フロントの差になります。

顧客は、これがまさに必要なものであることを確認します。 明確な質問をしますが、モデルシステムを設計しているため、他のタスクで開始（ロード）しない場合があります。 つまり、システムはこのような単純なテストタスクのみを実行するのが普通です。 顧客は、これにはテストタスクが必要であると言いました。 おそらく、システムがテストに合格したことを理解しているでしょう！ 当然、特性の確認により、つまり、影響が繰り返されました。



このセクションは、OSや開発者を軽視するために書かれたものではありません。 しかし、写真の完全な不完全さを示すためだけです。 一部のオペレーティングシステムの特性がRTOSに起因することを許可していないと主張しませんでしたが、この用語はマーケティング担当者によって使用されています。 タスクの要件に基づいて独立した研究所のオペレーティングシステムの選択を注文したときに、他のテストを見ました。 複雑なモデルの問題があり、ネットワークの相互作用、システムがロードされた場合のパラメーターの変化、およびさまざまな緊急事態での動作が考慮されました。

「リアルタイムオペレーティングシステム」という用語の定義

ここで、「リアルタイムオペレーティングシステム」という用語を紹介します。 いいえ、私はしません。 実際、この用語には多くの定義があります。 少なくとも元の記事に関するコメントを取ります：

リアルタイムシステムでは、一般に人は不必要なので、リアルタイムシステムの速度は、自動運転車であろうと工場のプロセス制御システムであろうと、制御するプロセスと比較する必要があります。

SRV / RTOS-これは、重要なイベントへの応答の予測可能性に関するランキングのみです。

RTOSは、タスクの正確性が論理的な正確さだけでなく、このタスクを完了するのにかかる時間によって特徴付けられるようなOSです。

0.1μsの測定値を持つ浮動小数点コプロセッサーを使用して、タスクのコンテキストを100 MHzプロセッサーあたり1μsに切り替える基準を設定すると、すべてが適切に配置されます。

RTOSの場所とそうでない場所が明確にわかります。

さて、 OSDAYカンファレンスの 1つで発言された記事で述べた意見を無視することはできません。

ロックされた割り込みで、不明な反復回数のサイクルがある場所がない場合、システムはハードリアルタイムシステムと見なすことができます。

しかし、おそらくそれはすべて特定のものであり、 コメントで提案されているように 、自転車を思い付くのではなく、クラシックを使用するだけです。 指定されたクラシックを引用します（誰かが推測しなかった場合は、アンドリュータネンバウム）：

「別の種類のオペレーティングシステムはリアルタイムシステムです。 これらのシステムの特徴は、時間を重要なパラメーターとして持つことです。 たとえば、産業用プロセス制御システムでは、リアルタイムコンピューターが生産プロセスに関するデータを収集し、それを使用して工場内の機械を制御する必要があります。 多くの場合、満たさなければならない厳しい期限があります。 たとえば、自動車が組立ラインを下っている場合、特定の瞬間に特定のアクションを実行する必要があります。 溶接ロボットの溶接が早すぎたり遅すぎたりすると、車が台無しになります。 アクションが特定の瞬間（または特定の範囲内）に絶対に発生する必要がある場合、ハードリアルタイムシステムがあります。 これらの多くは、産業用プロセス制御、航空電子工学、軍事、および同様のアプリケーション分野で見られます。 これらのシステムは、特定のアクションが特定の時間までに発生するという絶対的な保証を提供する必要があります。



別の種類のリアルタイムシステムは、ソフトリアルタイムシステムです。このシステムでは、望ましくない場合もありますが、期限を逃すことは許容され、永続的な損害は発生しません。 デジタルオーディオまたはマルチメディアシステムは、このカテゴリに分類されます。 デジタル電話もソフトリアルタイムシステムです。



リアルタイムシステムでは厳しい期限を満たすことが重要であるため、オペレーティングシステムはアプリケーションプログラムにリンクされた単なるライブラリであり、すべてが緊密に結合されており、システムの一部を保護していません。 このタイプのリアルタイムシステムの例は、e-Cosです。



ハンドヘルド、組み込みシステム、リアルタイムシステムのカテゴリはかなり重複しています。 それらのほとんどすべてに、少なくともいくつかのソフトリアルタイムの側面があります。 組み込みシステムとリアルタイムシステムは、システム設計者が入力したソフトウェアのみを実行します。 ユーザーは独自のソフトウェアを追加できないため、保護が容易になります。 ハンドヘルドおよび組み込みシステムは消費者向けであるのに対し、リアルタイムシステムは産業用です。 それにもかかわらず、彼らは一定の量を共有しています。」

しかし、この説明から、特定の期間内に反応が存在しないと悲惨な結果につながる可能性のあるシステムでのみシステムを使用できることがわかります。 さて、主要なパラメーター（反応時間を超えない）を達成するために、OSはeCosの例であるライブラリーにすることができます。

リアルタイム特性を実現する方法

厳密な定義を与えることはできませんでした（誰かがコメントを書く準備ができている場合）。 ただし、上記のすべての定義では、いくつかのプロパティが表示されます（今回と予測可能性）。 時間を予測可能性オプション（ある状態から別の状態に移行するときの弧の重み）に変換すると、予測可能性のみが残ります！



これを達成する方法について考えてみましょう。



重要なシステムから不要なものをすべて削除することは明らかです。 普遍的なシステムは安定しているとは考えられません。 タネンバウム同志でさえ、これについて話していた、つまり、彼がeCosについて話していたときです。



Tanenbaumが提案するシステムの予測可能性を高めるもう1つのアプローチは、リソース計画、主にプロセッサ時間、つまり特別なタスクスケジューラに特別な（単純な）アルゴリズムを使用することです。 彼は計画へのいくつかのアプローチを提案しましたが、私は最初に静的テーブル駆動型テーブルに焦点を当てたいと思います。



開発者は、すべてのタスクがタイムスライスの完了に成功することを確認する必要があります。 これを行うには、重要なタスクを静的に分析し、そのしきい値を決定することが提案されています。 このアプローチは、ARINC-653標準に規定されています。 オンボードシステムの標準であり、あなた自身が理解しているように、突然何かが飛行機で作業する時間がない場合、大災害が発生する可能性があります。



次のアプローチは静的なスケジュールですが、優先度に基づいています。 つまり、開発者はすべての状況を再度分析し、システムの優先順位ですべてのタスクを割り当てて、重要なタスクが特定の時間に完了することを確認する必要があります。



オリジナルはあるので、続けたくありません！ もちろん、それは私ができるよりも良く書かれており、さらに、彼らは再び事実を歪曲したとして非難されることができます。 いずれにせよ、最終システムの開発者がシステムの特性を保証する責任があることを示すために、これらのアプローチを正確に引用しました。 また、オペレーティングシステムは適切な機能のみを提供する必要があります。



予測可能性を高める方法の議論を続けて、私は別のコメントをしたい

「ラズベリーでリアルタイムを実現できますが、RTOSではなく、小さなステートマシンがキャッシュに侵入します。」

ここでは、次の点に注意を払いたいと思います。

• システムからRTOSが除外されるため、予測可能性（リアルタイムプロパティ）が向上
• 状態マシンによるプログラムの表現
• さて、リアルタイムシステムの依存性は、ソフトウェアの特性だけでなく、ハードウェアにも依存しています。

コードの行数が減少した場合の予測不能の量が減少すると、誰もが同意すると思います。 いつものように、私は同意しませんが、それについては後で詳しく説明します。



ハードウェアの影響も疑いの余地はほとんどありません。 特に、ロックされた割り込みの状態で、任意の反復回数のサイクルがないと言われたとき、説明されたRTOSの一部のcortex-mでは、割り込みの切断はまったくなかったように聞こえました。 割り込みコントローラーが同等またはより低い優先度の割り込みを個別に無効にするため、これは少しlittleです。しかし、影響の事実は明らかです。 そしてもちろん、キャッシュの存在、アドレス変換（またはページのミス）は不確実性の一因となります。 特に、私は実際、誰も装置の100パーセントの正しい動作を保証できないという事実に注意を喚起したかった。 さて、トランザクションはあなたから落ちました。RTOSの存在は、イベントの壊滅的な結果を避けるのにどのように役立ちますか？



状態マシンとしてのプログラムの表現、私は自明ではない側面からそれを検討することを提案したいと思います。 すなわち、予測可能性プログラムを分析できること。 そして、私たちはすべての条件について話しているので、考えられるすべての状況について、静的に分析する必要があります。 まあ、関数型プログラミング言語は静的解析に非常に適しているため、特別な言語でプログラムを開発したり、特別なプログラミング言語の使用を追加したりすることができます。 最初のアプローチは、たとえば検証済みのseL4カーネルで使用されます。 2番目のアプローチの例は、同じARINC-653標準であり、XMLで要件を強制的に形成します。



予測可能性、または必要に応じてシステムの予測可能性に影響する要因を増やす他の方法があります。 OSDayカンファレンスの1つで、このトピックに関するレポートを作成しました。 特に、既にリストされているものに加えて、アーキテクチャーのアプローチを強調しました。 結局のところ、たとえば、マイクロカーネルアーキテクチャによってシステムの予測可能性が向上することはよく知られています。 しかし、同じレポートでさえ、いくぶん自明ではない組織的なアプローチが強調されました。 これは、RTOSの欠如が予測可能性の向上につながることに同意しなかった点です。 考えてみると、一般に、オペレーティングシステムの概念により、コードの再利用によるエラーの数が大幅に削減されています。 つまり、実際に1つのスイッチ/ケースに収まるコードがない場合は、既製のモジュールを使用することをお勧めします。 結局のところ、パラメーター「コード1000行あたりのエラー数」はキャンセルされておらず、新しいコードがどのようにデバッグされても、エラーがあります。

RTOSはまったく存在しますか？

前のセクションでコードにエラーがあるという声明に落ち着いたので、私は別の挑発的な論文を作りたいと思います。 RTOSはまったく存在しますか？



それを理解しましょう。 リアルタイムシステムについて友人と話し合って、リアルタイムオペレーティングシステム（ハードリアルタイムシステムについて話している）はほとんど存在しないことに同意しました。 彼は、システム全体を、ある状態から別の状態への最大遷移時間を記述した状態マシンまたはグラフとして表現することを提案しました。 さらに、すべての入力および内部状態について、制限時間のある特定の状態につながるアークがあることが証明されている場合、システムは安定していると見なすことができます。 まあ、ご存知のように、これは非常に小さなシステムでのみ可能であり、解説で言及されたまさに状態の機械ですが、現代の世界ではそのようなシステムを必要とする人はほとんどいません。



しかし、リアルタイムシステムが存在することは間違いありません。 そしてもちろん、RTOSも。 そうでなければ、最初の空飛ぶキツツキは文明を破壊し、アビオニクス、宇宙飛行士、ロボット工学、ACS-TPなどはなくなります。



状況から抜け出す方法。 一般に問題は解決できない可能性が高いですが、特定の問題については、何らかの意味のあるエラーの確率で、それを解決可能にする制限を導入することができます。



たとえば、 リアルタイムPOSIX 、 ARINC-653 、 ITRONなどの標準が導入されています 。 実際、これらの標準は、この標準を順守すれば解決できるタスクのクラスを区別します。 または、特定のOSの特性がターゲットの問題を解決するのに適しているかどうかを調査する独立した研究所によって調査が行われます。

RTOSではなくEmbox RTOSですか？

私の意見では、Emboxと他のOSの両方について同様の質問に答えるには、「どういう意味ですか？」 より正確には：「リアルタイムの概念とはどういう意味ですか？」。 つまり、割り込み処理時間に関心があり、割り込みハンドラを直接呼び出すことができるかどうか、これは1つのことです、ゆっくりとはいえ、仕事の信頼性を高める必要がある場合、それは間違いなくはるかに失敗する可能性がはるかに低いです、これは別の、任意の標準への準拠検証は4番目です。 偉大な古典的なアンドレイ・タネンバウムが予測可能性を高める方法を提案したにもかかわらず、リアルタイムシステムの概念を使用したが、厳密な定義を控えたのは偶然ではありません。



PSこの記事の執筆時点では、1つのRTOSは影響を受けていません。