We will present non-deterministic models and compositions of synchronous systems.

Recall a deterministic EFSM from the previous lecture. \[(Q, X, I, O, q_0, x_0, \delta),\]

- \(Q\) is a finite set of modes (sometimes confusingly called states).
- \(X\) represents the typed internal state variables.
- \(I\) represents the input variables.
- \(O\) represents the typed output variables.
- \(q_0 \in Q\) is the starting mode; and \(x_0 \in D(X)\) is the initial value of the internal state variables.
- \(\delta: Q \times D(X) \times D(I) \rightarrow Q \times D(X) \times D(O)\) is the transition function wherein \(\delta(q, x, i) : (q', x', z)\) denotes that from the mode \(q\), internal state value \(x\), input value \(i\), we move in a step to \(q' \in Q\), \(x' \in D(X)\) and output the value \(z \in D(O)\).

The system is deterministic (since \(\delta\) is a function). Thus for every pair \((q, x)\), with mode \(q \in Q\) and \(x \in D(X)\), and each input \(y \in D(I)\), we have *exactly one* next state \[ (q',x') := \delta(q,x,y)\,.\]

Deterministic machines are often too *tedious* to specify.

The figure above shows a model of a vending machine with Boolean inputs: 'coin', 'cancel' and 'A', indicating the insertion of a coin, the cancellation of the transaction and a request for food A.

Imagine what happens to the machine in the 'Two Quarter' mode when 'coin' and 'cancel' are both pressed. There are two transitions enabled:

- The self loop from 'Two Quarter' to itself is enabled and returns the coin inserted, ignoring the cancel.
- The edge from 'Two Quarter' to 'One Quarter' is enabled returning a coin but still accepting a coin that the user will never be able to use again.

Thus, the machine can take either of the two options and is thus not *fully specified*.

We call such machines non-deterministic EFSMs.

A complete deterministic specification is often tedious at design time. Nondeterminism allows us the benefit of having options open, when it comes to unspecified behaviors.

- Nondeterministic EFSMs
A

*nondeterministic*EFSM has the following properties

- It may have multiple initial modes \(Q_0 \subseteq Q\) rather than a single one.
- It may have multiple initial start states \(X_0 \subseteq D(X)\) rather than a single start state \(x_0\) for the deterministic case.
- For some mode \(s\), the outgoing guards on the transitions need not be mutually exclusive (permitting multiple transitions to be taken for some states and inputs) or mutually exhaustive (permitting no transitions to be taken for some states and inputs).

Formally, a nondeterministic EFSM is a tuple \[(Q, X, I, O, Q_0, X_0, \delta),\]

- \(Q\) is a finite set of modes (sometimes confusingly called states).
- \(X\) represents the typed internal state variables.
- \(I\) represents the input variables.
- \(O\) represents the typed output variables.
- \(Q_0 \subseteq Q\) is the set of possible starting modes; and \(X_0 \subseteq D(X)\) is the initial value of the internal state variables.
- The transition
*relation*\(\delta\) has the following structure \[\delta: \underset{\text{current state}}{\underbrace{Q \times D(X)}} \times D(I) \times \underset{\text{next state}}{\underbrace{Q \times D(X)}} \times D(O)\]

For each tuple \((q,x,y, q', x',z)\) denotes that the system with 1. Current mode \(q \in Q\), 2. Internal state variable values \(x \in D(X)\), 3. Input \(y \in D(I)\) can move in one step to 1. New mode \(q'\), 2. new internal state \(x'\) and 3. new output \(z\).

Given a sequence of inputs $y(0), y(1), , $ a corresponding execution of a nondeterministic EFSM is a sequence of outputs, modes and internal state values:

\[(q(0), x(0), z(0)),\ (q(1), x(1), z(1)),\ \cdots \]

such that

- At time \(t=0\), we have \((q_0, x_0, y(0), q(0), x(0), z(0)) \in \delta\) for some state \(q_0 \in Q_0\) and \(x_0 \in X_0\).
- At time \(t >0\), we have \((q(t-1), x(t-1), y(t), q(t), x(t), z(t)) \in \delta\).

As a result, note that in certain situations, a machine may have multiple possible executions compatible with an input, and in some *no possible execution* compatible with an input. The latter is particularly useful when we wish to ignore possibilities that can be physically impossible due to the design principles used.