1. Applying SDL for Real-Time Systems Development: A Lip- Synchronisation Case Study Dr Richard Sinnott EPK Ericsson

2. Overview of Presentation Intention of presentation to address issues in SDL usage for general modelling vs validation –not all (small sized) models can be validated! Outline of Lip-Synchronisation system –outline of algorithm –outline of modelling approaches for Producer/Consumer sides Conclusions on SDL usage

3. Lip-Synchronisation Model Two producers wanting to send audio flow and video flow respectively to consumer –strict timing requirements for individual flows within some jitter bounds –strict timing requirements between flows avoid flows drifting apart –rates of production/consumption can vary allow faster/slower rates of production/consumption

4. Basic Timestamping Modelling Approach For Producer Side Producers use timestamping of frames with timestamps based on expiry of local timers –local timers set at controllable rates (durations) –rate of production dependent on rate variable sendFaster/sendSlower -> lower/higher value for rate results in higher/lower productivity producer can also ask consumer to consume faster/ slower, e.g. if producer has too many/not enough buffered frames to send

5. Producer Timestamping Approach Change rate (r) = change sending freq. Frames to send(fs) value below/above some limit = consume slower/faster resp. set(tnow+r,t1) wait t1 FrameSend( (. first(fs)!d,tnow+r.) ) tnow:=tnow+r fs:= substring(fs,2,length(fs)-1) length(fs)>0 tnow:= NOW startFlow ready False = stop flow True tnow + r = NOW

6. Basic Timestamp Approach For Consumer Side Consumer receives two streams of arriving timestamped frames –Ensure both streams satisfy individual timing constraints ensure timestamps of arriving frames within consumption rate +/- jitter for individual flows –Ensure both streams satisfy joint time constraints ensuring timestamps arriving frames within bounds compared to timestamped frames of other flows

7. Consumer Timestamping Approach f!d FrameSend(f) wait similar for video case checks if audio/video frame (f!d) checks value of frame timestamp (f!ts) with last video/audio timestamp, if ok compares with own local clock (act) and rate consumption (ar) +/-jitter (aj) if ok, add to buffered frames, else increment no. early/late (ae/al) frames, add copy of data to buffered frames if ae/al exceed maximum value, set producer clock with appropriate offset call checkAudioSynchronisation(f) df!d := last(afs)!d; df!l := f!l; df!ts := f!ts; afs := afs // MkString(df) act := act + ar - f!ts < act + ar - aj f!ts > act + ar + aj al := al +1 al > maxLateAudio OR ae > maxEarlyAudio setClock(aId, act + ar - f!ts) ae := 0, al:= 0 ae:= 0, al:=0, afs := afs // MkString(f) ae:= ae +1 True False True False True ‘audio’ Check timestamp of this frame vs time stamp of last video frame (or expected next video frame if buffered audio = buffered video) If False then increment error count: if error count > max then resetClocks Frame time OK Check early Check late lab

8. Problems Validating Using Timestamp Approach Consider same approach using INTERVAL time extensions Problem of accessing/reading time –now does not explicitly change in FrameSend so consumer cannot check if early/late actually value 0 sent but when try to access this causes “value out of range condition” –hence consumer cannot check timing information, e.g. frame early, late etc if try to send value of ac1 would result in non-validatable system –due to current techniques for clock constraint representation (polyhedra) during validation wait FrameSend( (. first(fs)!d,now.) ) fs:= substring(fs,2,length(fs)-1) startFlow ready #addclock(ac1) true #postpone(ac1>=9, ac1<=11) wait length(fs)>0False = stop flow True resetclock(ac1) ‘’ NOW=?

9. Problems validating …continued Validation of following systems causes deadlock does not result in signal X being sent –if interactively simulate system, then X sent e.g. NOW takes value of last timer that has fired wait t1 - NOW>=8 X - set(now+9,t1)

10. Conclusions Role played by specification important interactive simulation vs validation (via state space exploration) Often restrictions imposed which are not immediately apparent when specifying As well as language extensions and tool development Interval should (is!) identify these restrictions give guidelines how best to specify/verify such systems –don’t use time stamps accessing NOW –don’t use continuous signals based on NOW –… etc