### Modeling Example "State Machine"

In this system architecture pattern the modeling example “Client Server without Reply” is extended in such a way that now the task that receives messages (T2) not only varies its dynamic behavior and consequently also its execution time according the transmitted content but also depending on its internal state, meaning the prior transmitted contents. To achieve, this task T1 sends a message to task T2 with either 0 or 1 before runnable R1 is called. The value 0 is used in 75 % of the cases and 1 in the other cases as content of the message. Starting in state 0, T2 decreases or increases the state its currently in depending on the content of the message, 0 or 1 respectively. The runnable R 2,1, R 2,2, and R 2,3 represent then the three different states that the system can be in.

The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system’s behavior.

Task | Priority | Preemption | Multiple Task Activation Limit | Activation | Execution Time
--- | --- | --- | --- | --- | ---
T1 | 2 | FULL | 1 | Periodic | R1 | Uniform
Offset = 0 | Min = 9.9 * 106
Recurrence = 100 * 106 | Max = 10 * 106
T2 | 1 | FULL | 1 |  | R 2,1 | Uniform
Min = 99
Max = 100
Periodic | R 2,2 | Uniform
Offset = 15 * 106 | Min = 99 * 103
Recurrence = 60 * 106 | Max = 100 * 103
| R2,3 | Uniform
Min = 49.5 * 106
Max = 50 * 106

In order to show the impact of changes to the model, the following consecutive variations are made to the model:

1) Initial Task Set
  As defined by the table above.

2) Exclusive Area
  For this variation, all data accesses are protected by an exclusive area. Therefore, the data accesses in T1 as well as all runnables in T2 (R2,1, R2,2, and R2,3) are protected during their complete time of execution via a mutex and priority ceiling protocol. That way, blocking situations appear.

3) Priority Ordering
  As from this variation on, the priority relation between task T1 and T2 is reversed. As a consequence, the priority of task T1 is set to 1 and the priority of task T2 is set to 2. That way, the timing behavior is changed fully.

4) Inter-process Activation
  As from this variation on, task T2 gets activated by an inter-process activation from task T1 instead of being activated periodically. The interprocess activation is performed right after the message message is written in T1 and consequently before the runnable R1 is called. That way, a direct connection between T1 and T2 is established.

5) Event Frequency Increase
  As from this variation on, the periodicity of T1 is shortened. For this, the value for the period of task T1 is halved to 50 * 106. That way, the utilization of the system is increased, which results in extinct activations.

6) Activation
  As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.

7) Execution Time Fluctuation
  As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of the uniform distribution is increased by 1 percent so that the uniform distribution varies now by 2 percent. That way, the utilization of the system is further increased.

8) Accuracy in Logging of Data State I
  For this variation, the data write accesses in task T1 and task T2 are omitted. Instead, the runnables R2,1, R2,2, and R2,3, each representing the execution of a specific state, are executed with a probability of 60 %, 30 %, and 10 % respectively. That way, only a limited insight into the system’s runtime behavior is available.

9) Accuracy in Logging of Data State II
  For this variation, just task events are active. That way, only a limited insight into the system’s runtime behavior is available.