1. Specification and Validation of Real-Time Programs ©A. Mok 2009
CS 386C
Specification and Validation of
Real-Time Programs
©A. Mok 2009

2. Motivation: importance of timing behavior assumptions
A system of timing behavior annotation
An analysis example
Review

3. Example Timing Hazard ROBOT_CONTROLLER. Select
ROBOT_CONTROLLER.SYNCHRONIZE; or
delay 45.0;
STOP_ROBOT_ARM; -- controller not responding, stop the robot.
end select;
Semantics of the timed entry call:
Ada’83 Language Reference Manual (section ): “If a rendezvous can be started within the specified duration (or immediately, as for a conditional entry call, for a negative or zero delay), it is performed and the optional sequence of statements after the entry call is then executed. Otherwise, the entry call is cancelled when the specified duration has expired and the optional sequence of statements of the delay alternative is executed."

4. Issues Raised
Are there any other surprises in Ada real-time semantics?
Need for precise and expressive semantics.
Need for analysis tools.

5. Timing Behavior Analysis
Suppose we want to write an analysis tool to deduce the timing behavior of the following program:
task body T1 is
declare
use CALENDAR;
NEXT_TIME : TIME := CLOCK+INTERVAL;
begin
loop
delay NEXT_TIME-CLOCK;
T2.SYNCHRONIZE; --synchronize with task T2
CRITICAL_SECTION(); --execute a critical section
NEXT_TIME := NEXT_TIME+INTERVAL;
end loop;
end;
end T1

6. Ada’83 Semantics The intended behavior:
Schedule T1 exactly once every INTERVAL time units.
Ada semantics permits:
T1 to be scheduled far less often.
T1 to be scheduled twice or more in less than INTERVAL time units.
The delay construct in Ada does not lend itself to specifying stringent timing constraints which involve upper bounds on task suspension.
task body T1 is
declare
use CALENDAR;
NEXT_TIME : TIME := CLOCK+INTERVAL;
begin
loop
delay NEXT_TIME-CLOCK;
T2.SYNCHRONIZE;
CRITICAL_SECTION();
NEXT_TIME := NEXT_TIME+INTERVAL;
end loop;
end;
end T1

7. A Uniform System for Timing Behavior Annotation
Idea:
Introduce a language to express timing behavior
Superimpose this language over Ada program
Validation should include facility for interpretation of intended timing behavior
How:
Use a system of annotations which has two parts:
Event marker definitions
Timing behavior specification

8. Syntax
Event markers are stylized comments that are placed strategically in the program text.
There are two flavors:
<Statement 1> <Statement 1>
--v- <event name> ^- <event name>
<Statement 2> <Statement 2>
A event marker can be thought of as a time-keeper of computational activity.
A timing behavior specification is a set of assertions that relate the time of occurrences of different events to one another. Assertions are RTL (Real Time Logic) formulas.
The occurrence name>,<index>) can be thought of as the master time-keeper who can interrogate an event marker for the time at which some instance (specified by the <index> argument) of the event occurs.

9. Annotated Program Text
task body T1 is
declare
use CALENDAR;
--NEXT_TIME :
TIME := CLOCK+INTERVAL;
--v- RUN_T1
begin
--delay NEXT_TIME-CLOCK;
T2.SYNCHRONIZE;
--synchronize with task T2
--^- SYNC_WITH_T2
CRITICAL_SECTION();
--execute a critical section
--NEXT_TIME := NEXT_TIME+INTERVAL;
end;
--^- SUSPEND_T1
end T1
task body T2 is
begin
--statements of T2 before synchronization
accept SYNCHRONIZE;
--synchronize with task T1
--^- SYNC_WITH_T1
--statements of T2 after synchronization
end T2;
procedure CRITICAL_SECTION() is
--v- ENTER_CS
--body of critical section
--^- EXIT_CS
end CRITICAL_SECTION;

10. Timing Behavior Specification
1. Periodic task execution
 i (i-1)*INTERVAL i)  @(SUSPEND_T1, i) ≤ i*INTERVAL
2. Synchronization by rendezvous
 i @(SYNC_WITH_T2, i) i)
3. Critical section constraint
 @(ENTER_CS, i+1) i)

11. 1. i (i-1). INTERVAL ≤ @(RUN_T1, i)  @(SUSPEND_T1, i) ≤ i
1. i (i-1)*INTERVAL i)  @(SUSPEND_T1, i) ≤ i*INTERVAL This assertion states that the ith time at which the task T1 is run must be after the ith period has started, and T1 must be suspended, having completed its execution before the end of the ith period.
task body T2 is begin statements of T2 before synchronization accept SYNCHRONIZE; synchronize with task T ^- SYNC_WITH_T statements of T2 after synchronization end T2; procedure CRITICAL_SECTION() is begin v- ENTER_CS body of critical section ^- EXIT_CS end CRITICAL_SECTION;
task body T1 is
declare
use CALENDAR;
--NEXT_TIME :
TIME := CLOCK+INTERVAL;
--v- RUN_T1
begin
--delay NEXT_TIME-CLOCK;
T2.SYNCHRONIZE;
--synchronize with task T2
--^- SYNC_WITH_T2
CRITICAL_SECTION();
--execute a critical section
--NEXT_TIME := NEXT_TIME+INTERVAL;
end;
--^- SUSPEND_T1
end T1

