# Timing Constraints

Timing constraints are based on events. An event is an occurrence of one of the following actions:

- command Command_name, possibly with parameter(s)

- notification Notification_name, possibly with parameter(s)

- signal Signal_name, possibly with parameter(s)

- reply, possibly with parameter(s), e.g., reply(3), or also giving the corresponding command: reply to command Command_name, possibly with parameter(s)

In addition, events can be referred to by their type, without giving a concrete name:

- any command

- any signal

- any notification

- any event

When specifying events of interest, the states in which they may be observed can also be given: in state States event.

Furthermore, an optional condition expression can be specified in which references to interface variables can be used:

in state States event when a > 1, where a is an interface variable

event when b == 2, where b is an interface variable

The optional condition after when can be used only if the time constraint is given in an interface definition (.interface file). When the condition is evaluated, the value of the variables at the time of the event observation are used.

Timing constraints are defined as rules and specify admissible intervals between observed events. There are five types of timing rules:

- ruleName in state States event1 and in state States event2 → interval between events
  specifies that if there are two successive occurrences of event1 and event2 in one of the specified states then the difference of their time stamps is an element of the specified interval. Example:

  req1 in state on command Command and reply(5) → [ 5.0 ms .. 10.6 ms ] between events

- ruleName in state States event1 when expression - interval → in state States event2
  specifies that if event1 occurs in one of the specified states and the value of a is greater than 0 then event2 will occur in one of the specified states and the difference of the time stamps of these two events is an element of the specified interval. Example:

  req2 in state on, off command Level when a > 0 - [ .. 3.6 ms ] → notification Done

- ruleName in state States event1 → absent in state States event2 in interval
  specifies that if event1 occurs in one of the specified states then event2 will not occur in one of the specified states in the specified interval after event1. Example:

  req3 in state on, off command Level → absent notification Done in [ .. 3.6 ms ]

- ruleName in state States event1 then event2 with period realNumber ms jitter realNumber ms until event3
  specifies that if event1 occurs in one of the specified states then event2 will occur periodically with period realNumber and jitter realNumber until event3 occurs. Example:

  req4 in state on command Command then in state operational notification Done with period 750.0 ms jitter 50.0 ms until reply to Command
  Note that this requires that the periodic notifications should occur in state operational.

- group ruleName in state States constraint (one of first three patterns) - interval1 → event1 - interval2 → event2 …​.. end group
  specifies a scenario in terms of a sequence of events. Example:

  group req5

  in state on command Command and notification Done → [ .. 5.2 ms ] between events
  - [ 10.0 ms .. 100.0 ms ] → command Level
  - [ .. 20.0 ms ]→ reply to command Level
  end group

States is a list of states, e.g., "on, off"; the "in state" part is optional.

For an interval there are three possible forms:

- [ 10.1 ms .. 25.7 ms ] specifying a lower bound and an upper bound

- [ .. 25.7 ms ] specifying an upper bound only

- [ 10.1 ms .. ] specifying a lower bound only