The TASM Language Reference Manual Version 1.1 - Synrc

A sample run with the initial environment ((light, OF F ), (switch, UP )) yields
one update set:
U 1 = ((light, ON))
After the update set is produced and applied to the environment, the machine halts
its execution because it no longer has any enabled rules.
The final state of the environment after the machine run is: ((light, ON), (switch,
UP )).
Formally:
• S 0 = ((light, OF F ), (switch, UP ))
• U 1 = ((light, ON))
• S 1 = S 0 ◦ U 1 = ((light, OF F ), (switch, UP )) ◦ ((light, ON)) = ((light, ON),
(switch, UP ))
2.3 Time
The basic ASM definition does not address time explicitly. A few attempts have been
made to extend the ASM formalism with timing concepts [5, 7, 16]. These attempts
have their merits but they have focused on the verification of ASM behavior without
explicitly addressing how time is to be specified. In these approaches, time is viewed
as just another external dynamic function that can be used in rule guards.
The TASM approach to time specification is to specify the duration of a rule execution.
In the TASM world, this means that each step of a machine will last a finite
amount of time before an update set is produced and atomically applied to global state.
The semantics of rule execution are that of a delay followed by an instantaneous state
update. These semantics are analogous to the principle of durative actions, where an
action takes a finite amount of time to complete before its effects are visible in the environment.
At the specification level, time gets specified for each rule. The specification
of time can take the form of a single value t, or can be specified as an interval [t min ,
t max ]. The lack of a time annotation for a rule is assumed to mean t = 0. The specification
of time using an interval is useful to capture the uncertain nature of specifying
time during the early stages of system design. Furthermore, using interval specification
adequately captures the interval nature of real-time systems to express worst-case and
best-case execution times. For sequential execution, the worst-case execution time is
defined as the longest executing path that code can take. The computation time is affected
by branching decisions and algorithmic concerns. The best-case execution time
is the opposite, that is, the fastest executing path that the code can take.
Formally, the set of rules R in the machine definition becomes:
• R = {(n, t, r) | where n and r are defined in Section 2.2, and t denotes the duration
of the rule execution and can be a single value, an interval, or the keyword
next}
12