A formalisation of CREST
This section provides an overview of the formal aspects of CREST. The following definitions are a summarised version of the original formalisation (see [50]). Due to spatial considerations, we only provide a brief introduction and refer the reader to the extended original for a more elaborate description including detailed explanations, examples and discussions.
A.1 formal language structure
CREST ’s formalisation (both structure and semantics) is defined on a system-global level. This means that states, transitions, ports, etc., are first defined as a system-wide sets and then divided into mutually exclusive sets for each entity.
To help this separation, the formalisation uses the notion of non-overlapping set partitions (denoted by the \(\bigsqcup \) operator).
Notation
(Partition of sets) Given a set S, the subsets \(S_1, \dots , S_n\) are defined to be a partition of \(S = \bigsqcup _i S_i\) iff \(\forall i,j, i \ne j \Rightarrow S_i \cap S_j = \varnothing \) and \(S = \bigcup \limits _{1 \leqslant i \leqslant n} S_i\).
Definition 1
(Time Base) Being a timed language, CREST requires the definition of a time base \(\mathbb {T}\) that the systems operate in. Next to the set of time values \(\mathbb {T}\) is also required to contain an infinitesimal element \(\epsilon \) and infinity element \(\infty \). Usually we assume \(\mathbb {T}\) to be positive rational or real, e.g. \(\mathbb {R}_{\ge 0} \cup \{\epsilon , \infty \}\).
Definition 2
(Types and Values) Given \( Units \), a set of resource units, and \( Domains \), a set of value domains, the set of resource types is defined as \( Types \subseteq Domains ~\times ~ Units \). The values of a resource type \( type \) are \(\{\langle v, unit \rangle \mid v \in domain , \langle domain , unit \rangle \in Types \}\), where \( type = \langle domain , unit \rangle \). The set of all resource values is defined as \( Resources = \{ \langle v, unit \rangle \mid \exists \langle domain , unit \rangle \in Types \wedge v \in domain \}\). It contains all possible couples of values and units.
For legibility, the simplified notations \( domain\,unit \) and \( v\,unit \) can be used for resource types and values. Thus we write e.g. \(\mathbb {N}\text {Watt}\) and \(3\text {Watt}\) for \(\langle \mathbb {N}, \text {Watt} \rangle \) and \(\langle 3, \text {Watt} \rangle \). For instance, Fig. 4 uses these definitions:
$$\begin{aligned} Units =&\{ \texttt {Watt}, \texttt {Switch}, \texttt {Celsius}, \texttt {Colour} \}\\ Domains =&\{ \mathbb {R}, \{ \texttt {on}, \texttt {off} \}, \{ \texttt {red}, \texttt {green} \} \}\\ Types =&\{ \mathbb {R}{} \texttt {Watt}, \{ \texttt {on}, \texttt {off} \}{} \texttt {Switch}, \mathbb {R}{} \texttt {Celsius}, \dots \} \\ Resources =&\{ 0\texttt {Watt}, \texttt {on}{} \texttt {Switch}, 22\texttt {Celsius}, \dots \} \end{aligned}$$
Definition 3
(Hierarchy of Entities) A CREST system’s structure forms a rooted tree, where each entity can contain children entities. The system’s entity tree is defined by a set of entity names \( Entities \), and a function \( parent : Entities \rightarrow Entities \cup \{ \bot \}\), which returns the parent of an entity or \(\bot \) if it has no parent. The function \( children : Entities \rightarrow \mathcal {P}( Entities )\) returns the direct children of an entity, and \( root : Entities \) provides the system’s only entity without parent.
Definition 4
(Ports) CREST systems use ports for the transfer of resources, and storage of data. These ports are defined by a set of port names \( Ports \), and a function \( type : Ports \rightarrow Types \) that assigns the resource type of each port. The AC example’s port names and types are
$$\begin{aligned} Ports&= \{\text {temperature}, \text {switch}, \text {ontime}, \dots \} \\ type (\text {temperature})&= \mathbb {R}{} \texttt {Celsius} \\ type (\text {switch})&= \{ \text {on}, \text {off} \}{} \texttt {Switch}\\ type (\text {ontime})&= \mathbb {R}{} \texttt {Time} \end{aligned}$$
The system’s port names are partitioned into inputs, outputs and local ports: \( Ports = Ports ^I \sqcup Ports ^L \sqcup Ports ^O\), and each port is assigned to exactly one entity:
$$\begin{aligned} Ports = \mathop {\bigsqcup }\limits _{{e \; \in \; Entities }} Ports _e \end{aligned}$$
Intersection of these partitions defines each entity’s inputs, outputs and locals:
$$\begin{aligned} \forall e \in Entities {\left\{ \begin{array}{ll} \quad Ports ^I_e&{} = Ports ^I \cap Ports _e \\ \quad Ports ^O_e&{} = Ports ^O \cap Ports _e \\ \quad Ports ^L_e&{} = Ports ^L \cap Ports _e \end{array}\right. } \end{aligned}$$
To enforce the locality principle, CREST allows only certain ports to be used in transition guards (sources) and updates only to write to other specific ports (targets).
The function \(\textit{sources} : Entities \rightarrow \mathcal {P}( Ports )\) defines those ports of an entity, that can be used to calculate transition guards or the value of update functions. They consist of an entity’s inputs and locals, and its subentities’ outputs.
$$\begin{aligned} \forall e \in Entities , \textit{sources}(e)= & {} Ports ^I_e \; \cup \; Ports ^L_e \; \cup \\&\quad \mathop {\bigcup }\limits _{{e' \; \in \;\textit{children}(e)}} Ports ^O_{e'} \end{aligned}$$
Similarly, \(\textit{targets} : Entities \rightarrow \mathcal {P}( Ports )\) defines the set of possible targets of update functions, i.e. its local ports, outputs and all direct subentities’ input ports.
$$\begin{aligned} \forall e \in Entities , \textit{targets}(e)= & {} Ports ^O_e \; \cup \; Ports ^L_e \; \cup \\&\quad \mathop {\bigcup }\limits _{{e' \; \in \; \textit{children}(e)}} Ports ^I_{e'} \end{aligned}$$
Definition 5
(Bindings) \( Bindings = \{ b : Ports \rightarrow Resources \mid \forall p \in Ports , b(p) \in \textit{type}(p) \}\), is the set of mappings that associates each port with a value of its respective resource \( type \). For instance \(b(\text {temperature}) = 24\texttt {Celsius}\) and \(b(\text {switch}) = \text {off}{} \texttt {Switch}\).
Definition 6
(States and Transitions) Entity behaviour is defined using state automata, such that each entity specifies its own automaton. The system’s set of states \( States \), is globally defined and partitioned into subsets for each entity, such that each entity has at least one state:
$$\begin{aligned} States \; = \; \mathop {\bigsqcup }\limits _{{e \; \in \; \textit{Entities}}} States _e \qquad \forall e\in Entities, States _e \ne \varnothing \end{aligned}$$
Transitions are defined by the \( Transitions \) relation, which associates two states (of the same entity) and a guard function name \(t \in \mathcal {T}\)
$$\begin{aligned} Transitions \; \subseteq \; \mathop {\bigcup }\limits _{{e \; \in \; Entities }} \big ( States _e \times States _e \times \mathcal {T}\big ) \end{aligned}$$
The function \(\tau : \mathcal {T} \rightarrow ( Bindings \times Bindings \rightarrow \mathbb {B})\) maps the guard function names to guard function implementations. CREST does not specify a syntax or semantics for these implementations but requires them to adhere to a signature. Specifically when called with a current port bindings \( binding \) and a previous port bindings pre (\( binding , pre \in Bindings \)) guard implementations need to yield whether the transition is enabled.
Definition 7
(Updates) Updates are used to modify port values. Each update relates an automaton state to a target port and an update function name \(u \in \mathcal {U}\), so that u continuously updates the target port’s value when the automaton is in the related state.
$$\begin{aligned} Updates \; \subseteq \; \mathop {\bigcup }\limits _{{e \; \in \; Entities }} \big ( States _e \times targets (e) \times \mathcal {U}\big ) \end{aligned}$$
Only one update definition is allowed for each combination of target port and state, to avoid write-conflicts when two updates try to write to the same port:
$$\begin{aligned} \forall p \in Ports , s \in States , \mid \{ \langle s, p, u \rangle \in Updates \} \mid ~ \leqslant 1 \end{aligned}$$
The function \(\upsilon : \mathcal {U} \rightarrow ( Bindings \times Bindings \times \mathbb {T} \rightarrow Resources )\) maps the update names to their implementation functions. Applied to port bindings \( bind \), the previous port bindings pre (\( bind , pre \in Bindings \)) and a passed time span \(\delta t \in \mathbb {T}\), they provide a new value for the specified target port. Note the use of time \(\mathbb {T}\) that allows time-based value evolution.
Note 1 (The need for pre) The pre binding stores all ports’ previous value bindings. It can be used for various functionality in CREST systems where knowledge of the previous value is required, such as change of a port p’s value over time using update u’s implementation \(\upsilon (u)(b, \textit{pre}, \delta t) = \textit{pre}(p) + 2 * \delta t\).
Definition 8
(dependencies) The function \( dependencies : \mathcal {U} \rightarrow Ports \) returns a set of ports for each update function name. We add a constraint that an update’s dependencies can only be source-ports of the update’s entity.
$$\begin{aligned} \forall \langle s, p, u\rangle \in Updates , \forall e \in \textit{Entities}, s \in States _e, p \in targets (e), \\ \textit{dependencies}(u) \subseteq sources(e), p \notin \textit{dependencies}(u) \end{aligned}$$
The dependencies function is used to determine the execution order of updates within the operational semantics.
Note, that CREST entities are not allowed to specify circular dependencies between ports. This means that if a dependency e.g. reads a port A and writes B, then there cannot be an update reading B and write A.
Definition 9
(io-dependencies)\(\textit{io-dependencies} : Ports \rightarrow \mathcal {P}(Ports)\) is a function that specifies the dependencies inside an entity. As entities are usually treated as black boxes, by default the assumption is that all output ports depend on all input ports. This assumption can occasionally lead to cyclic dependencies between subentities. \(\textit{io-dependencies}\) can help resolve these dependencies by “shining a light” into the black box and revealing the actual dependencies inside a subentity.
$$\begin{aligned} \forall e \in Entities , \forall p \in Ports ^O_e, \textit{io-dependencies}(p) \subseteq Ports ^I_e \end{aligned}$$
Due to spatial limitations, we refer the reader to [50] for a detailed explanation of this aspect.
A.2 Global state of a CREST system
Definition 10
(State of the system) The global state \(w \in W\) of an entire CREST system is a combination of the current states of all entity automata, the bindings of all ports, the previous bindings of the ports, and a global time.
$$\begin{aligned} W = Currents \times Bindings \times Bindings \times \mathbb {T} \end{aligned}$$
Each CREST system further needs to define its initial state \(w_0 \in W\).
The set of current automata states (not to be confused with the global system state) is given by \( Currents = \{ f : Entities \rightarrow States \mid \forall e \in Entities , f(e) \in States _e \}\). In the AC example \( current \in Currents \) is initially defined as \( current (\text {AirCondition}) = \text {Off}\).
Definition 11
(CREST Syntactic Structure) Based on the previous definitions, a CREST system is specified as a structure S containing information about the resources (data types), entity hierarchy, ports, states and transitions, updates, dependencies, io-dependencies, and the initial global state \(w_0\):
$$\begin{aligned} S = \langle&Units , Domains ,\quad Entities , parent ,\quad Ports , type ,\\&States , Transitions , \mathcal {T}, \tau , \quad Updates , \mathcal {U}, \upsilon , \\&dependencies ,\quad \textit{io-dependencies},\quad w _0 \rangle \end{aligned}$$
A.3 Operational semantics
The following definitions specify the modification of individual automaton states and port values. The propagation of such changes’ effects on a complete CREST system and the upkeep of a well-formed system state however require more complex routines that are defined further below using structured operational semantics (SOS) rules.
Definition 12
(Change of automata states) The state transition of an entity e to a state s is represented by \(w[e \mapsto s]\). This change within one entity creates a new (global) system state \(w'\) where the current automaton state of all entities remains the same, except for e (the entity to be updated), which now maps to s.
$$\begin{aligned}&\forall w \in W , w = \langle current , bind , pre , t \rangle , \forall e \in Entities , \forall s \in States _e,\\&w [e \mapsto s] = \langle current ', bind , pre , t \rangle , \\&\text {where } \forall e' \in Entities , current '(e') = {\left\{ \begin{array}{ll} s &{} \text { if } e' = e \\ current (e') &{} \text { otherwise } \end{array}\right. } \end{aligned}$$
Definition 13
(Change of port values) Changes to port bindings are denoted by \(w[ ps ]\), where \( ps \) is a set of port-value mappings (\(p \mapsto r\)) such that there is at most one mapping for each p.Footnote 15 We define the value assignment to be the creation of the global state where the bindings for all ports p appearing within \( ps \) are the new values and all ports not specified within \( ps \) remain unchanged.
$$\begin{aligned}&\forall w \in \textit{W}, w = \langle current , bind , pre , t \rangle , \\&\forall \textit{ps} \in \{ f : P ' \rightarrow Resources \mid P ' \subseteq Ports \wedge \\&\quad \big (\forall p \in P', f(p) \in type (p)\big ) \}, \\&w [\textit{ps}] = \langle current , bind ', pre' , t \rangle , \text { where } \\&\forall p \in Ports , {\left\{ \begin{array}{ll} bind '(p) = r \wedge pre '(p) = bind (p) &{}\text {if } \exists p \mapsto r \in ps \\ bind '(p) = bind (p) \wedge pre '(p) = pre (p) &{}\text {otherwise} \end{array}\right. } \end{aligned}$$
Note that the previous port values pre of the ports in ps have to be updated, so that efficient dataflow modeling is possible and value changes can be observed.
A.3.1 Modifiers and precedence
The propagation of state updates within a CREST system requires a correctly ordered execution of updates and state transitions throughout the entire entity hierarchy. Thus, this execution order has to be established and used. The formal semantics use a precedence operator \(\prec \) that defines the according dataflows semantics. The operator expresses a partial order between ports, updates and child entities that arises from the dependencies. In this subsection we look at the formal definitions of these helper functions and operators.
Definition 14
(Port Precedence) The \(\prec \) operator for ports defines a partial order based on the \( dependencies \) function (see Definition 8), and the input-output dependency function \(\textit{io-dependencies}\) (Definition 9). We say that for any two ports \(p_1, p_2 \in Ports \) \(p_1 \prec p_2\) iff one of the following cases applies:
-
1.
there is an update that reads \(p_1\) to calculate the value written to \(p_2\) (i.e. \(p_1\) is a dependency of an update that writes \(p_2\));
-
2.
there is an entity, and \(p_1\) is an input, \(p_2\) is an output and there exists an io-dependency between the two;
-
3.
there exists a port \(p'\) so that \(p_1 \prec p'\) and \(p' \prec p_2\) (i.e. \(p_1 \prec p_2\) by transitivity).
Formally \(\prec \) is expressed as: \(\forall p_1, p_2 \in Ports , p_1 \prec p_2\) iff
$$\begin{aligned}&\exists \langle s, p_2, u \rangle \in Updates , p_1 \in dependencies (u)&~{(Case 1)}\\&\vee p_1 \in \textit{io-dependencies}(p_2)&~{(Case 2)}\\&\vee \exists p' \in Ports , p_1 \prec p' \wedge p' \prec p_2&~{(Case 3)} \end{aligned}$$
Note that \(\prec \) satisfies anti-symmetry to avoid circular dependencies between ports.
Definition 15
(Active-modifiers) An entity’s modifiers are all elements that have the capability of altering an entity’s target ports’ values, i.e. its updates and subentities. To facilitate the subsequent definitions, we define the set of all modifiers to be the union of all entities and updates.
$$\begin{aligned} \textit{Modifiers} = \textit{Entities} \cup \textit{Updates} \end{aligned}$$
Active modifiers are those modifiers that are “active” in a certain system state \(w \in W\). This means all updates that are related to a currently active automaton state, and all subentities. active-modifiers yields all such updates and child entities for an entity.
$$\begin{aligned}&\textit{active-modifiers}: W \times Entities \rightarrow \mathcal {P}(\textit{Modifiers}) \\&\textit{active-modifiers}(\langle \textit{current}, \textit{bind}, \textit{pre}, \textit{time} \rangle , e) = \\&\qquad \{\langle s, p, u \rangle \in Update \mid s = current (e) \} \cup children (e) \end{aligned}$$
modified-ports returns the list of ports that are modified by an entity. This means, it consists of all ports that are the targets of the update functions of the current automaton state or outputs of a subentity.
$$\begin{aligned} \textit{modified}&\textit{-ports}: W \times Entities \rightarrow \textit{Ports} \\ \textit{modified}&\textit{-ports}(\langle \textit{current}, \textit{bind}, \textit{pre}, \textit{time} \rangle , e) = \\&\{ p \mid \exists \langle s, p, u \rangle \in \textit{Updates}, s = current (e) \} \cup \\&\{ p \mid \exists e' \in \textit{children}(e), p \in Ports^O_{e'}\} \end{aligned}$$
Definition 16
(ordered-ports) The function ordered-ports creates a total order of ports that are modified according to their precedence.
$$\begin{aligned} \textit{ordered-ports}&: W \times Entities \rightarrow \textit{PortLists} \\ \textit{ordered-ports}&(w, e): [p_0, p_1, \dots p_n] \text { s. t. } \forall p_i, p_j, i\\&\quad < j, p_i \prec p_j \end{aligned}$$
The list of ports is defined by the PortLists type:
$$\begin{aligned} \textit{PortLists} := \varnothing \mid \langle \textit{Ports}, \textit{PortLists} \rangle \end{aligned}$$
We use the common list notation \([p_0, p_1, p_2]\) instead of \(\langle p_0, \langle p_1, \langle p_2, \varnothing \rangle \rangle \rangle \), where \(i \in \mathbb {N}\) is a port’s list index. The operator “ : ” splits a list’s head (its first element) from its tail (the rest of the list) as follows: \([p_0 : \textit{tail}]\), where \(p_0\) is the first element and \(\textit{tail}\) the rest \([p_1, p_2, \dots , p_n]\).
Definition 17
(ordered-modifiers) Based on the list of modified ports, we create a list of modifiers (updates and subentities) to specify their correct execution order, so that elements are executed only after the ports whose values they depend on are updated. This avoids calculations using wrong or outdated values. The type ModifierLists is used to describe such lists of modifiers. Its signature is given as
$$\begin{aligned} \textit{ModifierLists} := \varnothing \mid \langle \textit{Modifiers}, \textit{ModifierLists} \rangle \end{aligned}$$
The notation \([m_0, m_1, m_2, m_3, m_4]\) and the “head-tail” operator “ : ” are defined for lists of modifiers, similar to the \(\textit{PortLists} \) type above.
ordered-modifiers creates a modifier list so that for each port in ordered-ports there is a modifier that updates it.
$$\begin{aligned}&\textit{ordered-modifiers} : W \times Entities \rightarrow \textit{ModifierLists}\\&\textit{ordered-modifiers}(w, e): [m_0, m_1, \dots m_n, m_{n+1}, \dots , m_{n+k}] \end{aligned}$$
Specifically, for each port \(p_i\), there is a modifier \(m_i\) that alters this \(p_i\)’s value, i.e. \(\forall p_i \in \textit{ordered-ports}(w, e)\)
$$\begin{aligned}&\exists m_i \in \textit{active-modifiers}(w, e) \\&\quad \wedge {\left\{ \begin{array}{ll} m_i = \langle s, p_i, u \rangle \in \textit{Updates} \\ m_i = e' \in \textit{children}(e), p_i \in \textit{Ports}^O_{e'} \end{array}\right. } \end{aligned}$$
All additional modifiers \(m_n, \dots , m_{n+j}\) are appended at the end of the list:
$$\begin{aligned}&\forall m_{n+j} \in \textit{active-modifiers}(w, e), 0 < j \leqslant k,\\&\quad \not \exists p \in \textit{ordered-ports}(w, e), \\&\quad m_{n+j} = \langle s, p, u \rangle \in \textit{Updates} \wedge m_{n+j}\\&\quad = e' \in \textit{children}(e), p \in \textit{Ports}^O_{e'} \end{aligned}$$
Definition 18
(enabled-transitions) The function enabled-transitions finds all transitions from an entity’s currently active automaton state, whose guard functions evaluate to True.
$$\begin{aligned} \textit{enabled}&\textit{-transitions} : W \times Entities \rightarrow \mathcal {P}( Transitions ) \\ \textit{enabled}&\textit{-transitions}(\langle \textit{curr}, \textit{bind}, \textit{pre}, \textit{time} \rangle , e) = \\&\{ \langle s, t, g \rangle \in \textit{Transitions} \mid s, t \in States _e \\&\quad \wedge ~ s = \textit{curr}(e)~ \wedge \\&\tau (g)(\textit{bind}, pre ) \mapsto \mathbf{True} \} \end{aligned}$$
A.4 Formal operational semantics
CREST ’s semantics describe modifications of the global system state (\(w \in W\)) and the propagation of changes from the root to the leaves of the system’s entity tree. Thus, each entity maintains its own state and triggers the update of its direct subentities.
The semantics revolve around the concept of reaching a fixed point (“fixpoint”) after each system modification. In a fixpoint the system is stable and no changes happen unless time passes or external factors modify the system’s inputs.
set-values This fixpoint concept is triggered when modifying the system’s input port values, as shown in Rule 1. The altering of the port value bindings using according to the set \(\textit{vs}\) requires a subsequent application of the stabilise rule on the system’s root. Stabilisation triggers an entity’s updates and automaton transitions until a fixpoint (stable state) is reached. In the process stabilisation also recursively propagates port value modifications to the subentities.
stabilise Rule 2 is called on an entity e that should be stabilised, using a timestep size \(\delta t\). Here, \(\delta t\) is the time that should be advanced in the system. For stabilisation of the system without time advance, (i.e. after the setting of port values), this rule is called with \(\delta t = 0\), to propagate values but not take time into account in update functions.
Specifically, the rule first obtains the ordered list of modifiers and triggers their (ordered) execution in the apply-all rule. Subsequently, transitions executes the automaton transitions.
The above rule uses a set-pre, that, given a state \(w = \langle \textit{curr}, \textit{bind}, \textit{pre}, \textit{time} \rangle \) and an entity e, creates a new state, where the ports’ previous value binding pre is updated. This function is used before triggering modifiers execution, to assert that the modifiers have access to the port’s previous values (i.e. the values before the updates), which is necessary e.g. for incremental increases of port values and resolution of algebraic cycles.
$$\begin{aligned}&\textit{set-pre}\big (\langle \textit{curr}, \textit{bind}, \textit{pre}, \textit{time} \rangle , e\big ) = \langle \textit{curr}, \textit{bind}, \textit{pre}', \textit{time} \rangle \\&~\text {where}~ pre '(p) = {\left\{ \begin{array}{ll} bind (p) &{} ~\text {if}~ p \in targets (e) \\ pre (p) &{} \text {otherwise} \end{array}\right. } \end{aligned}$$
apply-all This rule takes an ordered list of modifiers and executes the first one (\(m_0\)). Subsequently, the rule recurses to execute the rest of the list. When the list is empty (i.e. \(\varnothing \)), Rule 4 serves as a break-condition to the recursion. In this case, no action is taken and w remains unchanged.
apply-one Two apply-one functions execute a modifier (update or subentity) based on its type. If the modifier is an update, update is called to calculate a new port value. Otherwise (if the modifier is a child entity), Rule 6 triggers stabilise to propagate the changed system state to the subentity.
update calculates the update’s target port value based on its function implementation (identified by \(\upsilon (u)\)). The new system state is calculated by taking the old state w and setting update’s target port p to the calculated value.
transitions The \(\texttt {transitions}\) rules are responsible for triggering transitions and deciding whether further stabilisation is required. If enabled transitions exist (Rule 8), one of them is executed (\(w[ e \mapsto t]\)) and the rule recurses on the stabilisation rule. Without enabled transitions, no further action is taken (Rule 9).
Note that CREST does not prescribe a strategy in the event where more than one transition is enabled. Thus, this is the place where non-determinism is possible, e.g. if guard conditions “overlap”.
Time Advance Being a timed formalism, it is necessary to discover at what point the system has to be brought into a coherent state. Specifically, this means that through continuous port value modifications (using updates), a transition might become enabled, requiring subsequent stabilisation. The semantics use four SOS rules to address several possibilities. The first two cover the basic requirements. As the time base \(\mathbb {T}\) is defined for positive sets only, a CREST system cannot “step back in time”.
An advance of \(\delta t = 0\) triggers a stabilisation.
For \(\delta t > 0\), we distinguish two cases. Assuming that, in a given system the next transition (and hence requirement for system stabilisation) becomes enabled at time \(t_{ntt}\) (due to the continuous time advances in update functions), we refer to the duration until that next transition time as \(\textit{ntt}\). Any time advance \(\delta t < \textit{ntt}\) only requires stabilisation at the end of the advance, to update the update ports’ target values. This is implemented in Rule 11.
If \(\delta t\) is bigger than the next transition time \( ntt \), Rule 12 splits the advance into two steps: First, it will \( advance \) with \(\delta t = ntt \) (using Rule 11) and trigger the a stabilisation, including transition firing and activating of the set of updates related to the new current state. Next, CREST recurses on the \( advance \) rule using the remaining time (i.e. \(\delta t - ntt \)). This will trigger either Rule 11 or Rule 12.
Figure 11 depicts these two scenarios graphically.
CREST ’s semantics rely on the availability of \( next\_transition\_time : W \rightarrow \mathbb {T}\). Given a system’s current state w, the function calculates the precise amount of time \(\delta t\) that has to pass until updates enable any transition’s guard condition. It returns \(\infty \) in case time-based advances do not enable any transition.
Note that these semantics do not prescribe an actual implementation of this function. Depending on the available resources, different ways of computing \( next\_transition\_time \) are possible, such as a search approach or complex analysis techniques that include symbolic reasoning. CREST ’s implementation translates the system functions into constraints that are handed to an SMT prover that aims to find a minimum next transition time.