ソフトウェアを修正してリアルタイムにする方法は？[閉まっている]

最初に、私はリアルタイムシステムプログラミングの初心者であることを述べたいので、私の質問が正しいかどうかはわかりません。申し訳ありませんが、私はいくつかの助けが必要です

簡単に言え ば、ハードリアルタイムソフトウェアを実装して、ハードデッドラインに確実に対応する方法を教えてください。QNXのいくつかの機能を使用する必要がありますか？それともLinuxでQNXに移植するだけで十分であり、デフォルトでリアルタイムになりますか？

完全な質問： Linux、Windows、Android、QNXのプロセス間通信を備えた複雑なクロスプラットフォームマルチプロセスソフトウェアを実装しました。プログラミング言語はC ++です。他のライブラリのBoostとPlantyを使用しています。私たちのソフトウェアはそれをうまく素早く実行しますが、それでもプロトタイプです。本番環境ではリアルタイムで実行する必要があります。一部の機能はリアルタイムで非常に堅牢である必要があります。これらの機能は非常に重要であり、ソフトウェアを使用するユーザーの安全性に依存している可能性があるためです。それらはかなり速く動作します-数百ミリ秒まで。しかし、この事実のため、私たちのシステムが本当にリアルタイムであるかどうかはわかりません（私は正しいですか？）。

ですから、主な質問があります。ソフトウェアをリアルタイムに変更する方法は？私はたくさんググってみましたが、どうすればいいのかまだわかりません。

プラットフォームに関するいくつかの追加情報：現在テスト目的でのみ使用しているLinuxおよびWindows。Android-必要かどうかはまだ決まっていません。QNX-本番環境のターゲットOSです。次の質問の答えは「いいえ」だと思います:)しかし、クロスプラットフォームのリアルタイムソフトウェア（リアルタイムOS（RTOS）および汎用OS（GPOS）の場合）を実装することはまったく可能ですか？

おそらく、QNXにのみすべてのリアルタイム機能を実装するよう努力する必要があるでしょうか。しかし、私はまだそれを行う方法を理解していません。誰かがこの質問に光を当てることができますか？

c++ real-time

— user172825
ソース

プロジェクトが安全性を重視する場合は、給与計算のリアルタイムシステムを理解している人が本当に必要です。

— Blrfl 2017年

リアルタイムシステムとは、実行時間の観点からコードがどの程度正確かであり、高速か低速かではありません。

— パゴッティ2017年

既存のソフトウェアをリアルタイムになるように変更するのではなく、明示的なリアルタイムの制約を考慮して、新しいソフトウェアを一から設計して作成すると思います。そして、あなたの質問は広すぎます：あなたのソフトウェアは正確に何をしていますか？正確な種類のリアルタイムシステム、具体的な組み込みシステムについて（目的：民間航空機の機内インフォテインメントは原子炉制御と同じではない）質問を編集して、より具体的で正確にし、モチベーションを上げる必要があります。

— Basile Starynkevitch 2017年

@Blrflのコメントをもう一度読んでください。そして、それを何度も何度も繰り返し、適切な経験を持つ人を雇うまで繰り返します。または、賠償責任保険が支払われていることを確認してください。リアルタイムの要件を備えた安全性が重要なソフトウェアを作成していて、その経験がない場合は、犯罪的に過失であるためです。

— kdgregory 2017年

「クロスプラットフォームのリアルタイムソフトウェア（リアルタイムOS（RTOS）と汎用OS（GPOS）の両方）を実装することはまったく可能ですか？」私の推測は「いいえ」でなければ、RTOSはそうではありません。存在します。「クロスプラットフォーム」は「聖杯」にかなり似ています。

回答:

高速はリアルタイムを意味するものではなく、リアルタイムは高速を意味するものではありません。

リアルタイムとは、結果が配信される日付がその値と同じくらい重要であることを意味します。言い換えると、結果の値は正しいが、配信が早すぎたり遅すぎたりする場合、全体的な結果は間違っています。

たとえば、ビデオプレーヤーについて考えてみます。ビデオフレームが適切なレートで表示されない場合、ユーザーは満足できません。画像と音声が同期していない場合はさらに悪い。

この例は、いくつかのリアルタイムアプリケーションを現在の汎用OSに実装できることを示しています。

ただし、デッドラインミスの結果に関しては、ハードリアルタイムとソフトリアルタイムに違いがあります。ソフトリアルタイムシステムでは、これは単なる煩わしさまたはサービスの低下です（数秒間の画像のフリーズを考えてください）。一方、ビデオプレーヤーの例）は、原子力発電所などのハードリアルタイムシステムにおける（破滅的な可能性のある）障害です。

— mouviciel
ソース

mouviciel氏、私の質問に答えてくれてありがとうございます。リアルタイムでハードになる機能がいくつか必要です。リアルタイムでソフトになる機能もあります。期限を保証するソフトウェアの記述方法がわかりません。この質問に光を当てていただけませんか？

— user172825 2017年

