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.

15. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 15 Topics (1) Families of specification methods, evaluation criteria Safety and liveness Expressing properties in predicate calculus (logic) Input/output assertions, partial correctness, Hoare logic, invariants Z notations: dom ran and special symbols Z schemas: defining the state, operations Z examples: symb. table, assembler, Unix files, telephone,...

16. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 16 Topics (2) Schema calculus: modularity, hiding,... Refinement in Z: applying mapping functions, data and operation refinement, applicability and correctness State machine: pure graph, traces, using Z for state machines Statecharts: superstates, parallelism, joint transitions, history, micro-steps, activities Lamport’s textual state machines: open versus closed system, critical moment

17. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 17 Topics (3) Allowed changes, parameter passing Temporal logics, linear: [], <>,..., next Anchored version, past operators, classes of properties, fairness Branching time: E, A, F, G, X, CTL Fault tolerance, lossy queue and fairness, alternating bit protocol impl. of queue Process algebras and LOTOS Nondeterminism, gates, actions, Process declaration and instantiation

18. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 18 Topics (4) Parallel comp.: |||, |[ gates ]|, | |, hiding Offering (!) and accepting (?), negotiation Stop, hiding, i, and multiway gates Semantic views: bisimulation equivalence, testing equiv., trace equiv. Algebraic specification and Larch, algebraic axioms, initial/final algebra Generated by, partitioned by, converts Shared versus Interface Languages Real time: TIME, ranges, bound vars. with temp. logic; for statecharts

19. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 19 Three kinds of specifications Data and transition modeling: Z vrs. Larch shared lang.; For individual steps; textual, sequential Control: Statecharts vrs. LOTOS (vrs. Esterelle vrs...) For concurrency, overlap, synchronization Global liveness (and safety too): Temporal logic in some version

20. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 20 Present Use of Formal Specifications Invariants and I/O assertions: added to UML designs, appear as run-time checks, assert statements and checkers (in recent systems, around 10% of Microsoft code) Elements of Z are in OCL (Object Constraint Language) extension of UML Software model checkers Bandera, accepts Java programs annotated with a version of temporal logic SLAM, a Microsoft product for checking temporal logic assertions about driver software Java Pathfinder: NASA tool for model checking Java

21. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 21 Present use (cont.) Feasibility checks for Java applets >No memory segment violations, no illegal operations Legal requirements for formal specification and verification using a tool, in addition to testing >Aircraft control >Railway control in Europe and the US >Software controlling nuclear reactors in Europe Description languages for test data generation Hardware (design) verification using model checking and/or simulation: widely used in Intel, IBM, Motorola

22. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 22 Trends Use formal methods selectively for problem areas Develop tools with clear added value Use for error detection as well as showing correctness Set up environment where methods can be combined (not yet widespread): >VeriTech: project to translate among verification tools and their specification notations >AOSD Formal Methods Lab: apply specification notations and verification tools to Aspect-Oriented Programming

23. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 23 Realistically.... Potential benefits are known. Problems with formal methods have become evident. Modeling and tools have helped on real projects in particular application areas. Software development is in so much trouble, there is new willingness to invest in formal methods.