Update Realtime Best Practices with advice on setting realtime software frame. (#1845)

* Add advice on setting realtime software frame. * Fix typos, grammar, from review.
2025-04-05 18:36:48 +00:00 · 2025-02-27 11:20:59 -06:00 · 2025-02-27 11:20:59 -06:00 · 0d02a0506a
commit 0d02a0506a
parent 304abf8bee
1 changed files with 30 additions and 2 deletions
--- a/docs/howto_guides/Realtime-Best-Practices.md
+++ b/docs/howto_guides/Realtime-Best-Practices.md
@ -217,7 +217,7 @@ When you build your Trick sim, the following data-product files are created for

 ### Other Useful Files Generated by a Trick Sim Run

-| Name | Desscription|
+| Name | Description|
 |:-----|:------------|
 |```RUN_*/S_job_execution```| Lists the simulation jobs by Name, Job ID, Trick Thread ID (PID) Job class, Phase, Start time, Stop time, Cycle, and whether the job is enabled.|
 |```RUN_*/S_run_summary ```|(Should be called build_summary) - Documents the name and path of the executable and the input file, the build time of the simulation executable, and the Trick version. It also contains the list of environment variables used when the simulation was built and the model versions.|
@ -387,7 +387,35 @@ Doing this has several benefits.

 1. The sim will initialize faster because ```default_data``` jobs are compiled rather that interpreted.

-2. If you can test and confirm that your base, default, "empty input file" sim is initialized to a valid state, then it will be easier to identify errors when the sim is customized for different scenarios, via an input file. It saves time and reduces pain.
+2. If you can test and confirm that your base, default, "empty input file" sim is initialized to a valid state, then it will be easier to identify errors when the sim is customized for different scenarios, via an input file. It saves time and reduces pain.
+
+
+#### 1.8 Realtime Software Frame should be based on the realtime requirements of external interfaces.
+
+A Trick simulation should not synchronize simulation-time to realtime more frequently than is required by external interfaces. The [realtime software frame](#realtime-software-frame) should be chosen to service a simulation's highest frequency external interface.
+
+**Example:**
+
+Consider a Trick simulation consisting of :
+
+* A 200 Hz  integration loop.
+* A 100 Hz scheduled job.
+* A 50 Hz scheduled job that services a graphics client that is required to update at 50 Hz.
+* A 25 Hz scheduled job that services a 25 Hz hardware avionics device.
+
+
+The external interfaces are the avionics device and the graphics client. These have **realtime** requirements. The 100 and 200 Hz simulation jobs do not. 
+
+The highest frequency of these external interfaces is 50 Hz. So, the software frame should be set to 0.02 seconds (ie., 50 Hz).
+
+**“What about the 200 Hz and 100 Hz jobs?”**
+
+Since they are not required to service external interfaces, these jobs can run as fast as possible in realtime. Simulation time and realtime are not the same thing, until simulation-time is (slowed down, and) synchronized to realtime. Remember that the [realtime software frame](#realtime-software-frame) specifies how often to synchronize simulation-time to realtime.
+
+**“What if I  set the realtime software frame to 0.005 seconds (i.e., 200 Hz) anyway? Is that a problem?"**
+
+Yes, it could be. The issue is that this wastes computing resources, and unnecessarily increases the probability of realtime over-runs. This is especially true if there is variability in the execution times of these jobs.
+

 ---
 ### 2. User Simulation Software