@ user172825-この質問への回答は、ライブラリの棚をカバーしています。出発点は、グーグルの「リアルタイムプログラミング」、関連するウィキペディアの記事、またはQNXやRTEMSなどのRTOSのチュートリアルかもしれません。

— mouviciel 2017年

それは私にとって最も複雑な質問でした。このトピックに関する大きな本をたくさん見つけました。しかし、私はそれを数文で説明することが可能であることを望みました。:)

— user172825 2017年

「コンピュータサイエンスには、キャッシュの無効化と命名という2つの難しいことしかありません。」-Phil Karlton OK、そしてリアルタイム。そこでは、1つの文で2つの文で説明できない理由が説明されています。定期的に予定されているプログラミングに戻ります。

「ハードリアルタイム」「確定的時間」と呼ぶことは、通常、人々にポイントを伝えるのに役立ちます。

— whatsisname

以下のよう@mouvicielはすでに述べた、高速なリアルタイムとは、多くのリアルタイムの期限が比較的高速な応答が必要とされていることを示唆していても、実際には2つの独立したプロパティです。

リアルタイムソフトウェアを作成する場合、正しい応答の次に重要な特性は、応答が与えられる速度を正確に予測できることです。ハードリアルタイム機能の場合、完全な電源障害を除くすべての可能な条件下で期限が確実に満たされるようにする必要さえあります。

予測不可能性の典型的な原因は、

動的メモリ割り当てとガベージコレクション
（優先度が高い）割り込み
OSのスケジューラー
オブジェクトの動的な作成と破棄
条件付きで実行される大量のコード

それらの領域を回避する必要があるとは言っていません（ほとんどの場合は不可能です）が、関連する機能のリアルタイムの期限を確実に満たすことが容易に予測できることを認識しておく必要があります。

— バートファンインゲンシェナウ
ソース

条件付きで実行されるコードでは、償却アルゴリズムに注意してください。ほとんどの場合、操作は安価ですが、たとえば、ベクトルを再割り当てする必要があるときにベクトルを追加する場合など、はるかに高価な操作になることがあります。

— ラチェットフリーク2017年

場合によっては、実行時間をミリ秒に予測してWCET分析を行う必要があるかもしれません

— Basile Starynkevitch

@ user172825：プロファイリングが役立ちますが、その多くは、言語とライブラリを本当によく理解して経験することにかかっています。

— Bart van Ingen Schenau 2017年

ハードリアルタイムの要件がある場合、プロファイリングだけでは不十分な場合があります。ランタイムが完全に確定的でない場合、プロファイリングを行うと、実際には100のうち99回しかデッドラインを満たさない場合でも、プロファイリングによって常にデッドラインまでに完了するという印象を与える可能性があります。厳しいリアルタイム要件がある場合は、 100のうち、それを100回を満たすために必要

— James_pic

@ user172825リアルタイムはソフトウェアのためであり、脳手術は医学のためのものです-あなたはそれを正しく引き出すために多くの経験とスキルを必要とし、あなたはあなたが何をしているのか本当に本当に確信していなければなりません。これらのプロジェクトは、その地域の熟練した専門家の監督の下で作成された方がよいでしょう。これらは、通常の開発者に投げかけて「これをリアルタイムシステムとして機能させる」ことができるものではありません。

— T. Sar

リアルタイムの2つの文の説明は、リアルタイムシステムは、入力が変化してから出力が変化するまでの最悪の場合の応答時間を理解および制御するように設計されていると思います。

それには、システム全体をカバーする分析が必要です。たとえば、USBキーボードとブレーキサーボで構成される簡単なシステムがあるとします。このシステムでどのような応答性を実現できますか？あなたは考慮する必要があるかもしれません：

入力ポーリング頻度、およびこれにかかる時間
入力割り込みレイテンシ
入力イベントが発生した後のオペレーティングシステムのコンテキスト切り替え時間
タスクのオペレーティングシステムの優先順位付け
プログラムでの動的割り当てまたは仮想メモリの使用を回避し、予期しない応答遅延またはOOMイベントを回避する
ガベージコレクションの使用を回避する
O（n）またはより高いまたは予測不可能なNを持つより悪いアルゴリズムの使用を回避する（非常に大きなプレイリストを車のエンターテイメントシステムにロードすると、ブレーキ応答が遅くなりますか？）
ディスクまたはネットワークの遅延を考慮します（例：車でのCANバスの使用）
出力制御待ち時間

この種の環境では、通常、MISRA C規格など、信頼性に関する特別な考慮事項もあります。

— pjc50
ソース

リアルタイムであることは、操作が確定的であるか、場合によっては再帰的であるか、場合によってはまったく計算可能であるかどうかの考慮を含むことも本当ですか？

はい、それらすべては「無制限」になります。スタックの使用に上限が課せられている場合は、再帰的アルゴリズムを許可できます。

— pjc50 2017年

avoiding use of garbage collection-これはavoiding use of non-deterministic memory management。ガベージコレクションはリアルタイムで実行でき、手動のメモリ管理は必ずしも確定的ではありません（mallocCの一般的な実装を参照）。

— 8ビットツリー2017年