1. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 1 Adding Real-time to Formal Specifications Formal Specifications of Complex Systems Shmuel Katz The Technion L e c t u r e n u m b e r L e c t u r e ti tl e B o t h o n m a s t e r

2. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 2 What is real-time? Specifying restrictions on the time needed/ required for operations, time between operations, global elapsed time for sequences of operations,.... Used in connecting software to a physical environment Essential in control systems, avionics, human-computer interfaces

3. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 3 Liveness and real time Liveness properties, such as eventualities in temporal logic, can be seen as an abstraction for lower level real-time requirements, before we have any timing information. [] ( p => <> q ) “q is true within 5 seconds of p” Real-time can be used INSTEAD of liveness requirements to guarantee progress.

4. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 4 Temporal Logic: Explicit Time Add a built-in TIME variable, STARTa constant for each time an operation a is started, and use constants UPPERa and LOWERa: []( in(s) => (TIME - STARTs  UPPERs ) ) []( after(s) => (TIME > STARTs + LOWERs) ) [] (at(s) => TIME  STARTs )

5. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 5 Liveness and realtime (cont.) The real-time properties are safety, not liveness! The liveness is “hidden” in the properties of the TIME variable itself. It must monotonically increase. Is that enough? Zeno, rabbits and tortoises

6. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 6 The non-Zeno Property For any constant r, <> ( TIME > r ) This plus safety properties given earlier, allow proving liveness properties in(s) => <> ~ in(s) Use []( in(s) => TIME  STARTs+UPPERs)

7. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 7 Checking internal consistency Example: a module s made of sequential composition of a and b Assume have UPPER and LOWER for each Must have: LOWERa + LOWERb  UPPERs UPPERa + UPPERb  LOWERs What if a and b are in parallel?

8. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 8 Temporal logic: adding bounds “Liveness” operators have added upper and/or lower time bounds: [] ( P => <> [1, 5] Q ) in(CS0) Until [3,7] ~in(CS0) Can use with CTL, linear, and still do model checking Gives most common real-time reqs., can reveal inconsistent bounds, hidden links

9. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 9 Temporal logic: adding dummy vars. [], <> and O can have bound variables added, that “remember” the time for future comparison. (called “freeze” variables) <>s. x > y /\ s < 6 [] t. ( req => <> s. answer /\ 1< s - t < 10) Non-Zeno becomes: for all r. <>t. ( t > r ) Better for model checking than using TIME

10. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 10 Tick Real-time => interleaving step should not mean time has necessarily advanced. Need to “calibrate” clocks “tick” a special action that advances time. All other actions do not advance time.... A tick could change the time by a full unit, or just advance it by some positive amount (but non-Zeno must still hold)

11. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 11 Restrictions on tick Unit tick: []t. Os. ((tick => s = t + 1) /\ (~tick)=> s=t) At most one non-tick step per processor between tick steps.... Calibrate: 10 steps in P1, but 1 in P2 between ticks. Continuous clock: still has non-Zeno, can calibrate with inequalities.

12. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 12 Real-time in Statecharts Already there: timeout, forcing transitions “3<“ at least 3 time units in the state “ 5>“ at most 5 time units in the state Transitions take 0 time, delay before or after Real-time is used to guarantee progress

13. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 13 Adding bounds on transitions [lower, upper] for time to do the transition Are we always “in a state”? >If not, makes complex consistency condition, but may be more realistic >If yes, wait in state until transition is made in 0 time Can reveal “hidden” timing relations (timing in one process affects timing in others because of sync., conditions,...) Also done for pure state machines

14. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 14 Summary Many ways to do it Becoming common, but still non-standard Can reveal hidden real-time links Problem in refinement: how to verify before lowest level is reached. Most useful for synchronous parallelism.