12. 2.  i @(SYNC_WITH_T2, i) i) This assertion states that the ith time the task T1 completes the issue of an entry call to T2 must be at the same time at which T2 completes the acceptance of the same entry call.
task body T2 is begin statements of T2 before synchronization accept SYNCHRONIZE; synchronize with task T ^- SYNC_WITH_T statements of T2 after synchronization end T2; procedure CRITICAL_SECTION() is begin v- ENTER_CS body of critical section ^- EXIT_CS end CRITICAL_SECTION;
task body T1 is
declare
use CALENDAR;
--NEXT_TIME :
TIME := CLOCK+INTERVAL;
--v- RUN_T1
begin
--delay NEXT_TIME-CLOCK;
T2.SYNCHRONIZE;
--synchronize with task T2
--^- SYNC_WITH_T2
CRITICAL_SECTION();
--execute a critical section
--NEXT_TIME := NEXT_TIME+INTERVAL;
end;
--^- SUSPEND_T1
end T1

13. 3.  i @(ENTER_CS, i+1) i) This assertion states that the i+1th time the critical section is entered by some task must not occur before the ith time the critical section is exited by some task.
task body T2 is begin statements of T2 before synchronization accept SYNCHRONIZE; synchronize with task T ^- SYNC_WITH_T statements of T2 after synchronization end T2; procedure CRITICAL_SECTION() is begin v- ENTER_CS body of critical section ^- EXIT_CS end CRITICAL_SECTION;
task body T1 is
declare
use CALENDAR;
--NEXT_TIME :
TIME := CLOCK+INTERVAL;
--v- RUN_T1
begin
--delay NEXT_TIME-CLOCK;
T2.SYNCHRONIZE;
--synchronize with task T2
--^- SYNC_WITH_T2
CRITICAL_SECTION();
--execute a critical section
--NEXT_TIME := NEXT_TIME+INTERVAL;
end;
--^- SUSPEND_T1
end T1

14. Uses of the Annotations
As obligations on correct implementations
As definitions of exceptions
As suggested restrictions on the execution of nondeterministic constructs, e.g., the select command
Timing Hazard Example Revisited
select
--v- SYNCHRONIZE_WITH_CONTROLLER
ROBOT_CONTROLLER.SYNCHRONIZE;
--^- SYNCHRONIZATION_COMPLETED or
delay 45.0;
STOP_ROBOT_ARM; -- controller not responding, stop the robot.
end select;
Raise an exception when the following assertion is violated.
 i @(SYNCHRONIZATION_COMPLETED,i) ≤ 45.0

15. Verification of Safety Assertions
Steps
Systems Specification
Safety Assertions
Application of Analysis Procedure
Three possible outcomes:
1) Safety Assertion is a theorem derivable from the systems specification
2) Assertion is unsatisfiable with respect to the systems specification
3) Negation of the safety assertion is satisfiable under certain conditions

16. An Analysis Example Sam puts a message in memory every P time units.
Paul removes a message from memory and processes it every P time units.
Paul takes C time units to process each message.
Paul's clock is Θ time units behind. (Θ < P)
Paul must remove a message from memory before Sam puts another one in.

17. RTL Specification of Analysis Example
Specification (SP)
Sam:  i1 @(S,i) = (i-1)*P
Paul:
  (i-1)*P+ Θ  @(P,i)≤ i*P+Θ 
Paul's clock skew: Θ < P
Safety Assertion (SA)
 P,i)

18. Analysis Procedure Want to show SP  SA
Alternatively, show that SP  SA is not satisfiable.
SA = i @(P,i)
SA = i @(P,i)
Remove quantifiers and skolemize:
SP: (1) @(S,i) = (i-1)*P
(2) @(P,i)  (i-1)*P + Θ
(3) @(P,i) ≤ i *P + Θ
(4) @(P,i) + C
(5) Θ < P
SA: (6) @(P,I)
To establish that SP  SA is not satisfiable, we need to show that the above inequalities (1) – (6) do not admit a solution.

19. Deriving a Satisfiability Condition
3) Chaining:
@(S,I+1) = I * P (1)
I *P +Θ  @(P,I) (3)
@(P,I)  @(P,I) + C (4)
@(P,I) (6)
A solution requires Θ > C
If Θ ≤ C, then the safety assertion must be valid.
1) Focussing:
@(S,i) = (i-1) * P (1)
@(P,i) ≤ i * P + Θ (3)
@(P,i)  @(P,i) + C (4)
@(P,I) > @(S,I+1) (6)
2) Rewriting:
@(S,i+1) = i * P (1)
i * P + Θ (3)
@(P,i) + C (4)
@(P,I) (6)

20. Review
To ensure safety/reliability, timing behavior must be deducible.
We can use a system of annotation that has a sound basis (based on a formal logic). Our language can be superimposed on block-structured languages and avoids implementation-defined pragmas.
Analysis and synthesis tools can take advantage of the annotations.