© Katz, 2007 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

© Katz, 2007 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

© Katz, 2007 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.

© Katz, 2007 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 )

© Katz, 2007 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

© Katz, 2007 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)

© Katz, 2007 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?

© Katz, 2007 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

© Katz, 2007 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

© Katz, 2007 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)

© Katz, 2007 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.

© Katz, 2007 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

© Katz, 2007 Formal Specifications of Complex Systems-- Real-time 13 Extended statecharts: 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

© Katz, 2007 Formal Specifications of Complex Systems-- Real-time 14 Some Difficulties Need tolerances Implementations cannot respond instantaneously to requests/changes in environment…need a delta of allowed response One model: Almost as soon as possible, where almost is defined. Need to be careful that we do not restrict the environment (because we can’t control it..), but do restrict the controller or system being developed

© Katz, 2007 Formal Specifications of Complex Systems-- Real-time 15 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.