アプリケーションを「リアルタイム」または「ほぼリアルタイム」、あるいはそれ以外のものとして分類するかどうかを判断するのに問題があります。
ソフトウェアは、ソースから生成されたデータをすぐに受信し、特定のルールに基づいて、特定の条件が満たされたときにアラートを生成します。ルールの基準が満たされているかどうかを確認するために、30秒ごとに最後の30秒のデータをチェックするというアプローチが採用されています。
それはリアルタイムですか？リアルタイムとほぼリアルタイムの定義のしきい値は何ですか？
編集
これは、ビジネス向けのWebでのリアルタイムの定義の複製だと思います。
上記のスレッドがあなたの質問に答えるのに不十分であるかどうかを判断してください。
リアルタイム = 解決までの最大保証時間。アプリケーションの要件に応じて、ピコ秒または分になる可能性があります
これは StackOverflow の最大の問題です: 資格のない人々は、「正しく聞こえる」答えで多くの質問に答えて投票されます。答えが実際に正しいかどうかを気にする人々は、間違った答えを修正するための担当者を獲得するのに十分な速さでナンセンスを吐き出しません。思わぬ反応が予想されるため、匿名で投稿します。
リアルタイムは、指定された期間内に完了したイベントに対して必要な応答を取得しているか、システムに障害が発生しています。
人々はこれが「ミリ秒/マイクロ秒の小さな数」を意味するに違いないと考えることに慣れていますが、それは必ずしも真実ではありません - それはあなたのシステムに依存します.
システムが30 秒以内に応答しないと失敗する場合、それは「リアルタイム」です。
システムによっては、障害が壊滅的なものになる可能性があります。たとえば、複数の死亡者が発生することがあります。これは、原子力発電所の停止など、セーフティ クリティカルと呼ばれます。
「リアルタイム」という言葉は、かなり広い領域をカバーしています。
あいまいな定義は、「限られた応答時間内で動作するソフトウェア」です。
車の噴射制御システムなど、境界が難しい場合、ソフトウェアは「ハード リアルタイム」であると言われます。
境界がソフトである場合、たとえば音楽再生システムなど、最大 50 ミリ秒の変動が許容される場合、そのシステムは「ソフト リアルタイム」であると言われます。
そうです、リアルタイムの定義によっては、システムはリアルタイムです。
しかし、実際にリアルタイム システムで作業している他の人の周りでリアルタイムと呼ぶと、おそらく笑われるでしょう。30 秒はかなり長いからです。
まあ、それは技術的な問題というよりもマーケティングの問題かもしれません。
組み込みハードウェアの観点から、リアルタイムには、着信情報（割り込みなど）を処理するための既知の固定最大時間が含まれます。
特に上記の情報の配信がそれより長い場合は、リアルタイムとして30秒の遅延を確実に主張できます。
たとえば、「アラート」がメールサーバーで10分かかる可能性のあるメールや、ユーザーが30分ごとにしかチェックしないモニターの赤い十字である場合、リアルタイムには30秒で十分です。
リアルタイムを定義する1つの側面は、プロセスが決定論的であるということです。つまり、アプリケーションの応答時間は、入力に基づいて完全に予測可能です。
したがって、非常に幅広いブラシストロークでペイントすると、Windowsの上にあるアプリは、せいぜい「ほぼリアルタイム」にしかできません。アプリが何らかのサンドボックスプラットフォーム（Java、.NET）で実行されていて、プラットフォーム機能（ガベージコレクションなど）を完全に制御できない場合は、二重にそうなります。
私の個人的なルールは、「リアルタイム」はデスクトップPCに属していないということです。これがPLCの領域です（もちろん、QNX、VxWorx、さらにはRTLinuxなどのOSを実行している可能性があります）。
コントロールの友人からの「ハード」リアルタイムの定義 - 遅れた情報は間違った情報です。1秒ごとに存在する必要があり、1.1秒でそこに到達する場合、計算には役に立ちません。
これについては、私の Web サイト real-time.org で長い説明を提供しています。ホームページには、ブリーフィングへの一時的なリンクがあります。ブリーフィングでは、人々が「リアルタイム」(および「ハード」、「ソフト」、「予測可能」など) の意味を理解していない理由と方法について説明します。いくつかの正確で一般的な定義を提供します。このトピックに関する私の説明に同意しない人から聞いたことがありますが、私のように正確で一般的なことを提案した人は誰もいません。ラリー・キングが言うように、「椅子を引き上げて、話しましょう」.
「リアルタイム」を定義するもう 1 つの方法は、多くのRTOS (リアルタイム オペレーティング システム) の機能を評価することです。たとえば、QNX の定義はこちらです。これらは、 POSIX PSE52 Realtime Controller 1003.13-2003 システム製品規格に準拠していることに注意してください。ほとんどの組み込みオペレーティング システムは、同様の機能を提供します。
その答えは、リアルタイム システムは主観的なものであり、「リアルタイム」は要件によって課される適時性の制約に過ぎないということだと思います。リクエストへの応答に 2 時間かかるものは明らかにリアルタイムではありませんが、30 秒の遅延はリアルタイムとみなすには十分な速さかもしれません。
私はリアルタイム システムと考えているものに取り組んでおり、システムでイベントが発生すると、システム上のデバイスにすぐに伝播され、デバイスの更新について知る際の遅延は、ネットワークの遅延と所要時間の積になります。メモリ内データを更新します。
個人的には、30 秒ごとに更新をポーリングするものをリアルタイムとは分類しません。前述のシステムの一部として Web アプリがあり、30 秒ごとに更新されるため、ユーザーには最大 30 秒前のデータが表示されます。これを、イベントが発生するとすぐに更新される win form equalivent と比較してください。
繰り返しますが、「リアルタイム」は、タイムリーな応答の定義によって制限されます。
リアルタイムの定義は文脈に依存すると思います。音楽の例と同様に、リアルタイムはミリ秒である必要がありますが、おそらくあなたの例では、リアルタイムは30秒程度以内である可能性があります。それはすべて相対的です。
リアルタイムで応答する必要がある特定のソリューションまたはソリューションの一部を確認する必要があると思います。リアルタイム応答は、受信者（アプリケーションまたは基本的にエンドユーザー）によってリアルタイムであると認識される応答です。
リアルタイムはマイクロ秒を扱います...主にロボット工学を中心にしています。考えてみてください'腕を30マイクロ秒動かします。自動車の組み立てのように、1000マイクロ秒を溶接します。
30秒は、非リアルタイムOSのスレッドスリープまたはタイマーに基づいていますか？もしそうなら、あなたは潜在的な多様性を持っています。その差異（30.01秒）の範囲外にある場合、それは失敗と見なされますか？そうでない場合は、リアルタイムではありません。
私はジョンに同意します。あなたのシナリオでは、少なくとも30秒の遅延が見られますが、ほぼリアルタイムであると言えます。