erational profile (of collection $Z$) is $$P(Z) = \lim_{\;k \to \infty} \frac{N_Z(\{{\mathit{s}}_n\}, k)}{k}.$$

### Conversion into a rate {#S:ABSOLUTE_OP_PROFILE_RATE}

Section \[S:INTRO\_REACTIVE\] mentions the synchronization function, a cross-reference between discrete and real time. During each step, an amount of real time appropriate for a software system emulating the automaton’s step is added to the time consumption budget. Let $Z$ be the usual arbitrary reference collection of steps and ${\mathit{o}} = \{{\mathit{s}}_n\}$ be an orbit. These two provide a set of events and a sequence of steps in which to count the events’ arrivals. The synchronization records discrete pairs $(i, t_i)$, where $i$ is the index of the automaton step and $t_k$ is the total elapsed time after $k$ steps. Call this mapping the synchronization function, having the formalism $\sync \colon {\mathbb{S}}^{\mathbb{N}}\times {\mathbb{N}}\to {\mathbb{R}^+}$, along with assumed starting point $\sync(\{{\mathit{s}}_n\}, 0) = 0$.

Let the sequence index of each step be the discrete analog of time. Of course, this has the effect that discrete software time will not hold proportional to hardware real time. The approximate real time required by execution of step ${\mathit{s}} = (\lambda, {\mathit{f}}, {\mathbf{f}})$ is $\tau({\mathit{f}})$ – that is, elapsed real time is taken as a function of the executing functionality.

\[D:SYNC\_APPOX\] For orbit ${\mathit{o}} = \{{\mathit{s}}_n\}$, approximate time elapsed during the first $k$ steps accumulates to $$\sync(\{{\mathit{s}}_n\}, k) = \sum_{i=1}^k \tau({\mathit{f}}_i)) = \sum_{i=1}^k \tau(\mho_{{\mathscr{F}}}({\mathit{s}}_i)) = t_k.$$

A theorem to avoid creating dependency on specific orbits is in order. Inability to define normal operations leads instead to conjecture, expressing such need:

\[T:TIME\_RATIO\] For different orbits ${\mathit{o}} = \{{\mathit{s}}_n\}$ and ${\mathit{o}}' = \{{\mathit{s}}'_n\}$ having the same usage pattern, $$\lim_{\;k \to \infty} \frac{N_Z(\{{\mathit{s}