In this paper we illustrate how the formal specification language Z can be used to reason about the temporal and throughput constraints associated with multimedia flows of information. In particular we show how it is possible to specify issues related to maximum delays, throughputs and jitter of information flows and how control of these flows can be achieved. What makes our work particularly interesting is that we deal with temporal aspects of systems without the use of a temporal logic. Rather, we highlight the versatility of the Z language in modelling systems with real time constraints

Sinnott, R.O.

English

Sinnott, R.

Fraunhofer-ePrints

Specifying Aspects of Multimedia in LOTOS

Enlighten

       Sinnott, R.O. (1999) Specifying multimedia configurations in Z. In: Verma, B. (ed.) Proceedings: Third International Conference on Computational Intelligence and Multimedia Applications: ICCIMA '99, September 23-26, 1999, New Delhi, India. IEEE Computer Society, Los Alamitos, USA, pp. 331-335. ISBN 9780769503004  http://eprints.gla.ac.uk/7239/  Deposited on: 18 September 2009   Enlighten – Research publications by members of the University of Glasgow http://eprints.gla.ac.uk Specifying Multimedia Configurations in ZDr Richard O. SinnottGMD-Fokus,Kaiserin-Augusta-Allee 31,Berlin, Germanysinnott@fokus.gmd.deAbstractIn this paper we illustrate how the formal specification language Z can be used toreason about the temporal and throughput constraints associated with multimedia flows ofinformation. In particular we show how it is possible to specify issues related to maximumdelays, throughputs and jitter of information flows and how control of these flows can beachieved. What makes our work particularly interesting is that we deal with temporalaspects of systems without the use of a temporal logic. Rather, we highlight the versatilityof the Z language in modelling systems with real time constraints.1.  IntroductionThe formal modelling of systems that deal with flows of information place a great manyconstraints on the specification languages chosen for that purpose. Many of theseconstraints arise from the timing aspects associated with the information flow. Mostapproaches to modelling multimedia systems, e.g. [1] typically use a temporal logic [2] toreason about the timing issues of the flows. Whilst temporal logics are well suited toreasoning about timing aspects of systems, they are limited in their modelling of thebehavioural aspects of systems. In this paper we show the power of the Z language inmodelling both of these aspects. To make our approach less abstract we specify a producerand consumer flow. For simplicity, we avoid the issues involved in determining whetherinformation sent from producers is that required by consumers. Instead we focus on thetiming aspects of sending and receiving of informations and how control over these timingaspects can be achieved.2.  Background Concepts for Modelling Information FlowsWe shall consider a generic idea of information flow represented by a sequence of frames(seq Frame) where a frame may be regarded as a particular item in the flow of information.Each frame can be considered as a unit consisting of data (this may be compressed) whichwe represent by Data and a time stamp used for modelling the time at which this particularframe was sent or received. It is often the case in multimedia flows that particular frames arerequired for synchronisation, e.g. synchronisation of audio and video. Therefore we associatea particular Label with each frame which can be used for selecting frames from the flow asrequired. We thus model a frame as: Frame  [ d: Data; ts: R; l: Label ]Information flows have inherent characteristics given by the nature of their flows, e.g.they can be isochronous where frames are sent/received in equal time segments:∀ f1,f2: Frame | < f1,f2 > F frames    f2.ts - f1.ts = constantHere all frames in the flow are separated by equal time intervals (the rate) which is aconstant. Alternatively, flows can be bursty which implies that time intervals betweensuccessive frames are not necessarily equal:∃ f1, f2, f3: Frame | < f1,f2> F frames < f2,f3 > F frames   f2.ts - f1.ts  f3.ts -f2.tsProducer and consumers information flows may be either flowing or stopped which werepresent by the free type: Status ::= Stopped | FlowIn | FlowOutAuthorized licensed use limited to: UNIVERSITY OF GLASGOW. Downloaded on September 18, 2009 at 06:23 from IEEE Xplore.  Restrictions apply. 3. Formalising the State of Producers and ConsumersInterfaces that produce or consume flows are required to access variables modelling time.It is possible to represent time in several ways in Z. Time might be represented by a variableglobal throughout the specification and is accessed and modified each time events (modelledas schemas) that consume time occur. Alternatively, it is possible to model time locally toschemas. We consider here a local model of time where the producers and consumers ofinformation flows have local variables modelling the current local time. The local time isincremented when operations occur, i.e. information items are sent or received. The amountthat the time is incremented by depends on the rate of production or consumption of flows.As we shall see, having a local time model also allows rates of production or consumption offrames to be modified. We may model a producer state by the following Z fragment:Here we state that the producer state is given by a sequence of frames (ps), the currenttime (ptnow), the rate of production of frames (prate), i.e. the time it takes for a producer toproduce a frame, the current status (either stopped or flowing out from the interface), and aset of constraints associated with the producer information flow. We also state that allframes in the sequence of frames to be sent should have increasing time stamps. Here thedots are dependent upon the constraints associated with the multimedia flow and how theyinfluence the flow itself. To allow these predicates to be given, it is necessary to be moreprescriptive regarding the constraints of interest. We consider the maximum delay,maximum throughput and (bounded) jitter associated with the information flow which maybe represented as: ProducerCons  [ pmt, pmd: R; pjb: R x R ]We note here that it is normally the case that Z specifications are written in a definitionbefore use manner. Semantically the ordering is unimportant provided the Z text can beordered in such a way that all Z fragments are defined before they are used. In the schemaProducerCons,  pmt represents the producer's maximum throughput,  pmd the maximumdelay and pjb the upper and lower limits on jitter. The maximum delay for isochronous flowsis simple the rate. The maximum delay for bursty flows is given by:The maximum delay of a multimedia flow may be regarded as the upper limit on the timewindow at which a frame is expected, e.g. a consumer may be able to wait for a certain timefor the next frame to arrive. For bursty flows, the maximum delay is the maximum timedifference between two successive frames in the sequence.The maximum throughput may be regarded as the number of frames a producer of a flowwishes to produce, or that a consumer wishes to consume. Isochronous flows should have aconsistent throughput (given by the reciprocal of the rate), whereas bursty flows may havesituations where more frames are output (or input) than at other times. In bursty flows it isespecially useful to put an upper limit on the maximum throughput of data. The maximumthroughput of a bursty flow is the maximum flow subsequence with a timestamp differenceof less than or equal to one second from its first and last elements (assuming the throughputwas measured over one second). Thus throughput may be represented as:We shall see that the values for maximum delays and throughputs can be assigned non-deterministically. With this, a more complete model of the producer's state is given by:PStateps: seq Frameptnow, prate: Rpstat: StatuspCons: ProducerCons ∀ f1,f2: Frame | < f1,f2> in ps  f2.ts > f1.ts  pstat F { Stopped, FlowOut }  ...maxDelay: seq Frames qloR∀sf: seq Frames  maxDelay(sf) = max{ f1,f2: Frame | < f1,f2> F sf  f2.ts-f1.ts } maxThru: seq Frames qlo R∀sf: seq Frames  maxThru(sf) =     max{ s: seq Frames; f1,f2: Frame | s in sf  f1 = head sf  f2 = last sf  1 P  f2.ts - f1.ts  # s }Authorized licensed use limited to: UNIVERSITY OF GLASGOW. Downloaded on September 18, 2009 at 06:23 from IEEE Xplore.  Restrictions apply. ∀ f1,f2: Frame | < f1,f2> in ps  f2.ts - f1.ts < pCons.pmd  1 div prate < pCons.pmtHere we state that all consecutive frames in the sequence should have time differencesless than the maximum allowed delay. We also state that the rate (prate) of production offrames must be less than some upper throughput limit. For simplicity we assume thatthroughput is measured over a single time unit. We note here that whilst these constraintscan be asserted directly and used to influence the production of frames, it is not possible towrite explicit predicates on the jitter. The jitter depends on the actual sending and receivingof frames. To model jitter we assume a similar model of state for a consumer as that for aproducer, i.e.with a sequence of frames to be expected (cs), a current time (ctnow), a currentstatus (cstat) which is either consuming or stopped, a rate of consumption (crate) and a setof constraints which we assume are on delays (cmd), throughputs (cmt) and jitter (cjb).We may represent the constraints that might be associated with a producer or consumergenerally by a parameterised free type definition. This can be represented as:Constraints ::= prodBindCons <<ProducerCons >> | consBindCons<<ConsumerCons >>We represent the satisfaction of constraints associated with producers and consumers as:For brevity we omit the associated predicates. Satisfaction of throughput and delayconstraints require that the maximum delay of a producer is less than the maximum delay aconsumer can tolerate and that the consumer can accept a higher throughput than theproducer can produce. Satisfaction of jitter constraints requires the producer allowed jitter iswithin the consumer jitter range.Producer and consumer initialisation may be represented as:This states that there exist producer and consumer constraints such that: the values theproducer and consumer constraints are set at, are satisfactory to the consumer and producerrespectively; the values  the producer's constraints are set at are satisfactory to the producerand the values the consumer constraints are set at, are satisfactory to the consumer.These constraints (if they exist) are assigned to the producer and consumer constraints.The producer is also instantiated with a non-empty sequence of frames to send and theconsumer initially has received no frames. The producer and consumer local times aresynchronised and both have the current status Stopped. Finally we state that the producerand consumer rates are set to values of the reciprocal of the maximum throughputs.4 Formalising Interfaces for Controlling Information FlowsAs well as having interfaces for producing and consuming information flows, producersand consumers of information flows are likely to have operations for manipulating theseinformation flows. We term these control interfaces. It is likely that these interfaces willfollow an RPC-like mode of interaction, where messages are sent and responses are given tothese messages. For simplicity here, we assume a basic set of messages that are passedbetween producers and consumers. These may be represented by the free type definition:Message ::= ExceedsMax | AlreadyStopped | AlreadyStarted | NotStarted | ArrivedEarly | ArrivedLate | OkThe most elementary operations are starting and stopping flows. A flow being started canbe represented by: ProdStartFlow = ProdStartFlowOk ProdStartNotOk where:PCInitPstate’CState’∃ pc: ProducerCons; cc: ConsumerCons; ss: seq Frames | ss  <> (consBindCons(cc),prodBindCons(pc)) F Satisfies  (prodBindCons(pc),prodBindCons(pCons))F Satisfies  (consBindCons(cc),consBindCons(cCons)) F Satisfies pCons’ = pc  cCons’ = cc  ps’ = ss  cs’ = <>  ptnow’ = ctnow’ pstat’ = cstat’ = Stopped  prate’ = 1 div pc.pmt  crate’ = 1 div cc.cmtSatisfies: Constraints I Constraintspstat = FlowOut res! = Already StartedProdStartFlowNotOkΞ PStateres!: Messagepstat = Stopped  ps‘ = ps  ptnow‘= ptnow pstat‘ = ptnow  prate‘ = prate  pCons‘ = pCons  res! = OkProdStartFlowOk∆PStateres!: MessageAuthorized licensed use limited to: UNIVERSITY OF GLASGOW. Downloaded on September 18, 2009 at 06:23 from IEEE Xplore.  Restrictions apply. The preconditions for ProdStartFlowOk require that the flow is currently stopped. Thepostconditions state that the status of the producer is changed to FlowOut. All othervariables associated with the producer state are unchanged. It might well be the case that theoccurrence of this operation schema might take a non-negligible time. In this case, the localvariable modelling time should be incremented by some amount. We assume that theoperation takes zero time and that time is only incremented on the sending of frames.ProdStartFlowNOk shows the failure case when the producer is already producing the flow.For brevity we do not provide the operations for stopping a flow which are similar to thestarting of a flow with the obvious changes to the predicates. For similar reasons we also donot provide the operations for starting or stopping a consumer flow which are similar to theoperations given for starting and stopping producer flows.The rate of production of information flows may be increased or decreased depending onconsumer demands. A successful operation to increase the producer flow rate is:This operation requires that the producer is currently outputting information and the newrate, i.e. the time to produce frames, is less than the existing one but within the throughputlimits. The postconditions state that the status, current time, sequence of frames andconstraints are unchanged. An output message is sent stating the operation was successful.We consider two cases in which this operation might fail: if the requested rate wouldresult in the maximum throughput constraints being exceeded or if a request to producefaster occurs when the producer has not yet been started. These may be represented as:The total operation showing how the producer flow can have its rate increased is:ProdFaster  ProdFasterOk ProdFasterExceedsMax ProdFasterNotStartedWe omit the operations showing how the information flow rates can be reduced. Theseare similar to those given for the increase in production but with the obvious predicatechanges,  e.g. checking that the rate does not become zero or negative. For reasons of brevitywe also do not provide the operations for increasing or decreasing the consumerconsumption rate. These are similar to the operations given for changing the producer flowrate but with the predicates modified accordingly.5.  Formalising the Production and Consumption of FlowsThe production of frames requires that the frames are time stamped with the local timewhen they are to be sent. The sending of a frame from a producer may be represented as:Several things should be pointed out here. Firstly, we require that the producer hasframes to send. The producer should currently have the producing frames status. Sending aframe removes that frame from the sequence of frames to be sent. The current rate andconstraints associated with the flow are unchanged. The actual time at which the frame wassent is given by the current time plus the current rate and a value within the jitter bounds.pstat = FlowOut = pstat‘  nr? < prate  pCons.pmt >= 1 div nr? ps‘ = ps  ptnow‘= ptnow  prate‘ = nr?  pCons‘ = pCons  res! = OkProdFasterOk ∆PStatenr?: Rres!: Messageps‘  <>  pstat = FlowOut = pstat‘  ps‘ = tail ps  prate‘ = prate  pCons‘ = pCons     ( ∃ t: R | (ptnow + prate + second(pCons.pjb) P t P (ptnow+prate - first(pCons.pjb))  prate‘ = t                (let nf == ( µ Frame | d = (head ps).d  ts = t  l = (head ps).l)  f! = nf))PSendFrame ∆PState f!: Framepstat = Stopped   res! = NotStartedProdFasterNotStartedΞ PStatenr?: Rres!: MessagepCons.pmt P 1 div nr?  res! = ExceedsMaxProdFasterExceedsMaxΞ PStatenr?: Rres!: MessageAuthorized licensed use limited to: UNIVERSITY OF GLASGOW. Downloaded on September 18, 2009 at 06:23 from IEEE Xplore.  Restrictions apply. The actual frame sent is the head frame in the sequence of frames to be sent. This is timestamped with the value for the time calculated previously. We note that the use of thedefinite description requires that a proof obligation is fulfilled to ensure the frame sent isunique. This is satisfied through modelling all frames in the sequence with increasing (i.e.non-equal) time stamps. We also require that the sequence of frames is non-empty.A consumer may receive a frame successfully provided the constraints are satisfied.The preconditions for this operation are that the consumer can currently receive frames,i.e. its status is FlowIn. The operation itself does not affect the rate of consumption, thecurrent status or consumption constraints. The frame is only accepted provided the timestamp is within the allowed jitter range associated with the consumer constraints. If the timeconstraints are satisfied then the frame is accepted and added to the sequence of framesreceived and the current time is incremented by whatever value the rate is currently set at.We consider two situations in which a frame may be rejected by a consumer. When theframe arrives outside the time constraints, e.g. too early or too late, or when the consumer isnot yet ready to start consuming frames. These can be represented as:The actual sending of a frame from a producer to a consumer may be represented as:ProdSendToCon  PSendFrame   (CGetFrameOk[f!/f?]                                   CGetFrameTimeNOk[f!/f?]CGetFrameNotStarted[f!/f?])6. ConclusionsThis paper has shown the flexibility of the Z language for modelling multimedia flows ofinformation and how these flows can be controlled. We have focused here on showing howdelays, throughputs and jitter can be specified and controlled directly. Extensions to thework are also possible, e.g. modelling the information (Data) in more detail and abstractrepresentations of the required compression/decompression techniques required to access thedata. The work could also be extended to model other forms of jitter, e.g. bounded jitter.Similarly extensions such as the synchronisation of clocks that have drifted apart, modellingunreliable media and latency related issues can be modelled directly [3].7.  References[1] G.Blair, L. Blair, H. Bowman and A. Chetwynd. Formal Support for the Specification and Construction ofDistributed Multimedia Systems (the TEMPO project), TR-MPG-93-23, University of Lancaster, 1993.[2] Z. Manna, A. Pneuli. The Temporal Logic of Reactive and Concurrent Systems, Springer-Verlag, 1992.[3] R.O. Sinnott. An Architecture Based Approach to Specifying Distributed Systems in LOTOS and Z. PhDThesis, University of Stirling 1997. cstat‘ = FlowIn = cstat  crate‘ = crate  cCons‘ = cCons  ctnow‘ = ctnow + crate  ctnow + second(cCons.cjb) P  f?.ts  P  ctnow - first (cCons.cjb)  cs‘ = <f?>IcsCGetFrameOk ∆CStatef?: Frame( f?.ts P (ctnow + second(cCons.cjb))  res! = ArrivedLate ) ((ctnow - first(cCons.cjb) P f?.ts)  res! = ArrivedEarly )CGetFrameTimeNOkΞCStatef?: Frameres!: MessageCGetFrameNotStartedcstat = Stopped   res! = NotStartedΞ CStatef?: Frameres!: MessageAuthorized licensed use limited to: UNIVERSITY OF GLASGOW. Downloaded on September 18, 2009 at 06:23 from IEEE Xplore.  Restrictions apply. 

Specifying multimedia configurations in Z

©1999 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.ISBN 9780769503004In this paper we illustrate how the formal specification language Z can be used to reason about the temporal and throughput constraints associated with multimedia flows of information. In particular we show how it is possible to specify issues related to maximum delays, throughputs and jitter of information flows and how control of these flows can be achieved. What makes out work particularly interesting is that we deal with temporal aspects of systems without the use of a temporal logic. Rather, we highlight the versatility of the Z language in modelling systems with real time constraints.September 23-2

Sinnott, Richard O.

University of Melbourne Institutional Repository

Enlighten: Publications

©1999 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.ISBN 9780769503004The formal specification language LOTOS provides a model of systems where the temporal ordering of actions is specified. LOTOS typically does not deal with the specific times at when actions can occur. Most approaches for specifying real time systems in LOTOS have either extended the language, e.g. with timing aspects, or used the language in conjunction with a temporal logic. We argue that such approaches are not always necessary and that LOTOS is much more flexible than sometimes claimed. To support our arguments we show how LOTOS can be used to specify a multitude of timing issues that can be associated with the production and consumption of multimedia flows.September 23-2

SINNOTT, RICHARD

Specifying aspects of multimedia in LOTOS

Specifying Multimedia Configurations in Z

The formal specification language LOTOS provides a model of systems where the temporal ordering of actions is specified. LOTOS typically does not deal with the specific times at when actions can occur. Most approaches for specifying real time systems in LOTOS have either extended the language, e.g. with timing aspects, or used the language in conjunction with a temporal logic. We argue that such approaches are not always necessary and that LOTOS is much more flexible than sometimes claimed. To support our arguments we show how LOTOS can be used to specify a multitude of timing issues that can be associated with the production and consumption of multimedia flows

A Calculus of Communicating Systems,

A Formal Technique Based on the Temporal Ordering of Observational Behaviour,

An Architecture Based Approach to Specifying Distributed Systems with LOTOS and Z, Ph.D Thesis,

Communicating Sequential Processes,

The Formal Specification and Verification of Distributed Multimedia Systems, Ph.D Thesis,

Crossref

http://minerva-access.unimelb.edu.au/bitstream/11343/28807/1/264071_sinnott_specifying.pdf

Specifying multimedia configurations in Z

Abstract

Similar works

Full text

Available Versions

Fraunhofer-ePrints

Enlighten

University of Melbourne Institutional Repository

Enlighten: Publications

University of Melbourne Institutional Repository

Fraunhofer-ePrints

Enlighten

Enlighten: Publications

Crossref