Computer Software Rate Error Model

SWITCH TO API

Description

The Computer Software Rate Error Model simulates the discrete execution timing of flight software on an onboard computer. In real spacecraft systems, flight software does not execute continuously but rather at fixed intervals determined by the processor clock and scheduling algorithm. This model allows the simulation to replicate this behavior by enabling or disabling software execution based on a configurable update frequency.

---

Example Use Cases

• Control Loop Timing Analysis: Evaluate the impact of discrete software execution rates on attitude control system performance and stability margins.
• Processor Loading Studies: Model different software update frequencies to assess computational resource allocation.

---

Module Implementation

The Computer Software Rate Error Model is a model that attaches to a Computer component. It governs the execution timing of all Software modules hosted on the parent computer by selectively enabling and disabling them based on a discrete clock.

Computer State Dependency

The model only operates when the parent computer is in a stable operational state. If the computer is not in the Running or Safe state, all software modules are disabled regardless of the clock:

$$\text{execute}=\text{false}\text{if state}\notin \{\text{Running},\text{Safe}\}$$

This ensures that software does not execute during computer startup, shutdown, or state transitions.

Clock Mechanism

The model implements a discrete clock that triggers software execution at regular intervals. The clock period $T_{\text{clock}}$ is determined by the configured frequency $f$:

$$T_{\text{clock}}=\frac{1}{f}$$

where $f$ is the update frequency in Hertz. The model maintains a state variable $t_{\text{next}}$ representing the next scheduled clock tick.

Software Gating

At each simulation time step, the model evaluates whether the current simulation time $t$ has reached or exceeded the next scheduled clock time:

$$\text{execute}=\{\begin{array}{ll}\text{true}& \text{if }t\ge t_{\text{next}}\\ \text{false}& \text{otherwise}\end{array}$$

When the clock condition is satisfied, all software modules attached to the parent computer are enabled for that simulation step. When the condition is not satisfied, all software modules are disabled until the next clock tick.

Clock Advancement

After each successful clock tick, the next clock time is advanced by the clock period:

$$t_{\text{next}}\leftarrow t_{\text{next}}+T_{\text{clock}}$$

This ensures that software execution occurs at regular intervals regardless of the simulation time step size.

Continuous Execution Mode

When the frequency is set to zero ($f=0$), the model operates in continuous execution mode. In this case, all software modules remain enabled at every simulation time step:

$$f=0⟹\text{execute}=\text{true}\forall t$$

This mode bypasses the discrete clock mechanism and allows software to run at the simulation rate.

---

Assumptions/Limitations

• All software modules on the parent computer share the same execution frequency; individual module timing is not supported.
• The model assumes instantaneous software execution; computation time within a clock tick is not modeled.
• Clock drift, jitter, and timing uncertainties are not modeled; the clock is assumed to be perfectly periodic.
• The initial clock time $t_{\text{next}}$ starts at zero; phase offsets from simulation start are not configurable.
• If the simulation time step exceeds the clock period, intermediate clock ticks are not executed; only the next scheduled tick is processed.
• The frequency parameter must be non-negative; negative frequencies are not physically meaningful.