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

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

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 9.7.3.4): “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."

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

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

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

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

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 function: @(<event 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.

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;

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

1. i (i-1). INTERVAL ≤ @(RUN_T1, i)  @(SUSPEND_T1, i) ≤ i 1. i (i-1)*INTERVAL ≤ @(RUN_T1, 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 T1 --^- SYNC_WITH_T1 --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

2.  i @(SYNC_WITH_T2, i) = @(SYNC_WITH_T1, 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 T1 --^- SYNC_WITH_T1 --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

3.  i @(ENTER_CS, i+1)  @(EXIT_CS, 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 T1 --^- SYNC_WITH_T1 --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

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) - @(SYNCHRONIZE_WITH_CONTROLLER,i) ≤ 45.0

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

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.

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

Analysis Procedure Want to show SP  SA Alternatively, show that SP  SA is not satisfiable. SA = i @(P,i) ≤ @(S,i+1) SA = i @(P,i) > @(S,i+1) 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)  @(P,i) + C (5) Θ < P SA: (6) @(P,I) > @(S,I+1) To establish that SP  SA is not satisfiable, we need to show that the above inequalities (1) – (6) do not admit a solution.

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) > @(S,I+1) (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 + Θ  @(P,i) (3) @(P,i)  @(P,i) + C (4) @(P,I) > @(S,I+1) (6)

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.