tele

Design of Reactive SystemsSummer 2001

Prof. Dr. Stefan LeueInstitute for Computer Science

Albert-Ludwigs-Universität Freiburg

leue@uni-freiburg.de

Copyright © Stefan Leue 2001

tele Design of Reactive Systems / Summer 2002 V - 2 © Stefan Leue 2002

Temporal Logic based Requirement Specification

Part 5a

tele Design of Reactive Systems / Summer 2002 V - 3 © Stefan Leue 2002

Properties Property

A system execution (computation) will be modeled as a sequence of states or events 0 = <g, a, z, g, ...> 1 = <g, a, d, g, ...>

A system property is represented by a set of computations = {0, 1, ...}

Definition a program P has the property if all its computations are in .

Property Representation normally too cumbersome to enumerate all infinite computations,

therefore use of mathematical formalisms– state machines

property corresponds to accepted language -regular expressions– temporal logic

tele Design of Reactive Systems / Summer 2002 V - 4 © Stefan Leue 2002

Safety and Liveness Classification of Properties

safety: something bad will never happen– example: it is never the case that more than one process is in the

critical section (mutual exclusion)– invariant violation

liveness: something good will eventually happen– example: any process attempting to get access to the critical

section will eventually be granted access

tele Design of Reactive Systems / Summer 2002 V - 5 © Stefan Leue 2002

Safety and Liveness Notation

: finite set of states +: set of all non-empty, finite sequences of states from : set of all non-empty, infinite sequences of states from

Finitary and infinitary properties We call + a finitary property, and a finitary or partial

computation We call an infinitary property, and an infinitary

computation

tele Design of Reactive Systems / Summer 2002 V - 6 © Stefan Leue 2002

Safety and Liveness Prefixes

tele Design of Reactive Systems / Summer 2002 V - 7 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 8 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 9 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 10 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 11 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 12 © Stefan Leue 2002

Safety and Liveness Why the safety/liveness classification?

Intuitively– checking safety property: simple exploration of all states– checking livenes property: exploration of all states, checking in

every state whether any continuation of the prefix will satisfy property

Consequence– more search effort for liveness properties– therefore more expensive to verify

tele Design of Reactive Systems / Summer 2002 V - 13 © Stefan Leue 2002

Safety and Liveness Example

if the system is in a state in which a message has been sent, then it will eventually reach a state in which a message has been received

tele Design of Reactive Systems / Summer 2002 V - 14 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 15 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 16 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 17 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 18 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 19 © Stefan Leue 2002

Safety and Liveness

tele Design of Reactive Systems / Summer 2002 V - 20 © Stefan Leue 2002

Safety and Liveness Other Classifications

topological– safety: closed sets– liveness: dense sets

temporal logic (more later) automata theoretic

tele Design of Reactive Systems / Summer 2002 V - 21 © Stefan Leue 2002

Safety and Liveness Examples

Safety– partial correctness

program doesn't produce wrong results and does not enter an unwanted state

– mutual exclusion never two processes in critical section at the same time

– absence of deadlock the program never reaches a deadlock state

Liveness– termination

the programme will eventually reach a final state– progress

the programme will eventually receive the requested service

tele Design of Reactive Systems / Summer 2002 V - 22 © Stefan Leue 2002

References [Hughes and Cresswell] G. Huges and M. Cresswell, An

Introduction to Modal Logic, Methuen, 1968 [Huth and Ryan] M. Huth and M. Ryan, Logic in

Computer Science - Modelling and reasoning about systems, Cambridge University Press, 2000

[Manna and Pnueli 92] Z. Manna and A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems - Specifications, Springer Verlag, 1992

[Schwarz and Melliar-Smith] R. Schwarz and M. Melliar-Smith, From State Machines to Temporal Logic: Specification Methods for Protocol Standards, IEEE Transactions on Communications, 30(12), S. 2486 - 2496, Dezember 1982.